AI Engineer — I ship the systems, then keep them running

Engineering is where AI projects are won or quietly lost: the verification step nobody budgeted, the prompt that drifts, the bill that triples. I have built and still maintain more than twenty platforms. Here is what that engineering looks like.

Engineering practices from the platforms

• Verify before you serve. newworld.education generates curriculum questions, then runs each through a verification pipeline; only verified items reach students — 89,000+ and counting.
• Autonomous, scheduled, auditable. KRM's daily brief runs on a scheduled serverless job, writes its output where it can be inspected, and emails subscribers — with authenticated endpoints so nothing can be triggered from outside.
• Shared knowledge, cheap delivery. The Dictionary's 13,000 terms, 316 writings, 223 papers and 3,000 moats are split into lazily loaded JSON so the first page is fast and the knowledge graph is generated, not hand-edited.
• Multilingual by construction. Interface strings, captions and assistant replies in sixteen languages, with right-to-left handled properly for Arabic and Urdu.
• Guardrails as code. Escaping rules for embedded data, scrubbing passes before publication, and evaluation against a fixed question set before any prompt change goes live.

What I engineer for clients

Retrieval over your own documents with a single source of truth; agents for order handling, fulfilment and reporting; evaluation harnesses so you know when a change made answers worse; observability and cost controls; and the staff-facing training that the EU AI Act (Article 4) and DIFC Regulation 10 now expect. Delivered as working systems, with the code and the documentation handed over.

Tooling I build for builders

createagent.ai — create and deploy AI agents without hand-wiring each one. makelive.dev — build-and-ship tooling for founders who need something live this week, not this quarter.

Questions people ask