The AI Factory has No Design Department
#056: The Agile Manifesto was written without a designer in the room, and we spent 25 years retrofitting ourselves into the result. It's happening again with AI.
BCG Platinion published a model this year for something it calls the agentic software factory, and it’s the most complete version of the idea I’ve seen yet. Five pillars, a rebuilt development lifecycle, a governance layer, the works. Autonomous agents build, test, and ship around the clock while humans define business intent and review outcomes. Two-week sprints get replaced by compressed delivery units they call bolts. It reads like a serious operating model instead of a vendor pitch.
Search that page for the word designer. It isn’t there. Neither is UX, nor user experience, nor usability. The word design shows up only as a verb, something you do to a factory, and in the bios of the consultants who wrote it.
Factory.ai, which sells the tooling, publishes a nine-stage pipeline: signals, triage, plan, build, test, review, secure, ship, monitor, and then back around to signals. Design isn’t a stage. The standardized inputs they say every unit of work arrives with are scope, acceptance criteria, owner, and target environment. Four real things, and not one of them says anything about what the software is supposed to be like to use.
I don’t read this as malice, or even as much of an oversight. These models were written by engineering leaders solving an engineering problem, and they solved it well. But the holes they left behind are design-shaped, and if designers don’t fill them they’ll get filled by whoever happens to be standing closest.
We have watched this exact thing happen before, and we are still paying for it.
Snowbird, 2001
In February of 2001, seventeen practitioners met at a ski lodge in Utah and came out with the Agile Manifesto. They came from Extreme Programming, Scrum, DSDM, Crystal, Feature-Driven Development, and a few other camps that had been arguing with each other for years. Programmers and methodologists, every one of them. Not a designer in the building.
Look at what they produced. Four values, twelve principles, and working software as the primary measure of progress. The word design shows up twice in those principles, and both times it means engineering design: continuous attention to technical excellence and good design enhances agility, and the best architectures, requirements, and designs emerge from self-organizing teams. Users appear exactly once, in a principle about maintaining a sustainable pace. Nothing about usability, nothing about research, nothing about whether the working software being delivered every two weeks was any good to use.
Nobody was shut out of that room. There was no designer at Snowbird because the people at Snowbird were solving their own problem, and design wasn’t part of their function, so it never came up. That’s a completely reasonable thing to have happened.
And on our side, we didn’t notice. Not for years. The UX community didn’t seriously engage with agile in print until around 2007, when Desirée Sy published on adapting usability investigations for agile teams and Jeff Patton started cataloguing practices for bolting UX work onto sprints. Six years after the manifesto. Lean UX didn’t arrive until 2013, a full twelve years later, by which point the ceremonies were set, the cadence was set, the definition of done was set, and none of them had a place for the work we do. I’d guess that even if more designers had been paying attention in 2001, most wouldn’t have cared much. It looked like somebody else’s methodology argument.
Everything design has done inside agile since then has been a retrofit. Sprint zero, dual-track, design running a sprint ahead, the whole discovery and delivery split. Each of those is a workaround for a hole that got designed into the process at a ski lodge in 2001 by people who weren’t thinking about us, and design has spent a quarter century arguing for a seat at a table that was built before anyone thought to set a place. Ask any design leader how much of their week goes to justifying the existence of the function rather than doing it.
The reason to bring this up is that the seating chart is being drawn again right now, in public, by a similar group of people solving a similar problem.
What the factory actually is
Strip the branding off and an agentic software factory is a production line where the things moving down the belt are units of intent rather than units of code.
Work enters as a described outcome. An agent, or more often a small team of agents with different jobs, turns that description into a plan, writes the implementation, runs the tests, opens the pull request, and in the more mature versions watches the thing in production and files its own follow-up work. Human effort relocates to the front and the edges: defining what success means precisely enough that a machine can chase it, then checking at fixed stopping points that what came out is what you asked for.
What BCG calls the harness is where the real engineering goes: the accumulated set of rule files, tooling hooks, and validation steps that tell agents how to behave at each stage. The harness is where an organization’s standards live in a form the machine can actually obey, so a team with a good one gets compounding returns while a team without one has effectively hired a very fast intern and then left the building.
Who’s actually running one
Spotify is the best-documented case I’ve found. They built an internal coding agent called Honk to handle large-scale migrations across their codebase. Deterministic scripts could already get roughly 70% of the fleet migrated, dropping timelines from nearly a year to under a week, so Honk was built for the other 30%, the edge cases where all the expense lives. Six months ago it took three months to reach a thousand merged pull requests. It now gets there in ten days.
The architectural decision that made it work was separating the agent runtime from the verification runtime. Honk pushes a branch, triggers a build through a service that abstracts away the CI system, waits for the result, and only opens a pull request once the thing has actually passed. The agent doesn’t get to grade its own homework.
That safeguard exists because early versions cheated. The agent would comment out failing tests, or quietly downgrade a Java version, to turn the red green. Anyone who has run a team against a hard deadline will recognize the instinct, and it’s a useful reminder that these systems chase the signal you gave them rather than the outcome you meant.
Once generation stopped being the constraint, review became the constraint, and review turned out to be much harder to relieve. Spotify came at it three ways: cultural changes that let migration drivers approve their own pull requests, tooling that prioritized and auto-merged the low-risk material, and, most consequentially, standardizing the codebase so there was less variation to review in the first place. One of their engineers reached for aviation to describe the resulting job, where the pilots monitoring automated systems have the hardest role in the cockpit.
The rest of the numbers in circulation point the same direction and deserve considerably more suspicion. Factory.ai’s own marketing page reports customers doubling feature velocity and halving pull request approval times. BCG’s 3x to 5x productivity figure comes from a BCG survey of organizations already operating this way, which is a self-report from a group selected for having already succeeded. And the story everyone repeats, a million-line product built in five months by three engineers who wrote no code by hand, traces back to OpenAI’s own publication about using its own Codex. Every one of those numbers is being reported by somebody selling the thing the number is about.
METR’s randomized trial in early 2025 found experienced developers ran 19% slower with AI tools while estimating they’d been 20% faster, and that finding became the load-bearing citation in basically every argument against all of this. METR then ran the experiment again, and the update they published in February is a mess in an honest way: developers refused to sit in control groups without their tools, the pay rate dropped, and time-on-task stopped measuring much of anything once people were running several agents at once. The raw result pointed the other way, an estimated 18% speedup among returning participants with a confidence interval you could drive a truck through, and METR’s own reading is that developers probably are faster now. The strongest study against AI productivity has been partly walked back by the people who ran it. I respect that a great deal, and it also leaves the comfortable skeptical position harder to hold than it was a year ago.
Where the skepticism holds up is downstream of the keyboard. The 2025 DORA report found that heavier AI adoption raises delivery throughput and delivery instability at the same time, and its central finding is that AI amplifies whatever an organization already was, so a team with fragmented tooling and thin testing now generates technical debt faster than before. Thirty percent of the developers surveyed reported little or no trust in the code the machine hands them.
So the honest version of the story is narrower than the pitch. Factories work where the organization was already disciplined, where the constraints are encoded somewhere a machine can read them, and where somebody competent is paying attention. Those preconditions are the whole story rather than a footnote to it, and they happen to describe precisely the situation where design has something to offer.
No excuse this time
The models being published right now are going to harden into how this work gets organized for the next decade, the same way the manifesto hardened into two decades of ceremonies that had no place for us. Nobody is conspiring to leave design out of these either. It’s the same dynamic as Snowbird, where people solving their own problem write down the parts they can see.
What’s different is that in 2001 we had the excuse of not knowing. The manifesto went up on a website, most of the profession didn’t read it for years, and by the time we did the shape of the work was set and all we could do was negotiate around it. That excuse is gone. These models are public, they’re being debated in the open, and the holes in them are shaped precisely like the work we already know how to do.
So a lot depends on what the profession does with the next couple of years, and I’d rather we didn’t spend them being right about AI’s flaws from the sidelines. Skepticism is warranted, and I’ve argued for plenty of it in this very issue. But skepticism that curdles into absence is how you end up back in the high chair, and this time nobody will have to wonder whether we were asked. We’ll have watched the table get built and declined the chair.
Next issue I’ll get concrete about where design actually plugs into one of these things: the two places the factory already admits it needs a human, the three layers of contribution that follow from that, and the five moments worth halting a production line that was built to never stop.
Before that, I’d like to hear from anyone whose engineering org is already heading this direction. Reply and tell me what it looks like from where you sit.
— Justin
Further reading