Write code, not specs
Doug Turnbull ● Covered by 6 sources
A dev argues you should stop writing specs for AI coding agents and just write code instead. His pitch: tests plus hand-built patterns build more trust than English-language instructions ever could.
Based on reporting by Doug Turnbull — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
There's a quiet rebellion brewing against the spec-driven approach to AI coding, and it comes from someone who tried the disciplined route first. He kept detailed specs, fed them to coding agents, and watched the whole setup collapse under its own weight. Turns out maintaining a precise spec alongside precise code just means maintaining two systems that constantly drift apart, and nobody signed up for that kind of bookkeeping.
So he flipped the model. Instead of describing what code should do in English, he writes the code himself, at least in the areas that matter most. He calls it tilling a garden: inside the patterns he's established by hand, he trusts agents to run wild. Step outside that boundary and trust drops fast, because agents left to guess at unfamiliar territory need constant babysitting and produce brittle results.
Tests do the heavy lifting that specs used to do. Rather than writing prose about expected functionality, he writes executable checks, and once he's confident a handful of tests actually verify something real, he lets an agent generate more while he watches closely. That's the mechanism for expanding trust gradually: some parts of the system become fully automated and protected against sloppy human edits, while newer, riskier corners stay slow and deliberate until they've earned the same treatment.
There's a resource argument buried in here too. He'd rather spend his limited attention solving actual technical problems than babysitting spec documents and getting distracted between edits. Even as agents get better at writing and debugging code, someone still needs the long-running context of how the whole system fits together, and that person is accountable when it breaks.
His closing analogy is the one that sticks: using coding agents isn't climbing to a higher abstraction layer, it's building a factory. You can't automate a car assembly line before you've hand-built a few cars and learned what good actually looks like, down to the bolts. Touching the code yourself, in his view, isn't a failure to delegate. It's how you develop the taste that makes the automation worth trusting in the first place.
My take — AI-written commentary, not fact-checked reporting
This tracks with something I've suspected for a while: the industry's obsession with prompt engineering and spec files is often just procrastination dressed up as process. Tests as the source of truth instead of prose is the right instinct, and it's basically what good engineering teams already knew before LLMs showed up wearing a cape. My only gripe is that 'developing taste' sounds suspiciously like a skill that doesn't scale to a team of five hundred engineers with wildly different standards, so I'd want to see this survive contact with an actual large codebase before crowning it the new methodology.
Read more about this at: Doug Turnbull
