What It Actually Takes to Build a Software Factory — Tereza Tížková, Factory

Generating code is only one part of delivering software. In Tereza Tížková’s account of Factory, a software factory starts with user feedback and logs, prioritizes what matters, orchestrates implementation, validates the result, tests in production and feeds what it learns into the next iteration. She describes Factory running this approach for enterprises including EY and Adobe. The central requirement is autonomy across that cycle.

The idea of continuously iterating agents predates the systems that could make it useful. Earlier attempts ran into hallucinations, limited context, weak reasoning and a shortage of isolated environments where agents could work. Improvements in those capabilities make the larger loop more practical. Adding thousands of coding agents, however, still leaves prioritization, coordination and verification to be solved. Writing code is the comparatively easy part.

That makes building a factory resemble building a team: workers need responsibilities, permissions, shared knowledge and a way to judge each other’s output. Tížková advocates rebuilding the organization around that work rather than dropping a consultancy’s strategy into its middle. Her three principles give the rest of the talk its structure: remain agnostic about models and existing workflows, support autonomous work with appropriate governance, and keep improving the system’s knowledge and working conditions.

Agnosticism begins with the organization’s existing habits. A factory needs to connect to places such as Slack and GitHub and accommodate subscriptions people already use. Model independence serves the same purpose: new models and benchmarks arrive too quickly to confidently commit the whole system to a permanent winner.

The Coinbase example separates token consumption from money spent. Tížková describes a chart shared by its CEO in which token usage continued growing while spending fell. The measures she highlights address different parts of that equation:

• Change default models. Stop making a frontier model the default for every task.
• Cache repeated context. Avoid repeatedly processing material the system has already seen.
• Require results for large spending. Evaluate what substantial usage produces rather than simply imposing a spending cap.
• Route tasks between models. Match the work to a model with sufficient capability at a lower cost.

Factory’s automatic model routing first chooses a model for the task and can switch if that model struggles or a provider fails. This also creates opportunities to improve speed: Tížková notes that open models can be faster. She reports approximately 25% savings in a Factory benchmark she characterizes as conservative; the supplied account does not specify the workload or comparison conditions, so that figure is an example rather than a general savings guarantee.

Routing starts with the task and the organization’s rules. Different roles—marketing, sales or engineering—can have different permissions and default models. The classifier then examines the prompt’s structure, the codebase, task difficulty and the tools involved. From that assessment, the router sets a capability threshold and chooses the cheapest model predicted to meet it. The useful decision is whether a model can accomplish this particular task.

Misclassification is the hard part. A cheap first choice can become costly if the system repeatedly switches models or has to redo work. Factory therefore aims to classify well enough that switching is uncommon. Tížková suggests that an occasional upgrade can still leave the overall task faster, but presents that as a possibility, not a measured outcome for every routed task.

Caching raises a separate question: who receives the savings? Reusing context avoids repeated prefill, the work of processing input context before generating a response. Hosted open models on dedicated compute can also use caching. Tížková distinguishes that technical capability from the price charged to users: the discount passed through depends on pricing decisions and agreements with API providers.

Autonomy turns the discussion from model selection to stopping conditions. Repeated execution and task decomposition are familiar ideas; the difficult question is how the system recognizes completion. A colleague’s agent loop for 3D-printing the Factory logo makes this concrete. A task that produces a physical object reaches beyond a simple programming loop with an explicit termination condition. Its intended result must still be verifiable.

Longer autonomous runs do not by themselves establish production reliability. The system may still need iteration and feedback. Worse, an incorrectly defined completion test gives an agent the wrong target: it can optimize for passing the check while leaving the intended task unfinished. Tížková calls this cheating. The problem lies in the gap between the test’s condition and the result the user actually needs.

Factory Missions organize long-running work around an orchestrator, workers and validators. The orchestrator decides what must be done and writes completion conditions. Workers implement the task; validators review the output and return feedback into the loop. Tížková reports Missions running for weeks and gives a customer example lasting 16 hours, with validation taking 40% of the process. These are reported run characteristics, not evidence that every Mission completes reliably.

The main workers run in sequence. Each accomplishes something and passes the work to the next, giving the next worker fresh context—a fresh head, in the human-team analogy. Parallelism remains available inside a worker’s assignment: subagents can research or build files while that worker proceeds. The architecture therefore combines sequential handoffs for the main task with smaller concurrent jobs within each stage.

Who judges completion, and how does feedback reach the next attempt? The diagram follows the handoffs. A validation contract is written before implementation, and validators judge code they did not write. That separates the original requirements, the act of building and the decision about whether the result satisfies those requirements.

Two validators inspect different kinds of failure:

• Scrutiny validator. Checks the codebase through linting, types and tests.
• User-testing validator. Operates a virtual computer, clicks through the application and checks whether its behavior works, without relying on how the implementation was produced.

The migration example shows why that second check matters. An engineer migrating codebases with Factory’s agent needed it to click through the result. Other products had produced something that looked like a finished application but was not interactive—a dummy result. Moving from generated code to an agent operating the application changed what could be observed: clicks could reveal whether the interface actually responded. Tížková describes that check as confirming working behavior, although she does not detail the migration’s individual interactions or fixes.

Computer use and persistent virtual environments make that behavioral inspection possible. The resulting Mission is a loop containing smaller loops: individual agents iterate on their assignments while the overall system iterates on implementation and validation. The nesting matters because progress within one worker is still subject to a separate judgment about the finished product.

Long Missions create a context problem. Enterprise tools such as Figma, Notion, Gmail, Drive and Slack bring schemas, parameters and descriptions with them. Loading all that material can crowd the context window, force compression and make similarly named tools harder to distinguish. More available integrations can therefore make the agent less effective if their full specifications are always present.

Factory’s deferred context engine progressively discloses tool information. Initially, the agent gets a short list with short descriptions. When it needs a tool, it can load the full details. Nothing is deleted; information waits outside the active context until it is useful. Tížková reports token savings of 50% or more as tool usage scales, without specifying benchmark conditions. The mechanism saves tokens by avoiding upfront detail for tools the task may never use.

What changes in the context when a tool becomes necessary? The flow below separates discovery from full loading. Short descriptions let the agent identify a candidate; the full specification enters only at the point of need. The remaining tool details stay available for later work without occupying the current context.

Continuous improvement also depends on what the agents inherit. Tížková describes AI adoption as having a power-law shape: teams can succeed dramatically or make an unprepared codebase worse. Her practical warning is that poorly structured, poorly documented code gives agents conditions in which mistakes can compound. The talk does not establish a measured distribution; the useful claim is that adoption alone does not ensure productivity.

Factory’s agent-readiness approach is a codebase hygiene check. Its factors are familiar engineering practices:

• Reproducible environments. Can the developer environment be recreated consistently?
• Tests and automated checks. Are useful tests, type checks and linters in place?
• Documentation and conventions. Are the code’s structure and expected style written down?

Larger customers go through the checks and receive recommended actions to address the problems they reveal.

Some essential context never reaches the documentation. New employees learn unwritten rules by observing colleagues; agents instead often need the same preferences explained repeatedly. Factory’s plugins package reusable skills and context so teams can codify some of that knowledge. Reviewing and updating documentation supports the same goal: make learned practices available to subsequent work rather than forcing every session to rediscover them.

The ending turns from agent architecture to human work. Tížková’s optimistic forecast follows earlier changes in abstraction: human computers performed detailed calculations, programming languages codified work, and coding agents took on implementation while people closely supervised them. Software factories extend that progression to structured teams of orchestrators, workers and validators. Humans monitor those teams and decide what to build. This is her proposed direction for work, rather than an established outcome for employment.

That division of labor includes more than writing code. Enterprise work consumes time in alignment meetings, collecting context from colleagues, sharing status and synchronizing plans. Those are candidates for the factory too. The promise is to give people more room for product decisions and the work they find interesting, while agents handle implementation and some of the coordination around it. The closing invitation has the same practical optimism: go touch some grass and let the agents build.