The Secret Life of Claude Code: Plan First, Code Second
The Secret Life of Claude Code: Plan First, Code Second
Why the most important conversation with Claude Code happens before you begin coding
#ClaudeCode #CodingWithAI #Programming #DeveloperLife
Margaret is a senior software engineer. Timothy is her junior colleague. They work in a grand Victorian library in London — the kind of place where no one is expected to know everything, but everyone is expected to know what they don't know.
Episode 8
You Need a Plan
The evening had turned cold, and Timothy had come prepared for it this time — coat buttoned, scarf wound twice around, a general air of having thought ahead. Margaret noticed this when he came through the tall doors and filed it away without comment.
He settled into the chair across from her and set his notebook on the table. It was open already, to a page that was mostly blank. This, too, she noticed.
"I've been thinking about something since Thursday," he said.
Margaret set aside the monograph she had been reading. "Tell me."
"I've been practicing the briefing. Context first, then the prompt. It's working — the output is better, more precise, less time correcting." He paused. "But I had a situation yesterday where even the briefing felt like I was arriving too late."
"Too late to what?"
He looked at the blank page in his notebook. "Too late to catch the mistake I'd already made before I opened Claude Code at all."
Margaret was quiet for a moment. Outside, the wind moved through the street, and the gas lamps flickered once and steadied.
"Describe the situation," she said.
"I had a feature to build. I understood it well enough — or thought I did. I wrote the briefing, I asked Claude Code to help me implement it, and we worked through it together. Three hours. The code was clean, the logic held, the tests passed." He closed the notebook. "Then I showed it to a colleague and she pointed out in about four minutes that I'd built the wrong thing entirely. Not wrong in execution. Wrong in conception."
"What had you missed?"
"I'd solved the problem I understood. There was a second problem — adjacent, related, invisible to me until she named it — that my solution made significantly worse." He looked at Margaret steadily. "Claude Code couldn't have told me that. I never gave it the chance. I arrived with a solution already half-formed in my head and used the briefing to dress it up."
Margaret picked up her pen and turned it slowly in her fingers.
"You didn't need better context," she said. "You needed a plan."
What a Plan Actually Is
"I thought I had a plan," Timothy said. "I knew what I wanted to build."
"Knowing what you want to build is not a plan," Margaret said. "It is a destination. A plan is the thinking you do before you begin moving — the questions you ask while you are still free to change your mind without cost."
She drew a single horizontal line across a fresh sheet of paper. At the left end she wrote problem. At the right end she wrote code.
"Most developers live here," she said, tapping the right end. "Some have learned to live here." She tapped the middle. "Very few spend real time here." She placed her pen at the far left, before the word problem.
Timothy looked at the line. "Before the problem?"
"Before the problem as you have currently framed it," Margaret said. "Because the framing is the most consequential decision you will make, and it is almost always made in haste, in the first five minutes, before you have asked a single clarifying question."
He thought of yesterday. He had read the ticket, understood it immediately — or believed he had — and opened his notebook to begin the briefing. The framing had happened without his noticing it. It had happened in the moment of reading.
"So the plan begins with questioning the frame," he said.
"The plan begins with sitting still long enough to wonder whether you are solving the right problem," Margaret said. "That is harder than it sounds. The mind wants to move. The moment you understand a problem well enough to imagine a solution, the imagination has already begun building. Stopping it requires discipline."
Claude Code As Your Thinking Partner
Timothy turned to a fresh page in his notebook. "How does Claude Code fit into this? Before the code, I mean."
"This is what most developers do not discover until much later," Margaret said. "Claude Code is not only a builder. It is a thinking partner. And it is, in some respects, a better thinking partner before the code exists than after."
"Because after, you're defending what you've already built."
"Precisely. Once code exists, it exerts a kind of gravity. You begin to think around it, to preserve it, to explain why it is correct. The sunk cost of having written it shapes every question you ask afterward." She set down her pen. "But before the code exists, you are free. And Claude Code, given the right prompt, will help you think — not build."
Timothy wrote this down. "What does that prompt look like?"
"It looks nothing like a briefing for implementation," Margaret said. "It begins not with what you want to build but with what you are trying to solve. And then it asks Claude Code to push back."
He looked up. "To push back."
"To find the holes. To name the assumptions. To ask what happens in the cases you have not considered. To tell you what adjacent problems your proposed solution might create." She paused. "You are not asking Claude Code to validate your thinking. You are asking it to stress-test it."
This was a different posture entirely, Timothy thought. Not help me build this but help me find out if this is worth building.
What Does a Proper Plan Contain
"What does a proper plan contain?" he asked. "If you were to describe it."
Margaret considered this. "It contains, at minimum, four things. First, a clear statement of the problem — not the solution, the problem. Written out, in plain language, without reference to implementation. If you cannot write it without mentioning code, you do not yet understand it."
Timothy wrote: Problem statement — no implementation language.
"Second, the constraints. Not just technical constraints — time, dependencies, performance requirements — but human ones. Who will maintain this? Who will be affected if it changes? What cannot be broken in the process?"
Constraints — technical and human.
"Third, the definition of done. Not 'the feature is built' — that is a beginning, not an end. What does success actually look like? How will you know, without ambiguity, that the thing you built is the thing that was needed?"
Definition of done — specific, unambiguous.
"And fourth," Margaret said, "the risks. What could go wrong. What you don't know. Where your understanding is weakest." She looked at him. "Most developers skip this one entirely. It feels like pessimism. It is the opposite — it is the most optimistic thing you can do, because it is the only step that gives you a chance to address the risks before they become failures."
Risks — what I don't know.
Timothy looked at his notes. "Four things. And Claude Code can help with all of them."
"With the right prompts, yes. Ask it to find holes in your problem statement. Ask it what constraints you might have missed. Ask it to propose three different definitions of done and explain the tradeoffs between them. Ask it what risks a senior engineer would identify in your approach." She paused. "None of this produces a line of code. All of it makes the code that follows better."
The Cost of Having No Plan
"What I built yesterday," Timothy said slowly. "The three hours. The clean code. The passing tests."
"Will need to be revisited," Margaret said, without judgment.
"Most of it, yes." He was quiet for a moment. "If I'd spent thirty minutes planning — actually planning, the way you're describing — I think I would have found the second problem before I started."
"You might have. Or Claude Code might have found it for you, if you had asked it to stress-test the approach." She tilted her head slightly. "What would thirty minutes of planning have cost you, against three hours of rework?"
It was not a difficult calculation. But Timothy found himself thinking that the real cost wasn't the three hours. It was the confidence he'd had going into it — the certainty that he understood the problem — and the particular deflation of discovering that certainty had been unfounded. That was the cost that didn't show up in any estimate.
"The plan isn't just about efficiency," he said.
"No," Margaret agreed. "It is about arriving at the work with clarity rather than assumption. The plan is the difference between building and building the right thing." She glanced at the window, where the cold had begun to press frost against the lower panes. "Speed without direction is not progress. It is a very efficient way of arriving somewhere you did not intend to go."
Helps You Better Understand the Problem
"One more thing," Margaret said, as Timothy was reviewing his notes.
He looked up.
"Sometimes the plan reveals that the problem itself is wrong. Not your framing of it — the problem. Someone upstream made an assumption that was never examined. A requirement was written based on a misunderstanding. A feature was requested to solve a symptom rather than a cause." She paused. "This is uncomfortable to discover. It is also the most valuable thing the planning process can produce."
"Because catching it before the code is written means you can still do something about it."
"Yes. And because the person who catches it — who comes to the conversation not with a built thing to defend but with a plan and a question — is taken far more seriously than the person who returns after three hours with code that solves the wrong problem."
Timothy thought of his colleague, the four minutes, the quiet precision with which she had named what he had missed. She had not been unkind. But he had felt the weight of having moved too fast.
"The plan is also how you earn the right to push back," he said.
Margaret looked at him with something that might have been approval. "Yes. Precisely that. You cannot question a requirement you have not examined. You cannot improve a problem statement you accepted at face value. The plan is the work of examining — and it is the work that most distinguishes the developer who builds things from the developer who solves problems."
Timothy closed his notebook and reached for his coat. The library had grown quieter around them, the last of the evening visitors long since departed, the shelves settling into their familiar nighttime silence.
"I'm going to go back to yesterday's feature," he said. "Before I touch the code."
"Good," Margaret said.
"Thirty minutes. Problem statement, constraints, definition of done, risks. Then I'll ask Claude Code to find what I've missed."
"And if it finds something?"
"Then I'll be glad I asked." He stood, buttoning his coat. "And if it doesn't find anything, I'll trust the code more than I did before."
Margaret nodded once. "That is the other thing a plan gives you," she said. "Not just clarity before. Confidence after."
He picked up his notebook and walked toward the tall doors, the frost on the lower window panes catching the lamplight in small bright lines.
Behind him, Margaret returned to her monograph, the scratch of her pen the only sound in the room.
Next episode: Margaret and Timothy explore the discipline of small tasks — why breaking work into the smallest possible units makes Claude Code sharper, faster, and easier to correct when something goes wrong.
Aaron Rose is a software engineer and technology writer at tech-reader.blog.
Catch up on the latest explainer videos, podcasts, and industry discussions below.
Comments
Post a Comment