1 November 2026

Everything is changing

You can’t help but notice that with AI coding, everything moves fast. Approving every tool call was the norm; now it’s a sign of madness. MCPs were good, then bad, then good again. “Plan mode” was a thing; now it’s legacy. Human code review is dying. I could go on forever.

LLMs change everything around us, how we manipulate the world, and how we get the signals back. Coding is at the epicenter of these changes and affected the most. Not only has it changed — the pace of change is directly guided by the pace of advancements in the SotA models.

When it comes to coding, whatever your current process is, it will continue to change. Without question, the next few years will be turbulent for everyone in the industry.

Some things will stay constant

Surprisingly, many things will stay the same.

Interestingly, most of the rituals that we always considered best practices still hold today. Writing (and maintaining) docs, having good test coverage, domain-specific and general-purpose static checks, modular code, version control hygiene, solid architecture — the things that benefited the carbon-based coders also seem to benefit language models immensely.

For coding harnesses specifically, I predict many things will stay as well. The modality will still be “text in, text out”. We will still have tool calling (mostly bash and MCPs, I assume). We will value observability at the right level of abstraction.

More importantly, in this fast-paced dynamic, we will value stability and reliability of the tools we use to direct the models. We will want a stable foundation, while also being able to mold everything around it. We will want something unopinionated to make our own opinions on top of it. We will adore software that puts you in control and doesn’t attempt to lock you in.

Why Pi?

What makes Pi the best fit here? Simple: it’s the only harness today that’s open source, vendor-agnostic, extensible, and minimal enough to not force opinions on you. It gives you full ownership and puts you in control. Being able to change the providers without switching apps alone is reason enough to adopt it, but the fact that it’s also so flexible makes it almost impossible for me to switch back.

Being minimal is important for two reasons. First, by being minimal you introduce no bloat that limits the capabilities of models (bloat especially harms the frontier models). Second, by staying lean you don’t need to unship features that are obsolete.

Being extensible is even more important. No two workflows are similar enough to warrant the same functionality. I’m a big fan of the AskUserQuestion tool, but somebody else might not need it. I like to be able to have a /usage command that shows my provider limits across all providers I use, but somebody else might not want that, or they want it in a different format, or they might use different providers. Nobody should be forced into those decisions.

At this point you might object: “Pi might be the best thing now, but how could it stay the best choice in the future?”

Fair question. I think there are two reasons.

Pi is Lindy ↗. It’s been around for a year and has arguably the biggest developer community across all harnesses. It’s here to stay.

Separately, Pi is good enough that I don’t expect an alternative to be an order of magnitude better. To switch, you usually need something 10 times better. Pi is definitely a major leap compared to Claude Code or Codex. At the risk of being unimaginative, I can’t figure out what could be a 10x improvement over Pi. Sure, there are certain features whose absence could become a deal breaker, like cloud agents, dynamic workflows, model routing, and a better plugin system, but I don’t see how those couldn’t become part of Pi eventually, either natively or via plugins.

Harness is the wrong term

Harness as a term is being so overused. Different people have different definitions for it, and it kinda became a meme concept. At the same time, harnesses are becoming so much more advanced under the hood, seemingly without any immediately obvious benefit: durability, sophisticated plugin systems, harmonizing provider-specific features in a coherent experience.

Instead, I’d use the term “harness engine” or just “engine”. An engine isn’t really about the system prompt or tools — those will converge over time. An engine provides a unified interface across providers, handles compaction, retries failed requests automatically, and marshals the transcripts. It’s a substrate that users then tailor to their needs.

A bet

I personally think Pi will win. I’m willing to back this bet with my time by working ↗ on an interface for it.

I don’t have any plans to add support for other harnesses. Only by focusing on a single one can you make a great product; otherwise, it will just be the lowest common denominator between them all.

What’s next?

Of course, “the last harness” is hyperbole. I don’t actually think there will be no more attempts at this. But I do think Pi has a chance to become the last widespread agentic coding harness.

Personally, I’m keeping an eye on:

• Orbs ↗ / Amp: first-class support for ephemeral, per-workload VMs is a significant productivity unlock. As somebody who’s doing all my work on VMs now, I’ve spent too much time managing shared resources, updating packages, and provisioning credentials. I’d much prefer using something that lets me focus on code.
• DeepSeek Harness ↗: a somewhat radical idea to make everything in the app a plugin, but I think it’s directionally correct. I routinely find some things too opinionated in Pi, and there’s nothing I can do about it.
• omp²: Can Bölük, the creator of omp, shared ↗ an extensive breakdown of harnesses in light of a new major release. The biggest personal takeaway is that harness/engine design is a nascent space, and there’s an opportunity to rethink pretty much everything: extension API, transcripts & journaling, provider handling, tools, and the runtime itself.