Three ways Claude Code gets it wrong — and the discipline that catches all of them before they ship
Margaret is a senior software engineer. Tim...
For further actions, you may consider blocking this person and/or reporting abuse
Nice post again. Thanks... While reading it I would say "one should write down the requirements", just few lines before Margaret actually said that :)
In systems engineering approach, software tests are done against software requirements and system tests against system requirements. (for big systems including sw ad hw)
This scenario exactly shows the benefits of these systematic approaches (or the possible pitfalls in case of lacking), regardless of whether the guy that writes the code is human or not.
Thanks again
Hi alptekin,
That moment where you thought it before Margaret said it —I love it! 💯.
You already have the discipline, and you and Margaret are on the same wavelength!
And you've put your finger on something important: the requirement-first principle isn't new wisdom invented for the AI age. It's systems engineering doing what it has always done — insisting that you define what success looks like before you build toward it.
The pitfall Timothy fell into has existed as long as software has.
Claude Code just made it easier to arrive there faster and with more confidence.
Margaret might say the tools change. The discipline doesn't. 🌹
Cheers buddy. Thanks for reading. ❤🙏✨
🙏🌹✨
I've been using the research -> plan -> execute loop more and more to solve for the "solving the wrong problem gap". It definitely produces more accurate/better results, but the tradeoff is speed. I'm still struggling to find the right balance of planning/specificity and openness/speed.
Hi Swift!
You know, Margaret would probably say that the planning phase isn't a tax on your speed — it's an investment that prevents the most expensive thing of all: arriving at the right answer to the wrong question.
But she'd also say the balance you're describing is real, and it takes time to develop. It sounds like you're developing good judgment in coding with AI. 💯
Cheers! 🌹🙏❤
The "wrong problem" failure mode really resonates. I run a multilingual programmatic SEO site with 100k+ pages, and when you're using AI agents to manage content at that scale, this exact failure mode compounds. An agent generates content that's technically correct for the prompt but misses the actual search intent — and suddenly you have thousands of pages with the same subtle gap.
What helped me was building explicit requirement checklists into the agent's workflow itself — essentially automating Margaret's discipline. Before generating any content, the agent has to match against a spec: target keyword, search intent type, required data points, edge cases to cover. It's the 3-4 line spec that Mihir mentioned above, but baked into the pipeline so it can't be skipped.
The "plausible fabrication" one is especially dangerous in data-heavy contexts. When an AI confidently returns a financial metric that looks reasonable but is slightly wrong, you don't catch it by reading the output — you catch it by validating against the source. Trust but verify, at scale.
Hi Apex,
Thanks for reading — and impressive work running a site at that scale.
Love how you've taken the 3-4 line spec and baked it into the pipeline itself so the discipline can't be skipped. That's a great architectural move.
The plausible fabrication point in data-heavy contexts is one I want to return to in a later episode. You've put it precisely: you don't catch it by reading, you catch it by validating against the source. At scale, "trust but verify" quietly becomes just "trust" if the verification isn't automated and mandatory. Thanks for laying out that point so clearly! 💯
Cheers! ✨🙏❤
Really appreciate you engaging with that point, Aaron. You nailed the core tension — at scale, the verification layer isn't optional, it's load-bearing infrastructure. We learned this the hard way with financial data specifically. A P/E ratio that's off by 15% looks perfectly reasonable to a human reviewer, but multiply that across thousands of ticker pages and you've built a site that's confidently wrong at scale.
The approach that finally worked for us was treating source validation as a pipeline stage, not a post-generation audit. Every data point gets checked against the API response before it hits the template. It adds latency to the build, but it's the only way to maintain trust when you can't manually review even 1% of the output.
Would love to read that future episode on data fabrication — it's one of those problems that gets worse the better the model gets at sounding right. Following the series.
The "confidence is not a signal" point really hits home. I've been burned by this exact pattern so many times now. The code looks clean, passes linting, even has reasonable variable names. But it's solving a slightly different problem than what you actually need.
What helped me was getting into the habit of writing a quick 3-4 line spec before prompting. Not a full design doc, just "here's the exact behavior I expect, here are the edge cases." When the output comes back I check against that instead of just reading the code for correctness.
The session expiry example in the article is perfect because it's exactly the kind of subtle logic bug that looks right during code review but breaks in production. Creation timestamp vs last activity timestamp is such a common trap.
Hi Mihir,
'The "confidence is not a signal" point really hits home. I've been burned by this exact pattern so many times now' - welcome to my world! 🤣
That 3-4 line spec habit you described is really powerful. Thanks for sharing that.
The check-against-spec instinct is also great. Reading code for correctness and checking code against expected behavior are two completely different acts. Nice one! 💯
And yes — creation timestamp vs last activity timestamp. It really is a common trap!
Thanks for reading! ❤🙏✨
Nice article... the danger of tools like Claude Code is that false sense of something being coded correctly, when a lot of the times it's us that have left out some (or many!) parts of the requirements. I know the headline says "When Claude Code Gets Wrong" but in the article I just read, I'm pretty sure it wasn't Claude Code that got it wrong... ;)
Hi Anthony, You're right: it probably wasn't Claude that got it wrong! 🤣 The tool just answers the question we ask. The real work for us is asking the right question, isn't it. cheers! ✨💯
This piece provides a nice exploration of the “Senior vs. Junior” mentality when working with ai tools. The difference between “the code isn’t broken” and “the code isn’t what you needed” provides a critical piece of advice. It reminds us that the most important work happens before the first prompt is sent. Do you find that taking the time to write down physical requirements before prompting significantly reduces the “Wrong Problem” failure mode in your day-to-day?
Hi xh1m!
Yes, for me, the act of writing requirements down, even just three or four bullet points, does something that thinking alone doesn't. It forces me to be more precise. Ideas that feel vague in my head become more clear the moment I try to write them in a sentence.
And to your point about senior vs. junior mentality — that is a major theme in this series. I think the senior developer's advantage is knowing what questions to answer before the tool ever gets involved.
Thanks for reading! ❤✨🙏
A movie plot 👏🏾
🙏❤✨
Thanks for content, I really find that AI is quite hard to explore :)
H SoftwareDevs, I feel the same way! it's a challenge to code with AI for sure. Thanks for reading. Cheers! ❤🙏✨