How should AI-generated software changes be deployed safely?

Generating a change quickly can create pressure to release it quickly. Yet a convincing diff and passing generated tests do not show how the change behaves with real integrations, data and traffic.

Safe deployment treats AI as part of the creation history, not as a reason to bypass engineering controls. The decisive question is whether the organisation has credible evidence and can contain an unexpected effect.

Establish an accepted change

Keep AI-generated work on a branch or equivalent controlled workspace. Review the actual change, dependencies, configuration, infrastructure and migration effects. Confirm that acceptance criteria reflect Product intent and that Engineering understands the implementation.

Run independent automated and human checks appropriate to risk. Tests written by the same model may repeat its assumptions. Use existing regression suites, static and security analysis, integration environments and specialist review where needed.

Record task intent, tool involvement, source provenance, reviewer and evidence. The agent that creates a change should not normally approve and merge it.

Protect the build and release path

Build from trusted repositories through a controlled pipeline whose rules cannot be silently altered by the agent. Protect signing credentials, deployment tokens and environment secrets. Verify artefact integrity and approved source before release.

Separate write, merge and deployment permissions. An agent may prepare a pull request without receiving production access. Where automated deployment is appropriate, require the pipeline to enforce acceptance conditions rather than trusting the generated instruction.

NCSC secure development guidance recommends trusted pipelines, peer review, automatic testing, careful secret management and controls that cannot be bypassed or reordered. These principles remain central for AI-generated changes.

Release according to consequence

Choose a strategy that limits blast radius: a development environment, staged rollout, canary, feature control or small user cohort where the system permits it. Define expected signals and stop conditions before release. High-risk data migrations or difficult-to-reverse changes need stronger preparation than a reversible presentation change.

Human approval should protect material transitions, not every mechanical step. The approver needs the exact version, affected systems, evidence, unresolved risk and recovery plan. If any of those change, the approval may no longer apply.

Do not assume a small code diff has a small operational effect. Configuration, permissions and shared components can create wide consequences.

Observe, recover and learn

Connect the deployment identifier to operational telemetry, customer effects, errors and security signals. Watch both expected behaviour and indicators of regression. Assign an accountable person or team during the observation period.

Test rollback, failover or forward recovery before relying on it. Some data changes cannot be reversed mechanically, so recovery may require compensating action and Product communication. Give teams authority to stop an unsafe release.

Afterwards, record false assumptions, review findings, rollback and supervision effort. Improve prompts, repository context, tests or controls, but keep the operational lesson in authoritative engineering records. Deployment is complete only when the change is operating acceptably, not when the pipeline reports success.

Example

An agent prepares a change to invoice calculation and opens a pull request. Engineers review the logic against Product rules and add an integration case the generated tests missed. The trusted pipeline builds and signs the artefact; the agent cannot merge or access deployment credentials.

The team releases to a small internal cohort with defined calculation and error signals. A named engineer watches the rollout and can disable the Feature. Only after evidence remains acceptable does the team widen release.

FAQs

• Should AI-generated code always require a manual deployment?

  No. Automated deployment can be suitable when trusted controls, evidence, scope and recovery have been proven. Human approval should reflect consequence rather than code origin alone.

• Can an AI agent deploy its own change?

  That combines creation and acceptance authority. Use it only within a tightly bounded, tested and observable path where independent controls can prevent or reverse harmful effects.

• Is rollback enough to make deployment safe?

  No. Rollback may fail or leave data and customer consequences. Prevention, progressive release, monitoring and a realistic recovery plan are all needed.