Skip to content

MaintainabilitySensorsForCodingAgents

Dennis Lee edited this page May 28, 2026 · 1 revision

title: Maintainability Sensors for Coding Agents type: technique created: 2026-05-28 last_updated: 2026-05-28 related: ["radar/techniques/LLMTDDLoop", "radar/techniques/ScalingLongRunningAgents", "radar/techniques/ExploringGenerativeAI", "radar/techniques/YearBuildingWithLLMs", "radar/tools/TDDGuard"] sources: ["https://martinfowler.com/articles/sensors-for-coding-agents.html"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner

Maintainability Sensors for Coding Agents

Maintainability Sensors for Coding Agents is a set of practices for instrumenting a codebase so that AI coding agents receive feedback on quality issues their output introduces, without requiring a human to notice and intervene. Documented by Birgitta Böckeler (Thoughtworks) on Martin Fowler's site on 2026-05-27 as a follow-up to her earlier piece on harness engineering.

The Problem

Coding agents struggle with the same maintainability problems as humans, but at higher velocity. Tangled codebases lead agents to look in the wrong places, create duplicates, or load excessive context. Early warning signs include small adjustments that touch many files and changes that break previously-working features. Without automated feedback, these defects only surface during human review, by which point the agent has already burned tokens and produced churn.

Sensor Categories

Category Examples What it catches
Computational Linters, type checkers, dependency-cruiser, mutation testing Local rule violations, dependency layering breaches, weak test assertions
Inferential LLM-driven modularity reviews, AI security review, AI data-handling review Cross-file design issues, semantic duplication, misplaced responsibilities

Computational sensors are deterministic and cheap to run frequently. Inferential sensors require an LLM call and are most effective when run multiple times — a second pass surfaces issues missed by the first.

Specific Techniques

Tighter linting tuned for AI failure modes. Default ESLint presets are too permissive. Configure rules targeting agent-specific patterns: max function arguments, file length, function length, cyclomatic complexity. Custom lint formatters override the standard message with self-correction guidance — described by Böckeler as "a good kind of prompt injection."

Dependency rules with dependency-cruiser. Encode layered module structure as enforceable rules (e.g., clients cannot import from services). Computational sensors excel at file-level rules; cross-file architectural concerns require inferential review.

AI modularity review using Khononov's Modularity Skills prompts. Found duplicate route code, inconsistent backend calls, parameters repeated at every level, and misplaced responsibilities — issues no linter detects.

Mutation testing with Stryker. Surfaces weak assertions that coverage hides. Böckeler reports a file with 100% statement coverage and 75% branch coverage had 13 surviving mutants — tests executed but did not verify behaviour.

Allow agents to suppress warnings with reasoning rather than treating sensors as binary gates. Marginal threshold raises are preferable to wholesale disablement.

Sensor Placement

Sensors run at four points: during the coding session (immediate feedback), in CI (gate-level enforcement), on a repeated schedule (drift detection), and in production (runtime signals). Different sensor types fit different points; modularity review is too expensive for every commit but appropriate as a periodic batch.

Caveats

Sensors create their own failure modes. Risks include false sense of security, feedback overload triggering over-engineered refactorings, and rule conflicts (e.g., max-lines pushing complexity into long property-passing chains in React). Human review remains necessary; sensors reduce its volume, not its requirement.

Radar Assessment

Placed in Techniques / Assess / inner.

Inner position reflects direct applicability for any team running coding agents on a non-trivial codebase. The constituent tools (ESLint, dependency-cruiser, Stryker, Semgrep, GitLeaks) are mature and free. The novel contribution is the framing — treating these tools as a sensor network for agents rather than a gate for humans — and the recommendation to embed self-correction guidance in lint messages so feedback closes the loop without human translation. Distinct from radar/tools/TDDGuard, which intercepts at the Claude Code hook level for a single rule (TDD discipline); this technique is the broader design practice of running a portfolio of computational and inferential sensors against agent output.

Trial gate: at least one custom AI-tuned lint rule with self-correction guidance and one inferential sensor (modularity or security review) running on agent-produced PRs in a real project, with documented evidence that the feedback loop changed agent behaviour.

Clone this wiki locally