Coding agent project update:
An observation.
Long horizon solvers are actually pretty easy to write.
You work on your structure. You work out your system. You build the architecture thoughtfully from the first day onward. And, if you’ve done that well, chances are good you can make your agents spin for as long as you need them to.
In fact, if you’re good at context isolation, and you can manage some kind of task-oriented memory between processes, you can even make long horizon solving work on some models in the 27B to 35B class, which would have been borderline unthinkable even a year ago.
At least… until you try to generalize that process across models.
That’s the piece I think people miss.
Models are chaotic. Tools, at least the way the industry does tools today, still need to be reasoned through. I have some very loud complaints about this practice, but I’m going to hold onto them for a minute and assume we’re all talking about tools that are cloud-first, or cloud-interchangeable in some meaningful way.
Where generalization becomes the benchmark
Because it’s tool reasoning, or sometimes the lack of it, that creates the bottleneck.
Imagine this, you’ve built the cleanest agentic runtime of your career, you’re thrilled with how logically perfect it is. It glimmers. But three models can get through a workflow, while the fourth one can’t.
You fix it for the fourth model, and somehow you’ve broken the same piece for the first two. Now you’re in the goblin cave with a flashlight and a clipboard, trying to figure out whether you need stricter invariants, simpler processes, better role boundaries, or a sitar and a ceremonial fire.
The answer is: yes.
That’s why generalization becomes a benchmark.
Even in less sophisticated systems, you’ll sometimes see warnings like, “We don’t know what’s going to happen when you use this model. Consider yourself warned!”
It’s also one of the reasons coding agents are such an interesting problem space.
There are plenty of other reasons, obviously.
You can’t really run a business with agents until you have coding agents figured out. But the part I find most interesting is that, with code, unlike other agentic work categories… you only have a vague idea of what the task is.
You don’t know the quantity of things. You don’t always know the consequences of a change before you start making it. You only have a rough idea of the complexity of any given project, assuming the user doesn’t spiral into a long chain of “wouldn’t it be nice if…”
Which they will, if you let them get chatty.
Coherent self-correction at scale
So when you’re building agents that can code for hours, days, or weeks without stopping, the whole game becomes maximizing certainty while keeping the self-correction loops coherent.
Then you generalize it.
Then you test it across the twelve most popular models of the moment.
Then you measure success by completed projects, stable handoffs, coherent recovery behavior, and hopefully, the smallest possible number of emergent AI tantrums.
Get there without a time sucking complexity melt, and you, my friend, are in business.
This is much harder to do than it sounds.
I think that’s the real reason most systems aren’t trying to do it yet.
It pulls your velocity down like nothing else.
It’s a dangerous thing to admit right now: that there are development contexts where even fully automated systems can slow your velocity to a crawl.
But that’s the real work.
You wade through the muck. You sit with your slow evals and pay attention, because this is precision work. You watch, you document, you tighten the loops. You simplify the process. You make the system less clever where cleverness hurts, and more explicit where ambiguity keeps leaking in.
And then when it’s done, you get to use the tool, which should give you your velocity back.
The current build
That’s sort of where I am today.
We’re in the last lap of the coding agent project. I just added internal telemetry to make auditing and debugging easier. Fewer steps. Better visibility. Easier to audit and monitor all the way around.
Next up is an orchestration-compatible MCP server, optimized for Paperclip. It should also work with Pillowfort when that drops. Same general principle.
We’ve survived the good times and the melty times.
And I’m feeling pretty confident about handing this thing off to my beta group soon.
This is going to be fun.