The AI-coding stack: a map for a landscape that won't sit still

seed · Aug 17, 2026

Every week ships a new AI coding tool, and every announcement uses the same words: agent, context, autonomous, 10x. I’ve argued before that these assistants should reach beyond the editor, across the whole development loop — but whatever they reach, you first have to tell them apart. If you try to reason about “AI coding tools” as one category, you end up comparing a frontier model to a YAML workflow runner to a Firecracker microVM vendor — and the comparison produces noise, because those are not three competitors. They are three categories of one stack.

Since late July 2026 I’ve been keeping a small public research repo¹ with one rule: claims come from reading source code and running preregistered experiments, not from launch posts. This article is the map that survived a month of that.

The core triad

Strip any working coding agent to the parts it cannot lack and three things remain: models, harnesses, and execution environments.²

Models

Models are the actual large language models: they take your request and its surrounding content into their context window and generate new content accordingly — code, plans, tool calls. Concretely, the category is the weights and the API surface around them — Claude Sonnet 5, GPT-5.6, DeepSeek V4. This category drifts fastest: pricing, caching economics, effort controls, and lifecycle stages change monthly (one vendor repriced its entire API to time-of-day billing the day before I checked its row³). The part nobody advertises: vendors don’t even share a lifecycle vocabulary — of ten models I track, one has been “in Preview” for six months with no GA plan stated as of 2026-08-17, another’s GA was quietly suspended three days after launch and redeployed weeks later.³

Beyond benchmark quality, the axes that actually separate model APIs are the surface around the weights: whether thinking is adaptive or a budget you set, what the effort controls default to, the write/read economics of prompt caching, whether batch pricing exists at all — each recorded in the vendor’s own vocabulary, because the economics differ structurally between vendors.³ And the route matters as much as the name: the same model reached through a first-party API, an aggregator, a cloud marketplace, or a local runtime is not the same product — prompt-caching support, quantization, rate limits, and silent context truncation all vary by route.⁴ This is also the category that most resists decomposition into components: even open weights yield transcribable architecture facts, not a mechanism you can trace the way you trace a harness’s loop in source. So the assessment lens is behavioral — tool-call fidelity, long-horizon coherence, usable context — and economic: per-token prices are the objective numbers vendors publish, but the figure that actually matters is cost per completed task, which a price sheet alone can’t tell you.²

Harnesses

Harnesses are the software that turns a model into an agent. Formally, a harness implements an agent-computer interface:⁵ it treats the language model as a new category of end user and supplies everything that user touches: the commands it can issue, the shape of the feedback it reads, and the management of its context window. In practice, that is the loop that assembles context, offers tools, executes actions, and decides when to stop. Claude Code, Codex CLI, OpenCode. This is the category most discourse treats as plumbing. It isn’t.

The paper that named that interface also measured its weight. SWE-agent (NeurIPS 2024) held the model fixed and redesigned only the interface the agent works through, and moved SWE-bench Lite⁶ from 11.0% (bare Linux shell) to 18.0%, a +64% relative improvement from interface design alone. The same paper contains my favorite negative result in the field: a search tool faithfully copied from human UI patterns scored below having no search tool at all. Tool existence is not tool value; a checkmark on a feature matrix can be negative.

Feature lists mislead here. What to trace instead is the harness’s three components, each an agent-shaped question:²

• The loop: who can stop or steer a turn, and with what authority? Iteration, tool dispatch, stop conditions, subagent fan-out, plan-mode checkpoints.
• Context assembly: what reaches the prompt, who wrote it, and where does the agent’s own output land? Rules-file and skill injection, memory write-back, compaction, cache discipline: the contested ground of 2026.
• The permission gate: what may the agent attempt without a human, and can the model influence that decision? The harness’s end of the harness↔environment edge, distinct from the environment’s own bounds.

Nine harnesses are tracked so far, four of them traced to deep-dive depth.⁷

Execution environments

Execution environments are where the agent’s actions actually land: your host, a git worktree, a devcontainer, a cloud sandbox like E2B, Modal, or Daytona. For weeks I suspected this category was just an attribute of the harness (“where does it attach?”), and I kept a pre-committed demotion rule for it. Then the first environment studied as a product in its own right — E2B, read from its open-source infrastructure — produced roughly 26 facts invisible from the SDK:⁸ every “create” is secretly a snapshot resume, the guest’s memory compactor is disabled for the host’s snapshot-diff economics, the credential-injection proxy doesn’t exist in the open-source build. An interface that hides that much is a category, not an attribute.⁹

An environment is three components:¹⁰

• Host: machine, OS, installed toolchain, and network position.
• Principal: the effective identity of the agent’s process (OS permissions, ambient credentials, inherited environment variables).
• Working directory: the anchor where discovery walks from.

The default execution environment every harness runs in is {your machine, your user, cwd} — full ambient authority anchored at a folder — and every product in this category is a device for narrowing it. The category’s three questions map straight onto the components: blast radius (host × principal — what can the agent damage), fidelity (host toolchain + working directory — does the project’s tooling run unmodified inside), and parallelism (the cost of multiplying working directories versus hosts) — and the field’s autonomy ceiling is set by blast radius, not model capability.² How a harness relates to its environment is a design position of its own, with exactly four verified shapes — bundle one, bind to one, internalize one, inhabit one — plus a legitimate fifth: deliberate abstention.¹¹

The two additional interfaces

Around that triad sit two more categories that behave less like parts of the machine and more like boundaries: workflow frameworks on the boundary between you and the stack, memory on the boundary between one session and the next.

Memory

Memory is persistent cross-session state, packaged as an installable product (mem0, MemOS, ai-memory): fed by hooks during the session, consolidated between sessions, injected back at the next session start, on any harness.² Harnesses ship memory features of their own (the harness ↔ memory section below returns to that), so for a user who lives in a single harness these products compete with a built-in. Their own domain begins where no single harness can follow: persisting what was learned across harnesses. A first cross-harness probe (n=1 per arm) measured that continuity as real, and entirely pull-shaped.⁹ Two findings frame the products: they sell to coding agents but benchmark on chat (LoCoMo,¹² LongMemEval¹³),⁹ and they share zero formats — each vendor pays the harness-fragmentation cost separately, in code, up to and including one product’s plugin blocking the harness’s native memory writes to redirect them into its own store.¹⁴

The category decomposes into three components — the pipeline to trace when assessing a product, each with its own trust question:²

• Capture: what enters the store, and who admitted it? The write path (hook, adapter, or agent-invoked; no two vendors alike) and the admission policy: what earns storage, and on whose evidence.
• Consolidation: what happens to it between sessions, and does that run by default? The store wager lives here (a git-versioned markdown wiki, a vector platform, a knowledge graph, a scored policy database), plus tiers, decay, and who may revise a memory once it turns out to be wrong.
• Recall: what reaches the next session’s prompt, pushed or pulled, framed as data or as authority? Injected memory is a prompt-injection vector, so the read-side trust boundary matters as much as the retrieval: the category’s pitch says “your agent remembers”; the measurement above says it can look things up, if it asks.

Eight products are tracked, three at deep-dive depth.⁷

Workflow frameworks

Workflow frameworks are methodologies encoded as installable tools: prompt and template packages that refine your intent into specs and subtasks going down, and carry research and verified evidence coming up. Formally, they are the tools that sit over an agent you already run while being neither the agent itself nor a kit for building one, which is how an independent six-framework study delimits the category.¹⁵ OpenSpec, spec-kit, GSD, and their cousins.

All of them exist to enforce a working structure on the agent. What varies is the nature of that enforcement. At one end sit prompt templates the model reads and follows, which keeps a framework portable across harnesses (prose runs anywhere) but makes its runtime the model reading instructions; at the other end sit small deterministic engines that parse, validate, and advance workflow state in code.¹⁶ Portability and enforcement power are the same tradeoff,⁹ a finding the same study reproduced independently, working from documentation alone.¹⁵

The four functions a framework performs are its components — what to check a candidate actually has:²

• Intent refinement: does the framework test the English before anything executes?
• Work decomposition: does work arrive at the triad in verifiable units?
• Gap research: does the framework measure the domain, or trust the model’s training data?
• Verification: who checks the claim of “done”, and with what authority?

Intent flows down through the first two; evidence flows up through the last two — and the preregistered experiments located nearly all of the measured value in the last two and almost none in the ceremony of the first two.⁹ Nine frameworks are tracked, four at deep-dive depth.⁷

The stack is being eaten from the middle

The reason this map needs dates on it: the categories don’t respect each other’s territory. Mechanisms that adjacent categories sell keep turning up natively in harnesses⁹ — and the pattern looks different on each edge, starting with the one where nothing is being eaten at all.

Harness ↔ model

This may be the map’s best-defined frontier: harnesses are not trying to bite anything off the model category. No tracked harness ships or trains its own weights, and none of the absorption findings names the model as a target — the model stays the swappable slab in the diagram. Where the frontier is crossed, the movement runs the other way: model vendors treating harnesses as data instruments — xAI’s acquisition of Cursor, followed by training Grok 4.5 on that harness’s session data, and hermes shipping trajectory-export tooling openly labeled for training its maker’s next models.²

Well-defined does not mean uneventful. Every harness is forced to take a position on whether models have “converged” enough to share one prompt, and the five documented positions are incompatible: nine bespoke per-model prompts sharing zero substantive lines (opencode), a per-family prompt registry built and then dismantled (cline), ~15 lines betting the prompt barely matters (continue), one shared prompt plus per-family appendices covering every major family except Anthropic’s (hermes), and a vendor swapping instructions per model slug within its own family (codex).¹⁷ None of the five is backed by a published eval. When the practitioners best placed to know can’t agree, “the harness doesn’t matter” is not a safe assumption.

And yet in public reporting the frontier barely exists. Leaderboards like Terminal-Bench¹⁸ score pairings — “Codex CLI + GPT-5.5” — and publish them as model results, so nobody knows which category they’re praising. Some benchmarking efforts are starting to pay attention: one open benchmark, llm-coding-benchmark, fixes the harness precisely to isolate the model, and when a subtler confound surfaced there (the harness’s own per-model prompt dispatch), reporting it upstream⁴ turned into a contribution to the fix.⁹ And for the vendors that span both categories, attribution is confounded by construction — the model and the harness were never built to separate.² That isolation is buildable — my own rig does it at personal scale for a few dollars.

Harness ↔ environment

One harness doesn’t attach to a sandbox — it is one: Codex CLI compiles Seatbelt, Landlock, bwrap, and a Windows sandbox into its own binary and invokes them per tool call; a Node or Python harness can call a sandbox, a Rust harness can be one.¹⁹ Claude Code ships worktrees as a first-class native operation, and its cloud side bundles its own sandbox. Underneath sits a substitution: permission gates and environments restrict the same thing — the harness gates per action in software, codex per action in the OS, a container structurally.¹⁰ What has not been absorbed is the environments themselves: they remain independently distributed products a harness binds to — bleed, not merger.

Harness ↔ workflow

The turn-end verification gate — the mechanism the framework experiments credit with category 4’s quality margin — now runs natively inside harnesses: hermes as an always-on loop policy that re-prompts the model when it finishes without fresh verification evidence, codex as stop hooks that can veto termination. Plan modes are everywhere, in four diverging shapes (an enforced mode, a tool, a bundled skill, a per-query flag), and subagent context isolation is native in all six harnesses checked.¹⁷ The inversion underneath: every tracked framework’s gates grade as prose or scripts — their runtime is the model reading instructions — while the harness-native forms grade as engine or hook. The framework category’s hardest problem is the harness category’s default posture. And what is not absorbed is a coherent remainder, not a lag: staged intent artifacts, artifact-structure gates, and workflow-scoped state — the spec-driven spine. Harnesses absorb mechanisms and leave methodology alone.

Harness ↔ memory

Autonomous memory loops are native in three of the four harnesses checked for them, in four different mechanism shapes: hermes runs a background fork on by default, codex ships a pipeline that is stable but off, Claude Code writes memory in-loop — and Warp is the verified counter-instance, agent-proposed but human-committed, with a deprecated field showing an auto-write path that was built and then removed.²⁰ “Native memory” was never uniform. And on this edge the traffic runs both ways: memory products colonize harnesses that already absorbed the feature — memos installs into hermes alongside hermes’ own loop — and one escalates to displacement, blocking the harness’s native memory writes to replace them with its own: the cross-harness bet from the memory section, fighting back.

Absorption isn’t only vertical. Warp’s multi-agent orchestration treats rival harnesses as selectable backends — an enum whose variants are its own agent, Claude Code, OpenCode, Gemini, and Codex — with drivers and transcript parsers for its competitors, and it launches those children with their own permission gates disabled: absorption of orchestration without absorption of governance.²¹ Any claim that “you need category X for capability Y” therefore has a shelf life — and not only because harnesses grow. In a preregistered ablation, one model tier absorbed a workflow mechanism’s entire measured value: a grounding instruction that lifted a smaller model’s trap discovery did nothing for the next tier up, which grounded unprompted.⁹ A measured margin for a workflow framework is a claim about current-tier models, with a built-in expiration date.

Where the map ends

The map stops at five categories on purpose, and not everything the research touched fits inside one. A sixth bucket cuts across the five (MCP servers, skills, rules files, hooks, and config packs like ECC):² distributable content that parameterizes the triad’s edges rather than standing as a category of its own.⁹ Some things are a different kind of object entirely: standards, like the MCP protocol itself, are specifications other people implement rather than things you install, and the rules-file and skill filename conventions are converging the same way. And a few of the field’s highest-leverage topics refuse to sit anywhere: context engineering lives in the harness, the rules files, and the workflow framework simultaneously, and verification and cost behave the same way.²²

That looseness is the state of the field, not a defect of the map. The map’s own history shows the categories moving: memory started as one type inside the extensions bucket and became a category of its own within a week; the environments category carried a pre-committed demotion rule before earning its place; the extensions bucket keeps a documented trigger for re-promotion.² New categories may arise, and current ones may dissolve, most likely into the harness, the way the middle of the stack keeps eating.

None of it obliges you to install anything. The map is for navigating the landscape, not for filling a cart: knowing what a tool is and which questions to ask of it is not an argument for needing one of each. Every addition is more context to assemble, another permission surface to trust, another bill to watch. You do not need a new tool in your stack for its own sake, or for the sake of trying something new. At the end of the day it is all just software; a text editor should do the trick.

Every claim above traces to the research repo,¹ where it carries its verification date. If the repo contradicts this article, the repo is newer — trust it.