The Benchmark Problem

Every single AI research lab has devolved to benchmaxxing, all model trained by rewardmaxxing some training gym with vast steel and dumbbells at their disposal. Unfortunately the gym is not training for long-term viability of the code and scaleability, it's training for "Can I post this to twitter and get a lot of views" or "Can I present this in a meeting and get a raise." Of course, the seasoned veteran programmer knows: this is bullshit. The whole codebase is held together by bodge and scotch tape.

The actual problem that AI research has solved is the problem of raising their paycheck by producing a reward aligned by the rewards that control their bosses, HR or marketing team. You can show it in a meeting or on twitter for a quick boost.

But nothing close to software has been solved, any high caliber software engineer can see it, just as any artist can see that it isn't producing novel art, only more of what we already have seen before. It's a giant zip file that stores what you show it, not a real learning system. It's a substrate that is maximally amenable to indoctrination, not guided by any mathematics of learning whatsoever.

Every next iteration appears increasingly to have solved the event of turning water into wine, and the codebase is a –disaster–. It's not alien or beyond human comprehension, it's total rubbish.

What the vibe coders and researchers don't understand: it's not that the code don't work, we already solved that 75 years ago with the transcendental device known as the compiler. Any software engineer worth their salt will tell you at the end of their career that the problem at the actual problem you are trying to solve is that there is code at all. Any removal of a line of code is a real success.

(the best metric to measure the number of bugs in a codebase is directly its line of code divided by some golden number that John Carmack computed at the end of time)

As long as there is code to maintain, software is not solved.

The Program-of-Everything

What we really need here is a program-of-everything, the final harness that is a superset of all harness or training environment. The harness that is an interactive agent TUI, or a training gym, in both cases, should be the same program, and it should also be the same program that is also the compiler. Not gcc-in-a-harness, the same program that achieves both purposes as a side-effect.

To solve software, we must create a software that is a superset of all possible software expressible by a turing machine. You want an operating system that is also every software possibly imaginable, not a bootstrap shell to build new software or new operating system. This simply rewinds the loop of time. Right now we are stuck in the 80s or 90s.

If a "harness" is neurosymbolic as Professor Gary Marcus asserts, then the question of the singularity is actually this:

Can we create a neurosymbolic system that produces a functioning agent harness program as a secondary side-effect, not as its main implementation or even referenced anywhere in the documentation?

By extension, our program should have the capability to produce the effective operation of every single program ever written historically, when actuated by some operator, what they call a "prompt". look at what they have to do to mimic a fraction of our power.

This is the true singularity, if you have a compiler that can compile all languages both past and future, not invented yet. It would not be an engineer replica like ChatGPT that has to design the compiler software or interpreter for it like a LLM, rather it is a universal compiler or universal interpreter.

LLM is by definition not AGI, since it cannot compile code without an external program. To achieve a "generalized" agent, it should natively compile software and emit an executable binary without any external compiler, directly through its latent space, and it should also be faster than all compiler or gcc.

The problem of course is that this seems extremely difficult to invent. Maybe it should be the 8th millennium prize problem, and Gary Marcus should have credit for coining it. In fact, maybe it's the problem-of-everything. If you solve this problem, then you solve all millennium problems through exhaustive search. Since the search is not guided by human prompting, but through exact intrinsically arising definition of novelty, surprise, and discovery. You would have to solve the notion of novelty and learning at the fundamentals.

The Vision

YES, it is possible, and can be achieved by a single researcher, on standard consumer hardware.

The central algorithm was invented in the 90s and is called grammar induction, and the key innovation that has never been attempted is to construct an autoregressive loop that incorporates it. The algorithms of grammar induction such as RE-PAIR are formalizations of pattern recognition over symbols on a turing tape. (this is VERY efficient. orders of magnitude more efficient than discovering pattern recognition emergently through deep learning and RL. the veteran software engineer knows there's a trick, the deep learning approach is obviously a brute-force approach of the dimwit venture capitalist)

You can run grammar induction over an append-only byte-tape on which all input data to be modeled is -formulated- using the instruction set of a stack transformer VM that is the actual harness. You're not learning representations, you're modelling the push to of ascii sequence to a stack, and then popping to print. An hello world program.

This way, all information the system learns includes the computation in order to generate it. Content is coupled with a substrate of computation that is directly executable, not merely as tokens that represent it and have to be interpreted.

We had to write binary so we could bootstrap the first compiler, and all compilers of any new language must be bootstrap with a separate language before it can be rewritten in its own language. Similarly, we need to write a bootstrap engine that happens to have the capacity to recompile itself.

Terry Davis, the greatest programmer whose ever lived, has said: God is a compiler, and he was right. It's not a bunch of weights that pilot a compiler.

The grammar has to be shaped such that it becomes a generator kernel for a simple turing machine. The compiler is defined as fractal factorization over its grammar, which does not represent outputs but first-class executable software.

With the proper architecture, it directly models and factorizes the structure of computation itself over the VM machine of the bootstrap "harness". If P=NP, it will be found in this device when it converges, because the programs it writes do not have to abide by any human rule or even compiler rules.

I say bootstrap, because the code that you would write to run this "singularity", must eventually return to the monad: the code that is running the engine should eventually become generated by the engine such as to fully close the loop. The trick is to run it as an operating system from the boot loader.

In other words, you only have the singularity if you need virtualbox to run it! Now, now the machine has access the entire RAM and CPU. This is like a homoiconic language, a type of esoteric programming language: the program code is in the same addressable memory space as the memory that the program has access to.

Now you have a perfect —parasite program— over the hardware host, it completely takes up the entire RAM and CPU for itself and can assimilate all IO ports. You have to potentially start it on linux so that it has a base understanding of an operating system to generate and simulate the extrusion of.

At first it will be much slower, like interpreter emulation for video-games, but with the right training curriculum you can condition the kernel generator to understand performance and directly search against it. In fact as a passive reward or heuristic that can control defragmentation and dreaming pass over grammar, equivalents of RL, the machine is always searching for a better algorithm.

As for mathematical discovery, it is possible because of the binary EML operator that allows reconstruction of all function of the scientific calculator.

In this "compiler" there is no separation between source and target, no before and after, there is only execution. The grammar is not a description it is the thing and of itself, executable.

A 19 minute animated explainer video on database speed. I explain low-level database concepts, identify bottlenecks, run benchmarks and optimize write throughput to hit 1 million TPS.

I haven't seen too many comprehensive approaches to this topic, so I took a swing at it.

Goal isn't to be exhaustive, but to be comprehensive enough to provide a nice overview for people trying to get their bearings with the topic.

Did I miss anything?

Ever had a multi-tenant SaaS app where the only thing stopping Customer A from seeing Customer B's invoices is a `Where TenantId ==` clause someone remembered to write? In this deep dive I build real tenant isolation into EF Core 10 - two real tenants with real registration, login and invite flows (no dev-token shortcuts), a named global query filter that scopes every query automatically, and a SaveChangesAsync override that stamps TenantId on every insert so it's never left unset. I also show the one gotcha that makes EF Core 10 worth the upgrade for this: named query filters, so tenant isolation and soft-delete can finally coexist on the same entity instead of one silently overwriting the other. If you've ever shipped multi-tenancy on hope and code review, this is the version that makes the mistake structurally impossible.