On Harness Engineering
Over the last few weeks, I've been hearing one term everywhere: Harness Engineering.
The term seems to have first been used publicly by Mitchell Hashimoto, co-founder of HashiCorp and Terraform, in February in My AI Adoption Journey. His point was simple: when an AI agent makes a mistake, you shouldn't just fix the prompt; you should change the system so that mistake doesn't happen again.
Shortly after, OpenAI helped popularize the term when talking about how they use Codex in an agent-first environment.
I think we're coming from here:
Prompt engineering was learning how to ask.
Context engineering was learning what information to give the model.
Harness engineering is learning how to build the environment where the agent works.
Tests. CI. Linters. Permissions. Tools. Memory. Skills. Repo rules. Workflows. Review gates. Scope limits.
Basically, everything that turns an agent from "a model writing code" into a working part of an engineering system.
The interesting part is that this is still not fully defined.
Every company, every team, and maybe even every developer is building their own harness right now. Their own way of saying: "This is how we work here."
The future won't just be about better models. It will be about better systems around the models.
Other reads on this trend:
- Agent Skills - By Addy Osmani | SWE at Google.
- The Agent Harness Belongs Outside the Sandbox - Andrea Luzzardi | Cofounder at Dagger and Mendral.
- Specsmaxxing - Acai.sh.
Originally published in CTO Circle Issue 006.