IDE Assistants vs Agent Harnesses: Different Products, Different Futures

Autocomplete-in-your-editor and run-this-task-autonomously get discussed as the same category because they're both "AI coding tools." They're different products serving different moments, and conflating them produces bad predictions about which survives.

The two shapes

The assistant sits in the editing loop. You're typing; it suggests. The unit of interaction is a few lines, the latency budget is milliseconds, and you evaluate each suggestion instantly by whether it's what you were about to type. Control never leaves you.

The harness takes a task and runs. The unit is a change or a set of changes, the latency budget is minutes, and evaluation happens at the end by reviewing a result. Control is handed over and returned.

→ The difference isn't autonomy on a spectrum. It's that one augments an activity you're doing and the other performs an activity instead of you, and those have opposite requirements almost everywhere.

Opposite requirements

Latency. The assistant must be imperceptibly fast or it disrupts the thing it's helping. The harness can take minutes because you've context-switched away.

Context. The assistant needs what's around the cursor. The harness needs the task, the conventions, the constraints, and the ability to go find more.

Failure cost. A wrong suggestion costs a keystroke to dismiss. A wrong harness run costs a review cycle, or worse if merged.

Verification. The assistant is verified by the human reading it as it appears. The harness needs its own oracle, because nobody watches the middle.

Model tier. The assistant wants fast and cheap — it's called constantly and the human filters. The harness wants capable, because nobody's filtering.

What that implies about their futures

The assistant commoditizes. Its requirements — low latency, local context, small suggestions — are exactly what small and local models are getting good at. Quality differences narrow, it becomes a feature of the editor rather than a product, and pricing power erodes. Being genuinely useful and being defensible are different things.

The harness differentiates. Its requirements are the hard ones: context assembly, tool design, verification, permissions, recovery, review presentation. Those are engineering problems where implementations differ enormously, and where being better is visible.

⚠️ Which suggests the products converging on harnesses are converging on the part that stays valuable, and products that are primarily assistants are standing on ground that's flattening.

💡 The part that gets missed

The harness's differentiators aren't AI capabilities. They're:

• How well it assembles context for a task.
• How good its tool surface is — descriptions, granularity, error semantics.
• Whether it has an oracle in the loop, and how it uses failure.
• How it presents work for review, which is the actual bottleneck.
• How it handles being wrong — escalation, partial results, recovery.
• What it does about permissions and blast radius.

Every one of those is ordinary software design. → Which is why the interesting competition is in software engineering rather than in model access, and why teams with identical model access produce very different results.

✅ What this means for choosing tools

For an assistant: optimize for latency and non-intrusiveness. Don't pay much; the capability is commoditizing and switching costs are low. Whether it's local or hosted matters mainly for latency and privacy.

For a harness: evaluate the things above, not the demo. Specifically:

• How does it handle a task it can't complete? Silent wrong output or a visible stop?
• Can you see and modify the tool definitions?
• Is there replay, so you can test changes deterministically?
• How does it present a change for review?
• Can you swap the model?

Those questions separate harnesses that will still work for you in a year from ones that demo well.

Expect to keep both. They serve different moments. Someone typing in an editor wants an assistant; someone handing off a task wants a harness. Neither replaces the other, and a product trying to be both usually compromises the latency requirement.

The takeaway

Assistants augment an activity; harnesses perform one. Their requirements are opposite on latency, context, failure cost, verification, and model tier. The assistant's requirements are exactly what commodity models satisfy, so it flattens into a feature. The harness's differentiators are context assembly, tool design, verification, and review presentation — ordinary engineering, which is where the durable differences are. Evaluate harnesses on those, and don't overpay for the part that's becoming free.