If you use a deterministic sampling strategy for the next token (e.g., always output the token with the highest probability) then a traditional LLM should be deterministic on the same hardware/software stack.
Wouldn't seeding the RNG used to pick the next token be more configurable? How would changing the hardware/other software make a difference to what comes out of the model?
Didn't someone back in the day write a library that let you import an arbitrary Python function from Github by name only? It obviously was meant as a joke, but with AIcolytes everywhere you can't really tell anymore...
Flask also started as an April 1st joke, in response to bottle.py but ever so slightly more sane. It gathered so much positive response, that mitsuhiko basically had to make it into a real thing, and later regretted the API choices (like global variables proxying per-request objects).
> Not suitable for production-critical code without review
Ah, dang it! I was about to deploy this to my clients... /s
Otherwise, interesting concept. Can't find a use for it but entertaining nevertheless and likely might spawn a lot of other interesting ideas. Good job!
you'd be surprised, but there's actually a bunch of problems you can solve with something like this, as long as you have a safe place to run the generated code
I was super interested in genetic programming for a long time. It is similarly non-deterministically generated.
The utility lies in having the proper framework for a fitness function (how to choose if the generated code is healthy or needs iterations). I used whether it threw any interpretation-time errors, run-time errors, and whether it passed all of the unit tests as a fitness function.
That said, I think programming will largely evolve into the senior programmer defining a strategy and LLM agents or an intern/junior dev implementing the tactics.
> That said, I think programming will largely evolve into the senior programmer defining a strategy and LLM agents or an intern/junior dev implementing the tactics.
That's basically what goog wants alphaevolve to be. Basically have domain experts give out tasks that "search a space of ideas" and come up with either novel things, improved algorithms or limits / constraints on the problem space. They say that they imagine a world where you "give it some tasks", come back later, and check on what it has produced.
As long as you can have a definition of a broad idea and some quantifiable way to sort results, this might work.
> The utility lies in having the proper framework for a fitness function
Exactly. As always the challenge is (1) deciding what the computer should do, (2) telling the computer to do it, and (3) verifying the computer did what you meant. A perfect fitness function is a perfect specification is a perfect program.
This is amazing, yet frightening because I'm sure someone will actually attempt to use it. It's like vibe coding on steroids.
- Each time you import a module, the LLM generates fresh code
- You get more varied and often funnier results due to LLM hallucinations
- The same import might produce different implementations across runs
There are a few thresholds of usefulness for this. Right now it’s a gimmick. I can see a world in a few years or maybe decades in which we almost never look at the code just like today we almost never look at compiled bytecode or assembly.
There's not much of a world in which we don't check up and verify what humans are doing to some degree periodically. Non-deterministic behavior will never be trusted by default, as it's simply not trustable. As machines become more non-deterministic, we're going to start feeling about them in similar ways we already feel about other such processes.
> Non-deterministic behavior will never be trusted by default, as it's simply not trustable.
Never is a long time...
If you have a task that is easily benchmarkable (i.e. matrix multiplication or algorithm speedup) you can totally "trust" that a system can non-deterministically work the problem until the results are "better" (speed, memory, etc).
I agree. At first the problems that you try to solve need to be verifiable.
But there's progress on many fronts on this. There's been increased interest in provers (natural language to lean for example). There's also been progress in LLM-as-a-judge on open-ish problems. And it seems that RL can help with extracting step rewards from sparse rewards domains.
You will always get much, much, MUCH better performance from something that looks like assembler code than from having an LLM do everything. So I think the model of "AIs build something that looks recognizably like code" is going to continue indefinitely, and that code is generally going to be more deterministic than an AI will be.
I'm not saying nothing will change. AIs may be constantly writing their own code for themselves internally in a much more fluid mixed environment, AIs may be writing into AI-specific languages built for their own quirks and preferences that make it harder for humans to follow than when AIs work in relatively human stacks, etc. I'm just saying, the concept of "code" that we could review is definitely going to stick around indefinitely, because the performance gains and reduction in resource usage are always going to be enormous. Even AIs that want to review AI work will want to review the generated and executing code, not the other AIs themselves.
AIs will always be nondeterministic by their nature (because even if you run them in some deterministic mode, you will not be able to predict their exact results anyhow, which is in practice non-determinism), but non-AI code could conceivably actually get better and more deterministic, depending on how AI software engineering ethos develop.
There was a story written by (IRRC?) Stanisław Lem: technology went to absurd level of complexity, yet was so important to daily lives that the species' survival depended on it. The knowledge of how everything worked has been long forgotten; the maintainers would occasionally fix something by applying duct tape or prayers.
Sufficiently advanced technology is indistinguishable from magic.
One example, arr.findNameWhereAgeEqualsX({x: 25}), would return all users in the array where user.age == 25.
Not based on LLMs, though. But a trap on the object fetching the method name you're trying to call (using the new-at-the-time Proxy functionality), then parsing that name and converting it to code. Deterministic, but based on rules.
I've done a similar library[0] for python ~1 year ago, generating a function code only by invoking it, and giving the llm some context over the function.
Apart from the fun that I got out of it, it's been there doing nothing :D
92 comments
[ 2.7 ms ] story [ 154 ms ] threadSuper fun idea though, I love the concept. But I’m getting the chills imagining the havoc this could cause
Yes, and the one thing that was asked about was "deterministic" not "stable to small perturbations in the input.
Sure, that would work.
> How would changing the hardware/other software make a difference to what comes out of the model?
Floating point arithmetic is not entirely consistent between different GPUs/TPUs/operating systems.
I've actually done this, setting aside a virtual machine specifically for the purpose, trying to move a step towards a full-blown AI agent.
I think there was another, later retrospective? Can't find it now.
Like self-driving cars and human drivers, there will be a point in the future when LLM-generated code is less buggy than human-generated code.
Ah, dang it! I was about to deploy this to my clients... /s
Otherwise, interesting concept. Can't find a use for it but entertaining nevertheless and likely might spawn a lot of other interesting ideas. Good job!
The utility lies in having the proper framework for a fitness function (how to choose if the generated code is healthy or needs iterations). I used whether it threw any interpretation-time errors, run-time errors, and whether it passed all of the unit tests as a fitness function.
That said, I think programming will largely evolve into the senior programmer defining a strategy and LLM agents or an intern/junior dev implementing the tactics.
That's basically what goog wants alphaevolve to be. Basically have domain experts give out tasks that "search a space of ideas" and come up with either novel things, improved algorithms or limits / constraints on the problem space. They say that they imagine a world where you "give it some tasks", come back later, and check on what it has produced.
As long as you can have a definition of a broad idea and some quantifiable way to sort results, this might work.
Exactly. As always the challenge is (1) deciding what the computer should do, (2) telling the computer to do it, and (3) verifying the computer did what you meant. A perfect fitness function is a perfect specification is a perfect program.
I love it
As a joke, that doesn't feel quite so far-fetched these days. (https://xkcd.com/353/)
Never is a long time...
If you have a task that is easily benchmarkable (i.e. matrix multiplication or algorithm speedup) you can totally "trust" that a system can non-deterministically work the problem until the results are "better" (speed, memory, etc).
But there's progress on many fronts on this. There's been increased interest in provers (natural language to lean for example). There's also been progress in LLM-as-a-judge on open-ish problems. And it seems that RL can help with extracting step rewards from sparse rewards domains.
I'm not saying nothing will change. AIs may be constantly writing their own code for themselves internally in a much more fluid mixed environment, AIs may be writing into AI-specific languages built for their own quirks and preferences that make it harder for humans to follow than when AIs work in relatively human stacks, etc. I'm just saying, the concept of "code" that we could review is definitely going to stick around indefinitely, because the performance gains and reduction in resource usage are always going to be enormous. Even AIs that want to review AI work will want to review the generated and executing code, not the other AIs themselves.
AIs will always be nondeterministic by their nature (because even if you run them in some deterministic mode, you will not be able to predict their exact results anyhow, which is in practice non-determinism), but non-AI code could conceivably actually get better and more deterministic, depending on how AI software engineering ethos develop.
It’s like the strong form of self-modifying code.
Sufficiently advanced technology is indistinguishable from magic.
We're basically headed in that direction.
[1] https://archive.org/details/1958-02_IF/page/4/mode/2up?view=...
"fuck, it's python!" *throws it in the garbage*
https://jfrog.com/blog/leaked-pypi-secret-token-revealed-in-...
One example, arr.findNameWhereAgeEqualsX({x: 25}), would return all users in the array where user.age == 25.
Not based on LLMs, though. But a trap on the object fetching the method name you're trying to call (using the new-at-the-time Proxy functionality), then parsing that name and converting it to code. Deterministic, but based on rules.
Apart from the fun that I got out of it, it's been there doing nothing :D
[0]: https://github.com/lucamattiazzi/magic_top_hat
it will be WASM-containerized in the future, but still