ARTICLE
Your Software Factory: Dream Factory or Treadmill?

Patrick Debois

Your agents ship more code each week. Yet the same questions return in Slack, the migration never quite finishes, and every new engineer discovers the same gaps in the setup guide. The factory is busy. You are still running to keep up.
Most conversations about software factories follow the path from intent to code, review, and release. There is plenty to improve there. But for engineering leaders, another question deserves attention: what does each trip around the loop leave behind? Some loops keep the work moving. Some make the next round easier. Others let you attempt something you have been putting off.
The treadmill loop: keep today's work moving
A dependency changes, so you update the integration. A release ships, so you refresh the documentation and the slides used to explain it. Someone asks how a service works, so you track down the answer. These are useful activities. A treadmill loop handles the immediate need, but leaves the next person with much the same investigation to do.
AI can make these rounds faster. Glean's Huntress case study describes separate agents for creating slide decks and summarizing shipped engineering work for other teams. Those are relatable gains: fewer hours assembling updates, more time to use them. They do not, by themselves, establish that existing decks stay accurate or that people understand how a change affects their work. Huntress case study
Keeping everyone in the loop belongs here too. A change needs to reach the people whose plans depend on it; their questions may reveal a missed dependency and send the plan back for revision. The useful result is coordinated work. If the factory only produces more updates for people to interpret, it can make the treadmill run faster without helping anyone keep up.
The learning loop: make the next round easier
An engineer answers a difficult setup question. A learning loop captures what was missing, updates the setup guide, and checks whether the next person can get through without the same intervention. Intercom demonstrates a related mechanism in support: it compares unsuccessful AI responses with successful human replies and recommends additions or corrections to shared knowledge. Applied to engineering, the value is that one person's investigation becomes useful to the next person. Intercom's knowledge recommendations
A large refactor offers another example. The first service reveals an undocumented convention; the second exposes an exception. Feed those discoveries into the migration instructions before starting the next batch. Augment describes this approach through migration playbooks that incorporate feedback from successive waves. The context that matters is specific: what changed, why an earlier attempt failed, and where the exception applies. Augment's migration approach
The same principle applies to agents. Tessl's agent-retro procedure uses earlier transcripts and review feedback to propose changes for future attempts. But a longer instruction file is only a record until the advice helps on another task. The test of a learning loop is visible in later work: fewer repeated investigations, fewer avoidable dead ends, or a migration batch that benefits from the previous one.
The dream loop: make room for work you keep putting off
Every team has a list of things it would like to try. Could we simplify this service? Replace the awkward library? Give developers a setup that takes minutes? Usually there is a plausible idea and too little time to investigate it properly. A dream loop takes one of those possibilities, tries a small version, examines the result, and uses what it learns to choose the next attempt.
Consider a service everyone wants to simplify. Give an agent the current design, its constraints, the reasons for past decisions, and the approaches already rejected. It can help build a limited alternative and compare it with the current implementation. That experiment may uncover a better approach, or explain why the existing complexity is still necessary. DeepMind's AlphaEvolve demonstrates iterative exploration for automatically evaluable algorithms: candidate programs and their results inform further candidates. Applying the idea to a service redesign requires broader engineering judgment, but the ambition is familiar: investigate more than the first workable option. AlphaEvolve
Learning loops improve how you pursue a goal. Dream loops expand what you can realistically attempt. For most teams, that need not mean inventing a new product. It might mean finally testing an alternative architecture or making progress on a refactor that has survived six planning cycles. Generating suggestions is the easy part. The loop needs an experiment whose outcome changes what you try next, including the decision to stop.
Why these loops were hard to sustain
We could do all of this before AI. Good teams documented answers, improved migration playbooks, and built exploratory prototypes. The recurring effort was reconstructing the situation: reading old discussions, finding the relevant code, understanding exceptions, and deciding which lead to follow. Scripts handled predictable steps well. The investigation between those steps often needed someone who knew the system and had time to dig.
AI can help with that variable work, provided it has useful context and tools to test its conclusions. An old design decision can explain why an obvious simplification failed. A successful support conversation can supply the missing detail in a guide. Results from a previous attempt can change the next experiment. This is where context earns its keep. The benefit disappears if a colleague must repeat the whole investigation to trust the result. Building effective agents
Choose what the next round makes possible
These are three ways to use a factory, and a team needs all three. Keep the documentation current. Let repeated questions improve it. Then use the understanding you have accumulated to try making the setup itself simpler. The work moves from keeping up, to getting better, to attempting something that previously stayed on the wishlist.
When you add another loop, ask what will be different after it runs. Will today's work be done? Will tomorrow's work be easier? Will an idea you have kept postponing finally get a fair trial?
Build a factory that gives you fewer things to repeat and more things worth trying.
COPY & SHARE

Patrick Debois
Patrick is a pioneer, credited with coining the term DevOps, co-authoring the DevOps Handbook, and launching the very first DevOpsDays back in 2009. Since then, he’s been shaping the tech industry and brings depth across development, security, operations, and GenAI.
READING
·
0%
COPY & SHARE

Patrick Debois
Patrick is a pioneer, credited with coining the term DevOps, co-authoring the DevOps Handbook, and launching the very first DevOpsDays back in 2009. Since then, he’s been shaping the tech industry and brings depth across development, security, operations, and GenAI.
YOUR NEXT READ
Who owns the cost of the AI software factory?
The article explores managing AI software factory costs, emphasizing visibility, ownership, and accountability to optimize budgets and improve workflow efficiency.

Patrick Debois



