Writing Code Got Cheap. Deciding What to Build Got Hard.

Right now I have two chats open on my screen, and I'm not writing code in either of them. The left one plans. I talk through an idea with Fable 5 until it turns into a real implementation plan and a handoff document. The right one builds. I paste that document into a second chat I call the Builder, and it works for the rest of the day: writing code, running its own checks, opening a pull request. Then the left chat reviews what the right one shipped. My job lives in the gaps between them: deciding what to build, and deciding whether what came back is good.

A year ago that setup would have sounded lazy, or fake. Now it's just how I build. And it forced me to admit something I'd been avoiding: the code was never the hard part.

Code got cheap almost overnight

Let me put a number on it. In May 2026, Anthropic reported that more than 80% of the code merged into its own production codebase was written by Claude, not by people. Before Claude Code launched in early 2025, that number sat in the low single digits. Their engineers now ship roughly eight times more code per quarter than they used to.

Your codebase probably doesn't look like Anthropic's. Mine doesn't either. But the direction isn't subtle, and it isn't only about volume. AI can also stay on a task far longer than it used to. METR, which measures how long a job an AI can finish on its own, found that this horizon keeps doubling about every seven months. When I started using these tools, an assistant could handle a single function. Now a Builder chat can take a whole pull request and run with it for hours.

When the typing gets close to free, the value moves to the two things that are still hard: knowing what to build, and knowing whether what came back is any good. That is the whole story of how I work now.

A planner, a builder, and a checker

Here's the actual setup. Two chats doing three jobs:

• The Planner — Fable 5. Turns a rough idea into a plan and a handoff document.
• The Builder — a Claude Code session. Takes the document, works the day, ends with a pull request.
• The Checker — Fable 5 again, reviewing the PR against the plan it wrote earlier.

I use Fable 5 to think. I bring it a rough idea, some feature or refactor I can't quite picture yet, and we argue about it. What should this actually do? What's in scope? What breaks if I do it the obvious way? Fable 5 is unusually good at this part, and it's good at turning the mess into structure. By the end I don't have code. I have a plan.

Then the Builder takes over. I paste the handoff document in and mostly get out of the way. It has its own flow, because the project is full of skills that fire on their own: checks that run, tests that execute, a skill that opens the PR. When the pull request is up, it stops. It doesn't merge. That's not its job.

Then I go back to the first chat, and Fable 5 becomes the Checker. It reads the PR the Builder produced and reviews it against the plan it wrote earlier. It's a strange loop. The thing that specified the work grades the work. And because most of my skills carry their own validation, the code gets looked at several times before I ever open it.

The piece I've come to love most is the handoff document — the single file Fable 5 writes to brief the Builder. It always takes the same shape: an objective, the decisions already made, the files that matter, and the next steps. That shape is the point:

🔄 Handoff: <feature> — Builder chat

▶️ Resume prompt — paste this whole document into a new chat
You are the Builder for <task>. <One paragraph of context, plus the
immediate next step.> When the PR is up, stop; the Checker reviews.

🎯 Objective
<What "done" looks like, in two or three sentences.>

🧭 Key decisions
Do:
- <The choices already made, so nobody re-litigates them.>
Don't:
- <The things that break something if touched.>

🧰 Tools, files & resources
- <Where to look. What to copy. Which contracts must not move.>

👉 Next steps
1. <Ordered, concrete, checkable.>

When I first watched Fable 5 produce one of these unprompted, I stopped and read it twice. It had a "Do" list and a "Don't" list. It told the Builder to stop and warn me if a dependency wasn't ready instead of guessing. It named the one file whose contract other code depended on and said, plainly, don't move it. That's not code. That's judgment, written down.

Why deciding what to build is the hard part

There's an old line about sculpture: the figure is already inside the block of marble, and the artist's job is to remove everything that isn't the figure. I used to think the hard part was the chiseling. It isn't. The hard part is seeing the figure before you start.

That's what the handoff document is. It's me and Fable 5 deciding, in advance, which shape we're carving out of a huge block of possible code. The Builder does the chiseling. It's fast, it's tireless, and it never gets bored halfway through. But it will happily carve the wrong thing beautifully.

So the plan is where my real attention goes now. Not the syntax. The decisions. Get the plan right and four things are settled before any code exists:

• what the feature is for
• who it's actually for
• what it must not do
• where it touches something fragile

Get those wrong and no amount of clever prompting saves the day. I've burned a Builder's whole run on a beautiful mistake more than once.

Where a QA background becomes an advantage

This is the part where my last decade shows up whether I ask it to or not. I spent years in QA, and QA rewires how you look at anything about to be built. You don't ask "how do I make this work." You ask "how does this break, and what happens to the person using it when it does."

Look back at that handoff skeleton and you'll see it everywhere. The "Don't" list is a list of failure modes I've already imagined. The instruction to stop and warn me instead of guessing is a QA reflex: fail loud, never silently. The whole three-job setup is really validation loops wrapped around a fast writer. The skills validate, the Checker validates, and I validate the Checker. I didn't plan it that way. It's just that "but what if this breaks?" is the question I can't stop asking, so it ended up baked into the architecture.

A few weeks ago the Planner and I were scoping a change to one of my skills, and I caught myself writing a rule into the handoff that said, in effect: if the backend isn't reachable, review the front end only and flag every place you couldn't check, loudly. I wrote that before a single line of code existed. That's the QA instinct working upstream, at the definition stage, where catching the gap is cheapest. Ten years ago I'd have found that hole in a bug report. Now I find it in a plan.

The tension between planning and shipping

None of this is settled. The obvious failure mode of a QA brain is over-planning: spending so long specifying the perfect handoff that I could have built the thing myself in the time it took. I've done it. I've written three-page plans for changes the Builder would have nailed from two sentences. The instinct that makes my plans good is the same one that makes me cage the Builder when I should let it run.

I wrote a whole post about the other side of this, knowing when to stop building, because that same reflex will keep you polishing a thing you should have shipped a week ago. And the reason I write the spec myself instead of asking the AI to guess it is something I worked out earlier, in why spec-based agentic development starts with QA thinking. The two-chat setup is where both lessons finally live in one workflow. The Planner is me writing the spec. The Checker is me refusing to trust the output until someone has actually looked at it.

So the skill I'm practicing now isn't prompting, and it definitely isn't typing. It's knowing how much to decide before I let go. Enough that the Builder carves the right figure. Not so much that I've done its whole job out of fear.

The strange thing is how familiar it all feels. I spent my career being the person who asks what the requirements really are and what happens at the edges. That used to be a support role, one step behind the people writing the code. Now it's the whole game. The writing got cheap. The deciding got expensive. And the deciding turns out to be the thing I was training for the entire time.

Are you building this way yet — something that plans, something that builds, something that checks the output? I'd genuinely like to hear how you've split the work. Tell me about your setup.