There’s a moment in every coaching session where I say something that makes the person blink a little.
For Jacob — a college student building a construction management app with Claude Code — it was this:
“You’ll know you’re actually getting good at this when you spend 80% of your time writing the spec, not the code.”
He’d been spending most of his energy wrestling with the code. Debugging, figuring out why Claude produced the wrong output, and iterating. Normal when you’re starting out. But I was describing where he’d be in a few months.
The ratio flips.
Why the 80/20 Inverts
Beginners treat AI coding like a shortcut for code generation. Feed in a vague idea, hope something usable comes out, fix what’s broken.
That’s why beginners spend 80% of their time on code. Not because coding is the important part, but because the vague input created a vague output, and now you’re paying the cleanup tax.
Experts do the thinking upfront. They spend most of their time writing what I’d call a PRD — a Product Requirements Document, but that sounds corporate. It’s really just a clear, complete description of what you’re trying to build.
What should happen when the user clicks this button? What’s the edge case when someone enters a letter instead of a number? What does “success” actually look like for this feature?
Answer all of those first. Then hand it to Claude Code.
A good spec is most of the work. The code is almost just output.
Garbage In, Garbage Out — But Not How You Think
I’ve been saying this for a while: garbage in, garbage out applies to AI more than anywhere else.
People usually take that to mean “use better prompts.” That’s true, but it’s the wrong level.
The problem usually isn’t word choice. It’s fuzzy thinking before you start.
I had a coaching session with someone building a construction tracker app. He kept getting messy output — wrong calculations, confused logic. We looked at his prompts. They seemed fine. So I asked him to walk me through the math out loud.
He stumbled.
That was it. He didn’t fully understand the problem himself. And if he couldn’t explain it clearly to me, he couldn’t explain it clearly to Claude.
There’s a quote I come back to a lot: defining the problem is half the battle — and it’s harder than most people think.
The quality constraint isn’t the AI. It’s the clarity of what you’re feeding it.
What Goes In a Good Spec
This doesn’t have to be a twenty-page document. For most small builds, a good spec is just a few paragraphs that answer the following:
What is this for? One sentence: who uses it, and what problem does it solve.
What should happen in the normal case? Walk through the main flow like you’re explaining it to someone who’s never seen your app.
What are the edge cases? What happens when something goes wrong, or when input is unexpected?
What does done look like? What can you test to confirm it’s working?
That’s it. You don’t need a formal template. You just need to think it through before Claude starts building.
When I flip the script and let AI interview me — ask “what do you need to know to succeed?” — it forces me to answer the questions I’d otherwise skip over. And when I answer them, the output is exactly what I needed.
The Architect Analogy
An architect who’s great at their job doesn’t build the house.
They draw incredibly detailed plans. They think through every room, every load-bearing wall, every pipe. They anticipate problems before construction starts. That’s where their expertise lives.
The builders execute from those plans. They’re skilled. But the thinking was already done.
AI coding works the same way. Once you have a clear spec, Claude Code is the builder. It’s skilled. It can execute. But it can only work from the plans you give it.
Your job — as you get more advanced — shifts from “making the code work” to “making the plans clear.” That’s the real skill development. That’s the 80/20 flip.
This Generalizes Beyond Coding
The principle isn’t just about code.
Garbage in, garbage out applies every time you ask an AI to produce something — a marketing email, a research summary, a draft proposal. The output quality is downstream of input quality.
Clear context beats clever wording, every time. The better you get at managing what you give the AI — and the more time you spend on that clarity before you start — the better everything downstream becomes.
It’s a skill anyone can develop. And it starts with slowing down before you start, not speeding up once you’re stuck.
Want to build this skill hands-on? The 4-Day AI Sprint is the fastest way to go from vague prompts to results that actually work.
