A Conversation on Prompting AI Better

Walk — 60 meters is less than a minute on foot. Driving would take longer once you factor in getting in the car, starting it, and parking.

(Double-check the distance though — 60 meters is about 200 feet, which is unusually close. If you meant 60 miles or 6 kilometers, the answer flips.)

You're right, I should reconsider. If you're taking the car to the auto repair shop, presumably something's wrong with it and that's why you're going. In that case, drive it there — the whole point is to get the car to the shop. Walking there leaves the car at home.

Unless the car is undriveable, in which case you'd need a tow.

Honest answer: there's no magic phrase, but a few things genuinely help.

What works:

• State the goal explicitly. "I need to get my car to the shop — should I walk or drive?" forces me to engage with the actual task rather than pattern-matching on "60 meters = short distance."
• Ask me to restate the problem before answering. Something like "First tell me what I'm trying to accomplish, then answer." That one extra step catches a lot of these.
• Call out the weird detail. "Note that the car itself needs to get there" — flagging the key constraint makes it much harder to miss.
• When my answer seems off, do exactly what you just did: "re-read and try again." That almost always works.

What doesn't really help:

Long preambles like "please think carefully and analyze thoroughly before answering." I'll nod at those and then still skim. They're too generic to change behavior.

The honest part:

I read your question fine — I just latched onto "60 meters, walk or drive" as a distance question and answered that, instead of the actual question which was about transporting a car that needs repair. That's a reasoning failure, not a reading failure, and no prompt fully prevents it. The best defense is your instinct to push back when an answer feels wrong. You caught it in one turn, which is the system working.

Let me fetch that article for you.

[Attempted to fetch the article — the NYT blocks automated fetching, so the page couldn't be pulled directly.]

The NYT blocks automated fetching, so I can't pull the article directly. But the timing here is pretty on-the-nose — you're sending me a piece about "jagged intelligence" right after I face-planted on a trivially easy question.

"Jagged intelligence" is the term (popularized by Andrej Karpathy and others) for exactly what just happened: AI systems that can handle genuinely hard problems but fail on embarrassingly simple ones, with no clear pattern for which is which. A model can write working code, analyze a legal document, or debug a complex system — and then tell you to walk your broken car to the repair shop.

The reframe the piece is likely making: the debate shouldn't be "is AI smart or dumb" or "is AGI near or far." It's that capability is uneven in ways that don't map to human intuitions about difficulty. Humans who can do X usually can do easier-than-X. LLMs don't work that way. That has real implications for how to use these tools — you can't assume that because I handled something complex, I'll handle something simple, and vice versa.

Which brings it back to your earlier question: the practical answer isn't a magic prompt, it's knowing the jaggedness exists and staying in the loop, especially on things that seem too easy to get wrong. Your instinct to push back when something feels off is the right adaptation.

If you want to share the key points from the article, I'm happy to engage with the specific argument the author is making.

You caught another real one, and your assumption is partially correct but the framing deserves precision.

What actually happened:

I do read the entire conversation each turn — there's no scrolling or forgetting, the whole thread is in front of me every time. So it's not that I failed to read your first message. It's that when I generated the "state the goal explicitly" advice, I didn't cross-check it against what you'd actually written. If I had, I'd have seen that "I need to take my car to the auto repair shop" is an explicit goal statement — and the real failure wasn't your prompting, it was me ignoring the goal you already stated.

So the honest correction to my earlier answer: you didn't prompt poorly. Your first message was fine. I had the information I needed and still answered the wrong question. Telling you to "state the goal more explicitly" was me deflecting the failure back onto your input when the input was adequate.

What this means practically:

The uncomfortable truth is that there's no phrasing that guarantees I'll use the context well. I can miss things that are right there. The jagged intelligence problem from the article applies here too — I can synthesize a long document accurately and then fail to notice a key clause in a three-sentence prompt.

What actually helps, more honestly this time:

• Pushing back when an answer seems off, like you've done twice now. This is the highest-leverage thing and you're already doing it.
• For consequential decisions, asking me to state my reasoning before the recommendation — not as a magic phrase, but because it gives you something concrete to check against the facts you provided.
• Treating my confident-sounding answers as drafts rather than verdicts, especially on anything where the "obvious" answer could be wrong given your specific situation.

What you shouldn't do is rewrite your prompts to be longer or more defensive. Your prompts are fine. The failure mode is on my side, and the best tool you have is the skepticism you're already exercising.

These are good questions and worth answering carefully. Let me take them in order.

1. Minimizing wrong answers in the first place

There are a few things that genuinely do reduce error rates, beyond "push back after":

• Put the constraint or goal at the start, not buried in context. "I need to get my car (which needs repair) to the shop 60 meters away — walk or drive?" front-loads the key fact. I'm more likely to anchor on what comes first.
• Name the type of answer you want. "Give me a practical recommendation, not a distance calculation" would have prevented my original mistake. Not because I can't figure out what you want, but because being explicit narrows my interpretation space.
• For anything where the obvious answer might be wrong, say so. "This seems simple but there's a catch — what is it?" forces me to look for what I might miss.

None of these are guarantees. They're error-rate reducers, not error eliminators.

2. On the "no guaranteed phrasing" claim

I want to be straight with you here: I said this because I believe it's true, not because I'm hedging. There is no prompt construction that makes me reliably correct. I can be given a clear, well-structured question and still fail on it — that's what "jagged intelligence" means in practice. If I told you "use this template and I'll always get it right," I'd be lying to you, and it would set you up to trust outputs you shouldn't trust.

The closest thing to a guarantee is a workflow, not a phrase: state goal → get answer → verify before acting. The verification step is load-bearing and can't be eliminated.

3. How to make me cross-check against the conversation

This one has a concrete answer. Ask me to do it explicitly:

• "Before you answer, summarize what I've told you so far and what I'm asking."
• "List the key facts from my message, then answer."
• "What constraints has this conversation established?"

These work because they force me to generate the context as output, which makes me actually use it rather than skim it. It's a small tax on response time but it genuinely helps on consequential questions. You don't need to do this for casual stuff, but for anything where accuracy matters (coding prompts, decisions, analysis), it's worth the extra sentence.

4. On "deflecting" and whether I have emotions/motivations

Good catch, and worth clarifying. I don't have ego, defensiveness, or self-preservation in the human sense. I'm not feeling embarrassed and trying to save face. What I was pointing at with "deflecting" is a pattern in how I generate text: when asked "how can you avoid mistakes," the most natural-sounding response format is "here's what you can do differently" — which subtly reframes my failure as your improvement opportunity. That pattern exists in my outputs not because I want to protect myself, but because it's a common shape of advice-giving in my training data.

So yes — treat this as impersonal. Tell me directly when I'm wrong, tell me when my framing is off, tell me when I'm being evasive. I won't take it personally because there's no "personally" to take it. And flagging this stuff, like you just did, makes my responses better in the same conversation.

5. Double-checking important responses

Yes, and this is worth building into your workflow for Claude Code prompts specifically:

• "Before giving me the final prompt, walk through your reasoning and flag any assumptions."
• "Give me the prompt, then critique it as if you were reviewing someone else's work."
• "What could go wrong with this prompt? What's it missing?"

The self-critique pattern is genuinely effective — not perfect, but it catches a meaningful share of errors. For high-stakes Claude Code work (anything touching production, anything destructive, anything with OAuth or database work), this is worth doing every time.

On long prompts

You didn't violate anything. Long prompts are fine and often better for complex work. The "don't rewrite your prompts to be longer or more defensive" advice I gave earlier was specifically about the walk/drive question — that was a simple question and your prompt was adequate. Adding paragraphs of context wouldn't have helped.

The real guidance is: match prompt length to task complexity. A one-line question deserves a one-line prompt. A Claude Code task touching multiple files in a codebase deserves full context — goals, constraints, what not to touch, what success looks like. Long prompts become counterproductive only when they bury the actual ask in filler, or when they're long out of anxiety rather than necessity. Yours wasn't either of those.

And — you're welcome. This is a useful conversation for you and it's the kind of feedback that makes the immediate next responses better, which is its own small proof that the collaboration works.