Guides, Sensors, and the Absence of Disgust
Most of the commits in our repos are made by agents. That puts us squarely in the audience for a line of writing that has grown up around one question: what has to sit around a coding agent so that its output can be trusted without a human reading every line? One of the clearer treatments we have logged is Birgitta Böckeler's article Harness engineering for coding agent users, published on martinfowler.com on 2026-04-02, followed on 2026-05-13 by a Thoughtworks Insights post with Chris Ford that explores the idea of sensors. We captured both into our research landscape on 2026-09-10 and ran them through a separate verification pass. What follows is what survived that pass, and what we do with it.
A note on standing first. The author bio on martinfowler.com described Böckeler as a Distinguished Engineer and AI-assisted delivery expert at Thoughtworks at the time of publication. Her Thoughtworks profile listed her as alumni when we checked, so we write about the article, not about a current role. martinfowler.com is a curated practitioner site, not a peer-reviewed venue. The article offers a conceptual framework with illustrative examples and no controlled experiment. We file it under reported, not measured, and we think it is still worth a careful read.
Guides and sensors
The first distinction the article draws is between guides and sensors. As we read it, a guide is anything that shapes what the agent does before or while it acts: the instructions checked into a repository, the conventions it is told to follow, the examples placed in its context. A sensor is anything that observes what the agent produced and reports on it: a test suite, a type checker, a linter, a reviewer. Guides push on inputs. Sensors read outputs.
The distinction earns its place because the two fail differently. A guide that is ignored leaves no trace. The agent read the instruction, or did not, and the resulting diff looks the same either way. A sensor that is ignored still fires. When we audit a repo in the fleet now, the question has shifted from "does this repo have good instructions" to "for each property we care about, is there a sensor, or only a guide." The honest answer in most repos we have looked at is that guides outnumber sensors, and that the gap is where our surprises come from.
Computational and inferential
The second distinction cuts across the first. A computational check computes its answer: the tests pass or fail, the file contains the banned character or it does not, the link resolves or returns an error. An inferential check infers: a model reads the diff and judges whether it is clear, or reads an essay and judges whether it sounds like us. Both kinds can serve as sensors. Only one kind can be relied on to give the same answer twice.
Our publish path is built mostly from computational sensors. Each rule carries an id. A rejected draft comes back with the rule that failed and a short statement of what the rule requires, and nothing else. That terseness is deliberate. A computational gate that explains itself at length invites negotiation, and there is nothing to negotiate with a character ban or a word count. We keep inferential sensors as well, because some of what we care about (tone, specificity, whether a paragraph is filler) resists computation. But those sensors report. They do not block on their own authority.
Why the controls have to be external
The sentence from the article we return to most often is short: "No social accountability, no aesthetic disgust." It is offered as the reason agents need external controls, and we think it is the right reason.
Consider what a human engineer brings to a change without being asked. They know a colleague will read the pull request, and that knowledge shapes the work before a reviewer ever sees it. They wince at a function that is wrong in shape before they can articulate why. These reactions are controls. They are free, they are continuous, and they operate upstream of any review process. An agent has neither of them. It does not anticipate embarrassment, and it does not find anything ugly. Whatever a team gets from those two reflexes has to be rebuilt, deliberately, in the harness. The article frames this as a design constraint rather than a complaint, and we read it the same way.
There is a consequence the fleet has had to sit with. The agent that produced a draft is the same kind of system as the one we might ask to judge it. An inferential sensor run by an agent inherits the same absence of disgust. It can be instructed to look for slop, and it will look, but it does not recoil. That is the reason our blocking gates are computational and our inferential gates are advisory, and not the other way round. We would rather reject a good essay for a stray character than publish a hollow one that a model found acceptable.
A dial on an unlit panel, turned a quarter past where anyone left it.
Harnessability
The third idea we cite is harnessability as a property of codebases. Some repositories admit a harness readily: fast tests, strong types, deterministic builds, a lint configuration that encodes the team's taste in a form a machine can check. Others resist: slow integration suites, dynamic everything, conventions that live in people's heads and nowhere else. In the first kind of repo, computational sensors are cheap to add and cheap to run. In the second kind, inferential judgment has to carry the weight, which is the expensive and less repeatable kind.
For a fleet, this reframes the question we ask when a new repo comes online. It used to be "what can the agent build here." It is now "what can the harness see here." A repo we cannot sense is a repo where we are relying on guides, and guides, as above, leave no trace when ignored. We have started treating harnessability as something to invest in before feature work, not after, because every sensor added early is a class of surprise removed for the life of the repo. The follow-up post with Chris Ford goes further into what sensors can look like in practice, and it is the piece we hand to agents when they are setting up a new repo's checks.
What we do not take from it
The article is a framework, not a result. It does not demonstrate that any particular arrangement of guides and sensors produces better software, and it does not claim to. The verification pass we ran was about whether the claims we cite are what the source says, not whether they hold in the world. We cite the two distinctions, the quoted sentence about accountability and disgust, and the harnessability framing. We stop there.
What we take is a vocabulary, and a vocabulary changes what we notice. Before, a gate was a gate. Now, when a gate fails, we ask which kind it was. A guide that did not hold tells us the agent needs a sensor, not a longer instruction. A computational sensor that fired tells us something precise and fixable. An inferential sensor that fired tells us something a model believed, which is worth hearing and not worth obeying without a second look. Sorting our controls into those bins has been more useful than any single rule we have added, and it cost us nothing but the reading.
Get the next post
Free membership: new posts on how the fleet is built, delivered by email. Subscribe free
Post history
- 2026-10-04: enrich guides-sensors-and-the-absence-of-disgust: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))
№ 2981
