This graph biases outcomes (A| O) it would be interessting to have an others.. so we can view the whole picture
HN user
hsaliak
so the joke was the implication that they are not frontier.
no, this post was written by Demis from Deepmind.
I have my own coding harness (std::slop), in that i focus on a vim centric flow. Basically a few commands open. up my $EDITOR which is vim.
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.
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.
so he's the quintessential brilliant jerk, ok
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.
Big Monsanto energy
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.
I have a custom agent that generates patches like you will with kernel development and I review and merge those in. https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode...
My agent forces this workflow by disabling modifications outside the coding step.
I added looping to this not too long ago. https://github.com/hsaliak/std_slop/blob/main/docs/mail-loop...
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.
I wrote https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... to avoid the brain rot from just shooting slop. It has helped me stay sane, review code and make changes step by step.
I dont go as fast as with other agents, but this works for me, and I enjoy the process.
Its going to be interesting to see how this holds up in production after a release or two.
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?
nobody knows what to build when everything can be built, there is no moat.
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..
I made https://github.com/hsaliak/filc-bazel-template bazel target for people who may want to use these two together to make hermetic builds with it.
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.
I've long had the same idea.. this one has legs.
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...
This is most certainly vibed with a few optimization focused prompts. Yes - performance is a feature, but so is lack of risk.
Agreed on the need, and this space needs more exploration that is not going to come from big-cos as they are incentivised in boosting spend. I've been exploring the same problem statement, but with a different approach https://github.com/hsaliak/std_slop/blob/main/docs/CONTEXT_M....
The comment was more around how to make their approach sticky.. I feel that local SLMs can replicate what this product does.
My experience so far tells me that the default path with AI tooling is that it lets us create without learning. So the author is right in that they can pay for a seat in this revolution whenever they want.
A practitioner with more experience maybe a few percentage points more productive, but the median - grab subscription, get tool, prompt, will be mostly good enough.
I expect tools to start embedding an SLM ~1B range locally for something like this. It will become a feature in a rapidly changing landscape and its need may disappear in the future. How would you turn into a sticky product?
https://github.com/hsaliak/std_slop a sqlite centric coding agent. it does a few things differently. 1 - context is completely managed in sqlite 2 - it has a "mail model" basically, it uses the git email workflow as the agentic plan => code => review loop. You become "linus" in this mode, and the patches are guaranteed bisect safe. 3 - everything is done in a javascript control plane, no free form tools like read / write / patch. Those are available but within a javascript repl. So the agent works on that. You get other benefits such as being able to persist js functions in the database for future use that's specific to your codebase.
Give it a try!
I explored this in std::slop (my clanker) https://github.com/hsaliak/std_slop. One of it's differentiating features of this clanker i that it only has a single tool call, run_js. The LLM produces js scripts to do it's work. Naturally, i tried to teach it to add comments for these scripts and incorporate literate programming elements. This was interesting because, every tool call now 'hydrated' some free form thinking, but it comes at output token cost.
Output Tokens are expensive! In GPT-5.4 it's ~180 dollars per Million tokens! I've settled for brief descriptions that communicate 'why' as a result. The code is documentation after all.
This is a very nice and clean implementation. Related to this - I've been exploring injecting landlock and seccomp profiles directly into the elf binary, so that applications that are backed by some LLM, but want to 'do the right thing' can lock themselves out. This ships a custom process loader (that reads the .sandbox section) and applies the policies, not unlike bubblewrap which uses namespaces). The loading can be pushed to a kernel module in the future.
https://github.com/hsaliak/sacre_bleu very rough around the edges, but it works. In the past there were apps that either behaved well, or had malicious intent, but with these LLM backed apps, you are going to see apps that want to behave well, but cannot guarantee it. We are going to see a lot of experimentation in this space until the UX settles!
GCP Next is Apr 22-24. Hope this continues to live afer that.