Who Throws the Stone?

Who Throws the Stone?

Key Points

A designer needs to change a button color. She opens Jira. Files a ticket. Writes acceptance criteria. Attaches the design comp. Waits for sprint planning. The engineer picks it up in week three. The button turns red.

This is Agile in 2025. And it's not a bug. It's the architecture.

The Scribe Problem

Every layer of Agile (the stories, the sprints, the standups, the reviews) exists to manage one core assumption: only engineers can convert intent into software. That assumption made engineers the Scribe class. The translators. The people through whom all work must pass before it becomes real.

The numbers are brutal. According to a Stripe study, developers spend only 32% of their time writing new code or improving existing code. The rest disappears into coordination, ceremonies, reviews, deployment, and support. Agile ceremonies alone consume more than 17 hours per week per developer, not counting the fragmented, interrupted stretches between meetings that make deep work nearly impossible. Sprint planning runs synchronous 64% of the time. Standups, 61.6%. Backlog refinement, 51.8%.

The queue isn't broken. The queue is the product.

Agile didn't invent this bottleneck. It institutionalized it. Gave it ceremonies. Gave it a name. Built an entire professional class around managing the flow of work into a room full of scribes and back out again.

Why Agile Won't Self-Correct

The market is already responding. Capital One eliminated 1,100 Scrum Masters. Royal London made 90% of its Scrum Masters redundant. A large UK bank cut 1,000 Agile coach and Scrum Master positions in a single sweep. The industry is amputating.

But that's not a diagnosis. That's trimming the fat while the bone stays broken.

Fewer Scrum Masters doesn't change the architecture. The problem isn't too many ceremonies. The problem is the assumption underneath all of them: work can only move forward when an engineer touches it. Remove the ceremony, keep the assumption, and you've just made the queue invisible.

Agile won't fix this from within. The incentive structure won't allow it. The certification industrial complex I wrote about in Scrum Is Dead wasn't an accident. It was a feature. A $1,000 course, a weekend workshop, and a credential that only makes sense if Scrum stays dominant. That ecosystem doesn't self-correct. It defends.

The Wall Is Dissolving

Here's what's actually happening.

85% of developers now regularly use AI coding tools. AI contributes 46% of all code written by active GitHub Copilot users, up from 27% at launch. A Microsoft, GitHub, MIT, and Harvard study found that developers using AI complete tasks ~55% faster. Twenty-five percent of Y Combinator's Winter 2025 batch reported codebases that were 95% or more AI-generated.

But that's not the real story. The real story is who's doing the writing.

PMs are shipping prototypes over a weekend. Designers are deploying components without filing tickets. SMEs are configuring business logic that used to require three sprints to translate. Tools like Cursor, v0, Claude Code, and Replit have fundamentally changed what "can build" means. The wall between "can think it" and "can build it" is dissolving faster than the Agile coaches are being laid off.

It Would Be Silly

It would be silly to have ever asked an engineer to change a button color when a designer is perfectly capable of doing it.

It would be silly to route a notification trigger through a sprint when the SME who wrote the business rule could configure it directly.

It would be silly to file a ticket, wait for sprint planning, wait for development, wait for QA, every time a PM needs to update the copy inside a component.

But that's exactly what Agile demanded. Every intent, no matter how small, had to route through the scribe. Every change required a handoff. Every handoff cost a week.

AI is making that silliness visible. And once you see it, you can't unsee it.

The Startup Factory

A new pattern is emerging. I'm calling it the Startup Factory: a team of two to four people (sometimes just one) equipped with the right AI tools, shipping at the pace and scope that previously required ten to fifteen engineers. The machines do the assembly. The humans provide the design, the direction, and the judgment.

Pieter Levels built and launched multiple profitable products as a solo developer years before AI made this mainstream. The playbook he wrote is now accessible to people who have never written a line of production code. That's the inflection point.

Most startup discourse gets this wrong, though. They treat the Startup Factory as a story about startups winning. It's not.

The Incumbent Comeback

In the old world, the startup's competitive advantage was speed. Small team. No legacy. No bureaucracy. They could outmaneuver a slow enterprise every time.

AI changes that math.

If a two-person startup can now ship in days what used to take a sprint, so can an incumbent. And the incumbent already has something a startup will spend years and millions trying to build: distribution. An existing user base. Existing trust. Existing revenue. Regulatory relationships. Marketing channels that reach millions of people who already know the name.

This is the Distribution Moat. In a world where attention is scarce and distribution channels are consolidating, the winner isn't necessarily who ships fastest. It's who ships fast enough and already has the audience waiting. A startup's product has to find its users. An incumbent's users are already there.

Enterprise giants know this. M&A activity is expected to surge in 2025 to 2026 as incumbents acquire AI capabilities rather than rebuild. The companies that adapt, that let their PMs, designers, and SMEs become first-class builders with engineers focusing on making sure that AI output is production-ready, will compound their existing advantages with new velocity.

The incumbents who don't adapt won't be disrupted by scrappy startups alone. They'll be disrupted by other incumbents who moved first.

What Engineers Actually Become

Engineers don't disappear in this world. They stop being scribes and start being something more valuable.

They become the people who make sure AI-generated requirements are translated faithfully into production-quality code. They build the caching layers, data models, and infrastructure that make everyone else fast. They catch what AI misses. Because AI isn't perfect. It hallucinates. It misses edge cases. It writes code that passes review and fails in production. But it's getting close enough to useful that the human's job shifts from writing to guiding.

Think of the curling analogy from Curling: The Framework That Replaces Scrum. When anyone on the team can throw the stone, when the designer can deploy, the PM can prototype, the SME can configure, the sweepers become the difference-maker. They read the ice. They clear the path. They make an imperfect throw land in the house anyway.

Engineers who embrace this shift will be among the most valuable people in any organization. They'll own the conditions that make everyone else effective.

Engineers who keep waiting for tickets will be managed by the PMs who used to file them.

The Button Is Red Now

She changed it herself. Deployed it. It shipped before the standup would have even started.

Agile's bottleneck was never really the engineers. It was the belief that only engineers could throw the stone. That belief is breaking. The architecture built on top of it is going with it.

There will be winners. Incumbents with distribution who get their act together in time. Small teams running Startup Factories with no overhead and no ceremony. Engineers who see the shift and decide to sweep instead of waiting to be handed the stone.

There will be losers too.

The question is which side of the ice you're standing on.