philbo
But what I've noticed is that lots of people don't want that. They're happy to delegate both typing and thinking.
There are folks who still want to think for themselves of course, but model providers are incentivised to maximise token spend over all else, so the "official" harnesses are not aligned with their needs. My message to those folks is: _go and build your own harnesses_.
I built one, it wasn't a huge lift and it completely changed how I work with LLMs. One consequence is that I choose smaller, cheaper models now because latency is more important with shorter feedback loops. I don't want a super-intelligent model that disappears for ages and provides a final answer, my own brain thinks and guides the process instead.
I'm deliberately not linking to my harness here because that's not the point. Think about what modes of work you want from a coding harness, then build one that works exactly like that. Immense happiness and satisfaction is just a couple of weekends away.
Google hit with €403M fine by Irish data watchdog over GDPR violations
Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anything listed in your .gitignore files. I only noticed it because I have separate read scopes for project files, ignored files, dotfiles and external files, so the latter three always prompt me for approval.
I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...
(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ )
I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...
(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ )
This is one reason
> and trying
and this is the other.
It has 2 modes, driver and navigator, that work like the driver/navigator roles for a human/human pair. In driver mode, Opair is similar to other harnesses but with less autonomy for the agent. In navigator mode, Opair has no access to writable tools at all. Instead it monitors the project directory for changes as you make them in your regular editor, and comments on them in real time.
Why? Because big changes are harder to understand if you're not directly involved in working on them, and I want to understand the codebases I work with. I use it as my daily driver and it's perfect (for me). I recommend everyone should consider writing their own harness. When you spend so long working with something, it's nice to have it perfectly tailored to your needs.
My own harness doesn't provide the agent with shell access, so everything has to go through focused tools with limited functionality. There's also a navigator mode where the agent has no writable tools at all, instead it monitors the project for changes you make in your regular editor and comments on them in real-time. That stuff seemed easier to implement from the ground up.
Very niche software, part 2
I wrote about this frustration a few months ago [1], then realised that if the model providers won't do it perhaps I should try fixing it myself. So, shameless plug klaxon, I wrote an open-source harness that tries to work more like pair programming and less like code review [2].
As usual, my "Show HN" post [3] sank like a stone, so I think perhaps most engineers aren't really interested in this direction. It is possible though, we don't have to just accept whatever tooling the labs throw at us.
[1]: https://philbooth.me/blog/agentic-coding-and-mental-models
Show HN: Opair, a coding harness that eschews autonomy
https://gitlab.com/philbooth/opair
Obviously everyone is writing their own coding harness these days, so I'll cut straight to the points of difference in mine:* There's no tool that grants shell access. Instead there's a bunch of development-specific tools, scoped to restricted functionality.* Reads and writes are gated by access control. Project files can be read without prompting, git-ignored files and dotfiles can't.* The...
1. Keep secrets in a dedicated secrets store.
2. Read directly from the secrets store in application code. There is no environment, there are no environment variables. Yes, even on local.
Reduce large sorted set memory with a packed B+ tree
It has:
* No tools that grant shell access, instead tools grant access to specific executables (dangerous args can be blocked).
* Separate "driver" and "navigator" modes that enable or block writable tool access for the agent.
* Role-based model config to control model options depending on whether the agent is planning/reviewing/driving/etc.
Very WIP and no installation process yet, but I'm using it as my daily driver and genuinely prefer it to Claude Code etc.
It's a coding harness that eschews autonomy and instead works like a pair programming partner, with distinct "driver" and "navigator" modes. I've only spent 3 weekends on it so far, so it's a long way from finished. But I am at least using opair to work on opair now, which is nice.
I didn't really want to write a harness, I just got frustrated enough that nobody else was writing the harness I actually want to use. I'll probably be the only person that uses this, but I'm fine with that.
Man nearly sucked out of window mid-air on Ryanair plane
It's still very wip, I spent a couple of weekends on it so far, but I'm working on a harness that eschews autonomy and instead aims to work as a pair programming partner. Key to that are distinct "driver" and "navigator" modes, with the capacity to flip between them rapidly.
https://gitlab.com/philbooth/opair
(not really usable yet, but after tomorrow's session I expect to be developing opair in opair, which is mildly exciting)
2. Commit ADRs to git
3. Mention ADRs in AGENTS.md
What I'm hoping to build ultimately is something that works more like a pair-programming partner than existing harnesses do. I want the user to be an engaged part of the development process all the way through, I don't want the agent disappearing to work on its own. I even want to make it possible for users to swap into the driver role and have the LLM automatically assume the role of navigator when that happens.
There's more info in the readme (actually the readme is all that exists so far, I wanted to get the idea straight in my head first):
https://gitlab.com/philbooth/opair
Even if nobody else uses it, I hope it will be a useful tool for myself and help me find a way to work with LLMs that doesn't harm my mental models, which is what I feel current harnesses do.
The nichest of niche social network clients. It's for people in one particular country, who watch one particular TV program, on one particular day of the week.
Now that the cost of writing software is zero, I love that my focus have moved from vain attempts to generate passive income to just building whatever random shit I feel like. Wish I'd made that choice earlier in life, but no worries!
They can be still be applied now using coding agents, if you're willing to push back against the default setup and change your mode of thinking a little bit. Of course it doesn't help that an entire industry is dedicated to persuading us that maximizing token spend is the only way to get shit done.
I appreciate this probably seems like an extremist take, but I wrote some more about it here in case there's anybody out there who identifies with it:
Agentic Coding and Mental Models
Top FEMA official said he once teleported to Waffle House
Can pumping chemicals into the ocean help stop global heating?
Online play does not require signup etc. Instead I create an ephemeral session when network games are created/joined and those sessions are deleted at the end of the game. Leaderboard state is entirely local.
Because the backend runs on a small instance, I've been quite aggressive with connection management. If the server goes a minute without hearing from a client (turn or heartbeat), it ends the game and awards the win to the opposing player.
It was a pretty fun project to work on, and I definitely wouldn't have finished it without the crutch of Claude Code to push me through some of the schlepp.