{"slug": "the-wrong-end-of-the-problem", "title": "The Wrong End of the Problem", "summary": "Most companies integrate AI into development by giving developers AI assistants without changing their process, leading to review bottlenecks. The author proposes shifting engineering work to spec-driven development where teams collaboratively define precise specs in \"Spec Sessions,\" then let AI agents implement from them autonomously. This approach aims to deepen thinking rather than just accelerate typing.", "body_md": "# The Wrong End of the Problem\n\nEvery company wants AI in their development process right now. That part is clear. What’s less clear is where they’re putting it.\n\nMost teams I see have done the same thing. Handed developers access to an AI assistant and told them to move faster. Copilot in the IDE. Claude in the terminal. Pick your tool. The tickets stay the same. The process stays the same. The planning meetings stay the same. The only thing that changed is how the code gets typed.\n\nThe tool got added. The process didn’t move.\n\nAnd it breaks down fast. One power user with AI can produce more code than a team can review. Two or three power users in the same team and the review process is basically gone. Nobody can keep up, and the code ships anyway.\n\nThere’s a term worth knowing here: Spec-Driven Development.\nThe idea is that a detailed specification becomes the source of truth, not the code.\nAgents implement from it.\nRequirements change, you update the spec.\n[AI Unified Process](https://unifiedprocess.ai/) is one example of this in practice.\nIt’s a sound technical approach.\n\nBut I think it stops short of the actual problem.\n\nThe spec has to come from somewhere. Someone has to write it, and someone has to agree on it. That part is still the old process, just with a new artifact at the end.\n\nWhat I’d suggest looks a bit different. And it has a name most engineers already know: shift left.\n\nNot in the testing sense. In the team sense. The collaboration moves earlier. The engineering work is now about defining what the system should do — precisely enough that an agent can run with it.\n\nThat happens in what I’d call a Spec Session. Mob planning instead of mob programming — the whole team, working on one spec. Or async — a pull request on the spec instead of on code. Review comments about intent and edge cases, not implementation. Engineers already know this workflow. The artifact is just different now.\n\nOnce the spec is agreed, the agent picks up the work. Not on anyone’s laptop — it’s sitting in your infrastructure, watching for ready tickets, the same way a CI runner watches for commits. It implements, an AI reviewer checks the output, flags what doesn’t fit, cycles back. That loop runs until it’s done. The human comes back in at the end to review the final output — not to write code in the middle.\n\nStacked diffs are probably the right format here.\nSmaller, sequential changesets the agent ships incrementally — easier to reason about, easier to review.\n[Gergely Orosz wrote a good primer](https://newsletter.pragmaticengineer.com/p/stacked-diffs) on why this workflow matters if you’re not familiar.\n\nAmbiguous acceptance criteria used to be something a developer resolved mid-sprint. In this model they surface in the Spec Session, where the whole team can catch them. That’s the point.\n\nI don’t think most teams are avoiding this intentionally. It’s just that changing the process is harder than adding a tool. Adding a tool has a procurement step and a license. Changing how a team thinks about its own work is a different kind of problem.\n\nBut fitting AI into an existing process gets you faster typing. The thinking stays the same depth as before.\n\nI 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.\n\nOne thing I haven’t figured out yet is what to call it. Mob Planning. Mob Specing. Spec Session. Extreme Specing. All of them borrow from XP deliberately — the idea is the same, just one level up from code. If you have a better name, I’d genuinely like to know.\n\nI don’t know if anyone is actually running this way yet. But I want to try. Especially the part where the agent just picks up the work and runs.\n\nAdding 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.", "url": "https://wpnews.pro/news/the-wrong-end-of-the-problem", "canonical_source": "https://schrottner.at/2026/06/18/The-Wrong-End-of-the-Problem.html", "published_at": "2026-06-19 21:41:50+00:00", "updated_at": "2026-06-19 22:07:49.640564+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools", "ai-products"], "entities": ["Copilot", "Claude", "AI Unified Process", "Gergely Orosz"], "alternates": {"html": "https://wpnews.pro/news/the-wrong-end-of-the-problem", "markdown": "https://wpnews.pro/news/the-wrong-end-of-the-problem.md", "text": "https://wpnews.pro/news/the-wrong-end-of-the-problem.txt", "jsonld": "https://wpnews.pro/news/the-wrong-end-of-the-problem.jsonld"}}