A model can maintain a port if you build the checker first. Most of the surprises were not where we expected.

The substrate underneath our current project is dense discrete mathematics. It is heavily scrutinized, tedious to build, tedious to tune, tedious to maintain. The system it supports has to run in many languages. The old answer to that problem is to hire port maintainers. The new answer is to throw a model at it. We took the new answer and watched what happened.

The bet is plain. Build a foundational example by hand. Let a model maintain the rest. This is the strategy and the lessons that followed.

The constraint

We are building a memory substrate that has to return the exact same answer on every machine. Not a similar answer. The same bytes. That requirement is what lets one machine trust what another one computed, and it is also why we could not keep building the normal way.

You cannot hand-maintain a byte-identical system in a dozen languages. The labor does not scale and the versions drift. Every language added is another implementation to keep in lockstep with the others as the design moves. For a system whose value depends on byte-for-byte agreement, drift is not a defect you fix later. It is the end of the product.

We made the call early. Two strong languages with multiplatform support and solid test harness, Swift and Rust, written and maintained by hand. Those two are the source of truth. Two on purpose, not one. Two independent implementations that agree on every byte are far stronger evidence the design is right than one implementation that only ever agrees with itself. Where the two agree, we freeze the result as a test case. That frozen set is the conformance checker.

Go is the tiebreaker for the rare case where Swift and Rust disagree and the cause is north pointing south. Rare. Inevitable.

Every other language is generated by a model and held to the same checker. If a model can write a correct port and keep it correct as the design moves, adding a language stops being a hiring decision and becomes a generation problem. The reference stays small enough to audit. The fan-out stays cheap.

What follows is what it actually took to earn that.

The loop

The method is plain. We ask a local coding model, a 30-billion-parameter model running 4-bit on a single Mac M5 Max — this is not work worthy of frontier AI spend — to write a port of one function. We run the checker. We keep what passes.

At a normal sampling temperature the model gets a hard function right about a third of the time and wrong the rest. We sample a few dozen times, throw out the failures, keep the passes. Then we fine-tune the model on those survivors, which are nothing more than its own correct answers with the checker’s stamp on them.

After a few hundred steps of that, the model writes the function correctly on the first try, temperature zero, every time. Stock model: fails. Same model trained on its own verified output: passes, deterministically.

We proved it first on Rust, where we had a hand-written reference to grade the model against. That was the point. Before trusting the method on a language we do not maintain, we wanted to watch it reproduce one we do. Then we took it to the five languages we actually want a model to own: Python, Go, JavaScript, Julia, and C#. It held in all five. No human wrote a correct answer. No human labeled anything. The checker did that work.

One example was enough

The first number that stopped us was how little data it took.

You would expect to need many verified examples to move a model. We did not. One worked. A single correct port, trained for a few hundred steps, was enough to lock the model’s first-try output onto the right answer. Two examples gave the same result. So did three. There was no curve to climb. One was the whole effect.

That is the first sign you are not teaching. You cannot teach a function from one example. You can only point at one. The capability was already in the model. The single example told it which of its own instincts to trust.

The failures were never the math

When a port failed we kept it and read it. Almost none of the failures were wrong math. The model wrote the hash constants from memory, correctly, nearly every time. What broke was always smaller and dumber than the math.

In Go, the model wrote a kitchen-sink list of imports and Go refuses to compile when one goes unused. In JavaScript, it tried to turn a byte array into a number using a call that throws on byte arrays. In C#, it handed a byte array to something that wanted a plain integer, and those types do not convert. In Julia, it called popcount, which Julia does not have under that name.

None of these are hard problems. They are the kind of thing a linter quietly fixes for a human. But each one is a single conventional detail with one right answer, and a model sampling freely will sometimes reach for the wrong one. The fixes were small and paid once. A sentence in the prompt, or a deterministic cleanup pass. One fix per language, never per port.

The clearest case was Python. One function kept failing for a different reason: the model knew the hash but not the exact order to feed the inputs, because we had never written that order down. We added one paragraph of documentation describing it. The pass rate on that function went from zero out of sixteen tries to fifteen out of sixteen. We changed no code and changed nothing about the model. We told it the part we had forgotten to say.

Correct examples can still be bad teachers

Two of the languages embarrassed us, and both taught the same lesson.

Every example we trained on had passed the checker, so each was correct by definition. Correct, it turns out, is not the same as good to imitate.

In JavaScript, most of our verified examples happened to end many lines the same way, with a long repeated piece of mask syntax. Train on enough of that and the model learns the rhythm too well. At temperature zero it falls into a loop, repeating that piece forever, and never finishes the function. Each example was individually perfect. The blend was poison.

In C#, the verified examples used two slightly different ways of writing one branch. The model learned both, then spliced them together into something that would not compile.

Both fixes were the same. Fewer examples, more uniform. Which returns to the point. What matters is not how many correct answers you have. It is which ones you choose to imitate. The checker tells you what is correct. It does not tell you what is worth copying.

One sentence, three times the yield

Late in the work we tried to make this measurable. For each language we counted how many genuinely different ways the model wrote the same function. Call it spread. More spread, lower pass rate. That was the prediction and it held loosely.

The sharper test was an intervention. JavaScript had the widest spread and the worst yield, seventeen percent. We added one sentence to the prompt telling the model to write the mask one specific way instead of leaving it open, and we wrote the prediction down before running it. Yield should rise.

It went to fifty-two percent. Three times the rate from one sentence. The looping problem disappeared at the same time and for the same reason. We had narrowed the model’s options, and with fewer options it stopped wandering. Producing more correct answers and producing one reliable answer turned out to be the same problem with the same fix.

The test that settled it

The functions so far all demanded an exact byte match. We also have functions that work in floating point, where an exact match is the wrong test because different machines round differently. For those, the checker accepts an answer that is close enough.

We ran the same loop on three of them. Two — an entropy measure and a z-score — the model got right on the first try with no training at all. That had never once happened on the exact functions.

The reason is the whole argument in a single observation. Those two are textbook formulas the model knows cold, and a close-enough target is wide enough to accept its answer as written. When the model knows the formula and the target is forgiving, it is already correct. There is nothing to fix, so training does nothing.

Which finally explains why the exact functions needed training at all. Not because the model lacked the knowledge. Because an exact target is unforgiving and the model’s best guess landed just beside it. Training never added knowledge. It nudged a deterministic answer the last few bytes onto a target the model was already circling.

The third floating-point function was a Fourier transform, and it was the exception that holds the rule. The model genuinely does not know that one well; it produced a correct version about one time in eighty. But one in eighty is not zero. The checker found the one correct version, we trained on it alone, and the model began producing it exactly. The rarest case in the project, and a single verified example was still enough.

What it means

If your work has a cheap mechanical way to separate right from wrong, and ours does, down to the byte, you already have most of what you need to turn an unreliable model into a reliable one. You do not need labeled data. You do not need a bigger model or a cluster. You need the model to be right once in a while and a way to notice when it is.

This sits inside a larger shift that is easy to miss. As models get more capable, the scarce thing is not raw capability. It is a trustworthy way to tell good output from bad, cheaply and at scale. We have that for this corner of our system because correctness was a hard requirement long before any of this, so we built the checker first and the model came later.

That ordering is the real lesson. Build the thing that decides right from wrong before you reach for the model to generate at scale. The checker was never going to teach the model anything. Its job was to find the answers the model already had and hand them back.

If you have a checker like that in your own work, you may be holding a teacher and calling it a test.

Bob Pankratz writes infrastructure. Off-Axis Labs publishes the notes.

The last post left a sentence on the table.

Some of us are not waiting.

This is the thing we were not waiting on. MOOTx01 is the long-term memory layer your AI was never given. It opens Friday, May 29.

What it is

A serious local LLM uses 70 to 90 percent of your machine. The narrow envelope that remains has to hold retrieval, memory, context assembly, and the orchestration that keeps the workflow honest. Most current implementations treat that envelope as a problem to defer. We treated it as the entire problem.

MOOTx01 is what came out the other side. It is on-device. It is yours. It captures what was said in the words it was said in, not in paraphrase. It consolidates overnight while the machine is otherwise idle. It returns ordered signal in the morning, prepared before the question is asked.

Any AI that speaks the grammar can read from it. Claude, ChatGPT, Gemini, a local model you run yourself, eventually Siri once Apple ships MCP support. The intelligence is rented. The memory is owned.

What it is not

It is not RAG. RAG is the basement archive — raw tape, slow, expensive, wrong often enough to matter. The giants have spent two years and several billion dollars trying to make the basement feel like memory. It does not feel like memory because it is not memory. Memory is what the basement gets sorted into, by the layer that runs while you sleep.

That layer is the thing the industry has been missing. MOOTx01 is that layer.

It is also not a feature being added to one product. It is a substrate. It does not care which AI you use this month. It does not need to be ported when you switch tools. It is the thing that does not move while the tools above it churn.

Who built it

Codedaptive. The work has been quiet on purpose. The site is live. The docs are honest. The launch is Friday.

If the previous post resonated, this is what it was upstream of. The discipline that produced MOOTx01 is the discipline the post described. The constrained-computing rules and the senior-peer working pattern were not theoretical. They were how the thing got built.

What happens Friday

Early access opens at mootx01.ai. The substrate is free for personal use and for any developer building and sharing non-paid work. License tiers exist for productized and commercial use. Specifics are on the site.

The kinds of contribution the project will reward are the kinds of work the previous post demonstrated. Reviewers who can read the design and find the seams. Refiners who treat working code as a starting point. Port maintainers who care about the metal. Regression authors who can wire MOOTx01 into a real project and benchmark it against alternatives.

If you read the previous post and recognized the working pattern, this is the project. If you read it and thought “I want to see what this looks like in practice” — Friday.

Some of us are not waiting. We were never going to.

MOOTx01 — A Codedaptive project. Launching May 29 at mootx01.ai. Off-Axis Labs publishes the notes.

The cost of advanced AI is not dropping fast enough for most real-world software. Companies are already moving down the cost ladder. The next step is low-cost or free hosted models. Below that are models that run on a phone, a laptop, or a local server.

Each step has a different cost. Per-token models charge a direct bill. Free hosted models replace the bill with data collection, tracking, or platform dependence. Local models avoid both, depending on license and origin.

Local models also eat the machine. On consumer hardware in 2026, a serious local LLM will use 70 to 90 percent of available compute and memory while it is running. That number is not going to fall meaningfully in the next two to five years. It is also not going to stop people from running it and making do with what remains.

Model architectures are still growing faster than silicon. The 10 to 30 percent of the machine that is left has to run the rest of the application. Retrieval, memory, context assembly, the orchestration that holds the workflow together. That is now the entire engineering envelope.

Instruction through broken assumptions

For about twenty years, software has mostly been built as if computing resources were unlimited. The belief made sense at the time. Computers got faster. Memory got cheaper. Developers no longer had to work within strict limits. The common response to a performance problem became simple: add more hardware. That response worked well enough that many teams stopped questioning it.

The response fails when the AI model is already using most of the machine.

Engineering teams now need to rebuild the skill of programming under tight limits. The rule is simple. Important decisions are based on measurements from the real hardware. Theory, benchmarks, and estimates can narrow the search. They cannot make the final decision. Only the target machine can.

A recent kernel optimization effort taught me the lesson again. In five out of eight cases, the paper analysis was right. The other three were wrong in instructive ways. One option that looked promising was unusably slow on the actual silicon. One option that I nearly dismissed turned out to be the winner. Cache behavior, memory bus, and instruction scheduling were responsible for the surprises. None of it was visible from the published papers.

That experience produced a process. Old discipline, current necessity. Every candidate is tested on the target hardware. Every version has to produce output identical to the trusted reference before benchmarking. No option is rejected without measured proof. The process is slower than the unlimited-resources alternative. It is also the only version that ships software which survives contact with the device.

A useful side effect: arguments that used to be mooted across three meetings now resolve in an afternoon. The hardware has the final word.

The senior partner shift

Through the end of April, the frontier coding models behaved like junior programmers who never tired. They could grind. They could produce volume. They could not push back, synthesize across layers, or refuse a bad premise. The skill in working with them was prompt engineering: examples, structure, careful instruction, broken-down tasks.

In May, the models refreshed.

The act of prompt engineering is moot. The discipline existed because the April model needed it. The May model does not. The May model is a peer. It pushes back when the question is wrong. It mooted three alternative architectures during a recent design conversation. Two were unprompted. One was correct.

Most practitioners have not noticed. They are still composing prompts. They are still measuring AI use by tokens produced and pull requests closed. They are producing junior-shaped output from a senior-shaped tool.

The competence that replaces prompt engineering is being a useful interlocutor. Leading questions. Adversarial framing. Demanding citations. Setting creative scope and stepping back. Knowing when to intervene and when to let the peer run.

None of this was in the prompt engineering courses six months ago. Accept it prompt engineering is obsolete move on nothing to see here.

The convergence

Constrained computing is coming back because devices will force it. The peer-collaboration model arrived because frontier providers shipped it. The second makes the first survivable.

Eight kernels to evaluate becomes eighty when there is a senior peer who can write the variants, run the conformance gate, generate the benchmarks, and present the reductive results. The exhaustive testing no human team could reasonably do by hand is now in reach of a small team with measurement discipline and a new senior team player in the loop.

The bottleneck shifts. The question is no longer can we run this experiment. The question is which experiments are worth mooting against the hardware.

That is the rediscovered skill. Not generating more code. Asking the right adversarial question of a peer who can run the experiment. Looking at what the hardware actually said. Being willing to be wrong on the way to being right.

Companies that treat AI tokens as a replacement for engineering judgment will produce more code and learn less. The metric they have chosen, output velocity, is the wrong one. The right metric is the one engineering used before the unlimited-resources era. Did the right thing ship. Is there measured proof.

The lesson

The industry will return to constrained programming because devices will not negotiate. The science team at Aperture believed enough compute could brute-force any problem. That assumption did not end well for them either.

Teams that relearn the discipline first will look like wizards. Teams that wait will pay for the lesson in production, where the cost of a wrong implementation is measured in customer-visible latency, support tickets, and the slow erosion of trust that follows software which almost works.

There is a third option. Build the measurement infrastructure now. Practice the conversation skill with your new peer. Run the experiments while the option space is still cheap to explore. Get the discipline back in muscle memory before the constraint forces the lesson on a deadline.

Some of us are not waiting.

Bob Pankratz writes infrastructure. Off-Axis Labs publishes the notes.