The worst AI code changes start with a quiet guess.
You ask for a small refactor. The tool finds a pattern. It fills the gaps. Then it writes clean code around a false idea.
Tests may still pass.
The fix is simple. Make the tool list its assumptions before writing code.
The failure hides inside the request
Say you ask:
Add retries to failed payment status checks.
The tool may make several guesses:
- Every failed request is safe to retry.
- A timeout means no work happened.
- Two requests cannot cause duplicate work.
Those guesses may be wrong.
The frustrating part is not the mistake. It is how reasonable the code looks afterward.
I kept reviewing the code instead of reviewing its starting beliefs. That was backward.
A good change starts with checked facts.
Use this prompt before risky edits
Paste this before the tool changes any file:
Before editing code, list up to five assumptions you are making.
For each assumption, include:
1. The assumption
2. Evidence from this project
3. The risk if it is wrong
4. What still needs checking
Do not write code yet.
That last line matters.
Without it, many tools will list assumptions and start coding anyway. You want a pause between thinking and changing.
What a useful answer looks like
A weak answer sounds like this:
Retries should be safe because they are common here.
That is not evidence. It is a guess wearing a tie.
A useful answer might say:
The client retries read requests in
src/client.ts. Tests cover status codes 429 and 503. Timeout behavior is not tested. We need to check whether the server can finish after the client times out.
Now you have something you can review.
You can open the file. You can read the tests. You can check the timeout case.
The tool has shown where its confidence ends.
Review the evidence, not the confidence
For each assumption, ask one question:
Can I point to proof inside this project?
Good proof includes:
- A test that names the behavior
- A caller that depends on the behavior
- A config value
- A current design note
- Code that already handles the same case
Weak proof includes phrases like these:
- “This is usually safe.”
- “Most systems work this way.”
- “The name suggests that.”
- “This seems low risk.”
Those phrases are not always wrong. They just need checking.
Use it where guesses cost the most
This prompt helps most when a change touches:
- Data writes
- Login or access rules
- Jobs that may run twice
- Public API behavior
- Error handling
- Old code with few tests
You do not need it for every typo.
Use it when a hidden rule could turn clean code into broken behavior.
The goal is not perfect certainty
You will never remove every unknown.
The goal is to make unknowns visible before they become code.
Once the assumptions look sound, tell the tool to continue. If one lacks proof, stop and check it first.
That small pause changes the review. You are no longer asking only, “Does this code look right?”
You are also asking, “Did it start from the right facts?”
Before your next risky edit, paste the prompt and inspect the first assumption.
Tags: ai, programming, productivity, testing
Top comments (0)