A Definition of Done for AI-Generated Code

AI-generated code is done when it meets the same standard as any other code - not when the model stops outputting. The definition of done for AI-generated code needs to be explicit because AI tools create a specific pressure to skip the checks: the code appeared quickly, it looks plausible, and asking a developer to spend forty minutes reviewing a change that took thirty seconds to generate feels inefficient. That pressure is how bugs, security issues, and unmaintainable patterns get into production.

Why AI-Generated Code Needs Its Own Definition of Done

Human-written code fails the way humans fail: logic errors, off-by-one mistakes, copy-paste bugs. AI-generated code fails differently. It fails confidently - producing code that compiles, passes obvious tests, and looks correct on a quick read, while containing an access control gap, a hallucinated dependency, or a data handling pattern that works in the test case but not in edge cases a developer would have considered. The pattern of AI apps that pass tests but have security problems is documented and repeatable.

A definition of done that was designed for human-written code often passes AI-generated code through unchallenged. The checklist below is designed to catch the specific failure modes that AI tools introduce, without slowing down the development process more than necessary.

The Pre-Merge Gate for AI-Generated Code

Automated checks (must pass before review)

TypeScript compiles with strict mode - no `any`, no suppressed type errors
ESLint passes with no errors or warnings (warnings treated as errors in CI)
All existing tests pass
New code has tests covering at least the main path and one error path - not just a snapshot test
No new secrets, API keys, or hardcoded credentials detected (use a tool like truffleHog or detect-secrets as a pre-commit hook)

Human review (required before merge)

The reviewer has read the diff, not just approved it - a change that took seconds to generate is easy to approve just as quickly
Every database query or API call has an explicit check that the requesting user is authorised to perform that operation - not just authenticated
Any new dependency is a real package from a known registry - verify the package name is exactly correct (research has shown that LLMs hallucinate package names, which attackers can register)
Input validation exists for every external input (user-submitted data, API parameters, file uploads)
Error handling does not silently swallow exceptions - errors are logged and surfaced appropriately
The code is readable to a developer who did not write it and has no context from the AI conversation

Security checks (required for any code touching auth, data, or payments)

Row-level security is enforced in the database for any query that touches user data - not just in the application layer
No direct SQL string interpolation with user input - OWASP recommends parameterized queries as the best prevention for SQL injection
Rate limiting is in place for any endpoint that could be abused at scale
Any environment variable used in the new code is documented and present in the staging environment before the PR merges

The Specific Things AI Tools Get Wrong Most Often

Access control is the most common failure to watch for. An AI tool will write a function that fetches a user's records from the database - but it will often write it as "fetch all records where user_id = X", relying on the application layer to pass the correct user_id. If the endpoint also accepts user_id as a URL parameter, any authenticated user can pass any user_id and see anyone's records. OWASP lists this pattern (viewing or editing someone else's account by supplying its identifier) under Broken Access Control, which holds the #1 position in its Top Ten. The code itself does not prevent it, the tests do not catch it unless they specifically test cross-user access, and TypeScript does not flag it.

The reviewing AI pull requests checklist covers this in more detail, with specific patterns to look for in Supabase and Next.js codebases.

Dependency hallucination is the second common failure. AI tools sometimes reference npm packages that do not exist or that have a slightly different name from the real one. A large study of code-generating LLMs generated 576,000 code samples across 16 models and found hallucinated packages in at least 5.2 percent of commercial-model outputs and 21.7 percent of open-source-model outputs on average, and called this a threat to the software supply chain. A successful `npm install` is not proof the package is legitimate - verify the package name against the registry, check the download count, and check when it was last published. Hallucinated packages as a dependency risk covers the supply chain angle.

Testing AI-Generated Code Is Not the Same as Trusting the Tests

One of the subtler problems with AI-generated code is that the same tool that writes the code often writes the tests for it. An AI coding assistant asked to add a function and test it will tend to write tests that confirm what the function does, not tests that challenge whether what it does is correct. A function that returns the wrong result for a specific edge case will pass all the tests if the tests were written by the same model that wrote the function, because the model will have the same blind spot in both.

This is why the human review step for AI-generated code must include reading the tests, not just checking that they pass. The question is not whether the tests pass - it is whether the tests are testing the right things. A test that only covers the happy path for an authentication function is worse than no test, because it creates a false sense of coverage while leaving the attack surface unchecked.

How to Apply This in Practice Without Slowing Down

The automated checks should be enforced by CI and pre-commit hooks - they are not optional and they are not something the developer has to remember. If they are not automated, they will be skipped. Set up the toolchain once and the cost per PR is seconds.

The human review should be calibrated to the risk level of the change. A CSS update generated by an AI tool needs a five-minute review. A new API endpoint that touches user data needs a thorough review against the access control and security checks above. The developer requesting the review should label the PR with whether it contains AI-generated logic, so the reviewer knows which checks to apply.

The goal is not to slow AI coding down to human coding speed. It is to build the habit of knowing what you are shipping. AI tools generate code fast. Debugging a production security issue or a data exposure discovered months after launch is slow and expensive. The gate at merge time is the right place to pay the cost.

Making the Definition of Done Stick

A definition of done that lives in a document nobody reads is not a definition of done. Enforce the automated checks with branch protection rules that require CI to pass. Make the human review checklist part of the PR template - a markdown checklist that the author fills in before requesting review. Review whether it is being followed in retrospectives, and update it when you find new failure modes.

If your team has been shipping AI-generated code without a structured gate and you want an honest assessment of what that has produced, request a technical review. We look at the code, not the commit messages, and tell you what we find.

Common questions

What is a good definition of done for AI-generated code?

It meets the same standard as any other code. Automated checks pass (strict TypeScript, lint, tests, secret detection), a human has actually read the diff, authorisation is checked on every query, and any new dependency is verified as a real package.

Can AI tools write both the code and its tests?

They can, but the same model tends to write tests confirming what the function does rather than challenging whether it is correct, so blind spots repeat. Reviewers should read the tests, not just check that they pass, especially for authentication and access control.

When should I get an outside review of AI-generated code?

If your team has been shipping AI-generated code without a structured gate and you want an honest assessment of what that produced, request a technical review. Zovintra looks at the code itself, not the commit messages, and reports what it finds.