Ordering Lunch for One / AI-assisted product development
How to Review AI Generated Code
Before you accept AI-generated code, define the behavior you need, examine how the change delivers it and test the ways it could fail. Keep enough evidence for someone else to understand your decision.
This guide is for developers and people responsible for accepting software changes. It includes a reusable checklist, three examples from our public Brava audit and a review record you can copy into an issue or pull request. The same questions are useful when reviewing code written by a person.
Start with the behavior you need
Write the review question in terms a user would recognize. “Export preserves the complete document” is a stronger starting point than “review the export helper.” It gives you an outcome to check across every component involved.
Record the exact version being reviewed, the affected task, the inputs and the expected result. Include constraints that matter: supported text, file sizes, interruptions, access permissions or work already in progress. Keep the source stable while the review runs. If it changes, identify the new version and which conclusions need checking again.
Choose the scope to fit the decision. A small correction needs a focused review of the affected behavior and dependencies. A repository audit needs a record of what was covered and excluded, so the next reviewer can understand its reach.
Follow the change through its consumers
Read the changed code alongside the code that calls it, displays its result or saves its output. Check which component owns each decision and whether the components agree about success, failure and recovery.
For a saved draft, follow the text from the editor through the save operation and back into a reopened document. For an asynchronous response, check what happens if the user changes the draft before the response arrives. A helper can behave as designed while the complete task still fails.
Look for unnecessary complexity after understanding what it protects. A guard that seems awkward may preserve newer work or prevent an uncertain action from being repeated. Simplify around those responsibilities.
Choose checks that could expose the failure
Each kind of check answers a different question. Match the evidence to the claim you want to make.
| Evidence | What it can support | What still needs checking |
|---|---|---|
| A successful build | This version compiles or packages in the recorded environment. | Whether someone can complete the intended task. |
| A focused automated test | The tested behavior holds for its inputs and assertions. | Whether the assertions detect the failure and the real consumer uses that path. |
| A source review | A reasoned finding about the examined code. | Whether the mechanism can be reproduced and the proposed correction works. |
| An observed task in the running app | The recorded task completed under the conditions observed. | Other conditions, recovery paths and effects outside that task. |
For a suspected bug, preserve a reproduction against the earlier version when feasible, then run the same check against the correction. Confirm that the test would fail for the behavior you are trying to prevent. An assertion that is caught and ignored cannot establish the expected result.
Three examples from our audit walkthrough
Our 14 October 2026 walkthrough described provisional source findings involving exports, delayed acknowledgements and a test that could swallow its own failed assertion. The checks below turn those concerns into review questions; they are suggested test designs, rather than a report of new test results.
| Concern raised in the walkthrough | A useful check to run | Acceptance condition |
|---|---|---|
| An export may alter Unicode text or omit content while reporting success. | Export a document containing varied Unicode text and content near the supported capacity, then inspect the saved result. Exercise an over-capacity case too. | Supported content is preserved completely. Unsupported input produces a clear failure or limitation before the user relies on an incomplete result. |
| An earlier acknowledgement may clear a newer draft or attachments. | Delay an acknowledgement, enter new text or attach a file, then deliver the earlier acknowledgement. | The newer unsent work survives. |
| A test may catch its own failed assertion. | Exercise the condition the test is meant to reject and inspect how the assertion reaches the test runner. | The runner reports failure when the expected rejection does not happen. |
These checks connect a code concern to something a person depends on: intact work, recoverable drafts and trustworthy test results.
Challenge the review as well as the code
Ask the reviewer to explain the mechanism, affected caller, consequence and evidence against the finding. A second review is most useful when it can challenge those assumptions. Treat its findings as claims to examine too.
In our 15 October audit follow-up, we reported coverage of 439 text files, including code, tests, fixtures and documentation, and ten bounded source findings. Independent assurance challenged the coverage, severity and proposed corrections. We deferred 19 nonessential cleanups and described a blind Copilot review of the repaired successor, with earlier findings withheld.
The installed correction candidate completed its bounded checks and final assurance. Brava remained in development and Gate 7 was open. The practical lesson was to strengthen checks across real component boundaries while keeping repairs focused on supported problems.
For your own review, separate a demonstrated defect from a preference about style. Make the smallest complete correction that addresses the mechanism, then check the affected task and nearby behavior that could regress. Record the version of the repaired candidate with its results.
Make a decision someone else can inspect
Use the acceptance conditions to decide whether to proceed. Record one of three outcomes with its reason:
- Accept for the stated scope when the required checks pass and any remaining limits fit the intended use.
- Revise when a supported problem has a clear correction that needs further checking.
- Hold when a material failure remains, the result cannot be reproduced or essential evidence is missing.
Write down what was observed and what remains open. “The selected context reached the next step in a controlled test” is a narrower claim than “the complete workflow works.” Our 30 October update on AI transparency made that distinction: a controlled native test connected the selected Brief and intention to request refinement, while the complete everyday journey and measured usefulness remained ahead.
Review effort should follow the consequences of failure. A small change that can lose someone's work may deserve more scrutiny than a much larger cosmetic change.
A checklist to use before acceptance
Keep private inputs, secrets and client material out of public review notes. Use synthetic or redacted examples when sharing the method. Before supplying code or data to an external review service, check its access and data-handling terms against your team's requirements.
Copy this review record
Review date and reviewer:
Task and decision being considered:
Source version and environment:
Scope and exclusions:
Expected behavior and acceptance conditions:
Relevant inputs, limits and failure cases:
Finding and affected consumer:
Mechanism, consequence and counterevidence:
Reproduction or source reference:
Correction and candidate version:
Checks run, with inputs and result references:
Observed result compared with the expected result:
Remaining limits or unresolved questions:
Decision: ACCEPT FOR STATED SCOPE / REVISE / HOLD
Reason and person responsible for the next action:Keep the record proportionate. A short change may need only a few lines; a wider audit may need a separate record for each finding. The important connection is between the behavior you need, the evidence you examined and the decision you made.
Explore the released examples
Each episode below includes a video, transcript and English captions.
- The AI code slop audit walkthrough, 14 October 2026 — the review method and provisional findings.
- Audit results and lessons, 15 October 2026 — the completed review and bounded correction checks.
- Adversarial reviews, 27 October 2026 — challenging proposals, repairs and reviews themselves.
- What does AI transparency mean, 30 October 2026 — connecting technical evidence to the experience someone can actually use.
If you want help defining a useful first AI project or the evidence needed to assess it, talk with Mevanu.