Field note · May 15, 2026

Why AI Makes Unsafe Deployments More Dangerous

AI-assisted development changes the release risk equation.

The old release process was built around scarcity. Code was expensive to write, so changes arrived in batches. Teams held release meetings, assembled checklists, and treated production as a place you visited carefully.

AI makes code cheaper. The team can ship many more changes in the same week. That sounds good until you remember that production risk scales with change rate.

If your deployment system is unsafe at one release per week, it will not become safe at ten releases per week because the code was written with an AI assistant.

This is the second pillar in AI readiness: production safety.

The bottleneck moves from building to surviving

AI helps engineers produce implementations faster. It does not automatically make those implementations safe for production.

Some AI-generated changes will be good. Some will be subtly wrong. Some will pass tests and still fail under real traffic, real data, real permissions, or real browser conditions. That is not a moral failure of AI. It is normal software risk, multiplied by higher throughput.

The question is whether production can absorb that throughput.

Can you deploy during business hours without scheduling downtime?

Can you turn a feature on for one percent of users before everyone?

Can you detect a bad release in minutes?

Can you roll back instantly without a six-hour war room?

If the answer is no, AI-assisted development becomes a liability. It gives the team more ways to create production change than the platform has ways to contain it.

Safe deployment is a system, not a ceremony

Safe deployment has four practical parts.

Google's SRE material is useful because it treats reliability as an engineering discipline, not a release checklist. The SRE book explains monitoring around symptoms and causes, and emphasizes practical signals such as request success, latency, traffic, and saturation in Monitoring Distributed Systems. The SRE workbook also describes monitoring data sources including metrics, logs, and distributed tracing in Monitoring Systems with Advanced Analytics.

AI-assisted teams need this discipline because they are changing production more often.

Feature flags decouple deploy from release

One of the most important shifts is separating "deployed" from "released."

Without feature flags, every deploy is also a user-facing release. The code reaches production and customers experience it immediately. That makes every deploy emotionally expensive, so teams bundle work, deploy less often, and increase blast radius.

Feature flags let the team deploy code dark, enable it for internal users, then a small customer cohort, then everyone. Martin Fowler's guide to Feature Toggles describes how toggle infrastructure can support canary release by enabling a feature for a small user cohort first.

For AI-assisted development, this matters because some generated changes will need real production feedback before the team trusts them. Flags give you a way to get that feedback without betting the whole product.

The anti-pattern is using AI to generate more code, then pushing it straight to every user because "the tests passed."

Canary and blue-green deployments reduce blast radius

Progressive delivery gives the platform a controlled path from new code to full production.

A canary deployment sends a small percentage of traffic to the new version first. Google Cloud's Cloud Deploy documentation describes canary as a progressive rollout that splits traffic between the current version and the new version before full release. The practical benefit is explicit: it gives the team a chance to ensure the new version is reliable before delivering it to all users. See Google Cloud's guide to canary deployment strategy.

Blue-green deployment keeps two production environments or versions available, with traffic switched between them. Argo Rollouts documents both blue-green and canary strategies for Kubernetes progressive delivery.

The exact tool does not matter as much as the capability:

• release to a narrow slice,
• watch the health signals,
• promote if healthy,
• stop or revert if not.

AI makes that operating model more valuable because the team is producing more release candidates.

Rollback has to be designed before the incident

Rollback is not a button you discover during an outage. It is a property you design into the system.

The hard parts are usually not the application binary. They are state and compatibility:

• database migrations,
• queue messages,
• cached objects,
• API contracts,
• background jobs,
• mobile clients,
• third-party integrations.

For AI-assisted teams, database migration safety deserves special attention. AI can generate plausible migrations quickly, but production data has history — which is why safe data changes stay a senior engineer's call. Safe teams use backward-compatible migrations, expand-contract patterns, parallel reads or writes when needed, and clear rollback plans before schema changes land.

The practical standard is simple: if the team cannot explain how to reverse or neutralize the change, the change is not ready for automated production flow.

This does not mean every incident should roll back. Sometimes rolling forward is faster. But the team needs a practiced recovery path either way.

DORA tracks failed deployment recovery time because recovery speed is part of delivery performance, not an afterthought. See DORA's software delivery metrics.

Observability is how production talks back

AI-generated code can look fine in review and still fail in production.

Maybe it handles the happy path but explodes on old customer data. Maybe it adds a slow query. Maybe it increases background job retries. Maybe it works for admins and fails for users with limited permissions.

The team needs production feedback that is fast, visible, and tied to user impact.

At minimum, AI-assisted production systems need:

• metrics for request rate, error rate, latency, saturation, and business-critical events,
• logs that explain what happened for a specific request or workflow,
• traces for cross-service behaviour,
• dashboards tied to SLOs,
• alerts that page on user impact, not dashboard aesthetics,
• release markers so the team can connect symptoms to recent changes.

Without observability, AI-assisted delivery is flying blind at higher speed.

A production safety checklist for AI-assisted teams

Use this before expanding AI-assisted development across a product team.

If production safety is weak, AI will not feel like acceleration for long. It will feel like more interruptions.

The founder-facing math

Imagine the team had five production changes per week and one in ten caused a customer-impacting issue. That is manageable if recovery takes ten minutes. It is painful if recovery takes four hours.

Now add AI and triple the change rate.

If the change failure rate and recovery time stay the same, incident load rises with throughput. Customers do not experience "more engineering productivity." They experience more product instability.

This is why AI readiness is not a tooling question. It is a delivery system question.

The goal is not to prevent every bad change. That is impossible. The goal is to make bad changes small, detectable, reversible, and boring.

What to fix first

Start where production risk concentrates.

If releases cause downtime, fix deployment mechanics first. If incidents last too long, fix rollback and observability. If every deploy releases everything to everyone, add feature flags. If database migrations are the scary part, introduce backward-compatible migration patterns before asking AI to help generate schema changes.

Do not scale AI-assisted development into a production platform that cannot recover.

AI lets engineering teams create more change. Production safety determines whether that change becomes product velocity or operational debt.