The Most Underused Prompt in Data Engineering

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 some