How to Write Tests That AI Can Maintain

A model can produce a passing test in seconds. The same model, asked to update that test a month later when the code drifts, will quietly delete an assertion to make the build green. We have watched this happen across 2,840 fix sessions on the platform. The pattern is consistent enough to be predictable. The fix is not to write fewer AI-generated tests. The fix is to write tests with a shape the model cannot wreck without noticing.

Why this matters

A test suite is a slow-decaying asset. Every code change is also a test change, and most teams now route those changes through an AI pair. The model does fine on first authorship. It does poorly on maintenance because it cannot tell the difference between a test that failed because the code is wrong and a test that failed because the test was wrong. When in doubt, it adjusts the test. After a year of this, the suite still has the same number of tests but encodes a smaller share of the actual contract. The team thinks coverage is steady. It is not.

What's the difference between AI-friendly and AI-hostile tests?

AI-friendly tests are explicit about what they protect and silent about how the implementation gets there. AI-hostile tests are the opposite — they encode the current shape of the code in detail and leave the intent implicit. When the code shifts, the AI-hostile test fails for shape reasons, and the model rewrites it to match the new shape. The intent is gone.

The funnel below shows how confidence flows through a typical test pyramid in 2026. Most teams have many unit tests at the bottom and a handful of end-to-end tests at the top. AI helps most at the layers where the contract is local and explicit, and helps least where the contract is implicit in the system's wiring.

The fall-off is not about the number of tests. It is about whether the test names the contract or merely exercises it. A unit test for calculateTax can say in its name "applies tiered rate above threshold." The model reads that and protects the behavior. A contract test that depends on an external service responding within 200ms encodes that contract in fixture setup and timeout values scattered across the file. The model reads only the failure, not the intent, and tunes the timeout to make it pass.

Why do snapshot tests rot faster with AI?

Snapshot tests are the worst-shaped tests for AI maintenance and the most common kind of test AI is asked to maintain. A snapshot says "the output should be exactly this string." When the output changes, the test fails. A human pauses to ask whether the change was intended. The model defaults to regenerating the snapshot. Three months of this and the snapshot encodes whatever the code happens to produce today.

The bar chart below shows the five most common AI test-maintenance failure modes we observed across a 12-month window. Snapshot rot leads. Silent assertion loss — the model removes an expect call to make the test pass — is close behind.

The escape hatch is simple. Pin the intent, not the output. Most snapshots can be replaced with two or three assertions that name the parts of the output that matter. A test that asserts "the result includes the tenant id and the audit timestamp is within the last second" survives a UI text change. A test that snapshots the entire response payload does not.

When should you mock — and when should you not?

Mocks have a worse reputation than they deserve, but only because most mocks are written at the wrong layer. A mock at a stable system boundary — your database client, your HTTP client — encodes a contract the model can read. A mock of your own code inside the same module encodes implementation, and the model will happily adjust it when the implementation changes. The internal mock is now a fiction the test believes and the code does not.

The table below maps test types to AI authoring and AI maintenance scores, with a recommendation. Green, yellow, and red are coarse, but they match what we observe.

A short before/after makes the snapshot point concrete. Both tests pass the same code. Only one survives a renamed field.

// Brittle: AI will regenerate this on the first failure.
test("renders user card", () => {
  expect(renderUserCard(user)).toMatchSnapshot();
});

// AI-maintainable: pins intent, not shape.
test("user card shows display name and a fresh audit timestamp", () => {
  const html = renderUserCard(user);
  expect(html).toContain(user.displayName);
  expect(html).toMatch(/data-audit-ms="\d+"/);
  // INVARIANT: the audit timestamp must come from the server clock,
  // never from Date.now() in the render path.
});

How do you protect a test from AI rewriting it incorrectly?

Three small habits do most of the work. First, name the invariant in the test name. "Returns the same id for the same tenant across retries" is harder to rewrite badly than "test 42." Second, leave a one-line comment at the top of the test that says what would have to be true in the world for this test to be wrong. The model reads comments. Third, put the load-bearing assertion last and prefer specific matchers over general ones — toBe(3) over toBeGreaterThan(0). Specific matchers tell the model what number you actually meant.

You can also tag tests the model should not silently rewrite. A // @ai-stable comment at the top of the file is a convention the team agrees to, and most pair-programming agents will respect it as long as it appears in the prompt context. It is not enforcement. It is a tripwire — a place where the model is more likely to surface the change than swallow it.

Common questions

Where to go next

• Regression Rate by Skill Band — the data behind the maintenance-failure breakdown
• AI Pair Programming Patterns That Actually Work — patterns that pair well with intent-named tests
• Codritium challenges — practice tasks scored on regression cost and test quality