The way we build AI deserves a second look. For a few years the advice has been to throw enormous amounts of data at a black box and hope a useful pattern falls out, and we have quietly filed hallucinations under the cost of doing business with a large language model. Anyone who has lost a weekend to a race condition in a busy WooCommerce checkout knows that hope is not an architecture. Compiling Programs into Transformers trades the probabilistic guessing for deterministic precision.
The architect’s critique: why training isn’t enough
In day-to-day work on enterprise AI integrations, a transformer is an inference engine. You fine-tune it, you prompt it, you cross your fingers. Sean Moran recently showed another option: treat the transformer as a programmable machine. Rather than waiting for the weights to emerge from gradient descent, you wire them analytically to run a specific computation graph.
That changes the calculation in high-stakes environments. In finance or healthcare, a 2% chance the model forgets how to do arithmetic is not something you can sign off on. Compiling Programs into Transformers turns the residual stream into working memory and every layer into a machine step. The model stops predicting the next token and starts behaving like a compiled computer.
Inside the machine: slots, registers and lookups
Think of the transformer’s hidden dimensions as registers in a CPU. Normally those dimensions stand for abstract concepts. In a compiled transformer they get explicit jobs:
- Slot A holds the input variable (x)
- Slot B holds the intermediate result (y)
- Slot C holds the final output (z)
Attention gets repurposed as a deterministic lookup operator. It is no longer searching for context; it matches specific keys, the inputs, and returns the values they map to. The feed-forward network (FFN) becomes the local compute unit, handling transformations like z = y + 1. It reminds me of the early days of tuning custom SQL queries, when every byte of the buffer pool mattered.
The toy program example
Here is a simple logic flow. In an ordinary backend it would be little more than an array lookup. Inside the transformer, the weights are wired to run it with no training step involved.
<?php
/**
* Conceptual logic for a compiled transformer "slot"
* This isn't how you code the weights, but how the
* state transition is managed internally.
*/
function bbioon_transformer_machine_step($current_state) {
$lookup = [
'A' => 2,
'B' => 5,
'C' => 9,
];
// Step 1: Attention (Lookup)
$y = $lookup[$current_state['x']];
// Step 2: FFN (Local Computation)
$z = $y + 1;
return ['x' => $current_state['x'], 'y' => $y, 'z' => $z];
}With a tool like transformer-vm, developers can compile WebAssembly straight into the model weights. The internal circuitry is then known before anything runs, which makes the model transparent and auditable.
What this changes for your next project
Most developers are still on the LLM plus tools stack: the model reasons, then an external API does the real work. That holds up for simple tasks and turns into a performance bottleneck once execution runs over several steps. Compiling Programs into Transformers moves the logic inside the model, so it does not have to leave the execution loop every time it needs an exact result.
If this Compiling Programs into Transformers work is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days, and I know how to get experimental AI into stable production code.
Where this leaves us
Treating AI as a black box is on the way out. On a specialized diagnostic tool or a supply chain automation, reliability is the metric that decides whether the thing ships, so deterministic execution is worth reading up on. The original Percepta research on constructing LLM computers goes a good deal deeper than this post does. Better to compile the output you need than to pray for it.
