What to do when Claude Code gets it almost right — and how one disciplined follow-up gets you the rest of the way there
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 conversations are finished properly, and where almost right is understood to be a different thing entirely from right. Timothy has arrived today with something he is not sure what to do with.
The Almost
He sat down without his usual preamble and turned the laptop toward her immediately. This, Margaret had learned, meant he wanted her to look before he explained. He was uncertain about something and did not yet have the words for it.
She looked.
On the screen was a function — a data export utility, clean and reasonably structured. She read it the way she always read code: slowly, without expression, beginning to end.
"Claude Code?" she said.
"Yes. Second attempt, actually. The first one was completely off. This one is..." He paused. "Close."
"Close," she repeated.
"It handles the main cases. The CSV export works. The date formatting is correct. But it doesn't handle empty datasets — it just throws an error instead of returning an empty file. And the column headers are hardcoded when they should come from the data schema."
Margaret looked at the code again. "And what did you do when you noticed this?"
Timothy hesitated. "I'm not sure whether to fix it myself, start over with a new prompt, or..." He trailed off.
"Or what?"
"Or tell Claude Code what's wrong and ask it to fix it."
Margaret set the laptop down between them. "That third option," she said. "That is what we are going to talk about today."
Why Developers Don't Follow Up
"Most developers," Margaret said, "when they receive output that is almost right, do one of three things. They accept it and patch it manually. They discard it and start over from the beginning. Or they send a vague correction and hope for the better."
"I've done all three," Timothy admitted.
"Most people have. None of them are wrong exactly — but none of them are the most effective approach either." She picked up her pen. "Patching manually makes sense for a trivial fix. Starting over makes sense if the output is fundamentally misconceived. But when the output is close — when the structure is sound and only specific behaviours are wrong — there is a better path."
"The follow-up."
"The follow-up," she confirmed. "Which is not simply sending another message. It is a skill. And like the first prompt, it requires thinking before typing."
What a Follow-Up Actually Is
"Think about what Claude Code knows at this point," Margaret said. "It has your original prompt. It has the solution it produced. It has no idea what you think of that solution — what worked, what didn't, what you expected that you didn't get."
"So I need to tell it."
"Precisely. But how you tell it matters enormously." She turned the notepad toward him. "A poor follow-up says: this doesn't work, try again. It gives no information. Claude Code will produce another attempt — possibly better, possibly worse, almost certainly not targeted at the actual problem."
Timothy was already nodding. He had sent that message before, in different words.
"A good follow-up," Margaret continued, "does three things. It acknowledges what worked. It identifies precisely what didn't. And it adds any context that was missing from the original prompt — because if the first output was wrong in a specific way, that wrongness often reveals a gap in what you originally provided."
She wrote three short phrases on the notepad:
What worked.
What didn't, and exactly how.
What I should have told you the first time.
"That third one," Timothy said. "That's the one people skip."
"Always," Margaret said. "Because it requires admitting that the original prompt was incomplete. Which it almost always is. The first output is not just a solution — it is a diagnostic. It shows you what Claude Code understood from what you gave it. When the output is wrong in a particular way, that wrongness is information about your prompt."
The Diagnostic Read
"Show me the error," Margaret said. "When the empty dataset is passed."
Timothy pulled up the output. The function threw a TypeError — it attempted to access the first row of the data to infer column structure, and when there was no first row, it failed.
"What does that tell you?" Margaret asked.
"That it assumed there would always be data."
"Yes. And why did it assume that?"
Timothy thought for a moment. "Because I didn't mention empty datasets in the prompt."
"Correct. The error is not a failure of Claude Code's ability. It is a reflection of your prompt's silence on edge cases." She looked at him steadily. "This is the diagnostic read. Before you write your follow-up, you ask: what did this output assume that I never specified? The answer to that question tells you exactly what to add."
He turned back to the laptop. "The column headers being hardcoded — that's the same thing. I said 'export to CSV' but I never said the headers should be dynamic."
"You assumed it would infer that from context. It did not." She allowed a small pause. "This is not a criticism of your original prompt. It is almost impossible to specify everything in advance. The follow-up exists precisely because the first exchange is a dialogue, not a transaction."
The Follow-Up Prompt
"Now write it," Margaret said. "The follow-up. Not yet — think first."
Timothy was quiet for a moment. Outside, London was doing what London does in the early evening — settling into itself, lights coming on in the buildings across the way.
"I need to acknowledge that the main export logic is correct," he said slowly. "So it doesn't throw that away and start over."
"Good."
"Then I need to describe the two specific problems. Not just name them — describe them. The empty dataset case should return an empty CSV with headers but no rows. The column headers should be derived from the schema object, not hardcoded."
"Better. And the third part?"
He thought. "I should tell it about the schema object. I don't think I mentioned it in the original prompt at all."
"You did not."
"So Claude Code invented the hardcoded headers because it had no idea the schema existed." He sat back. "The bug was in my prompt."
"The gap was in your prompt," Margaret said, not unkindly. "There is a difference. A bug implies carelessness. A gap implies incompleteness. The first prompt is rarely complete. That is why the follow-up exists."
Timothy wrote the follow-up carefully. He began by saying that the core export logic was working correctly and should be preserved. He then described each problem specifically — what was happening, what should happen instead, and under what conditions. Finally, he introduced the schema object he had omitted, describing its structure and how the headers should be derived from it.
He read it back aloud — the habit Margaret had taught him — and caught one imprecision. He corrected it before sending.
The response came back targeted and specific. The core logic was untouched. The empty dataset case now returned a header row with no data rows. The column headers were drawn cleanly from the schema.
"It didn't start over," Timothy said.
"Because you told it not to," Margaret said. "By describing what worked, you gave it permission to build on what already existed rather than replace it. That is not a small thing. A follow-up that begins with what is wrong invites a complete rewrite. A follow-up that begins with what is right invites a precise correction."
The Conversation, Not the Transaction
"I've been thinking of each prompt as a separate request," Timothy said. "Like placing an order."
"Most people do," Margaret said. "But that is not what it is. Claude Code holds the context of your conversation. It knows what you asked, what it produced, what you said in response. You are not placing a series of independent orders — you are having a conversation with a very capable colleague who happens to have no memory beyond the current session."
"So the follow-up is just... the next thing I would say in a conversation."
"Exactly that. If a colleague had built you this function and you found two problems with it, you would not hand it back and say this is wrong, do it again. You would say — the main logic is good, there are two things to address, and I should have mentioned this third thing earlier. That is a professional exchange. That is what a good follow-up sounds like."
Timothy looked at the corrected function on the screen. Clean, complete, handling every case he needed.
"How many follow-ups is too many?" he asked.
"That depends on what each one achieves," Margaret said. "If each follow-up produces meaningful progress toward the right answer, continue. If you find yourself sending the same correction and receiving the same gap in return — that is the signal to step back. Not to abandon the conversation, but to reconsider whether the context you have provided is sufficient." She paused. "Sometimes the right move is to start fresh with a prompt that incorporates everything you have learned from the previous exchange. The conversation was not wasted. It taught you what the prompt needed to contain."
Before He Left
The library was quieter now. The afternoon had become evening without either of them particularly noticing.
"There is one more thing," Margaret said. "When Claude Code produces something that is almost right — resist the urge to feel that almost right is good enough. It is not impatience or perfectionism to want the right answer. It is professional standards."
"I nearly accepted the hardcoded headers," Timothy said. "I thought — close enough, I can deal with it later."
"Later has a way of becoming never," Margaret said. "And a function with hardcoded headers will cause someone a problem at some point — possibly you, possibly someone who inherits your code, possibly a user. The follow-up costs five minutes. The fix costs considerably more when it arrives at the wrong time."
She picked up her tea.
"Claude Code is a patient correspondent. It does not tire of the conversation. It does not take corrections personally. It does not resent being asked to do better. Use that. The follow-up is not an admission that the first attempt failed — it is the natural continuation of a dialogue that was always going to take more than one exchange to get right."
He closed the laptop.
Outside, the lights of London had come fully on. Inside the library, a developer had just understood something that would change how he worked every day — that the first response is not the destination. It is the beginning of the conversation.
And knowing how to continue that conversation is a skill worth building.
Next episode: Margaret and Timothy turn to a different kind of challenge — reading code you didn't write. How to orient yourself in an unfamiliar codebase, and how Claude Code can help you find your footing without losing your judgment.
The Secret Life of Claude Code publishes every other day.
If this series is useful to you, share it with a developer who needs to hear it.
Aaron Rose is a software engineer and technology writer at tech-reader.blog. For explainer videos and podcasts, check out Tech-Reader YouTube channel.
Top comments (0)