How do I stop AI coding agents from breaking features that already work?

Reduce regressions by giving the agent a bounded task, reviewing the resulting changes, and checking the important existing workflows before release. Keep unrelated refactoring out of a small fix. A clear merge process and useful regression tests make it harder for a plausible new feature to overwrite working behaviour.

GitHub's protected-branch documentation describes controls such as required reviews and status checks. Those controls support a workflow; they do not determine whether the checks themselves cover your business requirements.

Why does a small request cause a large change?

An agent may lack context about existing behaviour, choose a broader interpretation of the task, or modify a shared component used elsewhere. The resulting app can look correct on the page being edited while another page stops working.

Before implementation, identify the affected component and where else it is used. Give the agent the existing requirements, known constraints, and the particular result you want. Ask for clarification when a requirement is ambiguous instead of allowing a guess to become code.

Preserve a known working state in version control so the team can inspect and recover changes.

What should a useful task brief contain?

For an illustrative login-form change, the brief could state that the task is to improve field spacing and mobile scrolling while retaining the existing request payload, validation, and error behaviour.

This is a review aid, not a substitute for reading the diff. An agent can still miss a constraint or misunderstand its consequences.

What should the reviewer look for?

Compare the changed files with the stated task. Look for unexpected dependency updates, renamed fields, removed validation, altered permissions, and shared styles that affect other pages.

Ask the developer to explain changes that seem unrelated. If a larger refactor is necessary, separate it into a reviewable proposal with its own verification rather than hiding it inside the original request.

Check the actual before-and-after behaviour. A screenshot can demonstrate spacing, but it cannot prove that a form still submits the same data or that an error preserves the user's input.

How do we make regressions less expensive?

Keep a short list of critical journeys and the checks that protect them. Add targeted regression coverage when a real failure reveals a gap. Use preview environments for review and release changes through a process with clear ownership.

If the same feature repeatedly breaks, investigate the underlying structure. Several duplicated copies of a form, for example, may need consolidation before more isolated patches will help.

Avoid asking the agent to "fix everything" after an unexplained failure. Reproduce the issue, narrow the cause, and verify the correction. That creates evidence the next developer can use instead of another broad, difficult-to-review diff.

Stabilize an app that keeps regressing

Bring a few examples of changes that broke working behaviour and the affected workflows. Discuss ongoing app maintenance to establish a review and release process around the actual application.

Frequently asked questions

Should we ban large AI-generated changes?

Use size as a signal to review the scope. Some changes legitimately span several components, but they still need an understandable purpose and verification plan.

Will telling the agent to preserve everything solve the problem?

It helps communicate intent but cannot establish correctness. Review the resulting changes and run the checks relevant to the behaviour being preserved.

Can we let an agent merge its own work?

Agree the authority and review requirements for your project. For consequential changes, keep an accountable reviewer and enforced checks appropriate to the release risk.