Auditing AI-Generated Code Before It Reaches Production

Generated code is often formatted well enough to invite a shallow review. I ignore naming and elegance on the first pass. I want to know what authority the code has, which data it trusts, and which side effects it can trigger.

For an endpoint that means tracing authentication, tenant context, input validation, database writes, external calls, and the response contract. For a worker it means delivery semantics, replay behavior, and what happens if the process dies between the side effect and the acknowledgement.

HTTP input, queue payloads, file metadata, webhook bodies, cached values, and third-party responses all cross a boundary. Types do not validate any of them at runtime. I look for the schema or guard that turns external data into a value the application can trust.

Authorization gets a separate check. A route can be authenticated and still expose another tenant's record. The useful question is not whether middleware exists, but whether this specific resource was authorized against the authenticated identity.

I walk through three moments: the dependency times out before doing the work, it does the work but the response is lost, and our process crashes after the side effect but before recording success. Generated implementations commonly treat all three as the same exception even though the recovery is different.

This is where idempotency keys, transactional boundaries, an outbox, or reconciliation may be necessary. Adding retries without answering the duplicate-effect question makes the system less reliable, not more.

Once behavior is sound, I compare the patch with nearby code. Did it bypass the existing error mapper? Did it introduce another validation library? Does logging use the request and tenant identifiers already present elsewhere? A locally clever solution can still increase the cost of the codebase.

Pattern fragmentation is one of the easiest forms of generated debt to miss. Each patch works, but five patches leave five ways to paginate, retry, or return an error. Review should push the code back toward one recognizable system.

A generated test suite often confirms the path the generated code already took. I add at least one scenario from outside that path: a user from another tenant, an out-of-order webhook, a duplicate queue delivery, or an old client sending the previous payload shape.

The final review note records what was checked and what remains uncertain. That is more valuable than labeling the patch AI-generated. Production ownership belongs to the team that merges it, regardless of who typed the first draft.