Building AI products that survive contact with reality

There is a wide gap between an AI demo and an AI product. A demo needs to work once, in front of a friendly audience, on a chosen example. A product needs to work at 8pm on a Tuesday for a tired child on a weak connection, and it needs to be wrong in ways that are recoverable.

Our engineering approach starts from that asymmetry. We assume the model will occasionally be wrong, and we design the surrounding system so that being wrong is cheap. Curriculum content is grounded in a structured syllabus map rather than generated freehand. Assessment logic is deterministic code, not a model judgement call. The model does what models are genuinely good at: explaining, rephrasing, encouraging, and meeting a child at their level.

We also treat evaluation as infrastructure. Every change to a prompt, a model version or a retrieval step runs against a fixed bank of student interactions before it goes anywhere near a child. A change that improves average response quality but regresses arithmetic marking is not an improvement.

Operationally, we keep the boring parts boring. Predictable hosting, managed databases, real observability, and a bias toward small reversible releases. The interesting risk in an AI product should be in the product, not in the plumbing.

None of this is novel. It is simply what it takes for something to still be working six months after the launch post.