The software factory has moved from a metaphor to something teams are actively trying to build, and the gap between the companies talking about one and the companies running one is now mostly a gap in preparation. The appealing version skips straight to fleets of agents producing code. The version that holds up starts somewhere far less exciting.

Dru Knox, Head of Product at Tessl, has been building both sides of this: the platform other companies use to get there, and Tessl's own internal factory, which recently peaked at around 850 pull requests in a single week with 85 to 90% of them handled by agents end to end. Speaking with Guy Podjarny on the AI Native Dev podcast, he walked through what that took and, more usefully, what it punished.

From Skills to Loops to a Software Factory

To make sense of the journey, it can be helpful to plot it as three stages rather than one transition, because each stage fails differently.

A software factory is a way of working, not a tool you install. It is the point at which almost all of a team's development has moved to creating, maintaining and monitoring loops, and those loops produce most of the software. Humans spend their time on the loops rather than on the product code.

The first stage is skills: writing down what good looks like, how code review should function, what changes between the CLI and the UI. The second is loops, which Knox described as effectively automated skills, running without immediate human intervention and carrying some meta process that improves them as they go. That improvement is the whole point. "You start to see agents sort of inflecting your productivity upwards faster than just linear," he noted, which is the first moment the curve stops looking like a headcount multiplier.

The third stage arrives on its own. Knox was clear that factory building is a continuum rather than a destination: you keep working on loops until so much of your work is maintaining loops and building loops to observe them that you are already in a factory. Tessl's own transition happened faster than planned. Within weeks of the first loops landing, Knox observed that "this is going to get out of hand really quickly," which forced the move to a different way of working.

Why Context Engineering Has to Come First

The most transferable part of the conversation was the failure mode Knox sees most often, and it has nothing to do with agent capability.

Adopting agentic code review is trivially easy. Install a GitHub app, click a few buttons, and agents are reviewing pull requests within the hour. Knox called it a dopamine hit, and noted how familiar the pattern is: "As is so often the case with AI, it's so easy to get to that first demo or that first wow moment. How do you scale it from there?" A couple of weeks later the honest answer for most teams is that a few more bugs get caught, merges are slightly faster, and nothing else has changed.

His diagnosis is that the wall is self-inflicted. "You tried to get to the big muscles without working out, or you tried to get healthy without eating your vegetables," he argued. A tool that promises to handle review on your behalf never requires you to articulate what quality means in your code base, which means there is no artifact to reuse. Nothing to load into the agent while it builds the feature. Nothing to sweep the repository with next month. Nothing to hand a new prototype in a different repo on day one.

Written-down context also gets sharper in a way that opaque tooling cannot. Standards can specialise by area, so a front end review can care about ARIA attributes, accessibility and border nesting while a back end pull request ignores all of it and spends its tokens on brittleness instead. That specificity appears to matter more than model choice: Knox's summary was that specificity is the ruler of all quality, and that a very specific instruction will beat a generic prompt about code smells every time.

Enforcement is the half most teams miss. As Knox put it, "yes, I wrote it down, but agents don't have to follow markdown," which is the reasoning behind Tessl's verifiers: small, cheap, narrowly scoped LLM-as-judge checks generated from a skill and fast enough to run in CI.

The Gains Nobody Forecasts

Most teams pursue a factory for throughput. Knox said the two effects that actually surprised him were different.

The first was quality. Extra agent capacity does not all get pointed at new features. One member of his design team landed 13 pull requests covering consistency, copy, brand voice and stray borders, the kind of work that ordinarily lingers on a backlog indefinitely. The second was fungibility, which Knox conceded is a boring business word for something genuinely useful: designers merging code, the go-to-market team editing the marketing site without waiting on engineering, engineers writing their own specs. Work goes to whoever finds it high leverage rather than to whoever has the right skills free.

Podjarny added a third, drawn from his security background. Moving work into defined cloud workflows produces visibility as a side effect. You can see what is installed, identify risks and contain them, and observe the system end to end, which is not usually true of a dozen developers each automating their own machine in isolation.

Where Factory Building Goes Next

Knox was candid that Tessl's factory componentry is still relatively light, and deliberately so, since much of it emerges from working alongside customers attempting the same thing. The conviction underneath it is that a factory is something a company should own, because it encodes that company's definition of correct software. Owning it does not mean building every part of it, which is where the tooling layer earns its place: scheduling, access control, observability, dashboards, and everything to do with capturing and assessing context.

The prediction worth sitting with is a plurality of factories. Not one per company, but one per repository, business unit or segment, each with its own standards. If that holds, the durable skill is not operating a factory someone else designed. It is being able to say precisely what correct looks like in your corner of the code base, in a form something else can act on.

Where did your own automation stop compounding?