Why I am building a custom software factory in 2026

Introduction

I am a software and product engineer. I am also a mother of 4 humans (and 5 cats), which makes me obsessed with organisation, workflows, automations and time optimisation. The story below is how those two facts took me from an AI assistant in my IDE to building a software factory I can hand a feature (or a batch of fixes and improvements) to, and walk away from.

As I state on my home page: I used to write code. Now I build the systems that write it. This post is why and how it happened, and where I stand in September 2026. How the factory works will be the subject of a next post.

The short version, before the long one:

timeline
    title From ChatGPT to a software factory
    2022 : ChatGPT in a browser tab
    2023 : Copilot Pro in the IDE
    2024 : Copilot Pro+, delivering more
    2025 : Spec Kit, specs before code
         : Unit tests as a quality gate
         : Training 1, TDD, BDD and clean architecture, React
    2026 : Training 2, with Claude Code, Python
         : BDD, TDD, clean architecture on every project
         : Experimenting autonomous agents with Claude, Ollama and OpenClaw, Langfuse for traces
         : Custom orchestrator as software factory, full epic and stories development

2023 to 2025: Copilot, then Spec Kit

Before Copilot, there was ChatGPT in a browser tab. I started my journey with Copilot Pro in 2023, because it was easy to start with in my IDE. As I started delivering more, I moved to Pro+ at the end of 2024.

In 2025 I started adding structure to my AI development process:

• Spec Kit, to define specifications before development.
• Unit tests in my products, as a quality gate for AI-driven development.

I built multiple features on different projects this way, leveraging Copilot’s cloud features to scale my processes and developments. Results were not always as expected, but they got better with prompting techniques along with the progress of the AI models. What I understood in this period was the importance of artifact creation for a development in multiple stages with closed context.

This methodology stopped being enough for big features, requiring back-end and front-end development with planning. I was missing a more complete specification process, to define the features with software design best practices. This gap pushed me to investigate different techniques, and led me to a training.

Training on clean code and TDD

I followed two trainings on TDD/BDD/clean architecture practices with Michaël Azerhad at Wealcome, the first one in 2025 for front-end projects with React, then a second one in 2026 for backend with Python. The last one was completely with AI (Claude Code harness) and it opened my mind to another level of AI coding with high quality standards.

Three main things I now implement on every project I build:

1. Behaviour-Driven Development, for clear user story and scenario specifications.
2. Test-Driven Development, for testing the code based on those scenarios.
3. Clean architecture guidelines, for a structured repository.

June 2026: Copilot changed its pricing, so I changed tools

In June 2026 Copilot changed its pricing and added limitations on model usage quotas. Tokens became (sadly) too expensive for my side projects. So I stopped, and switched to Claude and to other open-source models, with Ollama and OpenClaw.

While experimenting with OpenClaw, I quickly (and painfully) understood the need for budget control, monitoring and observability tools, to understand what happens behind the harnesses.

The agent that burned tokens in silence

The painful part was a persona setup I was testing: an architect, a planner, a developer and a tester, running through OpenClaw with Mattermost chat bots. I would launch an issue for planning or development and the agent would get stuck. No feedback in the chat, no response, and tokens being consumed without knowing what was happening behind.

I needed a monitoring tool, so I went with Langfuse. The traces showed the agent looping on a tool access it did not know how to run. I also struggled with the orchestration of the agents, and found myself babysitting them a lot, asking “how’s your progress” constantly. Even though the results were good (the features developed were working, the clean architecture layers respected), this setup was not sustainable for scaling to a fully autonomous development process.

Some of the problems I caught with Langfuse:

• Processes blocked or looping on tool errors.
• Instructions not followed correctly.
• Agents looping on environment issues, and failing to fix them.

What I understood from this: the prompt needs to be adapted with the right set of skills, so the agent knows how to execute its tools. Fine-tuning the harness and its tooling, the model and its parameters, is key to good results, especially with open-source models.

So I started building my own

After many experiments and multiple side projects with these workflows, I started building my own orchestration system, leveraging the BMAD methodology for spec-driven pipelines. This is the general system as it runs today:

The spec definition happens before the orchestrator, with the BMAD method: specs, architecture, planning and stories are written with AI, and validated by a human. What comes out is epics and stories, following the well known agile development process. Those go into the orchestrator.

The orchestrator is a simple Python API. For every story, it runs the same loop:

1. Story context.
2. Development agent: a BMAD dev agent in auto mode, in a harness running in non-interactive mode through its SDK, in its own session for the story. The harnesses run in a model-agnostic setup through LiteLLM. When the agent needs a validation or a clarification, the story goes to the human gate.
3. Deterministic checks: linter, unit tests, e2e tests.
4. On pass, the next story. On failure, a dev agent fixes the working branch and the checks run again. After N failures, the story stops at the human gate.

When there are no more stories, the deterministic checks run once more on the whole branch, and the orchestrator opens a pull request. The pull request goes through the CI/CD workflow and then to the human gate.

This setup allows me to be in control at all times, and more importantly trace back to agent sessions for every story, if necessary.

As mentioned in the polyglot programmer post, after some experiments I observed that for open-source, an orchestration of the pipeline is the key to good results. Deterministic checks and configuration allow agents to have a clean environment to start working on.

Where I stand in September 2026

AI coding tools are becoming good enough that the bottleneck is no longer code generation. The bottleneck is now orchestration, quality control, cost, observability, and knowing when a human needs to intervene.

Frontier models, with high reasoning and large context, are capable of orchestrating agents in an efficient way within their harnesses, through loops for instance. Nevertheless, this can consume a lot of tokens and become costly, since the context can grow exponentially.

I find the custom orchestration useful for four main things:

• Token cost optimisation.
• Model flexibility (do not depend on a provider).
• Closed development environment for agents, for security (agents will not access what they should not).
• A human gate at every step of the development process (only when necessary).

I’m in control of what is developed in the specification writing and architecture decisions and the final testing and validation, in between the pipeline handles the code writing so that I am only called when a human decision is needed.

I used to write code… Now I build the systems that write it.