Context and Review
Give AI useful context, detect confident mistakes, and keep generated work concise and maintainable.
AI does not know the whole system. It sees the context provided to it, may rely on stale general knowledge, and can produce a coherent answer when evidence is missing. Good context improves the proposal; verification decides whether it is correct.
Build a context pack
Include only what helps the task:
- the outcome and why it matters;
- current behavior and evidence;
- relevant files, interfaces, schemas, and tests;
- supported versions and repository conventions;
- security, privacy, performance, and compatibility constraints;
- non-goals and acceptable trade-offs; and
- a precise definition of done.
Do not dump the entire repository. More context can add noise, expose information, and hide the important constraint. Remove secrets and data that the approved tool does not need.
Make uncertainty visible
Ask the tool to separate:
| Kind | Expected response |
|---|---|
| Observed | Point to the file, output, test, or source |
| Inferred | State the reasoning and confidence |
| Unknown | Say what must be inspected or measured |
| Proposed | Explain trade-offs and how to verify it |
Check version-sensitive facts against primary documentation. Confirm that referenced APIs, flags, packages, and configuration fields exist in the versions the repository uses.
When AI is wrong
Do not argue with a confident answer. Return to evidence:
- Reproduce the behavior independently.
- Inspect the exact code path and inputs.
- Reduce the problem to the smallest failing example.
- Ask for competing explanations and a test that distinguishes them.
- Discard the answer when evidence contradicts it.
The model does not receive authority by sounding certain.
Prevent low-value generated work
AI slop is output that looks finished but adds little trustworthy value: repeated prose, generic comments, unused abstractions, shallow tests, invented claims, or code no one owns.
Before review, remove anything that does not help a reader understand, operate, test, or change the system. Check that:
- every paragraph says something specific to this system;
- every new abstraction has more value than indirection;
- tests assert the contract and meaningful failure paths;
- comments explain reasons or constraints, not syntax;
- error handling does not hide failure; and
- the author can explain every changed line.
Review the result, not the conversation
Review the final diff from the same baseline another engineer will see. Prompts and long tool transcripts can make weak changes feel justified. The repository, checks, and review record are the evidence that remains.