Why JR? Why would you do this to yourself?
Good question, friend. Good question. To answer that, let me tell you about my relationship with music and playing guitar.
I’ve played guitar for over 25 years. I’m a decent player, but I’ve always struggled with music theory. There are melodies and tunes I can hear in my head, but my fingers don’t always have the dexterity to execute them, and my brain lacks the language to transcribe them. You might say that I am a vibe musician. I can play—and play pretty decently—with the knowledge, technique, and practice I’ve honed over these years. And I’ve managed to do all that without understanding the underlying music theory. Of course, I think I’d be a much better and more versatile musician if I did know music theory, but that’s beside the point.
It’s not a perfect analogy, but it maps somewhat to my relationship with coding.
LLMs open a new avenue for me to take ideas that are trapped in my head and make them something tangible.
I’ve supported the creation, delivery, and maintenance of software for almost 20 years. I’ve been a nerd since long before the label was cool. I’ve lived the blood, sweat, and tears required to build good systems, release stable products, and keep them alive in production. But despite all those years around the craft, I never fell in love with programming. I never loved its abstractness, its strict grammar, or its finicky syntax. I learned to respect it, but I never loved it.
What I did learn about myself over two decades in tech is that I love communication and context.
- Need to make a tough decision? I want to analyze how adjacent teams handled similar problems and what trade-offs played out.
- Need to collaborate with someone? What’s their background? How long have they been with the organization? How do they absorb information?
Some might call that overthinking; I call it doing my homework. In fact, a recurring piece of justified feedback I’ve received over the years is: "JR, sometimes you provide too much context. Just get down to business."
And that brings us to the present. When you combine a deep care for human context, an understanding of real business problems, an appreciation for software architecture, and my own friction with directly writing code—LLMs land like a lightning strike.
To be honest, some of this post is me trying to understand myself. Why have I been taking my non-working hours and using them to:
- read
/r/Localllama - pull down and test the latest 24b models from Hugging Face
- Compile
llama.cppfrom source to test the newest templates and quantization fixes - Test prompt architectures to build a new apps
I was telling a friend that the feeling this moment stokes in me is similar to how I felt as a kid discovering a 386 for the first time—tinkering with BIOS settings, IRQ values, and DOS config files just to get a game to boot.
In the specific context of working with agentic LLMs, the hierarchy of critical skills has inverted. Traditional syntax is cheap; contextual clarity, specification design, and systems thinking are exponentially more valuable. That inversion is disorienting for many veteran engineers I know.
Over the last nine months, I’ve been immersed in AI, experimenting with five major agentic harnesses and over ten frontier and open-weights models. Here is the single biggest lesson I learned earlier this year: The harness matters far more than you think.
1. The Harness Is the Differentiator
Before 2026, most people’s mental model of an LLM was a chat box on a webpage or a rudimentary CLI wrapper. Asking a model to analyze code in Google’s AI Studio or a basic chat terminal felt "fine," but it never felt transformative. You’d get 60% of the way toward a solution, hit a context wall, and spend the next hour manually copy-pasting diffs.
On March 26th, 2026, my company gave me access to Anthropic’s tooling and Claude Code (CC). For me, it was revelatory. I may have let loose an expletive in the office that was heard around the floor. It was a disorienting mix of awe and mild panic at what it meant for the future of knowledge work.
Yes, the underlying models were impressive. But what actually altered my workflow was the harness.
Claude Code proactively remembered working preferences across turns. It interrogated me when my prompts were ambiguous. It executed multi-step tool calls, inspected test suites, ran linters, and self-corrected. Six months ago, tool calling felt like fragile black magic; today, a mature harness makes it feel like playing an interactive text adventure where working software emerges on the other side.
View on Threads
For me, a great harness isn't just an API pipe. It must:
- Work out of the box with zero-friction configuration. If an engineer has to fight PATH variables, configure five distinct YAML files, or fiddle with custom auth wrappers before running a single prompt, momentum is dead on arrival.
- Surface the right altitude of telemetry. It needs to let you inspect tool calls, bash execution, and model reasoning without drowning you in raw JSON dumps or terminal spam.
- Handle permission management sanely. Safety is critical, but a harness shouldn't force you to manually approve 40 consecutive read-only operations just to inspect a directory tree. Dangerous mutations need guardrails; routine reads need trust.
- Provide operational awareness. You need clear, ambient visibility into subagents, background jobs, and active task lists—eliminating the dread of wondering whether an agent hung or is legitimately thinking.
- Know when to stop and ask clarifying questions. When faced with an ambiguous schema migration or an undocumented dependency, a good harness pauses and asks instead of hallucinating forward into architectural debt.
- Support cross-environment ergonomics. It must cleanly handle terminal visuals, screenshot attachments, companion hand-offs for long-running batch jobs, and native Windows/WSL2 interoperability.
My Harness Tier List
After running tasks, custom hooks, and project specs through each, here is how I rank the current landscape:
Rank | Harness | Verdict |
|---|---|---|
🥇 1 | Claude Code (CC) | The gold standard for developer ergonomics, context management, and interactive dialogue. |
🥈 2 | OpenAI Codex | Incredible stamina on marathon, multi-hour autonomous tasks; slightly less conversational polish than CC. |
🥉 3 | Pi | Ultra-minimalist and lightweight. Great for scrappy builds, but requires heavy custom plugin maintenance. |
4 | OpenCode | Solid open-source effort, but clunky out of the box. Best suited for local, air-gapped tinkerers. |
5 | Google Antigravity CLI | Powerful under the hood, but hamstrung by abrasive permission toggles and token burn. |
6 | Google Antigravity (Web/Desktop) | Thin project management wrapper that struggles to inspire production confidence. |
🤮 7 | Google Antigravity IDE (1.0 & 2.0) | A case study in product whiplash and abandoned migration paths. |
Claude Code & Codex: The Heavyweights
Claude Code and Codex are currently in a league of their own. Working with Codex on a ChatGPT Pro plan (paired with GPT-6-Astra), I’ve watched it chew through big projects for hours without sight of the main objective. Yet Claude Code remains my daily driver: partly because it's what my organization is using and because in practice, its conversational feedback loop, restraint, and its CLI UX remain top-tier.
Pi: An Acquired Taste
Pi bills itself on minimalism. Pairing Pi with GLM 5.3 Flash via OpenRouter allowed me to hammer out the foundational architecture of a movie-ranking app on a shoestring budget.
The trouble begins when you start bolting on community plugins. There are some popular ones that I tried to add on - and none of them really felt seamless - it did feel like I had added on plugins that I needed to specifically remember to invoke and not something that seamlessly worked together. Obvious I guess when I say it that way, but for me, wasn't quite my jam. It has serious potential for power users who want to assemble a bespoke harness from parts, but it has a bit of a learning curve.
OpenCode: Solid for Local Hackers
OpenCode was my entry point into local models. While it felt clunky and unintuitive compared to commercial offerings, my impressions were partly colored by running low tokens-per-second local models at the time. It has continued to mature, and I look forward to circling back at some point and giving it another try.
The Google Antigravity Conundrum
Google has a huge budget, world-class talent, a marketing lead with DeepMind, but their LLM and developer strategy has been baffling.
Gemini CLI was slow to evolve. Then came Antigravity IDE 1.0—essentially VS Code with an LLM chat layer driving terminal commands. I gave it a shot, testing it on some personal projects, only for Google to deprecate it in favor of Antigravity 2.0, followed by a pivot to the standalone Antigravity workspace app with no clear migration path.
The latest Antigravity CLI (agy) shows promise—it finally supports agent teams and subagents—but the UX is still lagging behind the competition. Permission handling is currently a binary choice between running --dangerously-skip-permission or manually confirming a lot of tool calls. It's just not anywhere near the magical experience that I feel I'm getting with Codex or CC. Until Google treats the harness as a first-class developer product rather than an experimental staging ground, it will lag behind Anthropic and OpenAI.
What Comes Next?
I wrote this initially as one gigantic blog. But then it got unwieldy. So I've split it up.
In Part 2, I will get into more of the lessons I've learned working with LLMs: model routing, thoughts on Chinese models, auditing alignment inside Chain-of-Thought scratchpads, spec-driven development, and managing and persisting context across sessions.