The model won’t question your premise

Claude Code will check almost anything you point it at. It will test the code, review its own work, hunt for edge cases it hasn’t covered, and argue with you about whether an approach is sound. What it won’t do is ask whether the premise is the right one, because it’s not really part of the work, it’s the foundation.

A premise here is whatever was already true when the session started and never got said out loud. It doesn’t get examined because nothing draws attention to it, and everything built on top of it can be correct, tested and reviewed while the premise underneath is quietly false. So you have to make sure it’s understood.

Six careful rounds against the same imaginary person

The food journal app I’m working on tries to spot which food is behind a symptom, which is easy to get wrong in ways nobody would ever notice, so it gets tested against generated diaries where I already know the answer. Plant a culprit food in a fake person’s history, run the engine over it, and see whether it finds the right one and how often it accuses something innocent.

I ran round after round of that, tuning thresholds, comparing approaches, measuring how often it got the answer right against how often it cried wolf. Each round changed one thing, held the rest still, and came back with numbers I could act on, which I did.

In every one of those rounds, the planted culprit made the imaginary person ill about half the times they ate it. That’s a severe reaction, and it’s the easy case, because a food that hits you every other time is one you’d have worked out on your own without an app. The person this is actually for has something milder, where a food nudges the odds a little and the pattern is buried in everything else they eat.

But that 50% chance to feel ill was never a decision I made: the model picked it, probably because the extreme case looked like the one worth handling. It wasn’t noted down and it became a premise that was auto-accepted as true, because the code was there and previous sessions worked with it.

When I finally turned the planted effect down to that, the results from all those earlier rounds stopped holding, and the engine went from looking dependable to looking close to useless. The method had been sound every single time; it had just been run, over and over, against a person who didn’t need the app.

Speed is what makes that expensive, because 6 careful rounds resting on one unexamined assumption or an automatically accepted premise give you the wrong thing 6 times. And sometimes that makes it worse, because after 6 rounds of testing, you might finally get a good answer and believe it worked out, while the premise everything is built on is still false.

The version that went right

The same project had a stretch of work aimed at compensating for a problem we were fairly sure existed. Some weeks in, we measured whether the problem was actually there at the sizes that matter, and it wasn’t, so the thing built to compensate for it got deleted and the work redirected.

That is the good outcome, and the only difference between it and the one above is that the premise got tested at some point rather than assumed all the way through. It cost weeks, and it would have cost much more as a permanent knob nobody understood, sitting in the product, quietly adjusting something that never needed adjusting.

Getting at premises

I’d like to claim I state the assumption before the work starts, in a sentence, and check it before building anything on top. I don’t, not reliably, and every one of the above surfaced late or by accident. What has actually helped is a question that works at any point, including halfway through: what would have to be true for this to be the right approach? The answer is usually a premise, and often it’s the first time anyone has written it down.

There are two tells I missed at the time and now watch for. If hardening something keeps turning up new variants of the same failure, the premise is most likely wrong rather than the implementation, and every fix is buying a bit of time. And when a value gets picked for you along the way, by the model or by a session weeks ago, it stops looking like a choice very fast and starts looking like a property of the problem.

The last post is a look back at what all of this actually changed in how I work.

Send me the premise that got you, if you have one: @roland.leth.ro or @rolandleth.

The rest of the series is listed in What changed my mind about building with AI.