I think the whole industry is heading in the wrong direction. And it really frustrates me that most LLM coding agents are based on excessive delegation (or at least promoting it), which for me, is what causes the difficulty in entering the flow state. (I think the slow generation speed of SOTA frontier model labs also contributes to it, 30 seconds to generate something simple is a lot of time, but that's a different discussion)
We must kill excessive delegation. Our LLM coding tools should be built incapable of performing it.
Imagine if you have a coding agent where if you tell it "create a simple Todo app" it will fail telling you "simple Todo app is undefined", requiring to provide a more comprehensive descriptive prompt of what you want, then, this longer prompt becomes where your flow state functions, you are describing your edits and code in a more fluid way but still in text, and your focus becomes on this description/specification that you'll feed to the LLM.
(can't edit the above but for future references, this doesn't seem to be by Edward Fredkin, and I couldn't find "The intelligent machine" as the article states
Still, this is a pre-LLM era copy-pasta it seems, and the idea within it is still relevant)
Predicting "America" in "The United States of ..." Is a different task from predicting the whole sentence.
So the small model is laying the blocks, and the bigger model would be cementing them in place or kicking them down. The bigger model's course correction is what keeps the smaller models predictions relatively on track
"Write a function that takes a string parameter (Todo) and saves it into a text file with the name <current date time (as a Unix epoch)>.txt, and if already present, append to it to the file instead"
The probability distribution for the potential output is different, and it's more limited in the second case perhaps.
Besides, even the "deterministic" systems the author is referring to, are not fully deterministic. They are "deterministic" if we ignore a certain threshold of randomness that could afflict the system. Yes perhaps this threshold is higher when using LLMs, but even when using LLMs, not all inputs share the same level of indeterministic output
"In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.""
Also what people forget, even read access alone can be used to communicate with an attacker.
Assume locally i know a read only agent (running on account A) is reading a specific file from user B. Assume it has access to a secret that user B cannot observe. By prompt injection, you can have the read only agent encode the secret as "read" pattern that user B can decode by looking at file access times.
(You can think of fetch requests and the likes for more involved cases)
So read only, while helpful, does not innately prevent communication with an attacker
I've been trying to work on a new LLM code editor that does just that. When you instruct it to do something, it will evaluate your request, try to analyze the action part of it, the object, subject, etc, and map them to existing symbols in your codebase or, to expected to be created symbols. If all maps, it proceeds. If the map is incomplete, it errors out stating that your statement contained unresolvable ambiguity
I think there is a real benefit here, and it might be the actual next beneficial grounded AI sustainable use in programming. Since I the current "Claude code and friends" are but a state of drunkenness we fell into after the advent of this new technology, but it will prove, with time, that this is not a sustainable approach
My main gripe with tmux is the nested use case (tmux session on my local machine, in which I ssh to another machine, only to tmux attach within the remote machine too). Is there a terminal multiplexer/session daemon that supports nested sessions out of the box with ease?
Btw seems like NullClaw is facing the same issue. Currently the 1st result on Google is a shady website with popups, claiming to be NullClaw's (while the actual site (nullclaw.io) is not coming up
I'm yet to find a satisfying vim AI integration. I want something that blends into my vim workflow, and does not require me to switch Windows and copy paste or reload my open buffers after AI agents edit my code.
For instance I would love for it to seamlessly melt into a "highlight comments/pseudo code" -> some keybind, then AI would expand those to actual code for instance, or I don't know.. but something not like what we have currently
I found this to be inaccurate, I can run OSS GPT 120B (4 bit quant) on my 5090 and 64 ram system with around 40 t/s. Yet here the site claims it won't work
I think the whole industry is heading in the wrong direction. And it really frustrates me that most LLM coding agents are based on excessive delegation (or at least promoting it), which for me, is what causes the difficulty in entering the flow state. (I think the slow generation speed of SOTA frontier model labs also contributes to it, 30 seconds to generate something simple is a lot of time, but that's a different discussion)
We must kill excessive delegation. Our LLM coding tools should be built incapable of performing it.
Imagine if you have a coding agent where if you tell it "create a simple Todo app" it will fail telling you "simple Todo app is undefined", requiring to provide a more comprehensive descriptive prompt of what you want, then, this longer prompt becomes where your flow state functions, you are describing your edits and code in a more fluid way but still in text, and your focus becomes on this description/specification that you'll feed to the LLM.