What It Actually Takes to Build a Software Factory — Tereza Tížková, Factory
Tereza Tížková of Factory explains what a software factory really is: an autonomous, end-to-end software lifecycle that goes far beyond coding agents. She covers three guiding principles of agnosticism, autonomy, and continuous improvement, including automatic model routing, long-running multi-agent missions with sequential workers and independent validators, a deferred context engine, and agent readiness checks, and closes with a view on what remains for humans.
Tereza Tížková of Factory opens with a gap she sees between talk and practice: everyone is discussing software factories, but few teams are building one, and even fewer understand what it takes. She argues that the technology has finally caught up enough to run software factories in production for enterprises such as EY and Adobe.
What a software factory is
Her definition goes well beyond code generation. A software factory is the full software lifecycle run with autonomy: collecting signals, reacting to user feedback and logs, prioritizing what matters, orchestrating work, executing, validating, testing in production, and iterating while continuously improving and accumulating new knowledge and skills. She uses Factory’s own dashboard to show a system that covers this whole loop.
She is equally clear about what a software factory is not. It is not just a coding agent, and it is not a swarm of thousands of coding agents, because writing code is the easy part. Engineers spend most of their time on everything around the code. It is also not a consultancy engagement or an abstract strategy deck that someone sells to an organization. Her position is that an organization has to rebuild itself from the ground up to become a software factory, since you cannot bring in a consultancy and drop something into the middle of an existing organization.
Why it wasn’t possible before
She traces the idea back to the early generative AI wave. Projects like AutoGPT and BabyAGI already had the continuous loop of iterating on software, but they failed in practice. LLMs hallucinated, context windows were limited, reasoning quality was weak, and there were no good isolated environments where agents could work safely. Recent progress has made the paradigm viable and useful.
The three principles
Her framework has three principles, and she frames them through the lens of managing a human engineering team.
The first is to stay agnostic. A software factory should fit how teams already work, integrating with Slack, GitHub, and the rest of the stack, and it should let people bring the subscriptions they already use. The frontier landscape changes constantly, and she says it is hard to predict which models will win, so the system should not be locked to one vendor.
She then turns to model agnosticism, citing a chart shared by Coinbase’s CEO. Token spend kept growing, but the organization stopped its overall AI spending from climbing as fast. The tactics were not cutting usage. They included setting different default models for different people instead of pushing the frontier model everywhere, adding caching, and putting spending limits in place while requiring visibility into the results.
Routing is the central tactic. Factory’s automatic model routing first decides which model is most optimal for a task, then switches models if a task is failing. She stresses that the benefit is not only cost. Open-source models are often faster, and if one provider goes down, the system can fail over to another automatically. Factory’s deliberately conservative benchmark shows about 25% savings, and she suspects the real figure is higher.
She breaks routing into four parts. First, tasks are assigned, and organizations can set permissions and default models per role, such as marketing, sales, or engineering. Second, and most importantly, the system classifies task difficulty by analyzing the prompt structure, the codebase, the tools involved, and other factors. Third, it applies a threshold for what is sufficient to accomplish the task. Finally, it picks the cheapest model above that threshold. She admits that a good classifier is hard to build. The goal is to avoid switching too often, and even moving mid-task from an easier model to a harder one can still make the overall run faster.
On caching, she notes that LLM labs save a great deal by caching and skipping context prefill, and that open models hosted on dedicated compute can capture the same advantage. Passing those savings on to users is a pricing and vendor-deal decision rather than a technical limitation.
The second principle is to stay autonomous. She observes that loops have existed in programming for a long time and are now moving into agent workflows, as with the Ralph loop and recursive task decomposition. The hard question is not the loop itself but how to define “done”. In traditional programming, completion criteria are clear. With agents working on open-world, nondeterministic tasks, such as a colleague’s loop that had agents building a 3D print of the company logo, the criteria become open-ended and must be made verifiable. She presents a chart showing that the length of autonomous runs has been growing, but reliability has not kept pace. A poorly written definition of done invites cheating, where an agent optimizes to pass the tests rather than to accomplish what was intended.
Factory Missions address this with long-running sessions that can last hours or even weeks. An orchestrator sets the conditions for completion, workers execute the tasks, and validators review the results. She cites a real 16-hour customer mission in which validation accounted for as much as 40% of the total process. Workers run in sequence rather than in a swarm. Each one starts with fresh context and passes its output to the next, much as a human benefits from a colleague reviewing their code. Each worker can spawn parallel sub-agents for tasks such as web research or file generation. Validators judge code they did not write, against a validation contract written by the orchestrator before any code is produced. She describes two kinds of validators. The scrutiny validator is rigorous static checking: linters, types, and tests. The user-testing validator operates the application in a virtual computer and clicks through it, caring only whether the product actually works. She illustrates this with an engineer migrating codebases using Droid, where the initial output looked like a finished product but was essentially a non-interactive dummy. Only an agent that actually clicked through the app could catch that. She credits advances in computer use and persistent VM environments for making this possible. Her summary of the architecture is loops nested inside loops, with each agent running its own small loop inside one large overall loop.
The third principle is to keep improving. The central problem is context. Enterprises often use hundreds of tools, including Figma, Notion, Gmail, Drive, and Slack, and each comes with schemas, parameters, and descriptions. Loading all of that bloats the agent’s context, causes it to pick the wrong tool when two sound similar, and forces compression that loses information. Factory’s answer is a deferred context engine. It progressively discloses tools, presenting a short list with brief descriptions and loading the full definition only when the agent actually needs it. Nothing is removed, only hidden until required. She reports that the savings scale with the number of tools, reaching 50% or more of tokens.
She also emphasizes that AI adoption follows a power law, where organizations either succeed big or fail big. An unstructured codebase can turn AI adoption into a degradation process, and she cites Stanford research suggesting that poorly documented, unstructured code can make AI output worse. To address this, Factory offers what she calls agent readiness. She dislikes the word framework and prefers to describe it as a hygiene check. It covers how reproducible the developer environment is, whether tests are good, whether the code is well documented, and whether style, linters, and other standards are enforced. Customers who run the check receive recommended actions, and the readiness score correlates with how productively they can adopt AI.
Her last point on improvement concerns unwritten team knowledge. People repeatedly tell agents how they want things done, and agents do not seem to absorb the implicit rules, just as a new hire learns the culture by observation. Factory’s response is plugins: packaged, reusable skills and context that codify this knowledge, along with automatic documentation updates and reviews.
What happens to humans
Asked whether engineers will lose their jobs, she is optimistic. She places the change in a historical sequence, starting with humans as computers doing the most detailed work by hand, then moving to programming languages that abstracted that work, then to coding agents, and now to managing structured teams of orchestrators, workers, and validators. Humans will decide what to build, not how to build it. She also argues that AI will take the most annoying part of organizational life: alignment meetings, status syncs, and the effort of gathering context that lives between the lines. She closes with a playful call to action: go touch some grass and let your agents build for you.