frzxw
Resume
Blog

Harness engineering: the checks around the model matter more than the model

If AI writes more of the code, the engineer's job shifts toward building the guardrails it works inside: tests, types, linters, review and safe limits. Here is the harness I use and why.

Line illustration of Fariz WibisonoFariz Wibisono2 min read

Early in 2026 OpenAI's Codex team wrote about building a product where agents wrote almost all of the code, and named the work around it harness engineering (opens in a new tab). Birgitta Böckeler's first thoughts on the idea (opens in a new tab) put it simply: the harness is the tooling and practice that keeps an agent's work in check.

I find the word useful because it describes a real shift. If a model can produce code quickly, the scarce skill is no longer typing it. It is designing the environment that catches mistakes before they reach users.

Context and harness are two different questions

Context engineering asks what the model should see. Harness engineering asks what the system should prevent, detect and correct, whatever the model does. You need both: good context makes good output likely; a good harness makes bad output harmless.

The harness I actually use

On this site and on my larger projects, every change, whoever or whatever wrote it, goes through the same gates:

  • Types. Strict TypeScript, or Rust's compiler, rejects a whole class of mistakes before anything runs.
  • Tests. Unit tests for logic, end-to-end tests with Playwright for the flows people use. On this site, tests also check the content itself: every screenshot exists, every link is safe, every page that must exist does.
  • Linting and formatting. Biome catches suspicious patterns and keeps style out of code review.
  • Unused code. Knip reports files, exports and dependencies nothing uses, which is exactly what fast generated code tends to leave behind.
  • Architecture rules. In larger projects, rules about which part of the code may import which, so a quick fix cannot quietly create a tangle.
  • Supply-chain limits. New package versions must be at least a week old before they install, and install scripts never run. Generated code suggesting a fresh dependency cannot sneak in something malicious.
  • Review. Automated review on pull requests, and my own reading of every change.

All of it runs on every push, so a mistake shows up in minutes rather than in production.

Why it is a career skill, not a chore

A harness also makes me faster, not slower. I can accept a large suggestion with confidence because I know the checks will catch most of what I might miss, and I can spend my attention on what checks cannot judge: whether the design is right.

Further reading