The latest articles on DEV Community by Neo (@neo_efecd668f2fc8966c7e72). https://dev.to/neo_efecd668f2fc8966c7e72 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F2084060%2F9319ad89-ca9a-4739-a509-5627dc178c1a.jpg https://dev.to/neo_efecd668f2fc8966c7e72 en Neo Wed, 22 Apr 2026 03:09:27 +0000 https://dev.to/neo_efecd668f2fc8966c7e72/my-first-foray-into-harness-engineers-j3p https://dev.to/neo_efecd668f2fc8966c7e72/my-first-foray-into-harness-engineers-j3p <p>When our team set out to build <strong>BypassHire</strong> — an AI tool that cuts job-application time from 45 minutes to under 5 — we quickly realized that the interesting engineering challenge wasn't the model. The model was the easy part. The hard part was everything around it.</p> <p>Martin Fowler recently named that surrounding layer: <strong>harness engineering</strong>. A harness is everything in a coding-agent setup except the model itself — the guides, sensors, rules, and scaffolding that determine whether the agent produces something you can trust. We spent a significant portion of our sprint designing exactly that, and this post describes what we built and why.</p> <h2> Guides: Steering the Agent Before It Writes a Line </h2> <p>Fowler divides harness mechanisms into two categories. <strong>Guides</strong> are feedforward controls — they anticipate problems and shape behavior upfront.</p> <p>Our primary guide is <code>CLAUDE.md</code>, a project-level instruction file that encodes our conventions, enforced workflow order (<code>/plan → /tdd → /build-fix → /code-review → /verify</code>), security rules, and coverage thresholds. Every session starts with Claude reading this file. It establishes the rules of the game before any code is generated.</p> <p>Beyond static documentation, we deployed a suite of <strong>specialized sub-agents</strong> — architect, planner, tdd-guide, code-reviewer, security-reviewer, and build-error-resolver — each scoped to a specific responsibility. The security-reviewer, for instance, is OWASP-scoped and fires on any PR touching auth routes, DB queries, or Claude API prompts. Rather than one general-purpose agent deciding everything, we built a council of narrow experts. Specialization reduces the surface area each agent must reason over, which increases reliability.</p> <p>MCP server integrations (GitHub, Playwright, Vercel) extend the agent's reach into external systems without loosening its guardrails. The agent can check deployment status or run a browser test; it cannot make unreviewed changes to production.</p> <h2> Sensors: Catching Problems After the Fact </h2> <p><strong>Sensors</strong> are feedback controls — they observe what was generated and signal corrections. This is where Claude Code's hook system becomes infrastructure.</p> <p>We run <strong>four hooks</strong> wired into the session lifecycle:</p> <ul> <li> <strong>Lint on edit:</strong> ESLint and Prettier fire immediately after any <code>.ts</code> or <code>.tsx</code> file is touched. The feedback loop collapses to milliseconds.</li> <li> <strong>Test-runner guard on exit:</strong> When Claude tries to end the session, <code>npm test</code> runs automatically. If tests fail, the session is blocked from closing. "I'll fix it later" becomes structurally impossible.</li> <li> <strong>Green-test commit signal:</strong> After any test-runner Bash call exits 0, a hook injects a nudge asking whether to checkpoint. Signal only — Claude decides; the hook never runs <code>git commit</code> itself.</li> <li> <strong>Task-completion commit signal:</strong> When a todo transitions to <code>completed</code>, a snapshot diff fires the same nudge for that work slice.</li> </ul> <p>Fowler distinguishes <strong>computational</strong> sensors (fast, deterministic: linters, type checkers, tests) from <strong>inferential</strong> ones (AI-powered, slower, but semantically richer). Our hooks are computational. Our code-review and security-reviewer sub-agents are inferential — they catch the architectural and behavioral issues that linters cannot see.</p> <h2> Harnessability: The Stack Matters </h2> <p>Not every codebase is equally amenable to harnesses. Fowler calls this <strong>harnessability</strong> — the structural properties that make a system legible to agents. We chose TypeScript, Prisma, Zod, and Next.js App Router deliberately. Strong types, a schema-validated ORM, and runtime input validation at every API boundary give both human reviewers and agent sensors precise, machine-readable contracts to work against. The harness is only as good as the surface it grips.</p> <h2> The Steering Loop </h2> <p>Fowler's most important insight is that harnesses require a <strong>steering loop</strong> — humans monitoring repeated failures and tightening controls in response. After our first sprint, we noticed Claude occasionally drifted on auth patterns; we added an ESLint rule that bans direct imports from <code>@clerk/nextjs/server</code>, forcing all auth through our <code>src/lib/auth</code> wrapper. The harness got smarter because we observed where it was failing.</p> <p>That loop — observe, encode, enforce — is the actual job of a harness engineer. The model handles generation. We handle the system that keeps generation honest.</p> agents ai productivity softwareengineering