How I use agents

The agent writes the code. A check decides whether it ships.

Claude Code and Codex are in my normal working day. What follows is the mechanism I put around them, and the evidence that it holds, including the measurement that did not go my way.

The commit that cannot be faked

On singio, a songwriting tool I built in August, every feature starts as a written specification and the failing test is committed before any implementation exists. Twenty-five of its eighty-three commits are labelled committed red. Each contains only the spec, the decision record and the tests. No implementation at all. A separate commit afterwards makes them pass.

I state that number because it is the one thing on this page that cannot be added later. A configuration file can be written the night before an interview. Twenty-five commits in that shape would take a rewrite of history, and the audit I ran against my own repositories checked all twenty-five rather than the two it started with.

The ruleSpecification, then decision record, then the failing test, committed on its own. The agent writes code against a test that already exists.
AlternativePrompt for the feature and read what comes back. Faster per feature, and what agentic tooling is usually accused of being.
What it costTwo commits per feature and a specification for work I could have described in a sentence. On a small change it is slower than writing the code myself.
What it boughtA test the agent could not have shaped to fit what it had already written. That is the whole of the difference, and it only exists if the test lands first.

Before you weigh that

These repositories are private, so you cannot check any of this yourself today. I can put the log on a screen in an interview, and the commands that produce every number on this page are written down. That is a weaker claim than a public repository would be, and I would rather say so here than have you work it out at the point where it would change your reading of everything above.

Where I draw the line

singio's product runtime contains no language model. Harmony generation is deterministic, because a musician needs the same chords on the same melody twice. That is a product decision, so it is written down as one, and then three static-analysis rules make it a build failure to import an inference SDK into the engine. The rule says why in its own message: Claude Code and Codex are development tools, and an inference SDK in shipped code is a different thing entirely.

That is the pattern I reach for whenever a decision matters more than a preference. I do not trust a sentence in a prompt, or in a contributing guide, to hold a boundary that a linter can hold. The same technique guards the Vergabeautomat decision on this site: a rule blocks coalescing the retired total to zero, because rendering a measured-looking score the system never computed is a lie told to the reader, and it is exactly the kind of edit that looks like a tidy-up.

LayeringNine build-failing dependency rules on one project alone, among them domain-is-pure, adapters-never-import-app and shipping-never-imports-test-only
Product rulesHand-written static analysis for decisions generic security tooling cannot know about, including the no-model-in-the-runtime boundary
SuppressionsBlocked at the point of writing. A hook stops the agent adding an ignore comment, and the only matches in that repository are inside the tooling that detects them

What went wrong, and the rule it produced

On a retrieval platform of mine I over-trusted a secret scanner. Both pipelines ran it in the mode that writes its baseline rather than checking against it. I planted a live-format AWS key in a tracked file: the scan exited zero and quietly rewrote its own baseline by nearly four thousand lines. The contributing guide called that scanner a mandatory control and the security document listed it as a merge blocker, so the claim was load-bearing while the mechanism was decorative.

The fix was the checking form of the command, pinned by a test. The rule it produced is the one I now apply everywhere: prove a gate fails on a known violation, or it is manufacturing confidence rather than providing it. One project has a script that does this for every gate it has, injecting a real violation and asserting a non-zero exit, and it runs the secret and dependency cases in a temporary directory so the fixtures never poison the repository they are testing.

The same reasoning settled a smaller call. A code-scanning workflow in that repository is complete, pinned, and deliberately filed with its scanner switched off, because the tier it needs is not on that plan and a permanently red required check teaches people to merge past red checks. Off and explained beats red and ignored.

What this is not

It is one project, and it is recent. Twenty-five test-first commits on singio, and none on the other three. The honest version is that this is how I work now and not how I have always worked.

It did not reduce my rework. Over each project's first eighty-three commits, the project with no test-first commits at all reaches a slightly better ratio of fixes to features than singio does. The correlation I would like to claim is not in the data. What is there is a direction of travel: the oldest of these projects opened with fifty-one fixes against six features, and nothing I build now looks like that.

It is all solo work. Rules I wrote, follow and audit have never met a second engineer who disagreed with them, or a review I could not overrule. The reviewer is a subagent I configured. That is the real distance between working to an architect's standard and having done the job, and it is not something more tooling can close.

The scale is modest. Docker Compose on servers I run, with pilot users. The rigour is real and the traffic it has been tested against is not large.

Happy to walk through any of these in detail, including the parts that went wrong.