Planning Is Cheaper Than Coding, and My Own Logs Proved Me Wrong About Why

I went into this post sure of one thing: coding with an agent burns tokens like a house fire, and planning is the cheap part where you just talk. I’ve felt it. You watch the agent grep twenty files, read half of them, figure out what it already built, then start writing, and the usage bar just keeps moving forward. Planning, by comparison, is me and Opus talking for three hours and barely denting the budget. Obvious, right?

So I did the thing I should always do before I put a claim in writing. I looked at a month of my own Claude Code session logs across two projects.

The meter came back flat. Coding and planning cost about the same to run. I was wrong about why coding is expensive.

• The Slogan, and the Hole in It
• What the Meter Actually Says
• The Expensive Kind of Cheap
• And Planning Is Dense
• Even the Prototype Gets a Plan
• My Freeform Rhythm
• Planning Is Also How I Learn the Thing
• So, Cheap Compared to What

The Slogan, and the Hole in It

The line I started with is “planning is cheap, coding is not.” I still believe it. But there’s a hole in it and I’d rather stab it myself than let a commenter do it.

Here’s the hole: agents made code fast. The whole selling point is that you describe a thing and the machine types it out in a minute. If typing is free now, in what sense is coding “not cheap”? A skeptic reads the title and closes the tab, because on its face the tool that generates 2,000 lines while you get coffee is the cheapest thing in the whole stack.

I couldn’t answer that cleanly, which usually means I don’t understand my own point yet. So instead of arguing from vibes, I went and measured.

What the Meter Actually Says

Two projects. Both ones I had genuinely no idea how to build when I started. Which is the whole reason they’re useful here. One is a content pipeline. The other is a knowledge-graph site I’ve written about before. Different domains, different stacks, both explored more or less blind.

I parsed every session’s log and split each of the agent’s turns into two buckets: conversation turns (the agent replied with text and touched nothing) and tool-action turns (it ran a command, read, edited, or wrote a file). It’s not a clean planning-vs-coding line (the agent talks during a build and reads files during planning), but across a month it’s a fair read on where the time and tokens go.

Two things fell out of this, and one of them is the whole post.

First: both projects landed on the exact same split. Fifty-nine percent conversation, forty-one percent building. Two unrelated codebases, two different domains, both started from “I don’t know what the fuck I’m doing,” and I independently spent about sixty percent of my turns just deciding. I didn’t plan that symmetry. It’s just what working in unknown territory costs.

Second, and this is where I lied to myself: the per-turn token cost is basically flat. On the content pipeline, a conversation turn and a tool-action turn cost within about three percent of each other. Same story on the other project. Coding doesn’t burn more tokens than talking. It just feels like it does, because you sit there watching it work.

The reason is boring and it’s caching. I plan on a million-token context window, and every single turn, whether the agent is writing a paragraph of reasoning or grepping the repo, re-reads roughly the same enormous cached context. The dominant cost per turn is the size of the context, not the activity inside the turn. Reading a cached window is cheap per token, but there’s a mountain of it, and it gets re-read on every message. Planning quietly pays that toll on every back-and-forth and hides it, because nothing visible is happening. Coding pays the same toll and shows you a progress bar, so you blame the progress bar.

So “coding burns more tokens” is just false, at least for how I work. Good. Now I have to figure out what I actually meant.

The Expensive Kind of Cheap

Here’s what I meant, once the data forced me to say it properly:

Planning and coding cost about the same to run. What’s wildly different is the cost of being wrong.

A wrong decision while planning costs one edited sentence. I write “we’ll use X,” I talk it through, I realize X is dumb, I change the sentence to “we’ll use Y.” Done. The blast radius is a paragraph.

The same wrong decision, once it’s code, costs a refactor. Or a dead end. Or a start-over. Because the agent didn’t just write the line that encodes the decision. It wrote the four modules downstream that assume it, the tests that lock it in, the data shapes that depend on it. Agents didn’t make coding cheap. They made typing cheap, which is a different thing, and worse in a specific way: they make your wrong assumptions reality faster and in greater volume than you ever could by hand. By the time you notice the assumption was wrong, it’s load-bearing in a thousand lines.

That’s the real asymmetry. Not tokens. Reversibility. Prose is cheap to be wrong in because it’s cheap to change. Code is expensive to be wrong in because everything else is stacked on top of it. Planning is cheap because you can throw it away for free. Coding is expensive because you mostly can’t.

And I have the scar tissue to prove it. Of the first fifteen-or-so projects I built with AI, something like half either got completely refactored or thrown out and restarted from scratch. I burned out on the whole approach once and the lesson that came out the other side was, essentially: I had to plan more. Every one of those rewrites was a wrong decision I’d committed to code instead of catching in a sentence.

The cleanest example is a choice I didn’t pay full price for. On the content pipeline, this was my first real jump into agentic development: building workflows, not just pointing a coding agent at a repo. I’d done my own reading for a while and my instinct was the LangGraph / LangChain family. It’s what everyone reaches for. But before I committed, I spent planning sessions researching it with the agent and testing a couple of open-source projects built on it. In my testing the tokens just evaporated. Gone, nothing to show. Pair that with a pile of horror stories from people running those frameworks in anger, and I bailed. Landed on Pydantic Graph instead and it’s working well. And I can look at the code and know how it works.

Notice where that decision happened. In research and planning. Cost: a few conversations and a couple of throwaway test runs. If I’d made that call the vibe way (pick LangChain because it’s the default, build three weeks on it, then discover the token hole), that’s not a conversation. That’s a rewrite. Same wrong turn, two completely different bills, and the only variable was whether I found out in prose or in code.

And Planning Is Dense

There’s a second thing the meter doesn’t catch, and it cuts the same direction. My split, 59% talking and 41% building, counts effort. It says nothing about yield, and the yield is lopsided as hell.

Fifteen minutes of planning doesn’t buy fifteen minutes of building. It can buy an hour. A clear decision, a couple of constraints, a handoff to the agent, and it goes and runs with all of it while I do something else. Planning is dense. A little of it aims a lot of building.

Which is the reversibility point again, from the other end. That same dense fifteen minutes, if the decision underneath it is wrong, doesn’t cost you fifteen minutes back. It fans out into the whole hour that got stacked on top of it. Leverage runs both ways. A good plan multiplies what you build; a bad one multiplies what you rewrite. The denser the planning, the more each decision is worth getting right while it’s still just a sentence.

Even the Prototype Gets a Plan

The obvious objection: “Fine, but prototypes are throwaway. The whole point is to build junk fast and learn from it. Planning a prototype is like drawing blueprints for a sandcastle.”

I used to believe that. I don’t anymore, and it’s the same reversibility argument.

A prototype with no plan doesn’t actually test anything. It just generates code that looks like it works, which is the single most expensive output there is, because it lies to you convincingly. If you can’t say what question the prototype is supposed to answer, you haven’t built an experiment. You’ve built a thing that runs.

Planning a prototype doesn’t mean a spec. It means one honest sentence: what am I actually trying to find out here? Does this framework survive my token budget? Does this data shape hold up when the input gets weird? Can this feature even do the thing before I build the other five around it? That’s the plan. It’s cheap (cheaper than the prototype), and it’s the difference between a prototype that de-risks the project and one that just adds a codebase you’ll abandon.

The stakes go up in unknown territory, not down. When you already know the domain, you can afford to skip ahead, because your gut is a decent planner. When you don’t know the domain (which is where I live now, on purpose), the plan is the only thing standing between you and confidently building the wrong thing very fast.

My Freeform Rhythm

None of this means I plan the whole thing up front and then march. I never have. My process, long before AI, was tracer bullets with the safety off.

Back when I built scrapers (and I built a lot of scrapers), I’d start with a command-line app that did the one core thing. Does it actually pull the data? Yes? Okay. Then maybe a little Electron UI to wrap it. I had a vague idea of the architecture I wanted, but I’d build it up, change it, and refactor mid-stream constantly, because I wanted to see the result. That’s the honest core of it: I’m a creator and a builder more than a technologist. Code, AI, tools: those are how I make things, not the thing I love. I jump toward the result.

The AI version of this is the same shape. I get one feature working really well (not “it runs,” but “it does what I actually want as the end user”), and then I jump. Right now the article-writing pipeline is about 75% of the features I want, and I’ve hit the part I’ll admit out loud is boring. Nothing new is going to surprise me in the last 25%. There’s no “whoa, that’s cool” left in it, just grind. And I can grind, but there’s a timer on how long before I need something interesting again.

So I’m jumping to the novel-writing feature, because that’s going to be interesting for a while. The rest of the article pipeline goes on the back burner until I’m in grind mode again. One rule I don’t break, though: I’d rather leave a feature incomplete than ship one that isn’t what I want. I test each one as the actual end user (not “does it run,” but “would I be annoyed using this”) because I’ve learned the hard way that assuming a feature is right and backtracking later is exactly the expensive-code problem that is the point of this post. Incomplete is free. Wrong is a refactor.

Yeah, this probably means a pileup at the end, where everything I put off comes due at once and it’s grind mode for days. I’m aware. But that’s for the Stephan of tomorrow. He is much more patient than the Stephan of today…I tell myself.

Planning Is Also How I Learn the Thing

There’s one more reason planning earns its 59%, and it’s not on any token report.

I’m learning these domains while I plan them. I don’t know Pydantic Graph cold. I’m learning it as I go. I’m learning how graphify’s guts work slowly, session by session, on the other project. A big chunk of what looks like “planning” is really the agent teaching me the terrain before I commit to a route through it. Every back-and-forth where it explains why a graph approach beats a chunked one, or what a framework’s failure mode is, is a decision I now get to make with my eyes open instead of discovering the map by driving off the cliff.

And that learning compounds into things I couldn’t have specced on day one. Enough sessions poking at graphify taught me its node-and-edge model. Well enough that when I wanted my whole Obsidian vault in a graph, the agent didn’t just charge ahead and it didn’t flat refuse either. It made a reasoned call: pointing graphify at all ~2,400 notes in one shot wasn’t worth the grind, here’s why. So on a different project I had it build a custom connector instead, one that pulls every note’s folder, tags, and wikilinks out as structured facts, the exact raw material a graph turns into edges. I couldn’t have asked for that connector, or understood why the agent was right to talk me out of the brute-force version, before graphify taught me what a graph actually wants. The planning didn’t just produce decisions; it produced a version of me who knew enough to ask for the right thing.

Which is exactly why I never use plan mode. The official one, the structured feature: I don’t touch it, not for anything open-ended. It collapses the conversation into multiple choice. Pick A, B, or C. And when a decision is still half-formed, the options are never quite the thing in my head. I end up arguing with the menu instead of thinking. I want the back-and-forth: ask a question, get an answer, push on it, change my mind three exchanges in, then decide. That messy conversation is what has to happen. It’s where the learning lives, and it’s where the cheap decisions get made before they turn into expensive code. I wrote up the actual machinery I use instead (one living plan doc, numbered decisions, the whole system) in the living-plan post, so I won’t rerun it here.

So, Cheap Compared to What

I’m not here to tell you you’re doing it wrong. I genuinely don’t care if the vibe-coder down the street thinks planning is for cowards. Live and let live. Or live and mortgage your house to cover your coding bill, your call. Some of the best things I’ve built started as pure “just build it and see.” Prototyping to figure out how something even works is real and I do it constantly.

But I pulled my own numbers hoping to prove coding was the expensive part, and the meter told me the truth instead: it costs about the same as talking. The expense was never in the tokens. It’s in the concrete. A wrong sentence is free to fix. A wrong foundation is a rewrite, and the agent will happily pour you a bigger one, faster, than you could ever pour yourself.

So plan the thing. Plan the prototype, even. Especially the prototype. Not because planning is virtuous. Because it’s the only place left where being wrong is still cheap. Unless you’re a millionaire, of course, but for us working stiffs, coding still costs real money.