--- title: "AI-Generated Code Should Come With Evidence" description: "Demo artifacts can replace some code reading by showing that AI-generated changes satisfy the behavior they were meant to produce." date: 2026-08-04 tags: [ai, ai-reliability, ai-and-productivity] url: https://nem035.com/thoughts/ai-generated-code-should-come-with-evidence --- Since I started delegating more coding to AI, code review has become the least resolved part of the workflow. If I ask an agent to build a feature and then read every line it wrote, I can get to roughly the same confidence I had before. But a lot of the speed disappears because [comprehension is still the bottleneck](/thoughts/the-comprehension-bottleneck). The code was produced in minutes, while understanding it well enough to trust can take much longer. We already use abstractions without inspecting everything underneath them. When I write Python code that renames a file, I do not review how Python turns that call into an operating system operation. I trust the interpreter and the operating system to behave predictably, so I only need to review the layer I wrote. An AI coding agent looks like another abstraction layer. I describe the behavior I want and it produces the implementation. The problem is that this layer is not reliable enough yet. The agent can misunderstand the requirement, miss an edge case, use an outdated API, or make a change that works locally while breaking something elsewhere. If I skip reading the code, I am mostly trusting the agent's claim that it did a good job. A summary saying that the feature was implemented and the tests pass does not give me much confidence. Having [another AI review the change](/thoughts/you-cant-fix-ai-reliability-with-more-ai) helps catch some mistakes, but the same trust problem remains. The best proxy I have found is a small artifact that demonstrates the behavior. For UI work, nothing beats a before-and-after video. It shows the starting state, the interaction, and the result. A good recording can also show loading states, failed requests, validation, empty states, and the edge cases that are easy to omit from a written summary. We are already using this approach at [Flint](https://flintk12.com). Our AI QA system exercises product updates and records a before-and-after video automatically. In this example, the artifact shows clipped district-owner search results before the fix and confirms that the full list expands afterward. The recording is only seven seconds long, but it gives me the evidence I need for the behavior we changed.
*Video: Flint AI QA, made by my colleague [Zachary Reece](https://zacharyreece.dev/) and [shared publicly by Sohan Choudhury on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7486027236995694593/).* The same idea works outside of UI changes: - A CLI change can come with a recorded terminal session showing the command, output, exit code, and invalid input. - An API change can come with a script that runs representative requests and prints the responses. - A bug fix can show the original reproduction failing and the same reproduction passing after the change. - A data migration can include a dry run with row counts and invariants before and after it runs. These artifacts keep the review close to the original expectation. I asked for a behavior, and the agent shows me that behavior. I can judge the result without first building a full mental model of the implementation. Tests are part of this, but test output is often a weak artifact for a human reviewer. A green test suite tells me that some assertions passed. I still have to read the tests to know what they actually covered. A useful demo exposes the relevant inputs and outputs directly, even when tests or scripts produce it underneath. This is still lossy. A video can show that a flow works while missing an authorization bug, a race condition, a bad abstraction, or a hidden side effect. I would not accept an authentication change or a destructive database migration based only on a recording. Some changes still deserve careful code review because the important properties are not visible through normal product behavior. The artifact is also only as good as the scenarios it covers. If the agent chooses what to demonstrate after finishing the implementation, it can select the happy path and ignore everything uncomfortable. The acceptance criteria should be explicit before the work begins, and the artifact should show which criteria were exercised and which risks remain unverified. I want AI coding tools to return an evidence package with each meaningful change: the acceptance criteria, the relevant demonstrations, and a short list of what the agent could not verify. The diff is still there when I need it, but it stops being the only serious way to establish trust. For now, a 30-second before-and-after recording often gives me more confidence than a large diff and a confident summary. A recorded CLI session can do the same. Neither eliminates code review, but both make it easier to decide where reading the code still adds value.