A software factory is an agentic system where agents create the product shipped to users while engineers build and improve the system that produces it.
2
Harness engineering builds inner, outer, and meta loops that improve agent autonomy, reduce human review, and raise product quality.
3
Teams can start by making agent work legible, preparing their stack for agents, and turning repeated workflows into automated improvement loops.
Summary
Dru Knox defines a software factory as an agentic system where agents create the end product and engineers build the factory around them. He measures progress through autonomy, automation, and quality. Autonomy tracks how often humans must correct an agent, while automation tracks how much work can run without direct review. Knox argues that the long-term benefit is higher quality, because teams gain time for test improvements, refactoring, and exploration. Harness engineering is the discipline behind this system. It uses inner loops during coding, outer loops around pull requests, and meta loops that learn from logs, issues, pull requests, and user feedback. Knox then describes three layers: a control plane, an agent-ready technical stack, and improvement loops. Tessl supports these layers with a skills registry, Tessl Agent, and Tessl Launch, while Knox says the underlying techniques can work with any stack.
A software factory has agents produce the product while engineers build the production system
Knox defines a software factory as an agentic system where the complete product shipped to users is created by agents. The engineering team focuses on the factory itself, making it more autonomous, more automated, and better at producing software. This changes the team's work. Engineers become internal tool builders who improve the system used by everyone else to push features to users. Knox does not present a strict industry definition, since the terminology is changing quickly. He uses the idea to describe a target state for teams that already have coding agents handling easy and medium-complexity tasks.
Autonomy and automation measure different kinds of human involvement
Knox separates autonomy from automation. Autonomy measures how much humans must correct an agent or nudge it toward the right result. Automation measures how much work can run without human review or direct verification. An agent can have high autonomy because it often gets tasks right on its first attempt, while the team still has low automation because it does not yet trust the results. Knox says teams should improve autonomy first, then increase automation, while keeping quality constant. Quality includes the product users receive, along with measures such as user analytics, test quality, and test coverage.
The long-term payoff of a factory is more quality work, not only faster delivery
Knox says teams often justify software factories through higher feature velocity, even if the output contains some slop. He sees that as a short-term view. Teams already have backlogs of bug fixes, test improvements, architectural refactors, and explorations that they cannot fit into their schedules. A factory gives them more capacity to do this work because the backlog can shrink. Knox expects teams to keep quality constant, or accept only a small dip, during the transition. After that, the factory should raise the quality of the code. He also says people outside engineering can contribute ideas more easily when engineers focus on the underlying system.
The three loops place automation at different points in development
The inner loop runs while an agent is working on a pull request, before the pull request is opened. These checks need to be cheap and fast because the agent will run them repeatedly. They improve autonomy by catching problems and correcting the agent without human intervention. The outer loop starts when the pull request is opened. It can run more expensive checks, such as agentic QA or mutation testing, that would be wasteful during every iteration. These checks reduce the human review needed to trust the change. The meta loop sits outside development. It studies agent logs, pull requests, issue trackers, and user feedback, then sends lessons back into the inner and outer loops.
Harness engineering is difficult because the work changes, arrives unexpectedly, and lacks shared signals
Knox gives three reasons why unassisted harness engineering is hard. First, the discipline changes so quickly that teams may need to read papers, follow blogs, and revise practices every week. Techniques can become outdated or turn into anti-patterns soon after they appear. Second, the work is unplanned. Teams do not know in advance how an agent will fail or how long the fix will take, so improvement work competes with feature deadlines. Avoiding it leaves the agent stuck, while doing it can delay shipping. Third, useful evidence is often trapped in local agent logs, on individual machines, or in people's heads. Teams need to move work onto shared surfaces where later improvement loops can inspect it.
A control plane makes agent work visible and reviewable
The first layer is a control plane that makes the team's interactions with agents legible. In Knox's Tessl example, every task starts as an issue, goes to a headless agent in a sandbox, produces a pull request, and receives engineering feedback through pull request comments. This still allows manual correction, but the touch points are saved where tools can inspect them later. Knox describes three common control-plane parts: a way to track issues and start agent work, a review system such as GitHub pull requests, and a way to distribute shared workflows or skills. A skills registry or shared GitHub repository can hold practices that improve agent output.
An agent-ready stack exposes the services and environments that agents need
Making a stack agent-ready requires more than giving an agent access to the code repository. Knox compares it to moving a project with local configuration to a clean setup and discovering hidden dependencies. Teams may need to provide command-line and API access, a way for an agent to click through the product, access to internal services, and access to production logs. Those choices raise governance and compliance questions. The company also has to document how work gets done and provide an environment where the agent can execute code. Knox says the work is difficult to plan in advance because each company discovers different missing pieces while trying to let agents create pull requests without human intervention.
Improvement loops turn repeated mistakes and maintenance work into shared automation
Knox expects teams to spend much of their time on improvement loops. These include scheduled repository maintenance, playbooks for common development tasks, automation for repeated work, and regular checks of output quality. When an agent makes a mistake, the team can update the skill or playbook for that workflow so the same error is less likely to recur. Tessl's approach is to make these changes incremental. Its skills registry can store versioned workflows with governance, while Tessl Agent can find repeated work in pull requests and issues. Tessl Launch can turn a skill into an automated workflow run by a selected coding agent inside a sandbox.
Progress toward a factory can be tracked through human intervention and quality
Knox names practical measures for tracking progress. Teams should drive down manual takeovers and the number of human comments needed on pull requests. They should also watch for more pull requests being initiated without human input, which indicates growing automation. Quality remains a separate requirement. Knox says teams should first hold quality constant while increasing autonomy and automation, then aim to raise quality after the system has matured. These measures connect the factory idea to observable workflow changes rather than treating it as a label for using coding agents.
"A software factory is any agentic system where all of the end product of what you're building and shipping to users is created by agents and your software engineering teams effectively focus on building the factory."02:17
Who should watch
You already use coding agents for easy or medium-complexity tasks and want to move toward unattended workflows.
Your team spends time correcting agents, reviewing their pull requests, or repeating the same maintenance tasks.
You need a practical structure for exposing internal systems to agents and learning from their failures.
