In the first piece of the series I told the unease that made me start rebuilding tech at Prolog. At the end, I promised to open up each part. I’ll start with the one that took me longest to understand: the harness.
A heads-up first, there’s no magic formula here. It’s what I read, what I saw other companies doing, and what we’re trying to do, with hits and misses.
I spent months chasing a name for something I felt and couldn’t quite say.
The word I was missing
I kept seeing three-person companies shipping what used to take thirty. And I saw that the gain wasn’t in the model, because everyone runs roughly the same model. It was somewhere else, and I didn’t have the word for it.
In February 2026 OpenAI published a piece called Harness Engineering and gave me the word.
Their definition opens with two short lines: “Humans steer. Agents execute.” And what comes next changes how you think: a software engineering team’s primary job is no longer to write code, but to design environments, specify intent, and build feedback loops that let agents do reliable work.
Each piece there is real work. Designing the environment the agent runs in. Making clear what to do, the intent, instead of the step by step. And building the loops that tell the AI whether it got it right, so it can correct itself.
Notice what dropped out of the sentence: writing the code. It’s not OpenAI saying code doesn’t matter. It’s OpenAI saying that when the AI writes most of it, the human work moves up a layer. And when something breaks, the question moves with it. It stops being “try again, push harder” and becomes “what capability was missing in the environment for the AI to get it right”. The bug stops being the AI’s fault (“it’s dumb”) and becomes a question about what was missing around it.
So a harness is organizing code, process and work so the AI can see, understand and execute. It’s not a tool you buy. It’s a new way of thinking about what the team delivers.
The model is one thing, the harness is another
The most economical line I found to lock this in came from Vivek Trivedy, a LangChain engineer: “if it’s not a model, then it’s the harness”.
The model is the raw LLM. Opus, GPT, whatever. Text in, text out, done. And almost everyone has the model. It’s a commodity. The difference between who gets 10% and who gets 5x isn’t in the model.
It’s in the harness. The harness is everything else: the code, the tools the AI can call, the context it sees, the hooks, the orchestration, the sandbox it runs in, the memory, the business rules. Everything that wraps around the model in the flow, before the work reaches you finished.
You may have heard “context engineering”. It’s part of this, the part about organizing what the AI sees. The harness is bigger: it includes context, but also the tools, the hooks, the sandbox, the persistence, the orchestration. Context is one piece; the harness is the whole thing.
A harness is making everything legible to the AI
If I had to boil the harness down to a single principle, it would be this: make everything legible to the AI.
In the previous piece I told the diagnosis that got me. Prolog’s context lived scattered. A piece in Notion, another in Drive, another in Jira, in Figma. There was no single source. Every new conversation with the AI started from zero, because the information it needed was in five places and curated in none.
When you reread that through the harness lens, the problem is obvious. The AI couldn’t see. And what it can’t see, it doesn’t use.
Peter Pang, CTO of CREAO, shared a decision that sounds radical and makes complete sense: he merged all the code into a single monorepo. The reason wasn’t tidiness. It was so the AI could see everything at once.
That’s the work. It’s not a clever prompt, it’s not a trick. It’s taking what’s scattered, implicit, alive only in people’s heads, and making it legible in one place, written, reachable by the agent. Tedious sometimes. But that’s exactly what separates the 10% gain from the 5x gain.
The proof: 3 engineers, 1 million lines
I’m suspicious of hype by nature. So what convinced me this wasn’t a fad was a case with numbers.
The OpenAI team that built the Codex CLI, their command-line tool, was three engineers. In a matter of weeks, they shipped around a million lines of code: application, infra, tooling, documentation. And zero lines written by hand. The team’s stated philosophy was “no manually-written code”. It was around fifteen hundred pull requests, all merged, none typed by a person. The three steered, the AI built.
To avoid confusion: OpenAI has Codex, which is the model trained for code, and the Codex CLI, which is the tool. The three used the model, through the tool, to build the tool itself. The thing building itself with itself.
And it doesn’t stop there. Across all of OpenAI, Codex reviews 100% of the company’s pull requests.
What sealed it for me wasn’t OpenAI’s number alone. It was that Peter Pang, at CREAO, reached the same conclusion by a separate path, without coordinating with anyone. Two different places describing the same thing. When that happens, it usually isn’t a fad. It’s a pattern.
AI-assisted is not the same as AI-first
Here I need to be honest about where Prolog is.
There’s a difference almost nobody notices between using AI to assist the work and putting AI at the center of it.
AI-assisted is the human at the center and AI plugged in at the edges. Same sprint, same board, same meeting, same flow. AI helps inside the process that already existed. The gain is real and small: 10, 20%. It’s where most companies are. It’s where Prolog is today, and I won’t pretend otherwise.
AI-first is AI at the center and the human steering. You assume the agent is the primary builder and you rebuild the process, the architecture, even the org around that. The human critiques, validates, judges. The gain is a different order: 5x, 10x. It’s what Codex, CREAO and Anthropic are doing.
The difference, as Peter Pang puts it, is multiplicative, not incremental. And that’s why the harness matters so much. You don’t get to AI-first by plugging AI into what already exists. You get there by rebuilding so the AI can see, understand and execute. In other words, by building a harness.
And this isn’t just an engineering problem
OpenAI’s line, “the main job is no longer to write code”, was written with engineering in mind. But when I reread it swapping the subject, it fit every role in tech.
Product no longer just writes the doc; it enables the agent to propose the solution. Design no longer just draws the screen; it enables the agent to generate interface inside the system. QA no longer just runs the test by hand; it enables the agent to validate. Data no longer just runs the query; it enables the agent to answer the business question.
In all of them the question becomes the same: what capability is missing for the agent to do this, and how do I make it visible and controllable by it.
What I take from this
A harness isn’t a tool you buy or a better model you subscribe to. It’s work. The work of taking what’s in people’s heads and scattered across ten systems and making it legible, in one place, for a machine to use.
The tedious part is there’s no shortcut. The good part is that, being work, it can be done. We’re in the middle of it: far from AI-first, closer than we were two months ago. I’ll keep telling it as it goes.
Sources
- OpenAI, Harness Engineering: leveraging Codex in an agent-first world (February 2026). Where “humans steer, agents execute” and the Codex CLI team case come from.
- Vivek Trivedy, LangChain, The Anatomy of an Agent Harness. The “if it’s not a model, then it’s the harness” definition.
- Peter Pang, CREAO, on putting AI at the center. The monorepo so the AI could see everything, and the multiplicative difference.
- How OpenAI’s Codex Team Works and Leverages AI, Eng Leadership Newsletter. The Codex team’s numbers.