It's been clear for some time that model tool calling is heavily fit to a few common patterns, it's unsurprising that a tool call that looks the same or has the same name, but works differently, is falling back to priors and causing problems.
Things are not quite AGI yet; which is why people are now saying that intelligence is the harness + model, because the harness makes up for limitations in generalization.
Gemini fumbled not on the models but on the basics.
Gemini 3.1 flash was actually an amazing model to code with and their 20 dollar AI plans had solid value, but they locked it all behind 429s, needless gatekeeping of clients and poor product differentiation even among internal offerings. Users moved on. To claude for the best product, to OpenAI for the non gatekept API access. It’s hard to bring them back.
I’ve been looking for a way to articulate this shift, and your analogy nails it.
The value of libraries and infrastructure components in software engineering is eroding fast.
I am sure that in many organizations, teams responsible for this sort of work have less and less users coming to them.
This gives me the best of both worlds, hand curated reviews and automation. I often get the best quality if I do both, with an agent doing a pass first.
The problem with vibe coded re-writes is that you basically sign off on understanding the generated codebase at that point. Any historical knowledge of the codebase is gone.
the problem is not the forward pass, its the control/feedback loop when slop is written in response to the forward pass. Perhaps we should give the LLM 2 specs, one designed for the forward pass and another for the acceptance criteria /backward pass that's focused on tests, best practices and code, so that the output is independently verified?
Using CRDT gossip to inform scaling is a clever idea. You are on to something there. Perhaps extract it as a core library/concept from the runtime? I feel that would be generally useful!
I have a coding agent https://github.com/hsaliak/std_slop where the sessions are in SQL ledger. So /session [new, clone, deletes, undo] are supported and all sessions are persistent. Cloning lets you 'fork' the context and undo lets you roll back, basically solving the problem you state above.
Sessions are linear though, so you cant do this _while_ an existing session is cooking.
That said, I am excited about this update too, I've been playing with ACP support and Zed's UX was bare bones. I want to run my agent with multiple workers now, and see what happens.
I find parallel agents to be an exception rather than a norm. Maybe I’m the problem?
For those exceptional cases, opening a few more terminals gets the job done. It’s unclear to me if this needs to be the primary workflow. My brain naturally does better on deep work on one problem..
Clojure had lousy error messages, agents deal with this well.
Clojure is capable of producing some of the most dense code I’ve ever seen, so manual code reviews really start to feel like a bottleneck unless your goal is to level up.
Tool output truncation helps a lot and is one of the best ways to reduce context bloat. In my coding agent the context is assembled from SQLite. I suffix the message ID to rehydrate the truncated tool call if it’s needed and it works great.
My exploration on context management is mostly documented here https://github.com/hsaliak/std_slop/blob/main/docs/CONTEXT_M...
1. /edit => opens in editor
2. /feedback => opens the last llm message in an editor so i can inline feedback. Think inline responses in email vs bottom posting.
3. /review => same as /feedback but opens up the diff so i do an inline review. Yes I still read the code it ships.
So basically in this flow vim becomes integral to doing anything involved.