AI-generated code changes the economics of software delivery. It makes it easier to produce more code, explore implementation options, generate tests, scaffold integrations, and move through tickets faster. For engineering leaders, that sounds attractive for obvious reasons: less waiting, less repetitive work, and more output from the same team.
The risk is that production systems do not fail because code was typed slowly. They fail because assumptions were wrong, boundaries were unclear, dependencies behaved differently under load, permissions were too broad, tests missed the real failure mode, or the team shipped something they did not fully understand.
Review gates help, but they were designed for a different constraint: human-authored change moving through a human-paced workflow. AI-assisted delivery creates a new shape of risk. The volume of change can increase. The apparent polish of code can improve even when the design is weak. Reviewers may be asked to inspect work that is syntactically clean but semantically fragile.
A pull request can look tidy while still encoding the wrong business rule, weakening an authorisation boundary, or introducing a dependency nobody has operational ownership for.
That is why review gates are necessary but insufficient. Production safety requires a broader operating model: clear ownership, constrained generation, automated verification, architectural guardrails, security controls, runtime observability, and a release process that treats AI-generated code as untrusted until proven otherwise.
At Westpoint, this sits close to how we think about cloud architecture and platform engineering: delivery speed only matters when the system remains governable, secure, and maintainable after launch.
The old review model assumed scarcity
Traditional review processes developed around a familiar pattern. A developer works on a change, opens a pull request, another engineer reviews it, CI runs, and the change is merged if the review and checks pass. That model is still useful. It catches obvious mistakes, spreads context, and gives teams a moment to ask whether the implementation fits the codebase.
But it assumes scarcity in several places.
It assumes code is relatively expensive to produce. It assumes a reviewer can understand the intent behind a change from the diff. It assumes the author has enough understanding of the surrounding system to defend the implementation. It assumes automated tests cover enough of the behaviour to make approval meaningful. It also assumes that the riskiest part of the workflow is the code diff itself.
AI weakens those assumptions.
A developer can now generate a large patch quickly. The patch may follow local style, include plausible tests, and avoid obvious syntax errors. That can make review harder, not easier. The reviewer is not just checking whether the code is well written. They are checking whether the generated reasoning behind it was correct, whether hidden assumptions slipped into the implementation, and whether the author understands the operational consequences.
This matters most in systems with complex constraints: regulated data, identity flows, payment logic, multi-tenant platforms, cloud infrastructure, shared libraries, deployment automation, or integrations with external services. In those environments, the danger is rarely a single ugly function. It is a reasonable-looking change that bends a system boundary in a way nobody notices until production.
Review gates catch code shape, not always system risk
A review gate is good at asking: does this diff look acceptable?
Production risk asks a wider set of questions:
- Does this change preserve the intended security boundary?
- Does it alter data retention, logging, or privacy behaviour?
- Does it introduce a new dependency or external service call?
- Does it increase operational load or cloud cost?
- Does it create a migration path that can be reversed?
- Does it change failure behaviour under partial outage?
- Does the team know how to observe and debug it in production?
- Does the implementation match the actual business process, not just the ticket text?
These questions often sit outside a narrow pull request review. The reviewer may not have the full architecture in their head. The author may not have prompted the model with enough context. The tests may confirm that the generated code does what the generated test expects, while missing what the business actually needs.
This is especially risky when AI is used to modify infrastructure as code, IAM policies, CI/CD workflows, database migrations, or shared platform components. A small change can alter blast radius. A generated policy statement can grant more access than intended. A generated migration can lock a table in production. A generated pipeline step can expose secrets in logs. A generated retry loop can multiply traffic during an outage.
None of these risks are solved by saying, "someone reviewed the PR."
AI-generated code should be treated as untrusted input
The safest mental model is simple: AI-generated code is untrusted input.
That does not mean it is bad. It means it must cross the same trust boundaries as any other external contribution. A model can produce useful implementation work, but it does not own the production consequences. It does not understand the full commercial context, the compliance requirements, the incident history, or the informal decisions embedded in the architecture.
Security teams already use this kind of thinking for LLM-powered applications. The OWASP Top 10 for Large Language Model Applications includes risks such as prompt injection, insecure output handling, supply chain weaknesses, sensitive information disclosure, and excessive agency. Those risks are often discussed in the context of user-facing AI products, but the same principles apply to internal engineering workflows.
If an AI tool can suggest code, modify files, call tools, run commands, or open pull requests, then its outputs need boundaries. If it can access repositories, documentation, tickets, logs, or secrets, then its inputs need boundaries too. The development workflow itself becomes part of the AI risk surface.
The practical response is not to ban AI coding tools. It is to design the engineering process so generated output cannot silently bypass human accountability, security policy, or production verification.
Why polished code can be more dangerous than messy code
Messy code creates friction. Reviewers slow down. Tests fail. The team asks questions.
Polished but wrong code can pass through too easily.
AI-generated code often has a surface-level completeness: sensible names, consistent formatting, familiar patterns, comments where comments are expected, and tests that appear thoughtful. That can create misplaced confidence. The code reads like it belongs. The reviewer has to work harder to find the part that does not.
The failure mode is subtle. Teams do not ship AI-generated bugs because the code looks bizarre. They ship them because the code looks normal.
Common examples include:
- Validation logic that handles common cases but misses domain-specific edge cases.
- Authorisation checks that verify authentication but not tenant ownership.
- Error handling that catches exceptions and hides operationally important failure signals.
- Tests that assert the mock interaction rather than the real behaviour.
- Infrastructure defaults that are acceptable for demos but unsafe for production.
- Data transformations that preserve type correctness while losing business meaning.
- Generated documentation that confidently describes behaviour the code does not provide.
The review burden shifts from "is this code clean?" to "is this code true?"
That is a much harder question.
The production risk stack
A safer AI-assisted delivery model needs several layers. Review remains one of them, but it cannot carry the whole load.
The first layer is constrained context and permissions. Teams should decide what an AI tool is allowed to see, what repositories it can access, what commands it can run, and what files require human approval before modification.
The second layer is local validation. Generated code should compile, pass tests, and run against realistic fixtures before review. The author should understand what the tests prove and what they do not.
The third layer is human review. Reviewers should focus on intent, system fit, security boundaries, and operational consequences, not only syntax or style.
The fourth layer is automated policy. Infrastructure, dependencies, secrets, licences, and access controls should be checked by tools that do not get tired or skim large diffs.
The fifth layer is production-like verification. Staging environments, integration tests, migration rehearsals, and contract tests matter more when code volume increases.
The sixth layer is progressive release. Feature flags, canary deployments, rollback paths, and alerting limit the damage when a change behaves differently under real traffic.
The final layer is runtime observability. Logs, metrics, traces, audit events, and incident reviews tell the team what actually happened, not what the review process assumed would happen.
A review gate is only one checkpoint in that chain.
What leaders should change first
The first change is policy clarity. Teams need to know where AI-generated code is allowed, where it is restricted, and where it requires extra review. A blanket "use AI responsibly" statement is not enough. It gives teams moral responsibility without operational guidance.
A useful policy distinguishes between low-risk and high-risk areas.
Low-risk uses might include local refactoring, test scaffolding, internal scripts, documentation drafts, and boilerplate generation. High-risk uses include authentication, authorisation, cryptography, infrastructure, deployment automation, data migrations, billing logic, regulated workflows, and production incident response tooling.
For high-risk areas, AI assistance may still be useful, but the controls should be stronger: mandatory human design review before implementation, explicit test plans, security review, infrastructure diff review, and rollback planning.
The second change is ownership. AI tools do not own code. The engineer using the tool owns the code. The team owns the production behaviour. The platform or security team owns the guardrails. That ownership needs to be visible in the workflow.
The third change is measurement. If AI increases code throughput but also increases review queue time, escaped defects, rework, cloud spend, or operational noise, the business has not gained much. Productivity should be measured through delivery outcomes, not just volume of merged code.
This is where an owner-led delivery model matters. In complex programmes, the people making architectural decisions need to stay close to implementation and production feedback. That principle is central to Westpoint's approach to cloud consultancy, where architecture, delivery, governance, and operations cannot be treated as separate ceremonies.
Technical controls that matter
The technical response should be boring in the best possible way. AI-generated code needs the same disciplined engineering controls as any other code, applied with less tolerance for ambiguity.
Start with stronger automated verification.
Unit tests are useful, but they are not enough for generated code that touches system behaviour. Teams should invest in integration tests, contract tests, migration tests, policy tests, and end-to-end checks for critical paths. Tests should be written against real business expectations, not only against implementation details.
For cloud infrastructure, policy-as-code becomes important. Tools such as Open Policy Agent, Checkov, tfsec, cdk-nag, IAM Access Analyzer, and cloud-native policy controls can catch classes of risk that reviewers may miss. The exact toolset matters less than the principle: risky infrastructure changes should be evaluated automatically against explicit rules.
For software supply chain risk, teams should track dependencies, provenance, and build integrity. The SLSA framework is a useful reference point for thinking about source integrity, build integrity, and artifact provenance. AI-generated code can introduce packages, actions, base images, or snippets from unknown origins. Reviewers may not notice every new transitive dependency. Automated dependency scanning and provenance controls reduce that exposure.
For AI-assisted workflows themselves, permissions should be minimal. Coding agents and assistants should not have broad access to production secrets. They should not be able to deploy directly to production without human-controlled release gates. They should not be allowed to modify security-sensitive files without extra checks. Tool access should be logged.
For application security, generated code should go through the same static analysis, dependency scanning, secret scanning, and dynamic testing as human-authored code. Where AI is used to generate security-sensitive code, teams should assume the first version is a draft, not a design.
Review still matters, but the review changes
Human review becomes more important, not less. But the reviewer's job changes.
Instead of only asking whether the code is idiomatic, reviewers need to ask where the idea came from. What context was the model given? What alternatives were considered? What assumptions did the implementation make? Which production failure modes were tested? What could happen if the model misunderstood the requirement?
Good AI-era reviews are more architectural and operational.
A reviewer should look for signs that the author understands the change:
- Can they explain why the implementation fits the system?
- Can they describe how it fails?
- Can they identify which tests prove the behaviour?
- Can they explain why new dependencies are acceptable?
- Can they describe the rollback path?
- Can they show that security and tenant boundaries remain intact?
If the answer is no, the problem is not that AI was used. The problem is that nobody owns the reasoning.
One practical pattern is to require a short AI assistance note for high-risk changes. It does not need to be bureaucratic. It can simply state whether AI generated or materially modified the code, which areas were touched, what verification was performed, and what the reviewer should pay special attention to.
The goal is not blame. The goal is signal.
The role of architecture guardrails
Review gates become weaker when architecture is implicit. If every service has its own patterns, every team handles identity differently, and every deployment pipeline is unique, reviewers must rediscover the system every time.
Architecture guardrails reduce that burden.
A platform with standard service templates, approved deployment patterns, common observability defaults, shared authentication libraries, and clear data access rules gives AI tools a narrower path to follow. It also gives reviewers a sharper basis for judgment. The question becomes: does this change stay inside the paved road, and if not, why?
This is one reason platform engineering matters in AI-assisted delivery. The better the platform, the less room there is for generated code to invent unsafe patterns.
Westpoint's article on why CI/CD pipelines were not built for microservices makes a related point: delivery systems that worked for one architecture can become fragile as the operating model changes. AI-assisted development creates a similar pressure. The pipeline may still run, but the assumptions behind it may no longer be strong enough.
Governance without theatre
Governance often fails when it becomes paperwork after the real decisions have already been made. AI code risk needs governance that sits inside the delivery workflow.
That means:
- Clear classification of high-risk code areas.
- Required checks based on risk level.
- Traceability from requirement to implementation to test evidence.
- Explicit approval for production-impacting infrastructure changes.
- Release strategies that limit blast radius.
- Post-release monitoring tied to the change.
- Incident reviews that update templates, prompts, tests, and policies.
The NIST AI Risk Management Framework is useful here because it frames AI risk management as a socio-technical discipline, not a single technical control. For AI-generated code, that framing is exactly right. The risk is not only in the model. It is in how people use the model, how the organisation validates output, and how production systems absorb mistakes.
Governance should make safe behaviour easier. If engineers have to fight the process, they will route around it. If the platform provides approved patterns, fast feedback, and clear escalation paths, teams can move quickly without pretending review alone is enough.
A practical operating model
A pragmatic model for AI-assisted delivery can be built around four stages.
First, constrain. Define where AI can be used, what repositories and files it can access, and what actions require human approval. Keep production credentials and sensitive data outside model context. Use allowlists for tools and commands where possible.
Second, verify. Require automated tests and policy checks that match the risk of the change. For high-risk code, include integration evidence, security checks, and rollback notes. Generated tests should be reviewed with the same skepticism as generated implementation.
Third, review. Keep human review, but make it sharper. Ask for reasoning, not just a clean diff. Flag AI-assisted high-risk changes. Ensure the author can explain the operational impact.
Fourth, observe. Treat production as the final source of truth. Use progressive rollout, feature flags, logs, metrics, traces, alerts, and error budgets. If an AI-assisted change causes an incident or near miss, update the guardrails.
This model is not heavy for every change. A CSS tweak and an IAM policy update do not need the same process. The operating model should scale with risk.
What safe enough looks like
No serious engineering process eliminates all production risk. The goal is to make risk visible, bounded, and recoverable.
An AI-assisted delivery process is becoming mature when:
- High-risk areas are clearly identified.
- Engineers know when AI use is allowed and when extra review is required.
- Generated code cannot bypass CI, security checks, or release controls.
- Reviewers focus on system behaviour, not just code style.
- Infrastructure changes are checked against policy automatically.
- Dependencies and build artifacts are traceable.
- Production releases are observable and reversible.
- Incidents lead to better templates, tests, policies, and platform defaults.
The outcome is not slower delivery. It is delivery that can absorb higher code velocity without losing control.
That distinction matters. AI can help teams move faster, but speed without production discipline is just a faster route to rework. Review gates are part of the answer, but they are not the operating model. The organisations that benefit most from AI-generated code will be the ones that pair it with stronger architecture, clearer ownership, better verification, and production feedback loops that tell the truth quickly.
