Since July 2026 I’ve been Acting Head of DevOps at Ollion, leading a team of 16 engineers across client engagements in cloud platforms and infrastructure. When AI coding assistants became genuinely useful tools — not demos, but tools engineers reached for in actual work — we needed to be deliberate about how the team used them.
The goal wasn’t to slow down adoption. The tools make engineers more productive, and that matters. The goal was to make sure we weren’t trading a productivity gain for a new category of production incident.
These are the rules we landed on. They’re not universal; they reflect the work this team does — infrastructure-as-code, Kubernetes platform builds, cloud migration programs — and the risk profile that comes with it.
Rule 1: AI-generated IaC goes through the same review gate as human-written IaC. No exceptions.
This one sounds obvious and is frequently overlooked in practice. When an engineer generates a Terraform module with an AI assistant, there’s a subtle tendency to treat the output as pre-reviewed because the tool is confident and the formatting is clean. It isn’t pre-reviewed. It’s a first draft.
The review gate exists because IaC changes have blast radius. A misconfigured IAM binding, an incorrect CIDR block, a security group rule that’s too permissive — these don’t announce themselves loudly. They sit in the configuration and either get exploited or cause an incident during the next change.
AI-generated IaC goes through the same peer review as anything else. The reviewer doesn’t need to know whether the code was AI-generated; they need to review it with the same rigour regardless.
Rule 2: No credentials, customer data, or production configs in prompts.
The AI assistant doesn’t need them to do useful work, and the risk is asymmetric. Credentials and config that leave the team’s controlled environment — even to a tool the team trusts — create a surface that doesn’t exist if the prompt is written without them.
The practical version: write prompts using representative examples, synthetic data, or anonymised structures. If the assistant needs to understand a production architecture, describe the architecture in general terms rather than pasting the config. If you’re debugging, describe the behaviour rather than providing the credential that proves it.
This rule has an enforcement problem: it’s hard to audit. What we did was make it an explicit expectation in onboarding and in the team’s practice documentation, so the norm was clear before the habit formed.
Rule 3: AI is a pair programmer, not an approver. It can suggest; a human must verify.
The AI assistant doesn’t know the full context: the client’s regulatory environment, the existing security posture, the reason the previous approach was rejected, the constraint that makes an otherwise correct answer wrong in this specific situation. The engineer does — or knows where to find it.
The output of an AI assistant is a starting point, not a conclusion. The engineer’s job is to understand what was generated, verify that it’s correct for the situation, and take responsibility for it. “The AI wrote it” is not an acceptable answer in a postmortem.
This has a cultural dimension that matters as much as the procedural one. Teams that use AI well use it to accelerate their own thinking — to get a draft fast so they can spend their time on the parts that require judgment. Teams that use it badly use it to avoid thinking, which works until it doesn’t.
Rule 4: Any AI-suggested change to a security control gets a second human reviewer.
Security controls are where the blast radius is highest and where the AI is most likely to be confidently wrong in a way that isn’t immediately visible. Admission policies, network policies, RBAC bindings, IAM roles, secrets management configurations — these are the places where a plausible-looking but incorrect suggestion causes the kind of problem that shows up months later in an audit finding or a breach.
For these changes, one reviewer is not enough. The second reviewer’s job is not to rubber-stamp; it’s to independently evaluate whether the change is correct, not just whether it looks reasonable.
This adds friction. It’s the right amount of friction for this category of change.
Rule 5: Document when AI was used so reviewers know what to look at more carefully.
In code review, a comment noting “AI-generated, please review carefully” is not an admission of failure — it’s useful information for the reviewer. It tells them where to apply more scrutiny, not less.
This rule is about reviewer calibration. A PR that’s entirely hand-written by an engineer who’s been on the team for two years is a different risk profile from a PR that was substantially generated with an AI assistant and is the engineer’s first week on the project. The reviewer shouldn’t have to guess which is which.
What the rules don’t cover
These rules are about risk, not about productivity. They don’t constrain how often AI tools are used, which tools are used, or what they’re used for. Engineers use AI assistants for code generation, documentation, debugging, test writing, and a dozen other things. The rules only apply where the output touches production systems or security controls.
The productivity gains are real. The team moves faster on first drafts, spends less time on boilerplate, and can explore more options before committing to an approach. The rules exist to make sure that speed doesn’t bypass the human judgment that production infrastructure still requires.
The goal is a team that’s genuinely more capable with AI tools — not one that’s faster until it isn’t.