The Wrong End of the Problem — Simon Schrottner

The Wrong End of the Problem | Simon Schrottner

Every company wants AI in their development process right now.<br>That part is clear.<br>What’s less clear is where they’re putting it.

Most teams I see have done the same thing.<br>Handed developers access to an AI assistant and told them to move faster.<br>Copilot in the IDE.<br>Claude in the terminal.<br>Pick your tool.<br>The tickets stay the same.<br>The process stays the same.<br>The planning meetings stay the same.<br>The only thing that changed is how the code gets typed.

The tool got added.<br>The process didn’t move.

And it breaks down fast.<br>One power user with AI can produce more code than a team can review.<br>Two or three power users in the same team and the review process is basically gone.<br>Nobody can keep up, and the code ships anyway.

There’s a term worth knowing here: Spec-Driven Development.<br>The idea is that a detailed specification becomes the source of truth, not the code.<br>Agents implement from it.<br>Requirements change, you update the spec.<br>AI Unified Process is one example of this in practice.<br>It’s a sound technical approach.

But I think it stops short of the actual problem.

The spec has to come from somewhere.<br>Someone has to write it, and someone has to agree on it.<br>That part is still the old process, just with a new artifact at the end.

What I’d suggest looks a bit different.<br>And it has a name most engineers already know: shift left.

Not in the testing sense.<br>In the team sense.<br>The collaboration moves earlier.<br>The engineering work is now about defining what the system should do — precisely enough that an agent can run with it.

That happens in what I’d call a Spec Session.<br>Mob planning instead of mob programming — the whole team, working on one spec.<br>Or async — a pull request on the spec instead of on code.<br>Review comments about intent and edge cases, not implementation.<br>Engineers already know this workflow.<br>The artifact is just different now.

Once the spec is agreed, the agent picks up the work.<br>Not on anyone’s laptop — it’s sitting in your infrastructure, watching for ready tickets, the same way a CI runner watches for commits.<br>It implements, an AI reviewer checks the output, flags what doesn’t fit, cycles back.<br>That loop runs until it’s done.<br>The human comes back in at the end to review the final output — not to write code in the middle.

Stacked diffs are probably the right format here.<br>Smaller, sequential changesets the agent ships incrementally — easier to reason about, easier to review.<br>Gergely Orosz wrote a good primer on why this workflow matters if you’re not familiar.

Ambiguous acceptance criteria used to be something a developer resolved mid-sprint.<br>In this model they surface in the Spec Session, where the whole team can catch them.<br>That’s the point.

I don’t think most teams are avoiding this intentionally.<br>It’s just that changing the process is harder than adding a tool.<br>Adding a tool has a procurement step and a license.<br>Changing how a team thinks about its own work is a different kind of problem.

But fitting AI into an existing process gets you faster typing.<br>The thinking stays the same depth as before.

I think the teams that treat the Spec Session as the primary engineering output — and let the loop handle the rest — will end up somewhere different.

One thing I haven’t figured out yet is what to call it.<br>Mob Planning.<br>Mob Specing.<br>Spec Session.<br>Extreme Specing.<br>All of them borrow from XP deliberately — the idea is the same, just one level up from code.<br>If you have a better name, I’d genuinely like to know.

I don’t know if anyone is actually running this way yet.<br>But I want to try.<br>Especially the part where the agent just picks up the work and runs.

Adding AI to your process makes the typing faster. Moving the engineering work to the spec — and letting the loop carry it from there — is the part that actually changes the depth of the thinking.