AI-generated code has a specific signature: it compiles, it runs the example, and it is wrong in the places nobody looked. Veracode's 2026 GenAI Code Security Report, covering more than 100 models across four snapshots, found a near-100% syntax pass rate and a 56% security pass rate, virtually unchanged from the year before, while AI's share of committed code roughly doubled. Finishing AI code is a testing job before it is a coding job. Here is the order.

First, accept what the 2026 numbers say

Four findings frame everything else in this guide.

  • Security has stalled at a 56% pass rate (Veracode, 2026 GenAI Code Security Report, 100+ models, standardised tasks with no security prompting). Roughly 44% of code-generation tasks produce a known vulnerability. Python is best at 63%; Java is worst at 30%.
  • Coding-specific models are no safer. Coding-specialised models averaged 51% versus 52% for general-purpose ones. Model size made no difference (large 53%, medium 51%, small 51%). Only reasoning models showed a small edge, 56% versus 51%.
  • The best model still fails nearly one in three security tasks. The 2026 leader scored 68%; six of eleven newly tested models clustered at 50 to 53%.
  • Developers know, and still ship it. 96% do not fully trust AI code is functionally correct, 61% say it "looks correct but isn't reliable", yet only 48% always verify before committing (Sonar, 2026 State of Code Developer Survey, 1,149 developers).

The implication is simple. Treat every line of AI-generated code as untested code written by a fast, confident junior who has never seen your system. Veracode's own summary: scan it, fix it, never ship it blind.

The order of testing

Test in this order because each layer is cheaper than the next and each one changes what the next one needs to cover.

1. Does it do what the brief actually said?

Before running anything, read the generated code against the original requirement, not against your memory of it. Models routinely solve a nearby, easier problem: handling the sample input but not the general case, implementing the happy path and stubbing the rest with a comment, or quietly changing a requirement that was hard. List each requirement and mark it implemented, partially implemented, or faked.

2. Does it run on real data?

Generated code is trained on tidy examples. Feed it your actual data: the customer with a 200-character name, the CSV with a byte-order mark, the date in the wrong timezone, the empty list, the null the schema says cannot happen but does. Most "it worked in the demo" failures happen here, and they are the cheapest to find.

3. Edge cases and error handling

AI code tends to handle errors by catching everything and logging, or by not handling them at all. Write explicit tests for: empty input, oversized input, malformed input, network timeout, dependency unavailable, concurrent access, and the second call after the first one failed. Ask of every try/except what the user sees when it triggers.

4. Security, by the OWASP list

Given the Veracode numbers, this is not optional. Go down the list deliberately:

CheckWhat AI code typically gets wrong
InjectionString-built SQL, shell commands assembled from input, template injection. Look for any place user input meets a query or a command.
Cross-site scriptingConsistently among the most-missed categories in Veracode's testing. Output not escaped, innerHTML with user data, unsafe markdown rendering.
Authentication and sessionsAuth checked in the UI but not the API, tokens in localStorage, no expiry, "admin" role by string comparison.
Access controlEndpoints that take an ID and return the record without checking who is asking. The most common AI-generated data leak.
SecretsKeys in code, in example config, in the repo history. Search for every string that looks like a key.
DependenciesHallucinated package names (a real supply-chain attack vector), outdated versions, packages pulled in for one function.
Input validationValidated on the client, trusted on the server. Types assumed, not checked.

Run a static analysis tool and a dependency scanner as well. They are cheap and they catch the patterns AI repeats.

5. Integration with the system it lives in

The prototype ran alone. Now it has to work with your auth, your database, your queue, your logging, your deployment. Test the seams: does it use the existing user model or invent one? Does it respect your migrations? Does it log in your format? Does it fail your health check correctly? Most AI code has to be re-fitted here, and this is where a developer who knows the system earns their fee.

6. Performance under load

Generated code favours clarity over efficiency: N+1 queries, loading a whole table to filter in memory, synchronous calls in a loop, no pagination. Load test the endpoints that will see real traffic and profile the queries. The fix is usually simple; the discovery has to be deliberate.

7. Can you explain it?

If you cannot explain why the code is structured the way it is, you do not own it yet. Thoughtworks' Technology Radar calls the accumulated form of this "codebase cognitive debt": systems adopted faster than the mental model to maintain them. Either learn the generated code well enough to defend each decision, or rewrite the parts you cannot, in a form you understand.

A useful rule: no AI-generated code reaches production without at least one human who could have written it reviewing it line by line. Not skimming. Reviewing as if they were about to be paged for it.

Write the tests AI skipped

AI will generate tests if asked, and they will mostly test that the code does what the code does. Useful tests assert what the requirement said, especially where the two differ. For each requirement line from step 1, write a test that fails if the requirement is not met. Then add the edge and error cases from step 3. Coverage numbers do not matter; coverage of the brief does.

A definition of done for AI-assisted code

If you are posting this work for a developer to finish, or scoping it for yourself, this is a starting definition:

All requirements in the brief implemented, none stubbed. Runs against production-shaped data. Explicit handling for empty, oversized, malformed and failed-dependency cases, each with a test. OWASP checks passed; static analysis and dependency scan clean. Integrated with existing auth, data layer and logging. Load tested on the two hottest endpoints. Deployed to staging with monitoring and rollback. README explains the system, not the prompt. Reviewed line by line by a named engineer.

What this means for how you hire the work

Finishing AI code is mostly verification and integration, and those need someone who knows the target system and the failure modes. It is a different skill from generating a prototype, and a different price. When you brief a developer, give them the running prototype, the original requirement, access to a realistic data set and the environment it must live in. Then let the definition of done above be what they quote against.

How this was made: written by the After AI Work team from finishing AI-generated code on our own platform. Security figures from Veracode's 2026 GenAI Code Security Report (published July 2026). Developer trust figures from Sonar's 2026 State of Code Developer Survey (published January 2026). "Codebase cognitive debt" from Thoughtworks Technology Radar vol. 34 (April 2026). AI tools helped draft the table; every row was rewritten and checked by a person.