Senior Fullstack AI Platform Engineer

I've built systems that are still running many years later.

Most of my work has been the unglamorous half of a platform: message queues that do not lose work, event logs somebody can actually replay at an inconvenient hour, and deployment paths that a small team can operate without a runbook. The architecture matters less than whether it holds up under load and whether the next person can reason about it.

On AI systems specifically, I have settled on context as files: prompts, schemas, and reference material kept as versioned text instead of a database of prompt rows, because that is the only form in which a behaviour change arrives as a diff somebody can review. The discipline is in keeping the kinds apart. The application, its documentation, and the development loop each need something different out of it, each one goes wrong in its own way, and each one gets its own rule about where it lives and what checks it.

Every company that exists is the consequence of a series of events, so choosing events as the primitive and projecting database views from them is the right call early. It is the model that matches what the business actually is. When scaling accelerates, more systems, more teams, more infrastructure, the projections can be rebuilt to match and the organisation can follow. Starting from projections and trying to recover the history later is the expensive direction.