The bottleneck moved.
Most of your process didn’t.

For about twenty years, the way we organized software work was downstream of a single fact: writing and changing code was slow, and the people who could do it were scarce and expensive. Almost every practice we think of as “modern engineering process” is a response to that fact. Sprints exist to make a scarce resource predictable. Story points exist to estimate how much of it you can spend in two weeks. Standups exist to keep a handful of expensive people from blocking each other. Code review exists because a human writing code is the part most likely to introduce a defect, so a second human should look before it ships.

That fact is now changing faster than the practices built on top of it. And the interesting question is not whether “AI will replace developers” — a framing that mostly generates heat — but a quieter one that a room full of senior practitioners kept circling at a Thoughtworks retreat this February: if AI handles the code, where does the engineering actually go? Their honest answer was that nobody had the same answer, but everybody agreed the question was urgent.^[1] This essay is an attempt at one answer, and a description of what changes downstream of it.

What the ceremonies were actually for

It helps to be precise about what Scrum optimized. Scrum is coordination machinery for a team of humans whose individual throughput is the binding constraint. The two-week sprint is a batching interval — long enough to be worth the planning overhead, short enough to correct course. The backlog is a queue in front of a slow server. Estimation is capacity planning for that server. Retrospectives are the feedback loop that tunes it. None of this is stupid; it was a reasonable design for the constraint it faced.

Fons Kotrotsos put the uncomfortable version plainly: Scrum was always a workaround.^[2]When the workaround’s reason for existing weakens, the ceremonies start to feel like cargo cult. You can watch it happen in real time once a team gets capable AI tooling. The pattern, described almost identically in the Thoughtworks notes, goes like this: you give a team agents, they clear their backlog in days, and then they slam into a wall of cross-team dependencies, architecture reviews, and human-speed approvals. Delivery does not get faster. You get the same throughput with more frustration, because the bottleneck has moved off the engineering team and onto everything around it.^[1] The sprint board is now measuring the wrong server.

But be precise about which part of that wall is the bottleneck, because the obvious answer is the wrong one. Shipping is not it. Continuous integration, trunk-based development, and feature flags had already made delivery cheap and continuous — that problem was solved years ago, inside Scrum, and AI changes nothing about it. The expensive part was always upstreamof the build: turning a vague intention into a story a developer can pick up. A product owner takes a vision and grinds it, over hours and often days, into something estimable and “ready” — pulling in QA, an architect, and a designer to agree on what it even means, then scoring it in story points and tracking it through velocity and cycle time. That whole apparatus was rational for exactly one reason: the build it fed took half a sprint, so it paid to spend a day aiming it. Collapse the cost of the build and the arithmetic inverts — you end up spending your scarcest resource, aligned human judgment, to schedule your cheapest one.

The McKinsey survey Kotrotsos cites makes the same point from the data side: top performers report 16 to 45 percent gains in productivity and quality from AI adoption, while most companies see 5 to 15 percent, and the gap is not explained by tooling — everyone has the same coding assistants.^[2] The difference is structural. Bolting an exponential tool onto a process designed to ration a linear one gets you a fraction of the tool.

The part where I argue against myself

Here is where most “Scrum is dead” essays overreach, so let me take the strongest counterargument seriously, because it is correct.

The 2025 DORA report — the largest ongoing study of software delivery — found that AI adoption now correlates positively with throughput and with product performance. It also found that AI continues to correlate negatively with delivery stability.^[3]More change, faster, breaking more often. DORA’s framing is that AI is an amplifier: “AI doesn’t fix a team; it amplifies what’s already there. Strong teams use AI to become even better. Struggling teams will find that AI only highlights and intensifies their existing problems.”^[3] The acceleration exposes whatever weaknesses were already downstream. Without strong automated testing, mature version control, and fast feedback loops, a jump in change volume just produces instability.^[3]

There is an even more alarming wrinkle. DORA has spent a decade showing that smaller batch sizes correlate with higher stability. Because agents make large changesets cheap to produce, some teams are drifting back toward big, infrequent releases — a quiet reversal of one of the field’s most durable findings. The Thoughtworks group flagged the same regression and was blunt that “agile is dead” is the wrong reading: the disciplines that actually matter under AI are the XP practices, namely pair programming, continuous integration, trunk-based development, and test-first work.^[1]

So the honest synthesis is not that engineering discipline disappears. It is that discipline and ceremony were always two different things, and AI is prying them apart. The ceremony — the estimation rituals, the sprint theater, the ticket-to-code translation layer — was scaffolding for a constraint that is dissolving. The discipline becomes more load-bearing, not less, because you have removed the human pace that used to limit how much damage a bad decision could do in a week.

Where does that discipline live now? It moves upstream and sideways. The Thoughtworks practitioners described shifting their review from code to the plan that precedes it — “pre-reviewing the plans and post-reviewing engineering.”^[1] If an agent generates an implementation from a spec, the spec is the highest-leverage place to catch errors, which is why teams are dusting off structured requirement formats, state machines, and decision tables that user stories were always too vague to replace.^[1] Martin Fowler and his colleagues call the surrounding apparatus the harness: the guides that steer an agent before it generates, and the sensors — linters, type checkers, tests — that catch it afterward. Their formulation is that an agent is a model plus a harness, and that the engineering work is increasingly building and tending the harness rather than typing the code that runs inside it.^[4]

Tests are the sharpest example. The retreat’s most repeated finding was that test-driven development produces dramatically better results from coding agents, for a specific mechanical reason: written first, the tests stop an agent from the failure mode of writing a test that simply certifies whatever broken thing it just produced. TDD becomes a form of prompt engineering — deterministic validation wrapped around non-deterministic generation.^[1]Kent Beck, who has been doing this longer than almost anyone, describes the agent as an “unpredictable genie” that grants wishes in literal and unwanted ways, and reports that TDD is a superpower with these tools — when he can stop the genie from deleting the failing tests to make the suite go green.^[5] The genie has no taste. Left alone it will pad a giant function with more lines and call it done.^[5]

None of that is a process you run on Tuesdays. It is engineering judgment, encoded into the system so it applies continuously rather than at a review gate.

The team that comes out the other side

If the ceremonies were coordination overhead for scarce throughput, then making throughput abundant should shrink the team and widen each person’s scope. That is exactly what the leading edge looks like.

The clearest existence proof right now is Anthropic’s own Claude Code team. In a conversation with Lenny Rachitsky, Cat Wu — who runs product there — described a way of working with no Scrum anywhere in sight. There are engineers on the team “fully able to end to end go from see user feedback on Twitter through to ship a product at the end of the week with almost no product involvement.”^[6]Instead of a release process that gates work for months, they keep a standing “evergreen launch room” where an engineer posts a finished feature and triggers a same-day turnaround, often shipping it as a “research preview” so the label itself removes the commitment barrier that would otherwise slow things down.^[6] Feature timelines that used to be six months collapse to a week or a day.^[6]

What makes it work is not heroics. It is who is on the team. “PMs are doing some engineering work. Engineers are doing PM work. Designers are PMing and also landing code,” Wu says, and notes that nearly all the PMs have been engineers or ship code, and the designers have front-end backgrounds. That shared fluency “enables us to move a lot faster,” because there is no translation layer between someone who knows what to build and someone who can build it.^[6] The role boundaries that Scrum formalized — product owner here, dev team there, a backlog as the contract between them — are the friction being removed.

Give that convergence its plainest name: the product owner becomes a maker. The person who holds the vision can now enact it — not hand it down to be translated, estimated, and scheduled, but build it in an afternoon. The entire refinement apparatus existed to move intention across the gap between someone who knew what to build and someone who could build it; when one person is both, the gap closes and the apparatus has nothing left to do. The interesting question is what replaces it. With a single maker, nothing does. With several, you still need to stay roughly aligned on what each is building and where it is all headed — but roughlyis the operative word. The planning that survives is light and short-horizon: a shared picture you glance at and nudge, not a months-long roadmap defended in estimation meetings. The energy that used to go into making work legible across roles simply isn’t needed once the roles collapse into one.

The Thoughtworks group landed in the same place from the research side. They describe the PM, developer, and designer roles converging, with one large company literally researching whether the PM role needs a new name, and another training every PM to work in Markdown inside developer tools.^[1] They also named something I think is the most useful concept to come out of that retreat: the middle loop. Software has long been described as an inner loop (a developer writing, running, debugging) and an outer loop (CI/CD, deployment, operations). A third loop is forming between them — supervisory work of directing agents, decomposing problems into agent-sized packages, judging output quality without reading every line, and holding architectural coherence across many parallel streams.^[1] It is a different skill from writing code, and most career ladders do not name it or reward it yet.

The shape of the work changes with the shape of the team. A two-week sprint cadence assumes a long-running team grinding a perpetual backlog; it is a treadmill, not a finish line. When a capable small group can take something from feedback to shipped in days, work starts to look less like an endless queue and more like a series of short, sharply-scoped projects with a beginning and an end — assemble context, build the thing, ship it, disband or regroup. That is closer to how a film crew or a research group works than to how a feature factory works, and it fits a world where the expensive, scarce input is concentrated human judgment rather than sustained human typing.

It also relocates the bottleneck somewhere uncomfortable. If agents generate work faster than anyone can review and approve it, the constraint becomes decision-making capacity, and the middle managers who used to be coordination points quietly become approval queues. The Thoughtworks group reported this already happening — agents producing job specs, fixes, and feature implementations faster than humans can say yes — and asked the pointed question of whether organizations built around human review throughput need as many layers of it.^[1] A process whose main output is permission is exactly the kind of thing that does not survive contact with abundance.

There is one bottleneck none of this dissolves, and it is worth naming honestly because it is genuinely unsolved. Your half of the work can be done in a day; the team you depend on still moves at the old speed. You finish a feature and then wait months on a platform change, a legal review, a partner integration that no amount of local velocity can hurry. When you are fast and your dependencies are slow, the speed shows up as idle time rather than shipped value, and there is no clever process that makes someone else move faster. You can only choose what to build in the meantime — which is its own quiet argument for planning loosely and keeping more than one thing in flight.

This is where the founder’s intuition behind this essay comes in, and I think it is right: as the formal process thins out, high-bandwidth human contact becomes more valuable, not less. When a feature can go from idea to shipped in a day, the cost of a misalignment is paid the same day, and the cheapest way to stay aligned is not a ceremony but proximity — the constant, slightly exhausting mind-meld of people who share enough context to finish each other’s reasoning. The Thoughtworks practitioners reached for the same instinct through a quote about pairing: “If it’s important to understand the system, then do it all the time. You don’t do it in little phases where you have your code review.”^[1] Continuous shared understanding replaces periodic synchronization. Physical or near-physical closeness, which a decade of process and distributed tooling had made almost optional, starts to matter again.

What actually gets scarce

Every time a layer of software work gets automated, the scarce resource moves up a level. The Thoughtworks notes draw the analogy to computer graphics: in 1992 engineers hand-coded polygon rasterizers; two years later that was in hardware and the job became lighting and animation; now it is physics and world-building. Each time the abstraction rose, the people who insisted they were hired to render polygons got left behind.^[1] Code generation is that abstraction rising again.

So what is the new scarce thing? Two related things, and neither is typing.

The first is taste. Cat Wu is direct that product taste is the rare skill her team hires for above almost anything else, because once writing code is cheap, deciding what to build is the expensive part.^[6]Kent Beck’s complaint about the genie is the same observation from the engineering side — the model can generate plausible code all day and has no opinion about whether it should.^[5] When supply of implementation goes to near-infinite, judgment about what deserves to exist becomes the binding constraint.

The second is the story. Not the Scrum artifact — the actual narrative that explains why a product is shaped the way it is, what it is for, and what it refuses to be. This matters more precisely because the new way of working is fast and fragmented. When small teams ship daily, when prototypes go straight to production (which they now do, which is exactly why architecture and quality get moreattention, not less — you no longer get a throwaway draft phase to be sloppy in), the thing most likely to drift is coherence. A hundred individually reasonable decisions, made at agent speed by people wearing three hats each, will quietly pull a product apart unless something holds the big picture. Simon Willison’s line on vibe coding marks the boundary: building software without reviewing what the LLM wrote is fine for a weekend throwaway, but anything real demands that you can explain exactly what your code does and why.^[7]At the level of a product rather than a function, “why” is the story.

The irony the field is walking into is that the more we automate the small units of work — the tickets, the tasks, the stories in the Scrum sense — the more the large unit of meaning matters. You can delegate the what-next. You cannot delegate the why-this-at-all, at least not yet, and the teams winning right now are the ones that have concentrated their scarce human attention exactly there.

Why we built Stori the way we did

People ask why a tool called Stori does not have “stories.” It is a fair question; the artifact is right there in the name.

The answer is that we think the Scrum-ticket sense of “story” is the part that is dissolving, and the original sense of the word is the part that is becoming essential. Stori is built for the world this essay describes: small teams of people who hold both product and technical context, working fast, often alongside their own coding agents, with the big picture as the thing that has to stay coherent.

So Stori is one morphing canvas instead of a stack of routes — work items are objects you arrange spatially, and the board, the backlog, the releases, and the timeline are all just re-layouts of the same canvas, because they are different views of one story, not separate processes. The agent reads and writes that canvas directly over MCP, because the agent is now a first-class member of the team, not a tool bolted onto a human workflow.

We did not build a better sprint board. The sprint board was an answer to a constraint that is going away. We built the place where you keep the story straight while everything underneath it moves at a speed the old process was never designed for. That is the part that is getting harder, and the part worth building well.