4 min read
Clearly wrong code often fails quickly.
It does not compile. A test breaks. A type is missing. The package cannot be resolved.
Almost-right code is different. It can use the correct names, match the local style, pass the available tests, and
explain its choices. One product behaviour remains wrong or unproven.
That is why “almost right” is not a minor quality issue. It changes the economics of review.
Plausibility shifts the burden
Stack Overflow’s 2025 Developer Survey found that 66% of respondents who answered the AI frustration question selected
solutions that were almost right, but not quite.
The survey is self-reported. It does not show how often generated code fails in a controlled production setting.
It does capture a review condition engineers recognise: plausible code moves the burden from obvious rejection to
expert verification.
A reviewer must determine whether the implementation:
- solves the intended product problem;
- covers edge cases the prompt left unsaid;
- respects existing module ownership;
- reuses the right concept instead of the nearest name;
- introduces only requested behaviour;
- has tests independent enough to detect a mistake;
- keeps documentation and public contracts current.
The better the code looks, the easier it becomes to skip one of these questions.
Why summaries are not enough
AI-generated review summaries are useful navigation. They are not independent evidence.
The same model that interpreted the requirement, selected an approach, wrote the code, and generated the tests can
describe the result consistently because all artifacts share the same assumption.
Consistency is not the same as correctness.
Use the summary to find the evidence. Do not treat the summary as the evidence.
Give the reviewer an independent target
Review becomes cheaper when the expected answer exists outside the implementation.
A useful specification includes:
- observable behaviour;
- important edge cases;
- confirmed invariants;
- out-of-scope behaviour;
- proof method for each acceptance criterion;
- named owners for unresolved decisions.
Now the reviewer can map promises to evidence.
If an acceptance criterion has no test or review record, the gap is visible. If changed code has no corresponding
promise, the extra behaviour is visible.
This two-way traceability matters because almost-right code fails in both directions. It can omit something required or
add something sensible that nobody requested.
Separate evidence categories
Review reports often mix facts and judgement into one list of green checks.
Separate them:
Deterministic
Commands, exit codes, file checks, schemas, registry lookups, builds, and test results.
Measured
Performance data, coverage, complexity, and another result with a recorded method and environment.
Model-judged
Architecture coherence, likely requirement coverage, design quality, or security analysis that depends on reasoning.
Human-decided
Product behaviour, risk acceptance, architecture exceptions, and the production verdict.
The categories can support each other. They cannot replace one another.
A green test does not prove the specification reflects the user’s need. A model recommendation does not become
deterministic because it appears in a structured report.
Review the dangerous silence
Almost-right code often grows from a question nobody asked.
For each feature, inspect the silences:
- Which behaviour was ambiguous?
- Which assumption did the implementation choose?
- Which constraint exists only in a person’s memory?
- Which reused component carries a hidden business rule?
- Which dependency decision was made without a policy?
- Which risk changed because the diff remained small?
If the answer affects product, architecture, security, data, or cost, stop and create a decision packet for the right
human owner.
Make “inconclusive” an acceptable result
Review systems become unreliable when every run must end green or red.
Sometimes the correct result is:
- the available test does not prove the edge case;
- two documents conflict;
- the reviewer cannot determine whether reuse is appropriate;
- a package exists but its provenance is uncertain;
- the specification needs a product decision.
“Inconclusive” keeps uncertainty visible and routes it to the next useful action.
How paqad-ai addresses the review problem
paqad-ai is designed to create the independent structure around generated code: a routed workflow, approved plan,
frozen specification where risk requires it, scoped implementation, separate review roles, deterministic checks,
documentation sync, human decision pauses, and an evidence receipt.
The model can still be wrong.
The difference is that “done” no longer depends on the same model producing a confident explanation of its own work.
Almost-right code will remain part of AI-assisted development. The competitive advantage is not pretending it has
disappeared. It is building a review system that can find the missing part before the user does.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- Stack Overflow Developer Survey 2025, AI.
- Product workflow details are first-party claims from the current
paqad-ai repository.
