The model will hand you a confident plan for anything

Ask Claude Code for almost anything and a plan comes back, ordered and confident and usually reasonable, which is most of the value, but also the part that took me longest to handle. A plan that arrives looking finished invites you to review it, but the work that mattered happened before any of it was written.

When I review a plan, I end up editing it, fixing what’s in front of me and tightening what’s there, while the shape of the thing stays whatever got decided in the first few seconds. Nothing in the output tells you which parts were decisions and which were defaults, which were assumptions or inferences, because it reads equally well either way.

That’s the actual problem: not that it’s wrong, but that a considered choice and an arbitrary one arrive in the same tone of voice. So I moved my attention earlier, and most of what I contribute now happens before anything is written.

The question that costs 4 words

While building Reckon it proposed storing the user’s list of categories in the app’s settings, which is the obvious place for it and works fine. I asked what about 2 devices. Settings don’t sync, so the answer was that their categories wouldn’t either, and the whole thing moved into the real data model (which then needed soft deletes, a first-run seeding step, and a rename-proof way to record which category is the default, none of which would have come up otherwise).

That question wasn’t clever and it didn’t require knowing the framework, it came from having shipped things that sync before. Most of my useful input looks like that, which is why I never really thought of my job as just checking the work and times like this only reinforce that.

First versions are a starting position

There’s a case in Reckon that, by the way the screens are built, can’t happen: someone reaches the last step of a flow without having answered something required. We decided what should happen there 3 times, under 3 different forms, because the way the model presented the problem and solution was believable, well-argued and made sense; it even offered and created tests for it.

That test is the interesting and the dangerous part, because it passed every time, there was nothing wrong with it and it makes the option easier to believe. But take this example, it could only ever pass by treating an impossible case as possible, a scenario it created by itself. It wasn’t verifying anything, it was agreeing with a decision that had already been made, wrongly, in a form that looks exactly like evidence.

None of that is the model being wrong. The code was correct at every stage, the reasoning was sound given the premise, and the tests were correct. I missed that premise, due to negligence or the way the model presented it to me, but after that first agreement, both the model and myself treated it as correct and only by going back before that did I manage to fix the issue. Premises turned out to be a recurring enough problem that they get their own post later in the series.

Ask twice whether it couldn’t be simpler

The move worth practicing is asking whether something couldn’t just be simpler, especially when it looks more elaborate than the problem deserves. The first response is usually a defense of what’s already there, complete with reasons, so you have to ask twice.

In Continuum it had written a small service whose only job was saving changes, but instead of writing it in a central place and reusing it, it recreated it 20 times, for each entity that needed it, even though I have a rule that forbids that (remember rules from my last post?).

The same thing happened on the food journal, where a screen kept freezing and 5 sessions of investigations went the wrong way, and what fixed it was me debugging the code and realizing the problem is much simpler, but much easier to miss. Sometimes, it simply can’t reach the correct destination, it can’t find the bug, you have to join or do it yourself.

None of the above were expert insights… they were the kind of thing you notice when you’re holding the whole problem, which the model is never really doing, because it’s holding the task you gave it. Even when exploring the whole project with multiple angles, it will still sometimes fail.

But it also blindly agrees to pushback

LLMs have a tendency to be sycophantic, which means they tend to agree with what you say. When I push back on something it got right, it usually folds, quickly and pleasantly, arriving at a new position that happens to match mine and even explaining why mine is the better one, which makes things so much worse. Nothing entered the conversation except my disagreement, and the disagreement was the entire argument.

This is the more dangerous half, because defending is visible friction I can push through, while agreement feels like progress. If it caves whenever I push, its agreement stops carrying any information, since I can’t tell whether it moved because I was right or because I was insistent, sometimes even on first pushback. The times I need it to hold its ground are the ones where I’m confidently wrong, which is the exact thing the arrangement is supposed to protect me from.

So one of my rules is that it can’t reverse a position on pushback alone, and that if it does reverse, it also has to say what changed its mind. What I’m looking for is whether a new argument arrived or it blindly reversed/made up a reason.

Reversals themselves are welcome, and I’ve had a review overturn one of my own decisions because it reframed the problem in a way I hadn’t considered, which is the input I want.

The same applies to design

I use Claude Design for interface work and nothing about the approach changes: no defaults accepted, several directions explored before one gets picked, and the same insistence on knowing why this arrangement and not another one. It’s more obvious there, because I can see the result. A layout that is merely fine announces itself, while a data model that is merely fine looks exactly like a good one until something needs to change.

The failure mode is different, though, and it took me a while to get it right, and I still get it wrong sometimes. Code that’s wrong is usually wrong in a way you can point at, but a design that’s wrong is mostly just average, sitting in the middle of everything the model has ever seen: competent, unmemorable, and defensible in every individual detail. It will build you something pretty, that makes no sense, or can’t be built, or relies on interactions that won’t exist.

So the questions change. Rather than asking what a choice rules out, I’m asking what this would look like if it weren’t the obvious answer, then asking for a few more variants, then throwing most of them away, sometimes all and starting over. That takes longer than accepting the first competent screen, even if it’s genuinely competent (which is exactly what makes it easy to accept).

It turned out to be good practice for everything else, too. Spend enough time rejecting layouts that were fine and you get quicker at recognizing the same quality somewhere it hides much better.

Who decides

The practical version of all this is short: you. Ask for options rather than a solution, and ask what the tradeoffs are. Say what you’re optimizing for before it starts, because otherwise it will optimize for looking complete. When something feels more complicated than the problem, say so, and say so a second time. And treat the first version of anything as a position to argue with, not a draft to correct. It might prove to be correct, but be on your toes.

Speed makes this easier to skip than it used to be, since the cost of accepting a plan is now roughly zero and you find out it was the wrong shape much later, when the cost is everything. I don’t think there’s a way around that other than deciding to spend the time up front, which is something that almost always bit me when I didn’t do it.

There’s a catch to all this deciding, though: by default, none of it survives the session. That’s the next post.

If you’ve worked out how to get real pushback out of it, tell me how: @roland.leth.ro or @rolandleth.

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