In late August 2025, a team at OpenAI created an empty git repository. Five months later, that repository held roughly one million lines of production code — application logic, tests, CI configuration, documentation, observability tooling. Every single line was written by an AI agent. Not a line of it was typed by human hands.
Three engineers. 1,500 merged pull requests. A product with real daily users.
The same AI models were available to everyone. Same GPT-5. Same tools. But no one else was producing results like this. What did that team know that the rest of the industry didn't?
The answer isn't a better prompt, a secret API, or a smarter model. It's a discipline called harness engineering — and I wrote a 620-page book about it. This post is the short version.
The Bottleneck Moved
Here's the central insight: the bottleneck in software development has moved from writing code to designing the environment in which code gets written.
This isn't incremental. It's a phase change. The history of programming is a history of rising abstraction levels — from punch cards to assembly to C to Java to JavaScript. Each step abstracted away the previous layer's cognitive load and introduced a new one. We've now reached the point where the code-writing itself can be fully delegated to AI agents.
But delegation without structure is chaos. The METR research group ran a rigorous study in early 2025: 57 experienced developers, 800+ tasks, randomly assigned to "AI allowed" or "AI disallowed" conditions. The result? Using AI tools made developers 19% slower.
Not faster. Slower. Because the AI was dropped into workflows not designed for it. The overhead of managing hallucinated APIs, fighting with context windows, and debugging AI-introduced integration issues exceeded the time saved.
The OpenAI team succeeded not because they had better AI — they used the same models available to everyone — but because they built an environment specifically designed for agent-first work. That environment is the harness.
Four Pillars
Every harness, regardless of tech stack or team size, rests on four pillars. They operate simultaneously and reinforce each other:
1. Constrain
Reduce the solution space before the agent begins.
Constraints are preventive controls that tell the agent what it cannot do. Not suggestions — mechanical enforcement. A rule like "follow our dependency layering" in a prompt is advisory; the agent might comply, might not. A custom linter that fails CI when a file in the types layer imports from services is mechanical — the agent literally cannot merge code that violates the rule.
The OpenAI team defined a rigid layer architecture — Types → Config → Data → Services → Runtime → UI — and enforced it with custom linters and structural tests. Not as suggestions. As hard CI failures. The kind of architecture you usually postpone until you have hundreds of engineers became an early prerequisite with coding agents.
2. Inform
Give the agent the right context at the right time.
An informed agent is competent. An uninformed agent is a hallucination machine. The key insight: context curation is an engineering discipline, not a documentation task.
The team initially tried a "one big AGENTS.md" approach — a massive instruction file with everything the agent might need. It failed. Too much context overwhelmed the agent; stale guidance introduced more confusion than clarity.
Their solution: treat AGENTS.md as a table of contents, not an encyclopedia. Roughly 100 lines, pointing to a structured docs/ directory that serves as the system of record. The agent starts with a small, stable entry point and follows links to deeper context as needed — a pattern called progressive disclosure.
3. Verify
Check the agent's output against the intended behavior.
Verification is what separates agent-first development from wishful thinking. Without it, you're hoping the agent got it right. With it, you know.
But the verification that matters goes beyond unit tests. The OpenAI team made the application itself legible to the agent — bootable per git worktree, wired to Chrome DevTools Protocol for UI testing, with local observability stacks the agent could query. The agent could boot the app, navigate to a URL, take a screenshot, read logs, and verify its own work against real behavior.
The Affirm engineering team discovered a subtler challenge: when an agent generates both implementation and tests in the same session, a misunderstanding of requirements can produce code and tests that confirm each other's errors. Tests pass. Coverage looks strong. The defect ships. They're now piloting systems that cross-reference PR diffs against acceptance criteria using multiple models as an independent check.
4. Correct
When the agent makes mistakes, fix the system, not just the output.
This is the Hashimoto principle, attributed to Mitchell Hashimoto, co-founder of HashiCorp: whenever an agent makes a mistake, build a solution ensuring the agent never makes that specific mistake again.
The correction isn't to manually fix the agent's output — it's to add a constraint, improve the context, or enhance verification so the mistake becomes impossible. This is fundamentally different from how we handle human errors. Humans learn; agents don't accumulate learning across sessions. The learning has to go somewhere else — into the harness.
The OpenAI team operationalized this as the "taste feedback loop": observe a bad pattern, name it, document it, mechanize it with a linter, verify the linter catches it. Their lint error messages aren't complaints — they're remediation instructions. Instead of "unstructured logging detected," the message says "use logger.info({event: 'name', ...data}) instead of console.log." The error message itself becomes a prompt that enables the agent to fix the violation autonomously.
Why "Boring" Technology Wins
One of the most counterintuitive findings from the OpenAI experiment is the preference for boring technology. Not because boring is inherently better, but because agents learn from training data.
A technology that appears in millions of repositories, Stack Overflow answers, and blog posts is one the model has seen extensively. It understands the idioms, the pitfalls, the edge cases. A technology that's new and niche? The model has seen less of it, makes more mistakes, and produces less reliable output.
The OpenAI team was explicit: "Technologies often described as 'boring' tend to be easier for agents to model due to composability, API stability, and representation in the training set."
In some cases, it was cheaper to have the agent reimplement subsets of functionality than to work around opaque upstream behavior from third-party libraries. The custom implementation is fully visible to the agent, 100% test-covered, and behaves exactly as the runtime expects. Full legibility and controllability beats convenience.
The Affirm Timeline: How Fast This Is Moving
If you think this is years away, consider Affirm's timeline:
- December 2025: Over 80% of engineers were weekly active users of AI-assisted tools (autocomplete-level)
- January 2026: Company-wide mandate from the President — agentic AI development would become core to how they build software
- February 2026: One-week retooling of 800+ engineers
- April 2026: Over 60% of PRs are agent-assisted, weekly merged PR volume up 58% year-over-year
Four months from mandate to majority agent-assisted development. When your competitor can produce 58% more merged PRs per week with the same headcount, you don't have the luxury of a gradual five-year transition.
The economics are overwhelming. Wix's AirBot case study: $0.30 per interaction, saving 675 engineering hours per month across 4,200 flows. At even $100/hour fully loaded engineering cost, that's $67,500 in monthly savings for roughly $1,260 in interaction costs — a 53x ROI.
What This Means for Engineers
Your job is changing, but not disappearing. The mental model to internalize: you are no longer a software developer. You are a software development environment designer.
The conductor doesn't play any instrument in the orchestra, but the orchestra can't make music without one.
The skills that matter most in this new world aren't about typing code faster. They're about:
- Architectural taste — knowing what good looks like and encoding it as enforceable rules
- Context curation — deciding what information the agent needs, when it needs it, and how to deliver it efficiently
- Verification design — building systems that catch problems automatically, not relying on manual review
- Systems thinking — understanding that every agent failure is a harness gap, not a model limitation
These are fundamentally engineering skills. They require judgment, taste, and domain knowledge — the things that remain uniquely human even as code generation becomes commoditized.
Where to Start
You don't need a million-line codebase or a team at OpenAI to begin. The minimum viable harness has five components:
- AGENTS.md — basic instructions and pointers to key docs (~100 lines, not 1,000)
- Three lint rules — for the three most important constraints in your codebase
- CI pipeline — that runs those linters on every PR
- Structured docs/ directory — with architecture and design decisions
- A plan template — for breaking work into agent-executable tasks
Start there. Add more as you learn what the agent gets wrong. Every agent mistake is an opportunity to add a new constraint. The harness grows with you.
This post is adapted from Harness Engineering: The Complete Guide to Agent-First Software Development — 27 chapters, 8 appendices, 620+ pages covering context engineering, multi-agent orchestration, security, architecture enforcement, and the future of agent-first software development.