The code generator that wrote itself: OpenACR, fifteen years before the AI coding boom
In-memory data structures look like something you should be able to describe rather than write. I have a set of these and a set of those, with a cross-reference between them. Here I want a linked list, there a hash table, over there a binary heap. That is a declaration, not an algorithm.
Alexei Lebedev wanted exactly that while building reconfigurable exchanges with custom indexing. He tried tool after tool over the years and none of them got there. So he wrote his own, and called it OpenACR.
Fifteen years later, OpenACR is the heart of AlgoX2. It is also, as it turns out, a very good fit for the age of language models.
Tables in, C++ out
OpenACR is built on plain-text relational tables. You describe your structures, their fields and the relationships between them as rows of ASCII. A tool reads those tables and generates the C++: in-memory data structures with cascade deletes and automatic incremental group-bys.
The specific choices stay yours. One structure is indexed five different ways; another is not indexed at all; a third is never deleted, so it gets a simplified allocator. But every one of them is a customisation of the same generic description, and the code for each is generated.
The generator that generated itself
Once OpenACR could generate a little code, a question followed. The generator was full of template classes and hand-written code, but weren’t those just a cross-reference between structures and fields too?
So the generator went into its own tables. Running it produced the code for the generator. The hand-written version was deleted and the generated one took its place.
Then the crank kept turning. Around 80% of the hand-written code disappeared, because it turned out to be customisable boilerplate: structurally generic, even where every instance was custom. The descriptions are written by hand, and everything else comes out of the generator.
Faster than hand-written code
There is a learning curve, but once you are over it there is no going back. Generated code is faster than hand-written C++, for a simple reason: the generator is not afraid to regenerate another million lines.
No person has the time or the patience to write and debug a custom structure for every application. So hand-written code settles for general structures that are good enough. A generator can produce the custom structure every time, including the ones nobody would otherwise give the time of day.
Why there are (almost) no bugs
Generated code is not literally bug-free, but it comes close, and the reason is entropy. The generator reads a description and runs the same algorithm to produce code. It runs that algorithm hundreds or thousands of times a day, nothing in it is new, and it has been running for fifteen years.
Compare that with what a bug actually is. The computer does what it is told. A bug is a misunderstanding in your head: you thought you specified X, you specified Y, and the computer did Y. We call it a bug because we would rather not take the blame.
If you do any action at all, you’ll have a 5% error rate. Say you sort cards into red and black. Every once in a while, your hand just tosses the card into the wrong pile, and there’s nothing you can do about it. It’s the same with code, but the typos are a lot more prominent, and the whole thing just doesn’t work if you make one.
That is why programming has always selected for people who are extremely detail-oriented. A generator removes most of those chances to slip. OpenACR has been proven at scale: about five million lines of code were generated with it for NYSE’s Pillar trading platform. If people had written five million lines by hand, how many errors would still be hiding in them?
One context window for the whole platform
Language models changed how OpenACR is used, and made it more valuable. An LLM working on AlgoX2 does not read the generated code. It reads the compressed version: the tables.
One line of table becomes roughly fifteen lines of generated code. That makes the effective context window about fifteen million tokens. To Claude, the whole platform fits in one context window, so it can be turned this way and that and asked to do different things across all of it.
Working this way, Alexei mostly reads Claude’s description of what it did rather than the code. Occasionally he looks, finds a nested loop that runs in n-squared time, and tells Claude to record in its CLAUDE.md that it must never write one.
The gun, not the sword
The same shift changes who can build serious systems. OpenACR and Claude together are one of the reasons a relatively small team could build a data streaming operating system. They also mean AlgoX2 can hire young, talented developers who don’t know C++ and still have them contribute. Before, the hiring pool was a narrow set of people who are very hard to find.
A friend of Alexei’s compared LLMs to the invention of the gun. Before guns, a samurai spent ten years learning to draw and sheathe a sword without cutting their own hand. After, the skill was to aim. It was a great equaliser.
The engineer who succeeds with an LLM is the one who aims well: someone who knows exactly what they are trying to achieve, has an aesthetic sense, doesn’t accept nonsense, and gives clear direction. Before, the ideal programmer was extremely detail-oriented, because bugs were so expensive. Now many more people can succeed.
A second life
Code written by vibe-coding is full of bugs, and it is hard to understand what is going on without understanding what you are doing. A layer like OpenACR helps. Writing a description that a compiler turns into checked, generated code is a lot safer than generating that code directly.
OpenACR is open source, updated once or twice a year, and looking for contributors. When someone asks for Mac support, the answer is: of course, and you should be the first to build it. Everything is a Stream shows where it sits in AlgoX2, and the code is on GitHub.
Watch the video
Want more context on the platform? Read about the product, or get in touch with us on the contact page.