I can't even imagine how many joules would be used per function call! As an experiment, it's kind of cool. I'm kind of at a loss to what useful software you'd build with it though. Surely once you've run the AI function once it would be much simpler to cache the resulting code than repeatedly re-generate it? Can anyone think of any uses for this?
> run the AI function once it would be much simpler to cache the resulting code than repeatedly re-generate it? Surely, you'll run a function that does an AI call to cache the resulting code.
Software 3.1? – AI Functions
31–40 of 61 posts
Re: Software 3.1? – AI Functions
#32What is the BENEFIT of all this?
Let's use Blockchain instead of a database - because we can.
Let's create a maze of microservices - because we can.
Let's make every function a lambda function - because we can.
Let's make AI write code, run it, verify it, fix it, then run it again - because we can.
Let's burn untold amounts of energy to do simple things - because we can.
Re: Software 3.1? – AI Functions
#33I'm normally pessimistic about LLMs but I'll be the contrarian here and suggest there's actually a potential use case for what TFA proposes and it's programmatic/procedural generation for large game worlds.
Re: Software 3.1? – AI Functions
#34I can't even imagine how many joules would be used per function call! As an experiment, it's kind of cool. I'm kind of at a loss to what useful software you'd build with it though. Surely once you've run the AI function once it would be much simpler to cache the resulting code than repeatedly re-generate it? Can anyone think of any uses for this?
[0] e.g. something like the below which I expect to use maybe a dozen times total.
Main routine: In folder X are a bunch of ROM files (iso, bin, etc) and a JSON file with game metadata for each. Look for missing entries, and call [subroutine] once per file (can be called in parallel). When done, summarise the results (successes/failures) based on the now updated metadata.
Subroutine: (...) update XYZ, use metacritic to find metadata, fall back to Google.
Re: Software 3.1? – AI Functions
#35This has big "let's do this because we can" energy. What is the BENEFIT of all this? Let's use Blockchain instead of a database - because we can. Let's create a maze of microservices - because we can. Let's make every function a lambda function - because we can. Let's make AI write code, run it, verify it, fix it, then run it again - because we can. Let's burn untold amounts of energy to do simple things - because we…
Re: Software 3.1? – AI Functions
#36Re: Software 3.1? – AI Functions
#37I'm normally pessimistic about LLMs but I'll be the contrarian here and suggest there's actually a potential use case for what TFA proposes and it's programmatic/procedural generation for large game worlds.
There is a use for everything. The problem is, people will try to use this to create CRUD apps for no goddamned reason.
Eventually, perhaps. I've yet to see a use case for blockchains that isn't merely a worse facsimile of something already existing.
But the electron was useless when it was discovered, so maybe one day
Re: Software 3.1? – AI Functions
#38This has big "let's do this because we can" energy. What is the BENEFIT of all this? Let's use Blockchain instead of a database - because we can. Let's create a maze of microservices - because we can. Let's make every function a lambda function - because we can. Let's make AI write code, run it, verify it, fix it, then run it again - because we can. Let's burn untold amounts of energy to do simple things - because we…
Re: Software 3.1? – AI Functions
#39I'd like to see this with a proper local "instruction cache." It might even be fun that the first call generates python (or other langauge), and then subsequent calls go through it. This "otpimized" or "compiled" natural langauge is "LLMJitted" into python. With interesting tooling, you could then click on the implementation and see the generated cod, a bit like looking at the generated asssembly. Usually you'd just…