Harness Engineering
I asked our CTO what is the most important problem to work on? The question came from reading Richard Hamming’s book: If you do not work on important problems how can you expect to do important work?
CTO’s answer was: to build the harness. Build a system where you can make tickets, and those tickets are converted to code by agents, and tickets are produced from design files. Finally, the loop is closed when someone makes a code change that is reflected in the design files, which reflects in done tickets and in code. So, a product can be viewed from three angles: design, tickets and the actual code. Change in any reflects everywhere else. This way anyone, programmer, designer or product manager, can contribute to work done.
This way, we as developers should focus on building the harness for this to be possible. While the products build themselves.
Is this the most important problem? It’s risky and ambitious, but that doesn’t disqualify it, it might be exactly why it qualifies. The goal should be ambitious and unattainable, serving as a North Star. Better to have a direction than wander aimlessly, another idea from Hamming. The star can be adjusted along the way. And the business case is real: this is what leads to a scale of development that compounds output without compounding headcount.
Harness engineering is not a new idea that came with LLMs. First came RAGs, then tools, then skills. Each time, the work was building the app around the model to get the most out of it.
Boris Cherny, the head of Claude Code at Anthropic, said he no longer prompts Claude directly. “My job is to write loops.” In the early days of Claude Code, he wasn’t writing code, he was prompting. Now he doesn’t prompt, he writes loops, which in turn prompt. The work goes into building the harness which does the work for them.
I don’t want to use Claude or ChatGPT’s harness. I want a good harness where I can swap the models and customize it. For the last two years I’ve been trying to build it, but something keeps not adding up. Everyone has their own way of doing subagents, handoffs, remote agents, skills. There’s no good reference, you try to reverse engineer their source code.
There is a common denominator to these harnesses, yet it’s so hard to pin down. Once you do, it’s already outdated and the newest features you want are incompatible with it.
What I’ve learned is this: I know how to build the chat interface, render tools, wire up a model, ship something that works. What I don’t know is how to design what the chat interface is for. The architectural decisions: how to make it extendable, how subagents hand off to each other, how to sandbox it and give it real file system access, how the human actually interacts with it. A remote desktop where they can upload and work with files? An agent linked to the local machine like Claude Code? Either direction is hard to execute.
The scope keeps creeping. I focus on the UI, or I focus on the agent loop, and I can’t figure out what the minimal thing is that makes it actually feel like an agent. And when it does, it feels useless. Can’t code, can’t exit its environment, can’t use git.
There’s an example worth looking at: pi agent claims to be the simplest possible harness, stripped of complexity, letting the user ask it to extend itself. The right shape is probably something like that, the slimmest common denominator, extendable from there. My intuition for the interface: a chat UI combined with a file explorer and file worker. Not an IDE, but something adjacent. Cursor is exactly what I picture, but built for programmers.
The common denominator exists. The question is whether anyone will pin it down before it shifts again.