![Mohamed Khaled portrait](https://mokh.tech/wp-content/uploads/2026/05/icon-upload.png) Context engineering before it had a title Ten years building production software, most of it content platforms. That work taught me documentation is part of production, not something you write after the fact. Now I take AI products from zero to one and build the context that makes them legible to the humans who maintain them and the agents that act on them. --- Current work ## Taking AI products 0→1. The product calls and the engineering calls, same person. I work across the whole zero-to-one arc: deciding what is worth building and for whom, then making it real – retrieval architecture, evaluation discipline, latency budgets, regulatory fit. Most AI features die in the gap between a demo that impresses in a meeting and a product someone will pay for. Closing that gap takes product judgment and engineering at the same time, so I treat it as one job. Documentation gets the same treatment: the page and the prompt are the same artifact, read by a human and an agent. --- Background ## Ten years of software, two-and-counting of AI. I spent most of the last decade building web and content platforms. That kind of work teaches you why production systems fail in ways no design document predicts, and that the hardest calls are about what to build, not how. When GPT-4 landed in 2023 it was obvious LLMs would be load-bearing for the next decade of software, so I rebuilt my practice around them: reading papers, shipping demos, killing the ones that did not earn their keep. What surprised me is how much of production AI is plain engineering – observability, evaluation, deployment discipline – and how little of the rest you can get from a tutorial. The content-platform decade turned out to be context engineering in disguise. The documentation taught me as much about production systems as the code did. --- How I think about AI ## A few positions, repeated until people stop arguing. - **Ship the smallest thing that proves value.** The first version exists to answer one question: does anyone actually want this? Everything you build before you have that answer is a bet against yourself. Zero to one is about reaching that answer cheaply, not building the cathedral. - **The model is not the product.** The product is the system around the model: retrieval, evaluation, prompt construction, citation, monitoring – and the user problem it is pointed at. Pick the wrong system, or the wrong problem, and the best model in the world gives the wrong answer. - **Architects exist because measurement exists.** You cannot tune what you cannot measure. Most AI systems in companies today have neither an eval set nor a usage metric. That is the first thing to fix – before the model choice. - **Regulation is a forcing function, not a brake.** The EU AI Act is real, dated, and enforceable, and equivalents across the US, UK, and APAC are landing on similar timelines. The companies that treat compliance as a parallel workstream lose months. The ones that fold it into product and architecture from day one ship faster. --- Writing ## Lessons for the engineering. Insights for everything else. This site is where I work in public. The [lessons](/lessons/) are the engineering made tangible: each one is an interactive artifact you can run, not a static article – a tokenizer you can paste into, a chunker you can switch strategies on, a reranker you can run and feel the latency of. The [insights](/insights/) are the product side – the 0→1 calls, the cheap experiments, and what shipping teaches you that no roadmap predicts. Both aim at the same thing: a felt understanding of one real decision. --- Get in touch For collaboration, advisory, or 0→1 product conversations: [mokhaleddev@gmail.com](mailto:mokhaleddev@gmail.com). [LinkedIn](https://www.linkedin.com/in/mohamedkhaledref/) for shorter notes, [GitHub](https://github.com/Ref34t) for anything code-shaped.