If USDT gets to a frozen list - that means that Tether does not need to comply with requests to convert it into USD? I guess this is very useful for Tether and the other stable coin emitters.
My model is about gaps - all ideas start with gaps. LLMs can fill in these gaps quickly - but some ideas are just bad - so the filling in does not improve them. Maybe it would be useful to treat that filling in as a kind of hallucination - the LLM trying to meed impossible requirements.
But on other cases the ideas are good and the LLMs fill in the gaps in the right way. It is a kind of skill to see when LLMs are hallucinating in the gaps. I use LLMs very extensively and I am adding checks to that should catch when the filling in is weak - but it is still not fully autonomous.
I also try to keep the llm-enhanced (or even fully llm-generated) content separate from my human writing - because it is true that the failure modes are different. But think LLM writing might be useful even if it is not consumed directly - it can enhance LLM answering your questions.
And apparently I am repeating here what I already have in my KB: https://zby.github.io/commonplace/theory/llm-generation-rela... - I borrowed the model from Boretti. The agent says that the note is much more careful and better developed than my comment above. You can judge yourself - but I think it does have many more details and hopefully most of these details are the good kind of filling in - but I guess it might be harder to read.
> Several times, Gemini 2.5 became convinced it needed to get tea, even though it
> was playing the older game. The tea task for FireRed was in its weights, so it
> poisoned its context. It spent hours trying to find or give the guard tea. Once
> it had been added to its to-do list, the model could not get past it.
I don't understand why this is called context poisoning when the information was in the weights
"iced tea" in context was a symptom - it might influence the downstream - but it is hard to establish that. The root problem was in weights - naming it 'context poisoning' is poisoning our reasoning context :)
My point is that calling it context poisoning is confusing because of two things. First - it is hard to establish how causal it is for the downstream. Second - cleaning the context would not fix it - because it would be poisoned on next round - you need active measures to fight it.
It is also a bit tongue in cheek - if you did not notice - because of course all of this can be explained if needed even if the name alone suggests something else.
On the next round, it's likely to correctly determine lemonade.
Hallucinations are usually outliers. So 1 in 10 times it gets confused and picks tea. Those 1 in 10 times end up with poisoned context.
The models are not deterministic by design. Identical inputs produce different outputs. So if you roll a bad output, it can poison your context. Flushing the context can easily fix the problem (unless like the in the pokemon harness, you roll over a brief of the previous context)
Yeah - it depends on the frequency. I think the other guy is right that when it happens with low frequency then calling it 'context poisoning' makes sense - because cleaning the context mostly fixes it. I still would be very careful about using it - because it might be interpreted as if the poisoned context was the root cause - it might be a cause for the downstream processing - but it itself is caused by something else - so it will recur.
There is now a general consensus that agents should retain everything - but project from that retained state into more useful representations for each type of work. Your approach is good for creating evidence for all of the decisions - but the retained records will probably be too detailed as the main source for agents working in bigger or older repos. We need multilayer approach for this - but I am still not sure what it should be.
It is all about definitions. Writing instructions for llms is a new activity and we can call it as we wish - but I like to think about it as a new type of programming language instead of thinking about it as something completely new, because many analogies do transfer and you can use them to reason about larger systems composed of prompts. It is after all a way to instruct a machine.
There are differences and the article highlights some of them - but there are difference between programming in a functional language and an imperative one, there are differences between programming for a RISC machine and a CISC machine, there a lots of different semantics that programming languages support. Now we have a language with underspecified semantics.
It is something completely new and we should be thinking about it as such. Analogies can help us here, and I think the analogy of "instructing a software team" is a much more useful analogy than "instructing a compiler" and the latter clouds our thinking.
IMHO instructing llms is programming - the analogy is not perfect but it is so close that it is quite useful. Programming is instructing a machine. We have now two types of programming - the traditional one that follows strict semantics and the new way of programming by prompting. The article still holds by showing the limitations of this new kind of programming.
I don't have strong opinions on when it's ok to use the work "programming" or not, but I think if you're using claude-code/pi/open-code/etc to produce something like a website or application, the "program" is the code the LLM outputs, not your prompt etc.
I don't think I'd want to call it "natural language programming" in the way Dijstra's implying here unless the prompt was the thing that was actively being executed/ran/whatever when someone loads your app or website.
I've seen some newer testing frameworks where you prompt for the outcome you want under a specific scenario. The first run is a LLM agent that figures out the steps but those steps are then used for recurring runs. If something fails, it goes back to the agent loop to see if it's an actual error.
This works well in e2e type tests where the test implementation might change but the customer experience hasn't.
So maybe there is a hybrid approach in our future.
Yeah, that's an interesting case study. It's pretty common practice to do something like llm-as-a-judge if your programming agentic systems.
I think those are different from pure "natural langyage programming" though because there's normally code you've written that's calling out to the LLM, so it's within the context of written code.
I think this, and lots of other comments are so interesting. There are a lot of different increasingly complex ways LLM outputs and coding are being tied together by people, that I hadn't really considered.
>So product managers have been programmers this whole time after all.
The entire point of the article was that human language isn't suitable for instructing computers, and you somehow make the leap to "humans instructing humans must be the same thing".
Reading comprehension must be a thing of the past at this point.
I don't know - all of these cache hit rate advocacy is kind of goodhearting. Cache hit rates are less important than the accuracy of LLM answers and people seem to forget about it. For example I've seen articles how sub-agents poison the cache. Sure you can fill up your context with irrelevant data to have high cache hit rate - but that degrades the LLM work - sub-agents are about providing the LLM with a clean context - just the information needed to do its job, no distraction.
All of the main providers now offer cache management that can work with sub-agents - but it was kind of bolted on - and all of them have different apis - so nobody uses them anyway.
I agree with you, accuracy of answers and the ability to complete task is the most important thing. But once a system can achieve a goal, throughput and cost come into consideration. In this regard, I think cache rates help make things both faster and cheaper.
RSI is about turning that extra computation into acceleration - that is applying the compute to the (useful_work / compute) factor - this is the recursive part.
It says much more than that. It says that all custom architectures and approaches are become irrelevant if compute increases, which was proven again by the large latent models recently solving RL tasks better than any classical RL technique.
