It's kind of insane that one of OpenAI's internal test tasks is now "reimplement SQLite from scratch, preserving binary compatibility with existing database files".
Have they released this publicly? This seems about on the same order of difficulty to anthropic’s C compiler project, which ultimately failed. I’m surprised if they can do SQLite they wouldn’t show up Anthropic with a public working C compiler.
There's nothing insane about writing a de/serializer for an open source format with tests telling you every time you get it wrong to fix in a loop. Insane would be if they were willing to entrust critical production data to their vibecoded replacements (in multiple ways).
By "low-resource" they seem to mean "not much training data". I wonder if the fix for this was generic generalization ability, or just making a lot of training data for the specific languages involved. This distinction matters a lot for the question of whether new programming languages can be developed without having LLMs be bad at them.
So, Lingo is the programming language for Director / Shockwave. Most LLMs know very little about it, since its been MIA for a while, however, there's a niche community of people reverse engineering games and the entire Shockwave runtime for years now, and LLMs are accelerating these efforts.
In fact, because of these niche Shockwave communities, and they've admitted to it, the Habbo Origins client was able to be made. That effort was spearheaded by a player who reverse engineered their backend for years, and eventually built up a decompiler for Shockwave, and made their own game client run as a stand-alone EXE (Projector Mode for Shockwave iirc) which is what Origins did.
More recently, a project named "Shockless" emerged that took the Shockwave client for Habbo Origins, and rebuilt it in JS w/ PixiJS (I think?) in order to be a more special-purpose Shockwave runtime. Some months later (this month I think), Sulake released Keystone a new Origins client, essentially doing the same thing, itself coded in C++ but it looks like it took a very closely similar approach. Really fascinating seeing LLMs push reverse engineering communities forward to help preserve old tech and games, and in some cases, niche games forward from the grave.
I think the frontier LLMs have finally gotten to the point they can sort of pick up the syntax on the fly.
I made my own .NET based language using Opus 4.6 and it knew how to write code for it, since the rules were in the context window. I havent gone back to that project, since I've been trying to build other more ambitious projects, but its impressive how much LLMs can pull off as of early this year.
It is funny to me they mention Visual Basic, I've been on and off experimenting with rebuilding the VB6 IDE and eventually its compiler with a modern runtime using Claude, I've got a good chunk of the IDE, and I can load forms, I can even call VB6.exe to compile if you have it installed, but I had to pause since my old college copy of VB6 is kinda busted (I misconfigured something somewhere and it keeps crashing when I open a project).
I thought LLMs had been good at this for a while? I vibed a language out and the LLM could write in it pretty well. I even got Qwen 3.8 to write it (though it was pretty slow, it managed to get it done)
It is such a ridiculously cool thing that we're reaching an era where the programming language you chose is as temporary a choice as the name of a variable.
As it should be. Foundational principles between languages are the same, I don’t understand why positions are gatekeeped based on implementation trivia.
How can that signal anything other than improper planning. You prefer a changing codebase over something that has evolved and is being tested over a long period of time?
It can also signal very good planning. If a program is properly specified and all the business logic correct then implementation language is basically as afterthought.
I'm reminded of the software for the Gemini spacecraft. Does it still exist? We don't have any assembly or machine code. But much like today in the '60s the designers of the flight software, considered the assembly output to be an intermediate stage - a kind of temporary mapping from the real program. The real program was designed in "Math Flow 7" - a visual flowchart language for expressing logic. We still have the charts. Does that mean we still have the software? Is the set of charts the software?
This is equivalent to arguing that tech debt signals poor planning
I would much prefer it to be easy to change a codebase and for people to make lots of changes to their codebase than for people to stick with whatever they built up front
Except for platform constraints, like needing to use JS or Swift/Kotlin, why would I use anything else than Rust? I can’t even properly read it, but the agents somehow make it work well and the code doesn’t look particularly cluttered; and it’s so fast.
Because you don’t have an infrastructure to test all platforms and want to actually execute your code instead of waiting a decade until compiler is done?
> COBOL supports more than 40% of online banking systems, 80% of in-person credit card transactions and 95% of ATM transactions, while Fortran is used in weather forecasting and nuclear reactor safety analysis.
Can we not vibe code foundational bank infrastructure and nuclear reactor safety software? Pretty please?
Like all software, vibe coding is not the hard part. Maintaining it is. I'm sure there there 100 times the number of people wanting to vibe code this in Rust vs wanting to maintain someone else's vibe coded Rust. So, usually the natural state is keep running the show as-is until it is the next guy's problem.
I would not be surprised if a much larger volume of Clojure source code is in publicly-visible repositories. I’ve not met too many COBOL or Fortran hobbyists.
It's kind of insane that one of OpenAI's internal test tasks is now "reimplement SQLite from scratch, preserving binary compatibility with existing database files".
Have they released this publicly? This seems about on the same order of difficulty to anthropic’s C compiler project, which ultimately failed. I’m surprised if they can do SQLite they wouldn’t show up Anthropic with a public working C compiler.
There's nothing insane about writing a de/serializer for an open source format with tests telling you every time you get it wrong to fix in a loop. Insane would be if they were willing to entrust critical production data to their vibecoded replacements (in multiple ways).
And they do it in powershell
And if you thought that was ridiculous, consider that the "best" implementation is the SQL database it wrote in PHP.
Isn’t powershell just a C# (.Net) with an ugly syntax?
By "low-resource" they seem to mean "not much training data". I wonder if the fix for this was generic generalization ability, or just making a lot of training data for the specific languages involved. This distinction matters a lot for the question of whether new programming languages can be developed without having LLMs be bad at them.
So, Lingo is the programming language for Director / Shockwave. Most LLMs know very little about it, since its been MIA for a while, however, there's a niche community of people reverse engineering games and the entire Shockwave runtime for years now, and LLMs are accelerating these efforts.
In fact, because of these niche Shockwave communities, and they've admitted to it, the Habbo Origins client was able to be made. That effort was spearheaded by a player who reverse engineered their backend for years, and eventually built up a decompiler for Shockwave, and made their own game client run as a stand-alone EXE (Projector Mode for Shockwave iirc) which is what Origins did.
More recently, a project named "Shockless" emerged that took the Shockwave client for Habbo Origins, and rebuilt it in JS w/ PixiJS (I think?) in order to be a more special-purpose Shockwave runtime. Some months later (this month I think), Sulake released Keystone a new Origins client, essentially doing the same thing, itself coded in C++ but it looks like it took a very closely similar approach. Really fascinating seeing LLMs push reverse engineering communities forward to help preserve old tech and games, and in some cases, niche games forward from the grave.
I think the frontier LLMs have finally gotten to the point they can sort of pick up the syntax on the fly.
I made my own .NET based language using Opus 4.6 and it knew how to write code for it, since the rules were in the context window. I havent gone back to that project, since I've been trying to build other more ambitious projects, but its impressive how much LLMs can pull off as of early this year.
It is funny to me they mention Visual Basic, I've been on and off experimenting with rebuilding the VB6 IDE and eventually its compiler with a modern runtime using Claude, I've got a good chunk of the IDE, and I can load forms, I can even call VB6.exe to compile if you have it installed, but I had to pause since my old college copy of VB6 is kinda busted (I misconfigured something somewhere and it keeps crashing when I open a project).
I thought LLMs had been good at this for a while? I vibed a language out and the LLM could write in it pretty well. I even got Qwen 3.8 to write it (though it was pretty slow, it managed to get it done)
Yeah GPT and Claude both write my language really well[1]. GLM and Kimi did OK as well, but I haven't tried Qwen.
[1] https://march-lang.org/
I need to see SQLite implemented in PowerShell
> Our second evaluation asks models to migrate COBOL programs to C++, Java, Kotlin, Python, or Rust while preserving what each program does.
Reminds me of how Wall Street Raider [0] just simulates the original code instead of rewriting it.
[0]: https://news.ycombinator.com/item?id=46954696
It is such a ridiculously cool thing that we're reaching an era where the programming language you chose is as temporary a choice as the name of a variable.
As it should be. Foundational principles between languages are the same, I don’t understand why positions are gatekeeped based on implementation trivia.
How can that signal anything other than improper planning. You prefer a changing codebase over something that has evolved and is being tested over a long period of time?
It can also signal very good planning. If a program is properly specified and all the business logic correct then implementation language is basically as afterthought.
I'm reminded of the software for the Gemini spacecraft. Does it still exist? We don't have any assembly or machine code. But much like today in the '60s the designers of the flight software, considered the assembly output to be an intermediate stage - a kind of temporary mapping from the real program. The real program was designed in "Math Flow 7" - a visual flowchart language for expressing logic. We still have the charts. Does that mean we still have the software? Is the set of charts the software?
This is equivalent to arguing that tech debt signals poor planning
I would much prefer it to be easy to change a codebase and for people to make lots of changes to their codebase than for people to stick with whatever they built up front
Yes, and, many many billions (trillions?) of dollars have been lost because the programming language couldn't be changed. Both things can be true.
New languages do in fact come out, and old languages get better, and old codebases are thing some people have to maintain.
That's.. not..
Except for platform constraints, like needing to use JS or Swift/Kotlin, why would I use anything else than Rust? I can’t even properly read it, but the agents somehow make it work well and the code doesn’t look particularly cluttered; and it’s so fast.
> why would I use anything else than Rust?
Because you don’t have an infrastructure to test all platforms and want to actually execute your code instead of waiting a decade until compiler is done?
I believe these words capture the zeitgeist of the 2020s.
+1 ! We might actually have to rethink what are costly decisions for the post Agentic world. Truly sci-fi stuff
> COBOL supports more than 40% of online banking systems, 80% of in-person credit card transactions and 95% of ATM transactions, while Fortran is used in weather forecasting and nuclear reactor safety analysis.
Can we not vibe code foundational bank infrastructure and nuclear reactor safety software? Pretty please?
Like all software, vibe coding is not the hard part. Maintaining it is. I'm sure there there 100 times the number of people wanting to vibe code this in Rust vs wanting to maintain someone else's vibe coded Rust. So, usually the natural state is keep running the show as-is until it is the next guy's problem.
It's a nuclear reactor, Michael. What's the worst that could happen? A meltdown?
Soon enough, it'll be 'Could we not entrust our safety critical systems to those emotional error prone humans? Pretty Please?'
I feel that we have to mention Stanislav Petrov now.
https://en.wikipedia.org/wiki/Stanislav_Petrov
You forgot flight computers.
OpenAI is already working on fixing F-35 avionics.
https://en.technosotnya.com/2026/10/openai-55-ai-models-f35....
those are ada. Don't worry, they'll forget about ada until the defense contractors pay them to remember
oh man ada. I wrote a terrible Ada compiler in university.
> Can we not vibe code foundational bank infrastructure and nucelear reactor safety software? Pretty please?
How can you power the "rogue" AI infrastructure and mistakenly funnel the funds needed for the operation otherwise?
Matrix needs energy, Matrix needs money.
VIBE CODE ALL THE TIHNGS! /s
Haskell got left out :(
And Clojure. Perhaps these aren't considered low resource. I had good results in Clojure over a year ago.
I would not be surprised if a much larger volume of Clojure source code is in publicly-visible repositories. I’ve not met too many COBOL or Fortran hobbyists.
Haskell community will be overjoyed.
"avoid success at all costs"
It's too good.