AI coding does not end at merge

The pull request is approved, CI is green, and the branch has merged. An internal app can still be wrong in production.

The deployed service may use a different configuration. A background worker may not have restarted. A new permission may exist in staging and be missing in production. None of those failures is resolved by the fact that an agent generated the code successfully.

On September 23, 2026, Cursor introduced Rollouts and Security Review. Rollouts was described as checking deployment health by environment and reporting results back to the change. Its announcement said it did not merge or roll back on its own. The release notes document that scope. The useful direction is the connection between a source change and what happens after deployment.

Open full-size diagram ↗

Verify the behavior the change was meant to improve

Imagine a generated change to an internal export service. The requirement is to include records that previously fell outside a date filter. The application starts, the health endpoint returns success, and the error rate stays flat.

Those are necessary signals, but they do not show that the export now includes the correct records. A production verification plan needs a safe way to inspect the behavior that motivated the change, using synthetic data or an approved operational check.

It also needs to identify the deployed revision. If the check runs against an old instance or a cached response, it may confirm a result unrelated to the new code. Link the source revision, build artifact, deployment, and verification result so an operator can trace them.

For systems with several components, verify the whole path. A UI field may be present while the API silently ignores it. A successful request may enqueue work that later fails in a separate service. Checking only the interactive screen leaves those failures outside the completion claim.

Decide what failure means before deploying

Some changes can be rolled back by restoring the previous artifact. Others modify stored data or trigger external actions that a rollback cannot undo. An agent preparing a release should not assume those cases are equivalent.

For a schema change, examine whether old and new application versions can coexist. For an integration, determine whether repeated requests are safe. For a background job, identify how partial work will be resumed or reconciled.

The operator should know which signal would stop the rollout and who can make that decision. Automated monitoring can detect a condition, but acting on it requires authority and a recovery procedure that fits the system.

Open full-size diagram ↗

Internal apps need owners too

An application built for one department may have a small audience and still process important data. Someone needs to own its dependencies, access rules, backups, and incident response after the initial builder moves on.

We would record that owner before calling the app complete. The handoff should include the repository, deployment configuration, relevant dashboards, and instructions for disabling a problematic feature. That does not have to be a large operations manual. It has to be enough for the next engineer to act without reconstructing the generation session.

There is a useful distinction between "the requested code is implemented" and "the change is verified in production." Agents and people should report the stage they actually reached. If a deployment is waiting on approval, say so. If the application is live but the business behavior has not been checked, keep that verification task open.

The last step of AI-assisted development is still operating software. Connecting that step to the original task gives teams a better definition of done and a clearer account of who is responsible when the result needs attention.