Building a software factory

Most engineering teams that adopted AI got faster at writing code. The next big gain sits in everything around it: reviewing, testing and handing work from one step to the next.

We are setting up an internal software factory to achieve this: every engineer will lead a team of agents that plans, builds, reviews and tests, and will spend their own time on what to build and whether it is right. Below we share what changed, how the factory will work, what we will measure and where its limits are.

Two things moved at once over the past months. Models got better, so agents can take on bigger pieces of work, and the setup around them matured, which we call the harness: tests they can run alone, review automation that catches their mistakes, and shared skills and checks that every product reuses.

We built that harness across our portfolio first and agents became reliable enough to trust with real work. The next opportunity is how that work moves through a team and automating more and more of the orchestration.

Today the engineer is still in the middle of everything. Take one feature. Once the product brief and architecture are written, it gets split into many small pieces. For each piece, an engineer starts the agent, opens the pull request, reads the review and asks the agent to fix the remarks.

Little of that passing work needs human judgment. Anything agents can do properly should be done by agents, so people get their time back for the work only they can do.

This is the flow we are building towards.

1. A person defines the work. People do the most interesting part: the prototype, the product brief and the architecture.

2. Agents plan and build. Moving a ticket to Ready on the board starts a run. Agents split the feature into small pieces and build them. Later, a failing build or a production error will start a run too.

3. An army of agents reviews. Many specialists each check one risk, such as authorization, failure paths and database concurrency. In the final review of a feature, every possible bug is judged by two agents that cannot see each other's answer, and a third settles any disagreement.

4. More agents test. One tester per affected user flow gets its own browser, signed in as a test user, and clicks through like a real user. Each flow leaves a video as evidence.

5. An engineer signs off and merges. They try a running test version with the test report and videos at hand. Open major findings block the merge and agents cannot merge.

The role of engineer evolves from purely building software towards building and improving the system that builds the software. They sample what agents build, keep the quality bar high and improve the factory as they go. Our skills, rules and checks live in one place, so every improvement helps every product.

We are piloting the first step on one of our own products: agents that build a whole feature from start to finish. This gets better with every run, which is exciting to watch. Next comes the full factory and after that every project.

Our main number will be human minutes per finished feature. Quality has to rise with it, so we will track four more numbers every week: repair rounds per feature, runs where reviewer, tester and engineer disagree, any bugs that reached production, and agent decisions flagged as unsure that turned out wrong.

Those numbers show us when agents are ready for more. We start with a person approving every merge, and hand over more as each product proves itself.

It won't work when the foundations are missing. A codebase without tests or a deployment pipeline needs those first and agents can help with that work too. It also needs a clear goal: a vague requirement just becomes a fast build in the wrong direction. Strategy, product taste and new architecture stay with people.

If you're curious how far this could go for your team, we're happy to walk you through how we approach it.