---
title: 'In the News: August 14, 2026, Extra'
description: 'Birgitta Boeckeler ran an agent on sensor feedback alone. Mutation testing found 13 assertion gaps that a 100 percent coverage number had hidden.'
canonical_url: 'https://darkfactory.dev/news/2026-08-14-extra'
markdown_url: 'https://darkfactory.dev/news/2026-08-14-extra.md'
collection: news
date_published: '2026-08-14T16:30:00-04:00'
date_modified: '2026-08-14T16:30:00-04:00'
---

# In the News: August 14, 2026, Extra


Birgitta Böckeler has published measurements from building an application on agent sensor
feedback with almost no written guides. A file reporting 100 percent statement coverage
turned out to have no unit tests at all.

## 1. Coverage said the code was tested. Mutation testing found 13 places it was not.

**[Maintainability sensors for coding agents](https://martinfowler.com/articles/sensors-for-coding-agents.html)** · Birgitta Böckeler, Distinguished Engineer, Thoughtworks · martinfowler.com, 27 May 2026

This is the follow-up to [Harness engineering for coding agent users](https://martinfowler.com/articles/harness-engineering.html), the article that supplies the guides-and-sensors
vocabulary, and it reports what happened when Böckeler removed one half of that pair. She
rebuilt an internal analytics dashboard in TypeScript, NextJS and React from scratch, using
Cursor, Claude Code and OpenCode, and deliberately wrote almost no markdown guides, "to see
how well it can do just by relying on sensor feedback." The agent wrote the entire test suite
with, in her words, no oversight beyond manual testing and watching coverage.

One file, `mappers.ts`, reported 100
percent statement coverage and 75 percent branch coverage while having no unit tests
whatsoever; the coverage came from a single large acceptance test that happened to call
through it. Stryker, the mutation testing tool she used, reported 13 survivors, meaning 13
deliberate code mutations that the suite stayed green through. Her summary of the gap:
"coverage tells us that a line was executed, but not that its impact was verified."

Grounding an LLM modularity review in deterministic coupling data did not
improve it. "The AI mostly found confirmation in the data, but not any additional findings.
On the contrary, it pointed out lots of things that the CLI was missing." The raw metrics on
their own fared worse still, flagging a deliberate dependency-injection factory and a shared
schema as defects. Her lint messages offer a design move you can copy today: they carry
the reasoning rather than the verdict, and permit the agent to raise a threshold slightly
instead of suppressing a rule, "so that the rule fires again if it gets even worse in the
future." She found the one rule category where the agent behaved badly was the one category
where she had forgotten to configure that guidance.

She is equally plain about what did not work. Getting the agent to check the sensors at all
was unreliable: "I had to ask the agents many, many times why it had not run the sensors
check a single time." And she declines the larger claim outright, writing that the sensors
"are not a magical solution to take the human totally out of the loop."

This is one engineer's experience on one self-built internal
application, with no comparative baseline, and the sensor tooling is her own. Read the numbers
as measurements from that setup, not as a benchmark.

**Why it matters:** If you have let an agent write your tests, your coverage number is
measuring the wrong thing, and Böckeler has put a figure on how far wrong. Mutation testing is
the cheap check that tells you whether the suite would actually catch a regression, and it is
the one sensor in her list that becomes more important the more of the testing you hand over.
The lint-message pattern is the other portable idea here: a rule that explains itself changes
agent behaviour, and a rule that only forbids gets routed around.