You've learned not to trust the first answer.

So you read it carefully. You spot two problems. You fix them yourself, ship it, and move on. That's a reasonable way to work, and it's what separates an engineer who uses these tools well from one who copies and pastes.

But there's a step you skipped. You never asked Claude to find the problems, and asking produces a different kind of output than reviewing does.

🔍 What actually happens

Here's a specific case. You ask for an incremental load. You get something clean: a watermark column, a filter on records newer than the last run, an upsert into the target.

You review it. You notice it assumes source records arrive in order, which yours don't, so you add a buffer window. You notice it doesn't handle the first run when the watermark is null, so you add a default. Two fixes, maybe fifteen minutes, and now it's correct.

What you didn't find was the third problem: the upsert assumes a stable business key, and in your source system that key gets reassigned when records are merged. That one surfaces in production six weeks later as duplicate rows nobody can explain.

You caught the problems you were looking for. You didn't catch the one you weren't.

This is the normal outcome of self-review. You check against your own mental list of things that go wrong, and your list is good but finite. The problems that hurt are the ones outside it.

🧠 Why intermediates specifically miss this

Beginners don't review AI output much at all, so this isn't their failure mode yet. Seniors have usually developed the habit after being caught out by something their own review missed.

Intermediates sit in an awkward middle. They have learned, correctly, that AI output needs questioning. And they have concluded, understandably, that the questioning is entirely their job.

That conclusion makes sense. Reviewing is what you do with a junior's pull request. It's what you do with your own code before you push. Review is a human activity performed on work someone else produced, so of course you review the model's output yourself.

The step that doesn't occur to you is asking a second, differently-shaped question about the same code. Not because the model has privileged knowledge about its own output, but because a request to find problems produces different text than a request to solve one.

✅ The prompt

After any output you intend to ship, send this:

Critique this. What breaks first? What did you assume that I didn't tell you?

One extra turn. Here is what each part is doing.

"Critique this" changes the task. You asked for a solution and got one. Asking for problems produces a different response, and the overlap with what you already noticed is usually partial.

"What breaks first?" forces a ranking. You don't want a list of twelve theoretical concerns. You want the one most likely to actually fail, which is usually the only one worth acting on today.

"What did you assume that I didn't tell you?" is the most useful clause and the one people leave out. Every answer rests on things filled in from nothing, because you didn't specify them. Source ordering. Key stability. Null behaviour on first run. Timezone consistency. Surfacing that list is how you find the problem outside your own checklist.

In the incremental load example, that third clause is what surfaces the business key assumption. Not because the model knew it was a problem, but because listing assumptions is a mechanical task and you can then check each one against a system you know and it doesn't.

⚖️ The objection worth taking seriously

The weak version is "if it knew what was wrong, why didn't it say so the first time?" Easy to answer: you asked for a solution, not a critique.

The stronger objection, and one with real evidence behind it: models asked to critique their own work do not reliably identify their own errors. There is published research finding that self-correction without external feedback can leave output unchanged or make it worse, and that a model asked to find problems will often generate plausible-sounding concerns about code that is fine. If you treat the critique as a defect list and implement every item, you can end up with something more complex and less correct than what you started with.

That is a real limitation and it changes how you should use this. The value here is not that the critique is accurate. It's that it produces a list of things to check, and you are the one doing the checking. "This assumes source ordering" is useful to you because you know whether your source is ordered. The model doesn't. You're using it to widen the search, not to make the judgment.

Used that way, a wrong item in the critique costs you thirty seconds of reading. Used as a defect list, it costs you a worse pipeline. The distinction matters more than the prompt does.

🎯 The takeaway

One extra turn on anything you plan to ship:

Critique this. What breaks first? What did you assume that I didn't tell you?

Read the response as candidates to check, never as defects to fix. Most of the value sits in the last question, because the assumptions you never specified are exactly the ones you won't think to review.

This is post #3 in a series on AI practice for data engineers. Next up: **You Forgot to Mention the 500 Million Rows.**