Your team already merges AI-written code and review volume has jumped. A method to review with judgment, automate the repetitive checks and keep security in view.
On an ordinary Tuesday, a developer opens a 600-line pull request that the assistant mostly wrote. It compiles, the tests pass and it looks tidy. The reviewer, with three other PRs waiting, skims it and approves. Two weeks later someone finds an endpoint that any logged-in user could call to see another customer's data.
This is not a case of "AI writes bad code". Code is arriving faster than your review process was designed to absorb. This guide is for small development teams already using Claude Code, Cursor, Copilot or a similar assistant that want to review with judgment without slowing everyone down.
Why does AI-written code slip past review?
Three reasons that reinforce each other. First, generated code looks good: consistent names, comments, clean formatting. That polish lowers the reviewer's guard. Second, volume: an assistant produces in minutes what a person writes in hours, and reviewers do not scale at the same rate. Third, the author often did not write every line and cannot explain why something was done a certain way.
There is data showing the worry is reasonable. Veracode, an application security company, analyzed code generated by more than 100 large language models in Java, JavaScript, Python and C#, and reported that it introduced risky security flaws in 45% of tests (the October 2025 update of its report). It also notes that larger, newer models did not produce more secure code. That is a vendor study on test tasks, not on your project, so treat it as a warning sign rather than a number for your team. The practical takeaway is what matters: do not assume AI code is safer than human code.
The tools themselves say so plainly. Claude Code's security documentation states that you are responsible for reviewing proposed code and commands before approving them, and GitHub advises supplementing Copilot's review with a human one.
What should a person always check?
You do not need to read every line with equal attention. Put human time where a mistake is expensive. OWASP's 2025 Top 10 works as a map of categories: broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection and authentication failures, among others. In practice, for an AI-written PR, check these first:
- Authorization, not just authentication. Does every endpoint verify that this user may see or change this specific record? It is the classic gap when an assistant built "login" and assumed the rest.
- Inputs that reach a query, a command or a template. Look for SQL built by string concatenation, system commands with user text and unescaped HTML.
- New dependencies. Does the package exist, is it the right one (watch for look-alike names), is it maintained, and did we really need it? Check the lockfile too.
- Secrets and data. Keys, tokens and customer data in code, logs or error messages.
- Error handling. What happens when something fails: whether the code swallows exceptions or returns internal details to the user.
- Out-of-scope changes. Config files, permissions or tests touched without anyone asking.
What should you automate so human review goes further?
Automate the repetitive parts so people spend attention on what needs judgment. A reasonable setup for a small team:
1. Tests and static analysis on every PR
Tests, linter and type checks running in continuous integration, blocking the merge when they fail. Do not rely on the assistant "remembering" to run them. If your team uses Claude Code you can also ask it to run the tests before calling a change done, but the real gate is the one on the server.
2. Secret detection before secrets leave the team
GitHub offers push protection, which checks pushes in transit and blocks them when it detects a known secret. Availability depends on the repository type and plan (for organization repositories it requires GitHub Secret Protection to be enabled), so confirm what your plan includes. Other platforms and standalone tools do something similar.
3. An automated second read that does not replace the first
Claude Code includes the /security-review command, which analyzes the changes on your branch against the repository's default branch looking for risks such as injection, authentication problems and data exposure. GitHub Copilot offers code review on pull requests. Both are useful as a second pair of eyes, but GitHub states that Copilot is not guaranteed to spot all problems and sometimes makes mistakes. Treat them as a list of suspicions to investigate, never as a green light.
4. Rules written into the repository
If your team already has a project rules file (such as CLAUDE.md or Cursor rules), add your security requirements there: how input is validated, how secrets are handled, which libraries are approved. The assistant reads them each session and repeats fewer mistakes. It is guidance, not a guarantee, so review is still needed.
How does the review process change with AI on the team?
- Small PRs. Set a reasonable maximum size and split anything larger. It is the single change that most improves review quality.
- The author answers for the code. Whoever opens the PR has read all of it and can explain it. "The AI did it" is not a justification.
- An honest description. Say in the PR whether the change was generated with AI help and what testing you did yourself.
- Tests written with intent. If the same assistant writes the code and its tests, both can share the same misunderstanding. Check that the tests verify the right behavior, including cases where someone should not have access.
- Care with critical zones. Payments, authentication, permissions and personal data always deserve a second person, wherever the code came from.
For a more formal reference, NIST publishes the Secure Software Development Framework (SP 800-218), a set of secure development practices that can be integrated into any development life cycle. It is not AI-specific, but it is a good starting point if a client asks for evidence of your process.
What risks and limits should you keep in mind?
- Customer data in the prompt. Do not paste real databases, tokens or keys into an assistant. If you need to debug with data, anonymize it. Colombia's Law 1581 of 2012 requires a legitimate basis to process personal data, and sending it to an external tool is processing.
- Agent permissions. An assistant that runs commands can do damage with a mistake. Configure what it may run without asking and use isolated environments for sensitive work. Claude Code, for example, offers configurable permissions and sandboxing.
- Untrusted content. An assistant that reads web pages, issues or third-party files can receive hidden malicious instructions (prompt injection). Review the commands it proposes before approving them.
- False comfort. Passing tests, a clean linter and an automated review do not prove the code is secure.
This is general information and does not replace a security audit or legal advice. If you handle payments, health or sensitive data, commission an independent review.
A plan for this week
- Monday: agree on a maximum PR size and a PR template with the checklist above.
- Tuesday: turn on tests, linter and secret detection in continuous integration, and make them block the merge.
- Wednesday: add the security requirements to your project rules file.
- Thursday and Friday: run an automated review (for example /security-review) on three PRs already approved and compare what it found with what the team saw.
- Next week: adjust the checklist from what you learned and decide which areas of the code always need a second person.
If you want an outside hand to help define review standards and set these tools up for your team, I can help.