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).
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?
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.
The web devs tell me that fuckit's versioning scheme is confusing, and that I should use "Semitic Versioning" instead. So starting with fuckit version ה.ג.א, package versions will use Hebrew Numerals.
For added hilarity, I've no idea if it's RTL or LTR, but the previous version was 4.8.1, so I guess this is now 5.3.1. Presumably it's also impossible to have a zero component in a version.
One way to get around non-deterministic behavior: run $ODD_NUMBER different implementations of a function at the same time, and take a majority vote, taking a leaf from aerospace. After all, we can always trust the wisdom of the crowds, right?
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.
Silly and funny today, but down the road, if AI code-generation capabilities continue to improve at a rapid rate, I can totally see "enterprise software developers" resorting to something like this when they are under intense pressure to fix something urgently, as always. Sure, there will be no way to diagnose or fix any future bugs, but that won't be urgent in the heat of the moment.
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.
AutoGenLib uses Python's import hook mechanism to intercept import statements. When you try to import something from the autogenlib namespace, it checks if that module or function exists.
It reads the calling code to understand the context of the call. Builds a prompt to submit to the LLM. It only uses OpenAI.
It does not have search, yet.
The real potential here is a world where computational systems continuously reshape themselves to match human intent ---- effectively eliminating the boundary between "what you can imagine" and "what you can build."
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
There is still a computer involved, from an AI I expect it convinces me no program is needed and I should go walking in the forest instead. If anybody complains the AI will manage them by mail.
The library uses python dirty tricks, in this case using call stack, where the library looks for code from the user, gets the name of the file and reads it.
> 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!
Super fun idea though, I love the concept. But I’m getting the chills imagining the havoc this could cause