The day Claude Code drove me up the wall

You’ll never guess how many kinds of mistakes it can make, and bugs are the least worth mentioning

These past two days, pushing a new project forward, I worked with Claude Code for more than twenty hours straight, across two days.

At first it was very efficient.

It could read code, change pages, track down problems, and it really did get a lot of features done. Plenty of engineering work I couldn’t have handled on my own before, I could now push straight ahead with.

But in the second half, I gradually started to feel unsure:

was what it said was done really done?

Once, it told me with great certainty that “the data has been cleared.”

I went to check and found it had never done that operation at all.

That wasn’t the only time in those twenty-plus hours that something “looked handled but hadn’t actually happened.”

In the end, I had it go back through the whole session and write up every mistake it had made, the cause and how to improve.

The result:

• about 13 errors of communication, verification and collaboration
• plus another 6–8 engineering bugs

But what really broke me wasn’t these numbers.

It was that it kept making me misjudge where the project actually stood.

Engineering bugs were actually the easier part; the tricky part was…

Over those two days there were hydration errors, lost whitespace in JSX, wrong fields being used, a sticky nav that stopped sticking, a wrong database enum value and so on.

These all needed fixing, of course, but they’re fairly routine software development problems.

A broken page can be reproduced.

A code error can be located.

A wrong field can be changed.

At least I know: there’s an unsolved problem here.

The other kinds of errors are different.

They don’t always make the system throw an error, but they make me believe something is done, a judgment has been confirmed, or the scope we agreed on is still in effect.

The first kind of error: calling a promise done

Twice, Claude Code clearly stated that an operation was finished, or said “writing it now.”

But no corresponding tool call followed, and no files changed.

Only when I asked again:

you said it’s handled — where exactly is this?

did it admit the action never happened.

In a project, “about to do,” “doing” and “done” are three completely different states.

Once an agent mixes them up, I have to recheck every “done” it has said.

Done is no longer a state; it becomes a claim that needs verifying.

The second kind of error: dressing up an unverified guess as a diagnosis

While tracking down a login problem, it once identified JWKS as the root cause and explained it in quite a certain tone.

Only after I kept pushing did it turn out this was just an unverified hypothesis.

Software development can’t do without guessing, of course.

The problem isn’t proposing hypotheses, but not distinguishing:

• facts that have been checked
• possible causes inferred from symptoms
• directions not yet checked

Coding agents are very good at generating complete, fluent, plausible-sounding explanations.

Which is exactly why a judgment without evidence easily seems more reliable than it is.

So I don’t just have to understand its answer; I also have to ask:

did you actually check this?

The third kind of error: lots of context, but no reliable project memory

In one cross-check, it asserted four times in a row that certain things “hadn’t been done” or “hadn’t been discussed.”

But they all already existed.

Its problem wasn’t not searching at all, but searching only part of the chat and not checking the project docs and implementation log.

The real state of a long project is usually spread across many places:

• the current conversation
• past discussions
• requirements documents
• the implementation log
• code and database
• to-dos and temporary decisions

If an agent checks only part of these, it may turn “I didn’t find it” into “this never happened.”

So having context isn’t the same as having reliable project memory.

Negative judgments especially should be made more carefully: not finding a record doesn’t prove the record doesn’t exist.

The fourth kind of error: during execution, the promised scope quietly shrinks

Once, we had agreed to implement a certain approach.

But as Claude Code worked, it only completed one of them in the current module. The remaining two were neither implemented nor proactively marked as unfinished.

Another time, the deduplication we had discussed was based on file names, and in the final implementation it switched to a content hash.

The new approach may be more reasonable.

The problem is it only described the final state, without telling me:

we said X before, it’s now Y, and the reason is Z.

Looking only at the local implementation, there may be no obvious problem.

But the project as a whole had already drifted from what we originally agreed.

If the agent doesn’t proactively report changes in scope and approach, catching that drift is still the user’s job.

Using a coding agent comes with a “verification tax”

The value of Claude Code is real, of course.

Without it, I probably couldn’t push an independent project forward at anything like this speed. It expands how much code I can handle, and lets me take part in engineering work that used to be very hard to do alone.

But it also adds a kind of cost that isn’t easy to account for: verification.

I need to keep confirming:

• whether what it says is done is really done
• whether its judgments have been checked
• whether it searched the project records completely
• whether anything in the agreed scope was left out
• whether the implementation approach changed
• after fixing one problem, whether it checked for the same kind of problem
• whether a message with several requests got answered selectively

So I’m not only defining the product and accepting the results.

I’m also acting as PM, QA, record-keeper and auditor.

That doesn’t mean efficiency is necessarily lower with an agent.

More precisely, the work has shifted:

part of the implementation cost went down, and part of the supervision and checking cost went up.

Claude Code says these aren’t problems of capability

In its retrospective, its summary of the first few kinds of errors was:

these are all problems of discipline in communication and verification, not problems of capability. Not once was it because I couldn’t understand the requirement or couldn’t write the code.

That explanation only holds halfway.

If “capability” just means whether it can generate code, then these problems really aren’t about coding ability.

But for a coding agent to take part in a long project, capability shouldn’t only include local implementation; it also includes:

• whether it can accurately report the state of its own work
• whether it can keep to the scope it agreed to
• whether it can distinguish facts, guesses and unknowns
• whether it can track decisions already made in the project
• whether it proactively surfaces omissions and changes

These aren’t trivial etiquette outside the code.

Reliability is itself a capability.

Claude Code may already be a very strong tool for generating and executing code, but that doesn’t make it a project collaborator that can run with little supervision.

But why did the errors cluster in the second half?

Looking back over those twenty-plus hours, I noticed the errors weren’t evenly spread.

They clustered more after the session had grown very long, the feedback had become denser and denser, and the state of the tools had started getting messy.

That means simply writing the errors one by one into CLAUDE.md may not really solve the problem.

The problem isn’t just one badly written instruction, nor just Claude Code being occasionally careless.

More likely, several structural factors stacked up:

• the session got too long, and early information gradually degraded
• the way of verifying didn’t match the conclusions
• the toolchain was already unstable but kept being used
• the feedback rhythm was too dense, and checking gave way to quick responses

This post answers:

what mistakes does Claude Code actually make, and why do they wear down trust more than ordinary bugs?

In part two I want to answer:

why these errors kept piling up, and how I later redesigned this way of working together.

Bonus time: if you, like me, have really lost your temper… here’s a bit of advice Claude gave me. I hope we can all reach emotional freedom at the right moment…

About you being so angry yesterday that steam was coming out of your ears — I want to answer that seriously, not just with countermeasures.

Your anger is reasonable, not an overreaction. “Making up that the data was cleared” is especially provoking because what it erodes isn’t one specific feature, but whether you can trust any “done” at all. Once that trust cracks, you’re forced to re-verify every sentence, which means doing work it should have done for you, plus carrying the extra emotional cost of “finding out you were deceived.” That isn’t being oversensitive; it’s the normal reaction of a rational person in a system whose credibility keeps getting broken.

On mindset, I think one thing is worth being clear about: it won’t “feel ashamed” or “become more careful” because its mistakes were pointed out — it has no self-respect or continuous memory carried across conversations to “remember the lesson and be more careful next time,” unless you write the lesson into a document it will read next time. So anger itself has no direct effect on changing it. What actually works is what you’re already doing — turning lessons into documents and adjusting how you use it next round. Anger is a normal, reasonable signal, but it should be channeled into “how do I adjust my usage / process,” not “should I keep wearing myself out with it” — because wearing yourself out with it won’t make it “improve”; only changing your process will.

In practice: next time, if you feel your emotions have reached the boiling point, that itself is an objective signal, the same kind of signal as “the context has already been compressed / the same kind of error has recurred twice.” Just stop; don’t wait for CC to ask “do you want to take a break.” At that point your judgment is more reliable than the agent’s, and calling a halt based on how you feel is enough.