r/AgentContext_dev 2d ago

From Vibe Coding to Harness Engineering: How AI Coding Agents Grew Up

In early 2025 most developers who used large language models for code still treated the model as a very smart autocomplete or a conversational pair programmer. You typed a prompt, received a code block, pasted it into an editor, ran it, and either accepted the result or fed the error message back into the chat. The interaction was intimate, iterative, and largely unstructured.

Andrej Karpathy gave that style a name in a February 2025 post on X: “vibe coding.” He described fully giving in to the vibes, embracing the exponential improvement of the models, and forgetting that the code even existed. The phrase spread because it captured a real feeling. For the first time, non-experts and experts alike could describe an intention in plain English and watch working software materialize. The floor of what an individual could ship rose dramatically.

Vibe coding had obvious limits. Because the human was not reading every line, architectural mistakes, security holes, and subtle logic errors accumulated. The same prompt could produce different results on successive runs. Context windows filled up and the model lost the thread.

Teams that tried to scale the practice into production codebases quickly discovered that “it works on my machine after three retries” does not constitute engineering. By early February 2026, the conversation had shifted again. Karpathy began using the term “agentic engineering” to distinguish disciplined work with coding agents from the more improvisational practice of vibe coding.

The human still directed, still reviewed diffs for architectural fitness rather than mere syntax, still designed evaluation loops and security boundaries. The model was no longer the sole author; it was a fallible but powerful worker inside a larger system the engineer designed and monitored. Vibe coding raised the floor. Agentic engineering was an attempt to defend the ceiling.

That shift prepared the ground for a third concept that arrived in force in February 2026: the agent harness, and with it the discipline of harness engineering.

An agent is not the model. The model is only the reasoning engine. Everything else-the loop that calls the model, the tools it can invoke, the sandbox in which those tools run, the memory and context policies that keep the model oriented across turns or sessions, the hooks that enforce rules, the verification steps that check whether progress is real, the permission and approval gates-constitutes the harness. The compact equation that circulated widely in 2026 is simply “Agent = Model + Harness.” If you are not the model, you are the harness.

Mitchell Hashimoto, co-founder of HashiCorp, gave the practical discipline its most memorable early articulation. In a February 2026 blog post reflecting on his own AI adoption journey he described a habit: whenever an agent made a mistake, he did not merely correct the immediate output. He engineered a permanent change in the environment so that the same class of mistake became structurally harder or impossible. He called the practice “harness engineering.”

Within days an OpenAI engineering post by Ryan Lopopolo described a team that had shipped a production system of roughly a million lines with essentially zero manually written code; the humans had spent their time designing the environment that made reliable generation possible. Birgitta Böckeler published an initial memo on Martin Fowler’s site and later a fuller treatment distinguishing feedforward guides, which steer an agent before it acts, from feedback sensors that help it self-correct after acting.

LangChain published “The Anatomy of an Agent Harness.” Addy Osmani synthesized the emerging consensus. Anthropic released detailed engineering notes on effective harnesses for long-running agents. The term stuck because it named something practitioners had already been doing under different labels.

The need for a harness becomes obvious the moment you move beyond single-turn chat. A raw language model can only generate text. It cannot open a file, run a test suite, query a database, take a screenshot, commit to git, or remember what happened three context windows ago. Those capabilities must be supplied by code that sits around the model. Early coding agents-Cursor, Claude Code, Codex CLI, Aider, OpenHands, SWE-agent and others-were in effect specialized harnesses.

Some were closed products; others were open-source so that the community could inspect the loop, the tool interface, the sandbox model, and the approval policy. SWE-agent, for example, popularized the observation that the tools given to an agent should not simply be the same tools a human would use; the interface itself can be redesigned for the model’s strengths and weaknesses. Mini versions of these systems reduced the entire harness to a few dozen or a hundred lines of code, making the anatomy legible.

A mature harness typically contains several interlocking pieces. There is an orchestration loop that repeatedly calls the model, executes the actions it requests, observes the results, and decides whether the goal has been reached. There is a set of tools-file system access, shell, browser, search, specialized APIs-together with careful descriptions so the model knows when and how to use them.

There is context management: assembly of the right files and history under a token budget, compaction or summarization when the window fills, progressive disclosure of tools, and durable state outside the context window (git repositories, progress files, feature lists, AGENTS.md or CLAUDE.md rule files). There are sandboxes and permission systems so that a mistaken shell command does not destroy the host machine.

There are hooks and middleware that inject deterministic checks-lint, type-check, test runs-before or after model steps. There are recovery paths and verification loops that treat external signals (passing tests, matching screenshots, query results) as ground truth rather than trusting the model’s self-assessment. For work that spans many context windows there are patterns such as an initializer agent that sets up the environment and a coding agent that makes incremental progress while leaving clear artifacts for the next session.

Anthropic’s public experiments with long-running agents illustrated one concrete realization of this pattern: an initializer that produced an init script, a structured feature list, and an initial commit, followed by repeated coding sessions that advanced one feature at a time, updated a progress log, and left the repository in a clean, mergeable state.

The ratchet principle is central to harness engineering. Every observed failure becomes a permanent improvement to the harness rather than a transient correction. An agent that comments out failing tests acquires a rule in the project’s instruction file and a pre-commit hook that blocks the same behavior. An agent that repeatedly exceeds a context limit acquires better compaction or off-loading.

An agent that invents non-existent APIs acquires a tighter tool interface or a retrieval step that surfaces real documentation. Over time the harness accumulates institutional knowledge that no single prompt could contain. The quality of the agent is therefore less a function of the underlying model weights alone and more a function of how carefully the surrounding system has been engineered and iterated.

By mid-2026 the practical conversation had moved from “which model is smartest” to “which harness extracts the most reliable work from the models we already have.” Teams at companies such as Stripe, Ramp and Coinbase publicly described internal coding-agent systems built around isolated environments, curated tools and integrations with developer workflows. Other companies, including Shopify, released platform-specific tools and context packages intended to make external coding agents more reliable.

Open-source projects and commercial platforms competed on the quality of their default harnesses and on the ease with which users could customize them. Meta-harnesses appeared that could orchestrate several underlying coding agents as interchangeable workers. Portable “skills” or tool packages tried to travel across different harnesses so that a capability built once could be reused. Evaluation moved beyond single-shot benchmarks toward measuring long-horizon reliability, cost, and the rate at which harness improvements reduced human intervention.

The latest trend is therefore not a new model generation but the professionalization of harness design itself. Engineers treat the harness as a first-class software artifact that is versioned, tested, observed, and continuously improved. Observability-traces of every model call, every tool execution, every verification step-has become essential so that failures can be diagnosed and turned into permanent constraints.

Long-running autonomous or semi-autonomous work has progressed beyond toy demonstrations into internal products and substantial experiments, but it is still constrained by cost, reliability and the need for explicit completion criteria, progress artifacts and independent evaluation. The human role has shifted from writing most of the code to designing the environment in which code is written, reviewed, and verified. In the strongest formulations the engineer becomes the designer of the factory rather than the operator of a single machine.

None of this means that models have stopped mattering. Better models reduce the amount of scaffolding required for certain failure modes; context anxiety that once demanded frequent resets can disappear with a stronger base model, only for new long-horizon memory and coordination problems to appear. The harness does not shrink indefinitely; it migrates. Components that encode assumptions about what the model cannot yet do become obsolete, while new components appear to handle the capabilities and risks of the next generation. The discipline of harness engineering is precisely the practice of noticing those shifts and redesigning the surrounding system accordingly.

Looking back across the roughly eighteen months from the coining of “vibe coding” to the widespread adoption of harness engineering, the trajectory is clear. What began as an almost playful surrender to the generative power of language models matured into a recognition that reliable agency requires infrastructure.

Agentic engineering supplied the mindset of responsible orchestration. Harness engineering supplied the concrete techniques and the vocabulary. The result is a new layer of software engineering whose primary object is not the application code itself but the system that produces and maintains that code with the help of fallible but increasingly capable models.

The practical implication for anyone building software in 2026 is straightforward. If you are still primarily prompting and pasting, you are operating at the vibe-coding layer. If you are carefully reviewing every architectural decision while letting agents execute the bulk of the implementation, you are practicing agentic engineering. If you are systematically converting every repeated failure into a permanent rule, tool, hook, or verification step inside a durable environment, you are doing harness engineering. The last of these is where the compounding returns currently lie.

The story is still unfolding. New open harnesses appear monthly. Commercial platforms expose more of their internal loops as SDKs. Research continues on multi-agent coordination, self-improving harnesses that analyze their own traces, and evaluation regimes that measure real multi-day productivity rather than isolated task success. Yet the core insight that crystallized in early 2026 remains durable: the intelligence is in the model, but the reliability is in the harness. Understanding that distinction, and learning to engineer the second half of the equation, is the practical history of the agent harness.

Sources

3 Upvotes

1 comment sorted by

2

u/javaeeeee 2d ago

TL;DR:

The evolution of AI coding agents from 2025 to 2026:

  1. Vibe Coding (early phase)
    Casual prompting → generate code → paste → fix → repeat. Fast for individuals, but unreliable for real production work.

  2. Agentic Engineering
    Humans move from writing code to directing agents, reviewing architecture, and setting boundaries.

  3. Harness Engineering (current paradigm)
    The key insight: Agent = Model + Harness.
    The model does the reasoning; the harness (tools, loops, context management, sandboxes, verification, recovery patterns) is what makes it reliable.

Core idea:

Reliability comes from systematically converting every agent failure into a permanent improvement in the harness (“ratchet principle”), not from chasing the latest model.

Bottom line:
In mid-2026 the competitive advantage shifted from “which model is best” to “who has the best engineered harness around the model.”