Artificial intelligence (AI) can now draft working software in seconds, but speed does not change the nature of code. Code still reads files, calls databases, handles identity, moves money, stores secrets, and fails in production. The first rule is simple: AI-written code is untrusted until a human and an automated process have proved enough about it for the risk at hand.

Start with what code is allowed to do

A program is not just text. It is a set of instructions that can consume data, change state, spend resources, expose an interface, and affect people. Reviewing AI-written code begins by asking what power the code receives, not by admiring how plausible it looks.

A large language model (LLM) predicts likely text from patterns in training data and context. It does not truly know your business rules, your production environment, or which assumptions are dangerous unless you provide that context and then verify the result. This is why AI output can be fluent and wrong at the same time.

Think of AI-written code as a proposal. It may save time by producing a first draft, filling in repetitive structure, or suggesting tests. It should not bypass the normal path from idea to trusted change.

⚠️
Plausible is not proven. Readable code can still contain broken logic, unsafe defaults, hidden dependencies, or security flaws.

Review for intent before reviewing syntax

The most useful first review question is not whether the code compiles. It is whether the code does the right thing. AI-generated changes often look locally coherent while solving the wrong problem, skipping an edge case, or using a convenient library that the team would not otherwise accept.

Begin with the requirement in plain language. What should happen when inputs are valid, missing, hostile, too large, repeated, or late? What must never happen? Then read the code against those expectations. This catches errors that a compiler cannot see.

Only after intent is clear should the reviewer spend attention on naming, structure, idioms, and style. Style matters because future engineers must maintain the code, but a beautifully formatted mistake is still a mistake.

  • Ask what user or system need the change is meant to satisfy.
  • Check boundary cases: empty values, maximum sizes, timeouts, retries, and duplicate requests.
  • Trace error handling and confirm failures are safe, visible, and recoverable.
  • Look for invented functions, outdated patterns, and dependencies added without a clear reason.
  • Require explanations in the pull request, not only in the chat that produced the code.
Review whether the code does the right thing before spending attention on naming, structure, and style. Intent First AI-written code Right thing? Then review style Naming, structure Fix the intent Solves wrong problem Yes No
Review whether the code does the right thing before spending attention on naming, structure, and style.

Security review is about trust boundaries

A trust boundary is any place where data, identity, or control moves from one level of trust to another. Examples include a browser sending input to an application programming interface (API), an application querying a database, or a background job reading from a storage account. Many serious bugs happen when code treats untrusted input as if it were trusted.

AI-written code can be especially weak at security context. It may choose a shortcut that works in a tutorial but is unsafe in production, such as broad permissions, missing input validation, hard-coded secrets, weak cryptography, or a direct object lookup without authorization.

Secure review asks how the code can be misused. What if an attacker controls this string? What if a user changes this identifier? What if the service account is compromised? What if the model suggested a package with a known vulnerability? The goal is not fear; it is clarity about where controls belong.

⚠️
Never paste secrets. Do not put passwords, keys, tokens, certificates, or private customer data into prompts or generated examples.
Data crosses trust boundaries from user to database, and each hop needs its own control. Trust Boundaries User input Untrusted API Validate input App logic Check authorization Database Least privilege
Data crosses trust boundaries from user to database, and each hop needs its own control.

Use automated checks, but know what each one proves

Automated checks are essential because humans miss patterns and get tired. They are also limited because no tool proves that software is correct in every meaningful sense. A strong pipeline uses several checks that answer different questions.

Unit tests check small pieces of logic in isolation. Integration tests check whether components work together, such as an API calling a database. Static application security testing (SAST) scans source code for risky patterns before the code runs. Software composition analysis (SCA) checks third-party packages for known vulnerabilities and license issues. Secret scanning looks for credentials accidentally committed to the repository.

These checks should run in continuous integration and continuous delivery (CI/CD), the automated process that builds, tests, and prepares code for release. AI-written code should not get a lighter path through CI/CD because it arrived faster.

  • Tests prove specific expected behaviors, not all possible behaviors.
  • SAST finds known risky patterns, but it can miss design flaws.
  • SCA helps with known dependency risk, but it cannot judge whether a dependency is necessary.
  • Secret scanning reduces accidental exposure, but secrets should also be blocked by policy and rotated if exposed.
  • Runtime monitoring catches failures that pre-release checks did not predict.
Several automated checks answer different questions: logic, risky patterns, packages, and secrets. Layered Checks Unit tests Logic in isolation SAST Risky code patterns SCA Vulnerable packages Secret scanning Leaked credentials
Several automated checks answer different questions: logic, risky patterns, packages, and secrets.

Evaluate the AI assistant, not just one answer

A single generated function can be reviewed like any other contribution. An AI coding workflow needs a broader evaluation: does the assistant reliably help your team produce safer, clearer, and more maintainable code, or does it merely create more code to inspect?

Evaluation starts with realistic tasks. Use examples from your own codebase: add validation, fix a bug, write tests, migrate an API client, or refactor a confusing module. Keep a reference answer or scoring guide so the review is not based on taste alone.

Measure both benefit and risk. Useful metrics include accepted suggestions, time saved after review, defect rate, security findings, test coverage, reviewer effort, and how often the assistant introduces unnecessary dependencies. If models or prompts are built or hosted in Microsoft Foundry, the same principle applies: evaluate against your own tasks, data rules, and release standards.

Make policy decisions before the pressure arrives

Leaders and practitioners face practical decisions that should not be improvised during an incident or a deadline. Which repositories may use AI coding tools? What data is allowed in prompts? Who approves generated code in sensitive systems? Which checks are mandatory before merge? When must a security specialist review a change?

The right answer depends on risk. A prototype used by one internal team can move with different controls than payment code, identity code, medical workflows, or systems that process regulated data. The policy should be strict where harm is high and lightweight where experimentation is safe.

Identity and access matter here. If generated code connects to cloud services, databases, or internal APIs, it should use managed identities or service principals with least privilege, not shared secrets. In Microsoft environments, Microsoft Entra ID can provide identity and access controls, but the code still needs careful authorization checks.

📌
Decide in advance. A clear policy lets teams move quickly because they know which risks require extra review.

Build a habit of small, explainable changes

AI tools make it easy to produce large changes. Large changes are hard to review, hard to test, and hard to roll back. The safer habit is to ask for small, explainable patches that solve one problem at a time.

Require every AI-assisted change to carry evidence: what was requested, what changed, how it was tested, and what risks remain. The reviewer should be able to understand the change without trusting the assistant’s confidence. If nobody can explain a generated block of code, the team does not own it yet.

Over time, the best teams treat AI as part of the engineering system rather than a shortcut around it. They improve prompts, templates, test fixtures, review checklists, and security rules. The goal is not to prevent AI from writing code. The goal is to make sure code earns its way into production.

  • Prefer small pull requests with one purpose.
  • Ask the assistant to explain tradeoffs, then verify them independently.
  • Delete generated code that is clever but unnecessary.
  • Keep humans accountable for design, security, and release decisions.
  • Record lessons from review so future prompts and checks improve.
✅
Own the code. Once code is merged, it belongs to the team, not to the tool that drafted it.

Key takeaways

  • AI-written code should begin as untrusted and earn trust through review, tests, scans, and controlled release.
  • Review intent first: the code must solve the right problem before style or syntax matters.
  • Security review focuses on trust boundaries, permissions, secrets, dependencies, and hostile input.
  • Automated checks are necessary but partial; each tool proves only a specific kind of claim.
  • Evaluate the whole AI coding workflow using realistic tasks and measurable outcomes.
  • Policies for data use, approval, identity, and release gates should match the risk of the system.
Small explainable patches are easy to review, test, and roll back; large changes hide their effects. Small Or Large Small patches Large changes Easy to review Easy to test Easy to roll back Hard to review Hidden effects Risky to revert
Small explainable patches are easy to review, test, and roll back; large changes hide their effects.

Glossary

Artificial intelligence
Software techniques that perform tasks commonly associated with human reasoning, such as generating text, recognizing patterns, or making predictions.
Large language model
A model trained on large amounts of text to predict and generate language, including source code.
Trust boundary
A point where data, identity, or control moves between areas with different levels of trust.
Least privilege
The practice of giving code or users only the permissions they need to perform their required task.
Static application security testing
A method that scans source code for security weaknesses before the program runs.
Software composition analysis
A method that checks third-party packages for known vulnerabilities, license concerns, and dependency risk.
Continuous integration and continuous delivery
An automated process for building, testing, and preparing code changes for release.
Secret scanning
Automated detection of credentials such as keys, tokens, passwords, or certificates in code and configuration.