How to Stop Your AI Assistant From Breaking Work That Already Works

You ask AI to improve the screen. It improves the screen and breaks the export button. You ask it to fix the export button. It fixes that and drops a setting you spent an hour getting right.

Someone on my Facebook feed recently asked the question behind this entire series: even after using AI to build an app, how do you stop the work from going backward? How do you automate the scrutiny?

I have run into the same concern while building As Above. I have asked where an article went, why a route stopped working, and how we could protect the work already completed.

My answer is to make preservation part of the assignment, then test it outside the conversation. The agent should produce a changed artifact and evidence that the important old behavior still works. A confident message saying everything is fixed is not that evidence.

You do not have to become a software engineer to insist on this. You do need a simple process.

What an agent can and cannot remember

An AI assistant answers questions or prepares work. An agent can also use connected tools to carry out steps, within the access it has. The same product may do both. Neither label tells you whether it maintains accurate project history, can run tests, or has permission to publish.

Instructions buried in a long conversation are a fragile place to keep essential requirements. Anthropic has documented coding agents losing continuity between sessions, attempting too much at once, and declaring work finished too early. Its proposed remedies include persistent progress records and incremental work. This is a known engineering problem, not a personal failure to find the magic prompt. Source: Anthropic on long-running agents.

Here is the process I would put around your next revision.

Save the version that works

Before changing anything, preserve a copy you can actually restore.

For a document, that might be an original file plus a dated working copy. For an app, use version control, such as Git, and a known working build. Ask your coding assistant to identify the starting version before it edits.

Do not confuse code recovery with data recovery. Restoring yesterday's app may not restore a customer's deleted records. If the change touches stored data, back up that data and test the upgrade on disposable copies first. Some data changes need a recovery procedure rather than a simple rollback.

Keep backup access separate from the agent's everyday editing access where possible. A folder called Backup does not help if the same mistake can overwrite it.

Write down what must not change

Create a short requirements file outside the chat. It should contain the requested change and the things that must survive it.

For the reader's app, that could mean:

• Existing saved records still open after an update.
• Export still includes every required field.
• A returning customer does not have to recreate settings.
• A failed network request does not look like a completed save.
• Private information does not appear in a public screen or log.

For As Above, preservation includes existing article URLs, library content, and an approved homepage identity that should not change whenever we feature a new story.

Replace “make it better” with “improve this part while these five behaviors remain true.”

Turn the requirements into repeatable checks

A regression test checks that something which worked before still works now. The name sounds technical; the question is ordinary.

Start with a handful of important cases. Include a normal case, missing information, and a previously observed failure. For an app, automated calculations and device-level interaction tests serve different purposes; Google documents both in its Android testing guidance.

Ask the agent to run the old checks before editing, then run them again after editing. This helps distinguish a new problem from one that already existed.

Also test the test. On an isolated copy with fake data, deliberately remove a required field or break a calculation. The check should fail. If it still reports success, you have found a weakness in the check, not proof that the product is fine.

Keep the reviewer separate from the builder

I would not make a second AI conversation the only safeguard. Two assistants can repeat the same mistaken assumption.

Use exact checks for exact questions: arithmetic, required fields, file presence, links, and whether a button actually performs its job. Use a fresh review for judgment: whether a claim is supported, whether the instructions are clear, or whether an important edge case is missing. Keep human review for consequential decisions.

Anthropic's January 2026 evaluation guidance distinguishes code-based checks, model-based judgments, and human review. These answer different questions. A second opinion is useful, but it is not a substitute for running the work. Source: Agent evaluation methods.

Give the reviewer the original requirements, the previous version, the changed version, and the test results. Ask it to identify failures before suggesting improvements. Do not let the builder quietly delete a difficult requirement or weaken a test to get a green result. Test changes need their own explanation and review.

Make a failed check stop the release

This is where scrutiny becomes automation rather than advice.

Ask your coding assistant to create one documented check command. Have your build or release system run it every time. Configure the release to stop when a required check fails. In a code project, this can be enforced through required checks and branch protection, where supported. In a document workflow, keep the output in a draft folder until the checklist and review are complete.

Writing “do not release if tests fail” in a prompt is helpful. Preventing a failed build from reaching publication is stronger. The agent doing the work should not have unrestricted permission to bypass that gate.

You can let the agent attempt a repair on its working copy and rerun the checks. Set a limit on those retries, then ask for human help if it remains stuck. Do not let a repair loop repeatedly change the live system. Rerun your test cases when you change the model, instructions, connected tools, or source documents, not only when you change app code.

The sequence is: request, working copy, checks, review, approval, release, live verification. If you edit after approval, rerun the relevant checks on that new version. If a check cannot run, label it “not tested,” not “passed.”

OpenAI's current developer guidance similarly separates automatic validation from approvals that pause sensitive actions. Those controls have to be configured; this prompt does not install them. Source: Guardrails and human review.

What this looks like on my own website

As Above now uses one canonical editable site, versioned release archives, checks before deployment, and checks against the live site afterward.

On September 29, the verification record reported 203 successful live checks. The release preflight also checked a ledger of 272 protected pages. Those are separate scopes, not a claim that every possible behavior on every page was tested.

The same record explicitly said that a new subscriber receiving the welcome email had not been tested. That distinction matters. A signup form can look right while its delivery chain remains unproven.

This is the kind of report I want: what passed, what was preserved, and what remains unknown. I am not claiming the site cannot break. I want a problem to be easier to detect and a previous version to be recoverable.

Copy this into your next coding session

Before editing, identify the current working version and how to restore it. Read the project requirements and list what must remain unchanged. Make only the requested change. Run the existing checks before and after editing. Do not delete tests or weaken expected results without my approval. Add a check for the problem you fixed. Use fake data in tests. Report the changed files, commands actually run, results, untested behavior, and recovery steps. Do not publish or change live data without approval. If you cannot run a check, say so.

If your tool can only chat, it cannot execute these checks for you. Have it draft the checklist and test plan, then use a capable coding tool or developer to implement and run them.

For non-code work, ask for a dated draft, a comparison with the approved original, and a checklist showing where every required item appears.

After each session, save a brief handoff: current version, completed change, tests run, unresolved issues, next task. Start the next session from that record, not from the assistant's recollection.

Your first assignment today

Pick one thing the agent has broken before. Write down the correct behavior. Create one test that catches the old failure. Confirm the test fails on a broken sample and passes on the working version.

You have now moved one piece of scrutiny out of your memory and into a repeatable process.

That is how I would start. Not by asking AI to promise it will be more careful, but by making it show that the important work survived.

For a more advanced business workflow, read the custom model playbook. For the underlying authority question, read The Verification Layer Between AI and Physical Action.

Research checked September 30, 2026. AI assisted research organization and drafting. Sources are linked beside the claims they support. Editorial standards.