Backbone.The model isn’t the software — deterministic code is what holds it up.

The demo that lies

You’ve seen this demo. Someone pastes a messy invoice into a box, the model reads it, pulls out the amounts, and books them. On stage it looks like the future arrived early. Then it goes to production, and the same prompt returns 120000 on the first run, 1.2L on the second, “around 1.2 lakh” on the third, and on the fourth it quietly drops the GST line entirely. Nothing changed. Same invoice, same prompt. Only the dice moved.

The demo didn’t lie about what the model can do. It lied about what the model can be relied on to do — every single time, with money attached. That gap, between can and can be relied on to, is where most of the disappointment in this field lives. And closing it is not the model’s job. It’s the job of the code around the model.

Software is a promise. Inference is a sample.

A function that returns the same output for the same input is the entire foundation of software. Your tests assume it. Your debugger assumes it. Your users assume it without ever having heard the word deterministic. The whole discipline is built on the idea that behaviour is repeatable — that if it worked once, you can make it work always, and if it broke, you can find out exactly why.

A call to a language model is a draw from a distribution. Turn the temperature to zero and you narrow that distribution; you do not turn it into a function. A model update shifts it. The order of the context shifts it. A stray token shifts it. You cannot build a promise of behaviour on top of a sample. You build the promise out of deterministic code, and you let the sample live inside it, fenced, on a short leash.

What the backbone actually is

The backbone is the unglamorous 95% nobody puts in a launch video. It’s the data model that says an invoice has exactly these fields, of exactly these types. The parser that rejects malformed input loudly instead of guessing at it. The state machine that knows a notice goes draft → sent → resolved and can never slide sideways into nonsense. The idempotency key so a retried request doesn’t bill someone twice. The validator that refuses to persist a number it can’t round-trip. The decision layer that picks the price tier and the product from rules, not vibes.

That is the software. It is testable, reproducible, and debuggable at 3 AM by a tired human who did not write it. None of it trends on launch day. All of it is the reason the thing still works on the quiet Tuesday after launch, when the audience is gone and only the users are left.

Where the model genuinely belongs

Not nowhere. We are not romantics about hand-written rules — the model is the best tool any of us has ever had for the genuinely fuzzy edges. Turning a human sentence into a structured intent. Drafting a reply a person will read and edit. Classifying input that honestly has no clean rule behind it. We reach for it there, deliberately, and it earns its seat.

The rule we hold is simple: the model proposes, deterministic code disposes. Its output is never trusted raw. It lands in a schema validator, an allow-list, a range check, a “does this round-trip” gate. If the model decides the tier is “Enterprise Plus” and our price book has no such tier, the deterministic layer rejects it — the model does not get to invent a product that doesn’t exist. In our own stack that split is load-bearing: anything disputable is computed by code, and the model only writes the fuzzy prose around a decision it was never allowed to make.

The “just prompt it” trap

The fastest route to a demo and the slowest route to a product is the same move: push every hard problem into the prompt. It feels like progress — fewer lines of code, the model “handles it.” What you’ve actually done is relocate your business logic to the one place you cannot test, cannot diff, cannot reproduce, and cannot fix without re-rolling and hoping.

We’ve inherited a few of these systems from teams that moved fast early. Debugging them is archaeology — you can’t set a breakpoint inside a set of weights. The repair is almost always the same shape: pull the deterministic decision back out of the prompt and into code, then shrink the model’s job down to the single thing only it can do. The system gets duller, shorter, and far more reliable. Dull is the goal.

Eval theatre, and the tell

Here’s the tell that a system has it backwards. The team measures it with an eval suite that scores something impressive on a synthetic set — and the synthetic set was generated by the same kind of model being tested, so the number is mostly the system grading its own homework. It looks like rigour. It’s theatre.

When the backbone is deterministic, most of your system doesn’t need an eval at all. It needs unit tests, which either pass or they don’t. You only need probabilistic evals for the small, fenced part where the model actually lives — and even there, the deterministic gate around it is what stops a bad sample from ever reaching a user. We’ve thrown out our own leaderboard once, when it was flattering us instead of informing us. The honest version read worse and was worth far more.

Why this is the whole pitch

When a client asks us to “add AI,” what they almost always need is software — with a model in one specific seat. A 14-day build is mostly deterministic plumbing: the data model, the integrations, the validation, the state transitions, the boring guarantees. The model goes in last, in the one place it earns its keep, wrapped tightly enough that a bad day from the provider degrades a feature instead of corrupting the books. That isn’t hedging against the model. It’s what taking the model seriously actually looks like.

Close

The model is the most interesting five percent of anything we build. It is never the foundation. The foundation is the same boring, deterministic, gloriously predictable code it has always been — the kind that returns the same answer twice, fails loudly when it can’t, and is still standing at 3 AM when the interesting part is having an off night. Build the backbone first. Rent the model a room. Never hand it the deed.