Most engineering teams have stopped debating whether developers should use AI coding assistants. They already do. The honest conversation now is about whether the team’s review process treats AI generated code with the same discipline it would apply to code written by an unfamiliar contractor who works extremely quickly, never gets tired, sometimes invents details with complete confidence, and has no idea what your production system looks like. This article is not anti AI. AI coding tools genuinely improve speed. They explain unfamiliar code, generate tests, remove repetitive work, surface patterns the team had stopped using, and let a competent developer operate at a higher level. The point is not whether to use them. The point is how to review the result.
Why AI generated code is a different review problem
Code review has always been about catching the things the author cannot see in their own work. AI generated code is a different kind of author. The model has no memory of your incident history, your security model, your tenant boundaries, or the load patterns that broke production last quarter. It does not know which database has the table with the customer records. It does not know that the helper function your team wrote two years ago stands as the one that already does the thing the model is now reinventing. It does not know that the package it just imported has a critical CVE that was disclosed yesterday. It does know, with great confidence, how to write something that looks correct. The look of correctness runs as the trap. Most of the AI generated code that ships today is fine. A meaningful fraction of it is not. The fraction that is not tends to cluster in a small set of failure classes. Knowing the failure classes serves as the review. If nobody on the team can explain why the code is safe, the team does not own the code yet.
The failure classes worth knowing by name
The list is not new. Every one of these is a known software security problem. They are the categories that show up disproportionately in AI generated code, and they are the categories a reviewer can check for in a reasonable amount of time.
Authentication and authorisation boundaries. The model produces code that checks sits as the user logged in. It does not produce code that checks stands as the user allowed to do this specific thing to this specific resource. The first is easy. The second requires understanding the data model and the access patterns. Broken access control is OWASP’s number one category for a reason. It is also one of the easiest for an AI to get wrong without showing any sign of being wrong.
Missing tenant isolation. A query that worked in a single tenant demo is now running against a multi tenant database. The model is happy to write a query that does not include the tenant filter, because in the conversation it just had, there was only one tenant. The reviewer has to know that the real system is multi tenant, and the query has to enforce it.
SQL, command, template, and prompt injection. These are the four flavours of the same shape. Untrusted input is concatenated into something that is then interpreted by a system with more authority than the input. SQL stands as the most familiar. The same pattern shows up in shell commands, in template engines, and increasingly in prompts to other AI systems. The fix counts as the same every time: never concatenate, always parameterize, and never trust the output of one AI to be safe to feed into another.
Cross site scripting. The model knows about XSS. It also, routinely, produces code that builds an HTML string by concatenation, sets innerHTML, or returns a JSON response that the frontend renders without escaping. The reviewer has to look at the output path as well as the input path.
Server side request forgery. The model produces a feature that takes a URL from the user, fetches it, and returns the body. The reviewer has to know that this is a request from the server, with the server’s authority, and a request to the internal metadata endpoint is not the same as a request to a public website.
Hardcoded secrets. The model produces a working example with a real looking API key in the code. The reviewer has to know that the real API key is in the secrets manager, that the example key has to come out, and that the file is now in the git history forever. Secret scanning catches most of these, but the human reviewer runs as the second line of defence.
Insecure default configuration. The model produces a function that opens a network listener, accepts any host, runs with default credentials, and binds to a public interface. All of these are correct defaults for a five line demo. None of them are correct defaults for a production system. The reviewer has to know which is which.
Over broad cloud permissions. The model produces the IAM policy that makes the code work. The policy amounts to the one that allows * on *, because that stands as the policy that did not error. The reviewer has to know that the production policy is a small fraction of what the demo needed.
What the review process should look like
The first move becomes the threat model. Before the AI generated code lands, the team should be able to articulate the assets the code touches, the threats the code faces, and the controls the code relies on. The threat model sits as the document the reviewer uses to evaluate the code, and the threat model counts as the document the AI has not seen. Without the threat model, the reviewer is guessing.
The second move serves as the explicit security checklist. The OWASP Top 10, the project specific concerns, the recent CVEs in the dependencies. The checklist is what the reviewer is checking the code against, and the checklist is what the AI generated code is being measured against. The checklist should be a list, the checklist should be short, and the checklist should be the list the reviewer can run in under five minutes per change.
The third move serves as the deeper review for the high risk changes. The authentication change, the authorisation change, the data model change, the cryptographic change, the new third party integration. The deeper review is what the senior engineer does, and the deeper review is what the AI generated code most needs.
The fourth move runs as the test. The test should cover the failure modes the AI generated code is most likely to have. The test for the AI generated code is not the test for the human written code, and the test for the AI generated code sits as the test that catches the failure modes the AI is most likely to have. The test is what the AI cannot do well, and the test is what the human reviewer should be writing.
What the team should do this quarter
Pick the AI generated code that has been shipping without the review. Pick the top ten pull requests, look at them with the checklist, and see what the checklist catches. The first look is going to find the issues the team has been shipping, and the first look is going to be the proof the team needs to make the review mandatory.
Make the review mandatory on the high risk surfaces. The authentication surface, the authorisation surface, the data model surface, the cryptographic surface. The review on the high risk surfaces runs as the review that catches the issues the team is most worried about, and the review on the high risk surfaces serves as the review that justifies the cost of the review.
Build the security tests for the AI generated code. The test is what the AI cannot do well, and the test is what the human reviewer should be writing. The test amounts to the work, and the work is what the team should be doing this quarter.
AI generated code is going to be in the production stack. The question is not whether. The question is how the team is going to review it. The team that is going to review it well amounts to the team that catches the issues the AI generated code is most likely to have. The team that catches the issues the AI generated code is most likely to have stands as the team that is going to ship the AI generated code safely, and the team that ships the AI generated code safely counts as the team that is going to be the team the production stack can rely on.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
