Builder Harness
I work through Builder Harness, which I built and maintain: the instructions, skills, and configuration an agent loads before it touches a repository, versioned in one place rather than retyped into a prompt.
It is written to be editor-agnostic: no rule in it names a tool. Each agent environment is a declared target that reads a generated artefact, so wiring another one is a table entry rather than a migration, and there is one source of truth behind all of them.
Instruction architecture
Text format
Global layer Engineering principles, autonomy boundaries, output standards.
The verification standard. One file, no tool named in it.
Loaded by ↓
Editor layer Per-tool file at user level: model routing, delegation rules,
and the tool-specific way to honour the global layer.
Loaded by ↓
Project layer Per-repository file: stack, commands, architecture notes and
the constraints particular to that codebase.
The project layer uses the AGENTS.md convention, so it is readable by any tool that follows it rather than tied to the one I happen to be using.
The point of putting principles in configuration rather than in a prompt is that configuration is enforceable, and a prompt is a hope. The global layer carries things like: no shortcuts without explicit permission, where a shortcut means skipping tests, suppressing type or lint errors, hard-coding config, or leaving stubs. That rule holds on the two-hundredth task of a long session, which is exactly when a habit would not.
Skill library
32 authored skills covering the delivery lifecycle, each one a written procedure an agent loads on a trigger rather than improvises: test authoring and debugging, structured code review, changelog discipline, dependency and config setup, CI/CD pipelines, twelve-factor onboarding, documentation and docstring standards. MCP servers sit alongside them for context management and code-graph analysis.
The reason this matters for forward deployed work is that a skill library is installable into a team. It is the difference between an engineer who is fast and a delivery capability the customer keeps after the engineer leaves.
Guardrails
Agents run with scoped permissions, not with keys. The allow-list names the tools an agent may run unsupervised, the test runner, the linter, and the type checker among them. Deletion is denied outright. Credential locations are denied to reads, SSH and cloud provider directories, package registry and git credential files, and any environment file. Token environment variables are withheld from subprocesses. Sandboxed execution holds file writes and network access inside declared boundaries by default, and stepping outside it is an explicit, per-command decision rather than a mode somebody left on. Hooks fire before and after tool calls, which is where policy is enforced rather than requested.
One point of precision, because it is the thing an interviewer checks: the harness is the rules and skills repository and nothing else. Permission scope, hooks, and sandbox policy live in the agent tool's own settings beside it, because that is where the tool reads them from.
This is the part that decides whether agent-first work is admissible in a regulated environment. The question a security review asks is not how good the model is. It is what the tool is permitted to do and who decided.
Delegation and verification
Judgement stays in the main loop. Planning, review, debugging, and anything spanning several files are never delegated. What fans out to subagents is the mechanical work: locating code, read-only searches across a large repository, inventories, and small format-preserving edits. Subagent output is treated as a claim rather than as a result, and a claim gets checked against the cited line before it becomes a decision, a comment, or a sentence on a page like this one. A compressed claim is false however it reached you, and it does not stop being false because an agent produced it.
Text format
Main Loop (Judgement) | |-- Delegate: mechanical fan-out to subagents: search, inventory, small edits. | |-- Integrate: results return as findings, and cited lines get opened. | |-- Verify: tests, linter and type checker run before anything is called done. | `-- Gate: pre-commit and CI repeat the same checks independently.
The verification standard is a single rule, and it is not negotiable: a task is done when the relevant tests, the linter, and the type checker pass, or when the failure is reported verbatim. Never claim done without running them. Everything else in this method exists to make that rule cheap enough to keep.
Provenance control
AI attribution is disabled at the repository level across everything I build. No co-authorship trailers, no generated-with lines, no attribution hooks. The posture is universal: personal, commercial, and any public repository I publish. It is standing security hardening, adopted as practice rather than in response to an incident.
So there is no AI-authorship percentage on this site, and there will not be one. That metadata is not withheld. It is never written, and a number I cannot produce from source is a number I will not estimate.
The reason for telling you this rather than staying quiet about it: an enterprise deploying AI into a regulated environment has to answer for what it leaves its repositories, what its disclosure obligations are, and where its data sits. An engineer who already controls provenance as standing practice is answering the question the audit is going to ask. That is worth more than an authorship ratio, and it is the same judgement I would apply on day one inside a customer environment.
What carries the claim instead: throughput
Agent-first delivery is evidenced by output, measured out of band from the repositories so that it touches no commit provenance. On Handee: 880 recorded agent sessions produced 848 commits and 34 tagged releases across 86 days, sole-authored, at 552 test files. A little over one session per merged commit, about ten sessions a day.
Across all work in the window, 978 recorded sessions between 12 May and 8 August 2026. Aggregates only: counts, dates, and rates. No project paths, no customer names, no prompts, no transcript content on this page or anywhere else.
One limitation travels with the figure, and it should: the session record begins 12 May 2026, the same day as the first Handee commit. It covers the whole of that build and none of tendr or EVERYANGLE. The agent-first evidence is Handee and later.