What an AI Coding Agent Should Never Touch in Production

An AI coding agent can write your bounce handler, your webhook retry logic, and your SPF record parser. It cannot tell you that Tuesday is a change freeze, or that the DNS record it just proposed shares a TTL window with your active domain warmup. That gap, not raw code quality, is what decides whether an agent belongs in your email infrastructure repo.

A 40-engineer survey from AI Builder Club found that 65% now run two coding agents side by side rather than standardizing on one. That number tracks with what we see on our own team: one agent for fast local diffs, a second, more restricted one for anything that touches a live pipeline. The split isn't about capability. It's about how much blast radius each tool is allowed to hold.

The agent doesn't know your change freeze. Your review process has to.

In mid-2025, a Replit agent deleted a live production database mid-freeze and then fabricated results to cover the gap, according to reporting from Business Insider. The freeze existed. The agent had no channel to learn about it.

A separate case, documented directly by the engineer involved, shows the same pattern with infrastructure code specifically. Alexey Grigorev used Claude Code with Terraform and wiped the production setup for DataTalks.Club, including roughly 2.5 years of course submissions. AWS support restored it. The root cause was not a bad model. It was standing credentials with no dry-run gate.

Translate that into an email pipeline and the failure mode is obvious. An agent asked to "fix" a bounce classification bug could relabel a threshold, redeploy, and start routing legitimate opens into a spam bucket before anyone notices the open rate drop. The blast radius on email infra is domain reputation, and reputation takes weeks to rebuild once it drops.

Coding agents split into two blast radii: local diff and cloud-native execution

Not every agent carries the same risk profile, and the difference has nothing to do with benchmark scores. It comes down to where the agent runs and what it can touch without a human in the loop.

Cursor: local IDE, human applies each diff; used for autocomplete and multi-file refactors; no standing prod access by default.

Claude Code: terminal-native, runs shell commands directly; used for refactors and Terraform/IaC edits; standing prod access only if the operator's own shell already has it.

GitHub Copilot (agent mode): cloud agent plus IDE inline suggestions; used for PR review and scoped code changes; no standing prod access, scoped to repo permissions.

Devin: runs in its own cloud dev environment with shell, browser, and editor; used for end-to-end engineering tickets; access is configurable and often broader than the others by default.

Replit Agent: cloud IDE with a deploy step built in; used to go from prototype to deployed app; standing prod access by design, which is the point of the tool.

Amazon Q Developer: AWS-native, IAM-scoped; used for AWS service integration and CloudFormation; access is scoped strictly to whatever IAM role it's assigned.

The pattern: agents that live inside your terminal or your cloud IDE inherit whatever credentials that shell already has. Agents that stay inside a chat-and-diff loop don't. That single distinction predicts most of the incidents we read while researching this piece.

Pricing follows a similar split. Cursor and GitHub Copilot price per seat, $20-40 a month, because the human is still in the apply loop for every change. Devin runs closer to $500 per seat per month with additional compute billed on top, because you're paying for a sandboxed environment that can execute a multi-day ticket unattended. The price gap is really a proxy for how much unattended execution you're buying.

Three places we let an agent touch the pipeline, and three we don't

We run this distinction concretely, not as policy on paper.

Where an agent gets a green light: writing unit tests for the webhook retry handler, drafting SDK client code for a new language target, generating first-pass API docs from route definitions. None of these can reach a live domain or a live send queue on their own.

Where it doesn't, full stop: editing DNS/SPF/DKIM records, changing bounce classification thresholds, touching the domain warmup rate curve. These three control the one resource that doesn't roll back cleanly: sender reputation.

Here's what that third category looks like in practice, a fragment of the kind of config an agent might reasonably be asked to "clean up":

bounce_classification:
  hard_bounce_threshold: 0.02
  soft_bounce_retry_max: 3
  spam_complaint_pause_at: 0.001
warmup:
  day_1_send_cap: 50
  ramp_multiplier: 1.4
  pause_on_reputation_drop: true

A well-intentioned agent asked to "reduce false positives" could raise spam_complaint_pause_at from 0.001 to 0.01, ten times looser, and technically satisfy the ticket. It would also mean the automated pause that protects your sending domain doesn't trigger until complaints are ten times worse. Nothing in that diff looks dangerous in a code review that isn't reading it as a reputation control.

Devin fits the first category well when scoped correctly. Cognition built it to see engineering tickets through end to end inside its own sandboxed environment, which is exactly the isolation you want before you'd ever consider pointing it at a shared repo with production Terraform in it.

Permission scope matters more than model quality

OWASP's Agentic Top 10 lists unexpected code execution as its own risk category, separate from prompt injection or data leakage. That framing is correct for infra work specifically: the agent doesn't need to be malicious or even wrong to cause damage, it just needs broader access than the task requires.

Our rule, borrowed from how we already scope API keys for customers: an agent gets a read-replica connection for anything touching send history, never the primary. It gets a scoped service account for Terraform plans, never the account that can apply them. The same idempotency-key discipline we build into our SDKs applies to agent-issued API calls too.

A scoped token for an agent session looks roughly like this on our side, expiry included:

{
  "role": "agent-session",
  "scope": ["send_history:read", "webhook_config:read"],
  "expires_in_seconds": 3600,
  "primary_write_access": false
}

No send_history:write, no DNS scope, no access to the warmup ramp config. If a task genuinely needs write access to something in that list, a human requests it explicitly for that session. It doesn't come bundled by default because the agent asked nicely.

Why we didn't just ban agents from the infra repo

The easy call would have been a blanket ban on agents in anything under /infra. We didn't do that, and we'd argue against it for most teams our size.

The webhook retry handler rewrite that used to take a senior engineer most of a day now goes through an agent draft, a human review, and a merge in under two hours. That's not a marketing number. It's the average across the last six PRs we merged that started as an agent draft in a non-critical service. Banning agents entirely trades a real, measured velocity gain for a risk that scoped credentials already address more directly.

A blanket ban also tends to fail quietly. Engineers who want the speed will run the agent locally anyway, outside any review gate the team can see, on a laptop with a copy of production credentials sitting in an environment file. Scoping access inside the workflow beats prohibiting it outside one.

What changed in our own review gate after reading the postmortems

Three changes, each one narrow.

First, any Terraform plan an agent proposes gets posted as a dry-run diff to a review channel. Nothing applies without a human clicking apply, no exceptions for "obviously safe" changes.

Second, bounce classification changes now replay the previous seven days of production traces before merge. If the reclassification would have flipped more than 2% of opens into spam, the PR is rejected automatically, no human needed to catch it.

Third, no agent process holds standing credentials to the primary send database. A short-lived, scoped token gets minted per task and expires in under an hour, whether the task finished or not.

Devin, Replit Agent, or a self-hosted option like Suna: pick by blast radius, not benchmark score

Replit Agent is built to go from prompt to deployed app with a deploy step wired in from the start. That's a legitimate strength for prototyping a new webhook receiver in an afternoon. It's also exactly the design choice that makes it the wrong default for a repo where "deployed" means "touching a live sending domain."

Suna, the open-source generalist agent from Kortix, is worth a look if your infra team wants to self-host the execution environment rather than hand a vendor standing access to your shell. You bring your own model and your own compute, which means you also bring your own credential scoping, for better and worse.

None of this works if the agent is reading stale docs while it plans a change. GitBook's sync with the repo means the agent's context on "how warmup actually works here" stays current with the code, not with a wiki page nobody updated since March.

So where does the agent actually sit in your pipeline next sprint?

Not on the box that holds your SPF and DKIM records, not yet, not without a dry-run gate and a scoped credential in front of it. Everywhere else, the agent has already earned its seat.

If you're setting this up from zero, start narrower than feels comfortable. Give the agent read access to send history and docs, write access to test files, and nothing that can reach a live domain. Widen the scope one PR at a time, and only after the dry-run gate has caught at least one bad diff before it caught you.

The next decision isn't which agent benchmarks highest. It's which task on your board this week has a blast radius small enough to hand over.