What Will Larson's "Software Factory" Actually Proves

Will Larson published something last week that’s been doing the rounds in engineering leadership circles: a write-up of what he’s calling the “software factory pattern,” an experiment he’s running at Imprint, the fintech company where he’s CTO. I think most people are reading it slightly wrong, including some of the people criticising it.

Will Larson’s “Trying the Software Factory Pattern”

The idea, in Will Larson’s own words, is “looping on a broad goal, and then relying on the harness to drive progress towards that goal.” In practice that means a slash command called /linear-project-loop that runs four steps on repeat: audit the project’s goals against an RFC in Notion and a Datadog or Snowflake dashboard tracking progress; assess the current metrics and issue list and add or update work items; execute the next unblocked task, usually a pull request; then iterate, moving to the next item or rerunning the whole loop if the project description’s gone stale.

What struck me reading it wasn’t the AI part. It was everything the AI part depends on. Will Larson is explicit that the pattern only works because Linear is already the single source of truth for work at Imprint, because projects already have an RFC describing their goals, and because there’s already a Datadog or Snowflake query tracking whether the work is moving the number it’s meant to move. He says outright that these pieces compound only to the extent you have the other pieces. If you take any one away, then the loop has nothing to check itself against.

I think that’s the most important point in the whole piece.

Hacker News Pushed Back

The Hacker News thread on Will Larson’s post is sceptical, and the scepticism is mostly fair: nobody’s shown a shippable, economically viable result yet, one commenter asks pointedly whether anyone’s gained market share over a competitor who isn’t doing any of this, and more than one person points out that the software factory “gets exponentially nastier the longer it runs without someone reshaping it.” All fair points. But most of that criticism is aimed at the AI agents, when the actual dependency sits upstream of the agents entirely. A team without a real RFC process, without a shared source of truth for its backlog, without dashboards anyone trusts, can’t run this loop badly. It can’t run it at all. The AI doesn’t create the discipline; it just makes the absence of that discipline show up faster and more expensively.

The DORA ROI Report Reached Similar Conclusions

DORA’s “ROI of AI-assisted Software Development” report, published this year by Nathen Harvey (see also InfoQ’s write-up), makes almost exactly the same argument from the other direction. Its headline line is that “the greatest returns on AI investment come not from the tools themselves but from a strategic focus on the underlying organizational system.” In its modelled scenario for a 500-person engineering organisation, first-year ROI comes out at 39% against an $8.4m investment, rising to an average of 727% over three years, which sounds like a strong case for going all in. But the report also models what it calls an instability tax: change failure rate rising from 5% to 6% as AI-generated code ships faster than the organisation’s testing and review processes can absorb it, worth negative $344,000 in its own model. AI raised output. The organisational system around it didn’t keep pace, and the model charges for that gap directly.

If you compare Will Larson’s argument with DORA’s, you get one argument instead of two: AI is an amplifier, and it amplifies whatever’s already there, good or missing. A team with clean backlogs, honest metrics and a working review culture gets something close to Will Larson’s result, a genuinely useful loop that mostly stays out of its own way. A team without those things gets DORA’s instability tax: more code, more incidents, no faster.

Why This Matters

This is where I think a lot of engineering leaders are going to get the next eighteen months wrong. It’s tempting to read Will Larson’s post as a tooling decision: buy the orchestration platform, wire up the agent fleet, watch the pull requests appear. I think it’s actually a test of whether you already have the unglamorous agile basics in place: a single place work actually lives, goals written down somewhere real rather than implied in a stand-up, and a metric someone actually looks at before deciding a project’s done. Those are the same three things good agile coaches have been nagging teams about for two decades, and for just as long they’ve been treated as optional, the bit you get to once the “real work” is out of the way.

If you’re an engineering leader who is trying to decide whether to run something like Will Larson’s loop, I think the first question isn’t which platform to buy. It’s whether your teams could pass Will Larson’s own test today, on a Tuesday, with no notice: pick any live project and ask whether there’s a written goal, a dashboard that tracks it, and a single place where the work lives. A lot of organisations I’ve seen would fail that test long before an AI agent ever got involved.

#Agile#Software Engineering#AI

Read Next

Fix the Factory First

David Heinemeier Hansson stood up at Rails World last week and told a room full of programmers that he's retired. Not from 37signals, the company he still runs. From programming itself. "I spent a quarter of a damn century chiseling code by hand and loving every moment of it," he said, "and this is something to look back upon with joy and accept that it is over." As Gergely Orosz reported in [The Pragmatic Engineer](https://newsletter.pragmaticengineer.com/p/the-pulse-end-of-coding-by-hand), the internet did what the internet does with a line like that: it took the seven words that fit in a headline and ran with them, past the part of the same keynote that actually matters for anyone leading a team through this.

Creating a Team Charter

Having your team all working towards a common set of goals is extremely important. However, as leaders and managers we can sometimes get far too hung up on what needs to be delivered and forget about who is actually doing the work. Forgetting about the people and focusing only on delivery goals may get you to one particular deadline but failing to build the team effectively and align them around a common set of principles will rapidly cause longer term problems. A team charter can help prevent this.