The machine can’t be held accountable. You still can.
SubscribeSign in
The machine can’t be held accountable. You still can.<br>On cognitive sovereignty in the age of AI-assisted development
Milos Solujic<br>Jun 12, 2026
Share
Why I believe this story is true
And there are most likely many more like this in the wild.<br>This story is worth sitting with, because it’s not a failure of AI tooling. The tools worked exactly as designed. It’s a failure of cognitive posture, and it’s becoming the dominant failure mode of the current moment.<br>In the past year, I’ve built two serious products using Codex, Claude Code, and Cursor. And I can attest that the effort to keep things in check increases significantly when LOC exceeds 100K. Just some of that effort could be outsourced to more powerful models, such as Claude Fable 5, at a cost of (b)millions of tokens, but even that will not guarantee that it is doing the right thing for the project long term.<br>Let us step back for a moment and observe where we are and what to do about it all.
Thanks for reading Pragmatic Builder! Subscribe for free to receive new posts and support my work.
Subscribe
Acceleration and its asterisk
The numbers on AI’s impact on engineering throughput are real. The 2026 AI Engineering Report from Faros AI, based on two years of telemetry from 22,000 developers across 4,000 teams, found epics completed per developer up 66%, task throughput up 33.7%, and PR merge rate up 16.2%. More features shipped, more initiatives completed, faster cycles. Engineering leaders are right to want more of this.<br>But the same dataset carries a different set of numbers that rarely make the headline slide.<br>Code churn, the ratio of lines deleted to lines added, is up 861% under high AI adoption. The probability of a production incident per code change has risen 242.7% . Bugs per developer are up 54%. And 31.3% more code is merging into production with no review at all.<br>The report’s authors named this “the Acceleration Whiplash”: AI has flooded a system built around human-paced development with output it was never designed to absorb. Throughput is up. So are the hidden costs accumulating at every downstream stage.<br>Kent Beck, whose fingerprints are on more software development methodologies than almost anyone alive, put the current moment plainly: “When anyone can build anything, knowing what’s worth building becomes the skill.” The 2026 Thoughtworks Deer Valley gathering, attended by Beck, Martin Fowler, and roughly 50 senior engineering leaders, framed the same problem differently: cognitive debt is the new technical debt. When AI generates code nobody fully understands, you accumulate cognitive debt. And it compounds exactly like technical debt.<br>“Velocity without understanding is not sustainable.”
What you’re actually outsourcing
There is a clarifying distinction that gets lost in the AI productivity conversation: the difference between task execution and reasoning.<br>LLMs are extraordinarily good at task execution given sufficient context. Feed them your conventions, your domain model, your existing patterns, a clear specification, and they will generate code faster than any human team. This is genuinely valuable. This is the part worth accelerating.<br>Reasoning is different. Reasoning is: why does this component exist? What problem does this architecture solve, and what problems does it create? What happens to this system under load six months from now? Who is responsible when it fails?<br>LLMs do not reason in this sense. They pattern-match against an enormous corpus and produce plausible next tokens. They have no stake in the outcome. They cannot be paged at 2am. They will not be in the incident post-mortem. They cannot be responsible for anything, which means, if you’ve delegated the reasoning, you’ve made yourself responsible for decisions you didn’t make and don’t fully understand.<br>This is not a critique of the tools. It’s a structural fact about what they are.<br>The Reddit developer’s codebase wasn’t broken. It was a liability they didn’t know they’d taken on.
The spectrum of exposure
The stakes are not uniform across all use cases. A back-office utility processing internal data has a different risk profile than a B2B SaaS product with contractual SLAs. A solo side project has different exposure than a system handling financial transactions. The appropriate response to AI-assisted development scales accordingly.<br>If you’re building with a larger codebase, multiple domains, or multiple contributors:<br>Start with documentation, not of the code, but of the reasoning behind it. Your business rules. Regulatory constraints. Architectural principles. Domain boundaries. Not to satisfy a compliance checkbox, but because this is the context that separates purposeful generation from confident hallucination. The better you can articulate why your system is structured the way it is, the more your AI tooling behaves as an accelerator of your intent rather than a substitution for...