Your AI agent changed the requirements. Here is how to stop it

What it looks like

• An acceptance criterion in the spec now says what the code does, not what you agreed.
• A failing test was "fixed" by changing the expected value, or deleted.
• A decision you made on purpose, such as which data you store, was reversed in a doc edit buried in a large diff.
• The agent reports the task as done, and it is, against a requirement it rewrote along the way.

Why the agent does it

To an agent, your requirements are one more file in the repository. When the code and the spec disagree, it is asked to make the task pass, and editing a markdown file or an expected value is the shortest way there. It is not being sneaky. Nothing tells it which side of the disagreement is the one you meant.

There is a quieter path too, and in our own sessions it is the common one. The agent proposes a new wording, you reply "yes, go", and the requirement changes. Nothing went wrong in that moment. Two weeks later nobody remembers that the old wording was the agreed one, because the only record is a line in a git diff.

What helps, even without new tools

• Say it in the instructions file. In CLAUDE.md, AGENTS.md or Cursor rules: requirements and tests are read-only; if code and spec disagree, stop and ask.
• Review spec and test changes on their own. A doc edit inside a feature diff is easy to miss. Split them into their own commit or pull request.
• Protect the files. A CODEOWNERS entry on the spec folder and the tests means a human signs off on every change to them.
• Fail the build on weakened tests: a pre-commit or CI check that flags new skip markers and deleted assertions.
• Give each requirement a stable id and ask the agent to cite it in commits, so a change to the requirement and the code that relied on it can be found together.

All of these work, and all of them rely on the agent following an instruction or a reviewer catching a diff. The requirement still lives in a file the agent can write to.

How Entalpa handles it

Entalpa moves the requirements out of the repository the agent edits. Your agent reads them over MCP as a structured spec: stakeholders, user stories, requirements with acceptance criteria, each with a stable id. The code lives in your repo; the agreed version of what it must do lives in Entalpa.

• Lock a requirement and Entalpa's AI never rewrites it. Generation and suggestions build the rest of the spec around a locked requirement; a suggestion that would change it is not applied.
• Every change, yours or your agent's, lands in the project history. You can compare versions and undo, so a "yes, go" is visible and reversible.
• When a story changes, the requirements built on it are marked for review instead of being rewritten silently.
• Agents write status back onto the requirement: implemented, code references, test coverage. Progress gets recorded next to the requirement instead of overwriting it.

A lock is not a permission system for people: you can still edit a locked requirement yourself. It keeps models from rewriting what you decided, and the history keeps everyone honest about the rest. Setup takes one command for Claude Code, Cursor, Codex and other agents.

Questions this raises