I know it is overused on tweeter - but all this really seems to be about status. Like Robin Hanson said - people read stuff because it seems prestigious.
IMHO training weights has peaked and now it is time for a training paradigm for prompts and code. We don't have the gradient descent here - but I think it can be more sample efficient because causal theories can be better than just correlations.
I am working on a unified theory in https://zby.github.io/commonplace/ - it is all agent edited so it might be hard to read, but hopefully we are catching most logical errors. Some day the llm prose will improve.
Is there any reason to think that training weights has peaked rather than is accelerating? It feels like now they are increasingly able to pick some low hanging fruit by using the models in order to improve themselves and test optimizations.
I think it is now or close to now - and not because there is no more to be gained - but rather because it is now clear that you can gain more with the right agent environment.
But benchmark saturation is also something to account for.
It's a pity that the Perl6 saga killed the new regex ideas - I wish the raku regexes were adopted elsewhere (like the Perl5 regexes were): https://docs.raku.org/language/regexes
If I remember well, the starting point was that memory is only useful if it changes the system behaviour. There are many ideas of automatic 'tips' or 'rules' that are injected into the prompts so that the agent acts accordingly to some retained lesson. But there are many failure modes for this.
But maybe I'll need to revise the phrasing on that page and in instructions.
I believe there should be easy ways to move logic between prompts and code in a smooth ways. Moving from prompts to code is for getting deterministic, fast, well defined and cheap execution - the other way is when you want to quickly extend your system or when you want to relax a pre-condition (which is extending if you look into it deeply).
There are some inroads into this vision - but I haven't seen anything build directly for this (beside my own experiment).
I am not sure if this is sarcasm - but just in case - https://github.com/sshwarts/skillscript does not offer a unified namespace for functions and prompts (agents) like https://github.com/zby/llm-do (currently in suspended development).
There are now also the 'dynamic workflows' in Claude Code that are pretty interesting approach - they are like a compiled prompt in many aspects.
No sarcasm. In that thread we discussed recursive, interleaved application of code and prompt. No morphing, however.
Thanks for dynamic workflow pointer. I don’t know if I like JavaScript for workflow definitions tho. IMHO sshwarts has the right idea on severely constrained workflow definition language. I plan to look closer into ADK2 workflows as well.
I’m not saying anyone did what you are doing, I’m saying multiple pieces are converging on that, at least in my imagination.
It is all binary, all the way down. Code is text that passes the compiler's checks. Human language is text that has a really ambiguous compiler. And all text is still binary in the computer.
If you think about it, the transformers architecture was created to solve language translation. It works well for human language to code and other way around, already!
It is interesting to compare this to LLMs - they also have the bounded context that you can see as the analogue to our working memory. It can contain enormously more bits of information than the 4 things the article says is the capacity of our working memory - but the 4 things can probably be much more complex internally - they are more like 4 pointers probably.
But at some level context engineering is very similar to what this article talks about.
Hello, author here. Lovely comment, and yes: not just similar, but exactly what the article talks about. In the middle. Where it unironically talks about being lost in the middle. And it seems to have made its own point, on even the careful reader!
The feature I am waiting for in all of these editors is integrating 'red lining' as a channel for LLM input. This is the best interface for working on a text. https://www.roughdraft.md/ does the core idea pretty well - but is not well integrated with the rest (browsing, etc).
If the action is decided by code based on metadata - then what is really the LLM task? And if you say that it is only the type of action that is decided by code - then this is maybe a mitigation - but the llm still can do a lot of harm. And also it is very limiting - using the llm to decide the action is very useful. This is different from SQL injection - where the action is determined by the code and the injection is really making a code parsing error.
It might still be the way to go - but calling it 'the real solution' is overselling it.
I believe it is the other way around: the LLM decides the type of action and the input to the action; the code validates the permission to act and the acceptability of the input. But, yes it is very different than SQL injection in that way.
reply