Taming the Beast
Since my last post I've been working with Opus 4.5 and Claude Code daily, building whatever I could dream up, waiting to hit "the wall." If you've used AI coding tools in the last year, you likely know it well. It's the point where the code base gets so slopped up that the app falls apart. Well, that wall never came. Instead, I found myself paying down debt from previous projects, sharpening their quality, thinking about what problem I could solve next. My ideas were the limitation, and it was crazy fun.
Harnesses
I've written before about how difficult it can be to get an LLM to follow explicit instructions. As a programmer, I'm used to inputs determining outputs, the same thing happening every time. Through frustration, I realized this new way of working required me to abandon determinism. I had to treat this technology as something unpredictable and try to wrestle some determinism out of it.
In early December, I watched Dex Horthy's talk "No Vibes Allowed: Solving Hard Problems in Complex Codebases." He dropped a term I hadn't heard before: "harness engineering."
I absolutely love this term because using AI right now feels like what it must be like to domesticate a wild animal. You approach slowly, provide treats, get bit, find ways to work together, eventually get close enough to touch. Trust grows. You build a symbiotic relationship. Eventually, you can put a saddle on it. Then a full harness. Domestication leads to cooperation with utility beyond what either could achieve alone.
The AI harness isn't leather and metal. It's managing context, creating workflows, hooks, rules, sub-agents, skills, commands, and prompts. Combine these tools in an environment where you can experiment, and something unpredictable becomes controllable. Using Opus 4.5 in Claude Code is this environment and using this pair results in a total paradigm shift in how we build software. The harness abstracts away the complexity of writing code and becomes the interface where the human describes intent and steers the model towards what they want.
Claude Code Is the Saddle
Claude Code provides an interface that brings everything together and it's opinionated and not at the same time. It enables you to use the baseline harness it provides and actively encourages you to build your own using all the aforementioned parts. Don't want to use plan mode or todos? You don't have to. This is what makes Anthropic's work impactful and well ahead of others competing to be the AI coding leader. They are the makers of the model and the provider of tools for people to make harnesses. Together they work in sweet harmony.
Over the past few weeks, I've experimented building my own harness. Here's where I netted out.
Insights on Context Management
Knowing that AI models have limited understanding (context windows), it's critical to understand how these models perform as more and more of this limited context window is used. Think of it like remembering all the details in a book you just read. The larger the book, the harder it is to retain everything that happened.
In Dex's talk, he went in depth about using the sweet spot of the context window that yields the sharpest understanding of the information it's been given. He refers to this as working in the smart zone and avoiding the dumb zone.
With this in mind, I followed Dex's suggestions and used Claude's sub-agent workers to break up work into chunks of generally decoupled work. Tasks that normally soak up large chunks of context like codebase research, searching the web, and code reviews could be offloaded to subagents to do the work, and then return a compacted report of the findings. This ensured that we'd keep our agents in the sweet spot of the context window and maximize their intelligence performance.
This orchestration of sub-agents was a critical piece of building a harness that worked well. Dex's suggestions here were a game changer. If you haven't seen his talk on harness engineering, it's probably the most actionable resource I've found on this topic.
Experimenting with Harnesses
I started by adapting a workflow from Boris Cherny:
Explore → Plan → Confirm → Code → Commit
but settled on a variant of Dex Horthy's "RPI" workflow:
Research → Plan → Implement
These both felt similar to the divergent and convergent stages of the design thinking process. This maps roughly to the second half of the double diamond: once you know the problem, how do you solve it right?
Planning:Brainstorm → Refine → Plan
Delivery:Kanban loop (spawn workers for Ready chunks) → Review → Polish
Planning
I created a custom command: /plan
This takes a known user problem as input and initiates a conversational brainstorm that pulls detail out progressively, challenging vagueness until there's a solid idea.
Refinement pressure-tests ideas through a "debate of ideas" where a sub-agent wears multiple hats—including a "you're not going to need it" lens to avoid over-engineering. This stage was added due to models adding features that weren't asked for.
After refinement, a planning agent turns the refined scope into a plan with chunks that include explicit dependencies (what must complete before each chunk can start).
The output: PLAN.md with a dependency graph, and MEMORY.md as a kanban board (Ready/Blocked/Done). These drive delivery. At this point, I /clear my conversation and start implementation.
Delivery
/implement
The main agent becomes the orchestrator. The kanban in MEMORY.md shows which chunks are Ready (no dependencies or dependencies satisfied), Blocked (waiting), or Done. It spawns chunk-worker agents for Ready chunks and each worker implements, validates against the plan, updates the kanban, and commits. When a chunk completes, any chunk that depended on it moves from unblocked to Ready.
Parallel execution: If multiple chunks are Ready with no dependencies between them, multiple workers can be spawned in a single message.
Purple team mode (--use-purple): For larger features, each chunk gets Team A (implements) and Team B (validates and fixes gaps), iterating up to 3 times. This gives each chunk a clean context window.
Both modes update MEMORY.md after each chunk so progress persists across sessions. Phase gates pause for manual testing between major stages. The kanban format also enables resuming. The agent would read MEMORY.md to see what's Ready next.
After all chunks complete, review agents evaluate the work. Critical issues get iterated on.
Results
View the intents-plugin on GitHub
I've built sophisticated features with minimal oversight. One plan ran for over two hours with me just hitting "yes" for permissions.
Usually when Opus finishes up, the work is only needs a couple adjustments to get nice results. What's missing is usually UX polish or a broken API call. The cool part is that most gaps in the solution were gaps in the plan, not random oversights.
Models matter. I ran the same plan through this harness with Sonnet 4.5. It didn't get nearly as far. It skipped steps, and rushed to mark things done. Core features like file upload weren't carried through to completion or tested at all. They were assumed to work. When I pointed out the issue I'd get the classic "you're absolutely right!"
Opus 4.5 responds well. It validates work, completes tasks, and follows the structure the tools provide. It provides a confidence that didn't exist before. I found myself not even looking at the code. The only time I would is when it got stuck on UI styling and pixel-perfect spacing. This is where my background wrestling with CSS paid off.
More sub-agents with shared memory keep each agent in the model's context sweet spot without compacting or clearing. MEMORY.md makes this possible as a shared state every agent reads on initialization.
Granted, this is still super experimental, and for my small projects, it just crushes pretty much anything I can throw at it. I'm really curious how teamwork is going to be impacted by these models and workflows.
What's Next
Andrej Karpathy posted this reflection:
If you feel like you're falling behind, you're not alone. I took some comfort in this tweet. Boris Cherny, the creator of Claude Code, responded:
"... The last month was my first month as an engineer that I didn't open an IDE at all. Opus 4.5 wrote around 200 PRs, every single line. Software engineering is radically changing, and the hardest part even for early adopters and practitioners like us is to continue to re-adjust our expectations."
I think 2026 is the year of the harness. As we get more capable and "agreeable" models that accept harnesses, and ultimately prefer to have a harness, the code is going to step into the shadows. By the end of the year I'm guessing we'll have to think way less about how we'll code things and we'll be thinking way more about what problems are worth solving.
Harnesses aren't just about controlling the model. They're about building confidence in non-deterministic outputs. The validation loops, the code review agents, the shared memory: these create a verification layer that lets you trust code you didn't write and may never read. For low-stakes work, that's enough. For high-stakes work, humans will stay in the loop longer. But the gap will close as these verification systems mature.
I'm still just a guy hacking away on side projects. But the progress I'm making suggests we're closer than ever to a world where more people can ship. If I can build sophisticated features with minimal oversight, running agents for hours while I just approve permissions, the barrier to entry is dropping fast.
Send me what you're doing with your own harnesses. Have a great 2026!