Guides and sensors are the two kinds of control in the model of a coding agent’s outer harness that Birgitta Böckeler proposes in Harness engineering for coding agent users. Guides (feedforward controls) anticipate the agent’s behaviour and aim to steer it before it acts, increasing the probability of a good result on the first attempt. Sensors (feedback controls) observe after the agent acts and help it self-correct. Each can be of one of two execution types: computational — deterministic and fast, run by the CPU, such as tests, linters, type checkers and structural analysis — or inferential — semantic analysis, AI code review or LLM-as-a-Judge, typically run on a GPU or NPU, slower, more expensive and more non-deterministic.
Usage
The article’s examples pair the two axes: coding conventions in AGENTS.md or skills are inferential guides; a tool with access to OpenRewrite recipes is a computational guide; a hook running ArchUnit tests against module boundaries is a computational sensor; and skills holding review instructions are inferential sensors. Sensors are described as particularly powerful when their signals are optimised for LLM consumption, such as custom linter messages that include instructions for the fix — which the author calls a positive kind of prompt injection.
Computational sensors are cheap and fast enough to run on every change alongside the agent, while inferential controls add richer guidance and semantic judgment at a cost. The model has humans steer the agent by improving the guides and sensors whenever an issue recurs, and places sensors across the change lifecycle according to their cost — fast ones before integration, more expensive ones after it, and some running continuously against the codebase or at runtime.
In a practical follow-up, Maintainability sensors for coding agents, the same author reports applying sensors to keep an AI-built application maintainable while deliberately using hardly any guides. Computational sensors — linting with custom self-correction messages, dependency rules, and mutation testing as a check on the test suite — impressed her most at the file and function level, whereas raw coupling data on cross-file concerns was noisy and of little use without the semantic interpretation of an inferential sensor, such as an LLM-based modularity review run on a slower cadence to catch accumulated drift.
When It Applies
The model is framed for users building an outer harness around a coding agent, not for the harness agent builders provide. It assumes both kinds of control are present: according to the article, feedback alone yields an agent that keeps repeating the same mistakes, and feedforward alone yields one that encodes rules but never finds out whether they worked. How much can be built depends on the codebase (Harnessability). The author reports that sensors for internal code quality are the easiest to build today and that sensors for functional behaviour remain largely unsolved. Her follow-up experiments add open questions of their own: sensors can conflict with one another (rules limiting file and function length pushed complexity into long chains of component properties), and it is not yet settled how guides and sensors should be balanced once a set of sensors is trusted. The vocabulary is one author’s proposal, presented as a mental model rather than an established standard.