Blog · AI

The model proposes, the code disposes.

How to put AI inside a system that has to be right, without making that system unpredictable.

Elvis Chege · 11 October 2026 · 5 minute read

[Draft for Elvis to review and edit before publishing.]

Every organisation is being told to "add AI". Most of the advice skips the part that matters to a bank, an insurer or a ministry: what happens when the model is wrong? Language models are useful because they are flexible, and risky for exactly the same reason. The answer is not to avoid them. It is to give them a job they are good at, and keep them away from the jobs they are not.

Split thinking from doing

Let the model reason, suggest and explain. Let ordinary, deterministic code do anything that changes the state of the system. The model proposes an action; a layer of code you can test checks that the action is allowed, that its target exists and that its inputs make sense, and only then carries it out.

We built iKlippa, a browser video editor, this way. The model never writes the project directly. It reasons over the edit and proposes changes; a command layer validates each one and applies it as an edit you can undo. The AI is useful, and the editor stays predictable.

If an AI action cannot be undone, it should not be automatic.

Give it structure, not a paragraph

A model asked a vague question gives a vague answer. Give it the actual state of things as structured data: in iKlippa that means the tracks, clips, selection, captions and pacing of the current edit. Its suggestions then refer to real things your code can check.

Put the cheap, certain checks first

Not every decision needs a model. In Uwatu, a livestock-protection system, a SIM swap on a tag's line or an animal leaving its geofence triggers an alert by plain rules, instantly. A statistical baseline and a trained anomaly model handle the subtler cases. A language model comes last, and only to write the alert in plain words.

Plan for the model being down

Models time out, rate-limit and fail. In Uwatu the scoring service has a 500 millisecond deadline and a safe fallback, and the generated alert has hard-coded text to fall back on. An alarm should never wait for an API.

Measure it like any other component

Keep a set of real examples with known right answers and run the model against them whenever you change a prompt or a model version. If you cannot say how often it is right, you cannot say whether it is ready.

Keep confidential data where it belongs

Know where your data goes. Customer records and internal documents should never be sent to tools that keep them or train on them. Sometimes the right model is a smaller one you run yourself.

The short version

1. Let the model think; let tested code act.
2. Give it structured context, not prose.
3. Use rules first, models last.
4. Make every AI action reversible.
5. Always have a fallback.
6. Measure it, and protect your data.