We recently published an article aboutCL-bench the limits of context engineering.
Every model has a hard limit on what it can absorb. Adding more context does not mean the model can use all of it effectively.
A separate experiment now provides the other half of the answer.
Without changing a single line of the underlying AI model, researchers moved it from outside the top 30 to the top five on a coding benchmark, a 13.7% improvement.
The model stayed exactly the same. The result did not.
LangChain ran the experiment in February using GPT-5.2 Codex. The team changed only the layer around the model: the system prompt, tool configuration, and several middleware hooks.
Its ranking on Terminal Bench 2.0 then rose sharply.
The conventional assumption has been that weak AI coding performance calls for a stronger model. This experiment points elsewhere: the constraint may sit outside the model, in the environment designed around it.
In 2026, one term is likely to become much more familiar: harness engineering.
A harness for AI
A harness is the complete set of reins, saddle, and equipmentthat lets a rider control direction and force.
It is an unusually accurate metaphor for AI systems.
An AI agent can be powerful and fast, but not always disciplined.Without a harness, where it goes, when it stops, and how it recovers after drifting off course all become open problems.
Harness engineering is the discipline of building that control system.
The concept was introduced by Mitchell Hashimoto, co-founder of HashiCorp and creator of Terraform.
In a February 2026 post, he described six stages in his journey of working with AI. Stage five was called 'Engineer the Harness.'
His definition was practical: whenever an agent makes a mistake, invest in a mechanism that prevents it from making the same mistake again.
The answer is not to blame the model or immediately replace it with a more expensive one.It is to redesign the environment so that the failure cannot recur.
OpenAI's experiment
A few days after Hashimoto's post, OpenAI published a field report titled 'Harness engineering: leveraging Codex in an agent-first world.'
Three engineers began with an empty repository and spent five months building entirely through Codex agents. The result was roughly 1,500 merged pull requests and about one million lines of code.The engineers manually wrote zero lines of code.
Three engineers, five months, and no hand-written code.So what did they work on each day?
- Designing the repository structureThey wrote AGENTS.md files and documentation that defined the repository's operating rules: what belonged in each directory, which files were off limits, and which direction architectural dependencies could flow.
- Configuring lint rulesIn an agent-first workflow, a linter is more than a standard for human contributors. It becomes immediate corrective feedback for the agent. If generated code violates an architectural constraint, the linter blocks it and tells the agent what must change.
- Building the CI pipelineThey created feedback loops in which every change automatically triggered tests. Failed tests sent the work back to the agent, which iterated until the checks passed.
Many coding and repair steps can happen inside that loop, but human engineers still own the specification, constraints, feedback system, and final judgment on critical outcomes.
The team also introduced a particularly useful mechanism: a dedicated 'garbage collection' agent.
It periodically scanned the repository for deviations from architectural constraints and opened pull requests to correct them.
Engineering discipline did not disappear. It moved.
Previously, discipline meant writing careful code, reviewing it thoroughly, and following coding standards. Now it also means creating the documentation, constraints, and feedback loops that allow agents to work reliably.
Most of this work happens at the environment layer, but it determines whether the entire system can make stable progress.
That begins to define a new kind of engineering role.
Writing code is no longer the primary responsibility. The role becomesdesigning the environment in which agents operate.。
Three paradigms of AI coding
Over the past three years, AI coding has moved through three paradigms. Each addresses a broader problem than the one before it.
From 2023 to 2024, prompt engineering dominated.The central question was how to speak to an AI system. Teams focused on wording, repeatedly refining prompts with roles, few-shot examples, and chain-of-thought techniques.
Its lasting contribution was the recognition that language matters: small changes in instructions can produce very different results.
Its limits also became clear quickly.A single message can hold only so much information, and wording alone cannot contain a genuinely complex task.
In 2025, attention shifted toward context engineering.The central question became what information the AI should see.
Teams started designing the whole information environment: dynamic system-prompt injection, conversation-history retention, RAG retrieval, and the way tool outputs feed back into the model.
This was a major advance, but it still concentrated on the input side: the information supplied to the model.
It did not fully govern what happened once an agent began executing work.
In 2026, harness engineering extends the scope again.The question is now what kind of working environment we should build for AI.
It covers not only the model's inputs, but the entire execution environment around it.
To continue the analogy:
- Prompt engineering teaches the horse to understand commands.
- Context engineering helps it see the terrain ahead.
- Harness engineering builds the complete track, with guardrails, turn markers, and a finish line, so the horse can move quickly without losing control.
In the first two paradigms, you were the AI's conversation partner. In the third, you become the architect of its environment.
Why agents fail
The cause is rarely a lack of intelligence
Consider the LangChain experiment again.
When the team analyzed the most common agent failures, it reached a counterintuitive conclusion:most failures had little to do with model intelligence.
The real causes looked like this:
- The agent submitted code without testing it. A pre-submit middleware check made validation mandatory and removed the failure mode.
- The agent did not know its working directory, project position, or available tools and had to explore blindly. Middleware that automatically injected the project structure and tool inventory solved the problem.
- The agent repeatedly edited the same file and became trapped in a loop. A loop detector prompted it to change strategy after a defined number of attempts.
- The agent could not manage time, iterated indefinitely, and always believed another improvement was possible. Time-budget warnings provided a boundary.
None of these problems required a stronger model.Each required another control in the existing model's harness.
The team's conclusion was equally direct: engineering effort invested in the harnessproduced a much higher return than effort spent choosing between models.
That is an important lesson for any team building AI products today.
A failure from a real project
An article in the Tencent Cloud Developer Community described a representative case.
During cross-service development, Service A defined the meaning of an error code. The agent implementing Service B had no access to that shared semantic contract,so it invented its own handling behavior.
The critical issue is that an AI system does not announce'I am guessing here.'It simply produces code that looks entirely reasonable.Only after deployment did the team discover that the behavior was wrong.
The bug did not reflect insufficient agent capability. The cross-service error-code contract had never been captured in the specification, leaving a gap in the harness environment.
Once the team added the complete error-code contract to the system-level specification, the same agent produced an implementation that passed validation immediately.
This reveals the central purpose of harness engineering.
It is not primarily about sophisticated architecture.
It is about convertingimplicit knowledge scattered across people's memories, conversations, and meeting notes into explicit assets that an agent can access and reason over.
The three pillars of a harness
Based on the engineering analysis published on Martin Fowler's website, a harness can be understood in three layers.
1
Context Engineering
First,context engineering has not been replaced. It has become part of the broader harness.
Continuously improving the repository's knowledge base, while giving agents access to dynamic context such as observability data and browser navigation, remains foundational.
2
Architectural Constraints
Second, architectural constraintsmust be enforced in code.
Custom linters, structured tests, and dependency-direction checks are deterministic. They do not depend on whether the model happens to follow an instruction on a given run.
3
Entropy Management
Third, systems need entropy management, or what we might call garbage collection.
Everything degrades in a long-running system: documentation becomes outdated, rules are bypassed, and conventions are forgotten.
Agents should therefore run periodically to counter that entropy, detect inconsistencies, and initiate repairs. OpenAI's approach was to scan for architectural drift and automatically open pull requests.
Technical debt behaves like a high-interest loan. Paying it down continuously in small increments is better than allowing it to compound.
Final thoughts
The progression from prompts to context to harnesses has unfolded in only a few years.
Yet the shift is already unmistakable.
The hardest problems in AI engineering are gradually moving away from the model itself and into the systems around it.
Harness engineering will not be the final stage.
Today, we are asking how to build effective environments for agents.
Tomorrow, we may ask whether those environments can optimize themselves, detect their own weaknesses, reduce errors, and drive the next iteration autonomously.
Continued progress in that direction will redefine many technical roles.
The other side of the equation is already emerging.
As harnesses become more capable, the surrounding systems will also become heavier.
Will rules become too complex? Will configuration expand without control? Will every team's forked harness eventually become another maintenance burden?
There are no standard answers yet.
But the direction is clear.
We once concentrated capability in the model. Increasingly, meaningful value is being created in the layer around it.
Decisions that were previously left for the model to guess are returning to the engineering system, where they can be designed, constrained, and verified.
That is what makes the harness engineer worth discussing.
The next phase of AI coding will be decided bywho can build a system that works in production, remains governable, and continues to improve.
As more companies build serious operating environments for AI, they will need partners who can turn product goals, domain knowledge, and engineering controls into a coherent production system.
GeekOnUp aims to be that long-term technology partner: product-minded, focused on business outcomes, and equipped to make complex AI scenarios work in the real world.
