AI in production: RAG, evals and prompt injection
Anybody can build a demo that impresses. What separates the demo from the product is three disciplines, and most teams have none of them.
Archive · Blog
Every article comes out of something I built or watched break: payments, distributed systems, AI in production. Start with whatever is biting you right now, or work down the list from the top.
Anybody can build a demo that impresses. What separates the demo from the product is three disciplines, and most teams have none of them.
Two questions come up in every company: why did the report take down production, and why is the number on my dashboard different from yours. Both have the same root cause.
The demo works in five minutes. What nobody shows is the evaluation, cost and failure layer that separates a prototype from something a real user can survive.
Three techniques that let you safely change a system you did not write, do not understand, and cannot stop.
Tests do not exist to prove the code is right. They exist so you can change it tomorrow without fear. That change of goal reorganises everything.
Every gateway redelivers webhooks. If your handler is not idempotent, you will find out on the day the same sale gets counted three times.
The three most confused acronyms in authentication, what each one solves, and the mistakes that show up in almost every codebase.
Most breaches that make the news do not use sophisticated technique. They use one of these six flaws, and all six have a known, cheap fix.
A six command routine that turns "it must be the network" into "it is layer X, on hop Y".
The service starts fine and gets worse over days. Three causes explain almost every case, and all three have distinct signatures.
The choice between the two models is not taste and not fashion. It is determined by the profile of your load, and there is a calculation that settles it.
The bugs that do not happen on your machine, do not happen in tests, and do happen in production. How to recognise them by reading code.
A decision guide organised by problem, not by structure. You have a need; which structure answers it, and at what cost.
Why Postgres is good at ranges and Cassandra is good at writes. It is not marketing: it is the tree each one picked, and the bill each choice comes with.
No mysticism and no maths: what the model does, why it hallucinates, and how that changes your architecture decisions.
The three pillars are not interchangeable. Each answers a different question, and using the wrong one is why investigations drag on for hours.
Why renaming a column breaks production, and the four step pattern that turns a migration into a Tuesday afternoon task.
How one slow secondary dependency takes down the whole system in ninety seconds, and the five patterns that prevent it.
You need to debit one account and credit another, and they live in different databases. The two patterns that solve it in practice, and what to avoid.
CAP is the most quoted and most badly stated theorem in distributed computing. This article fixes the statement and shows the vocabulary you actually use day to day.
Sharding is the most irreversible decision in a data system. This is the guide to deciding whether you need it and, if you do, how to pick the key.
How an index works on the inside, why column order decides everything, and how to read an execution plan to know what to do.
Adding a cache is easy. The hard part is living with the four consequences it creates, and all four have known solutions.
Your average latency is lying to you. The three concepts that turn 'the system is slow' into a sentence with a number, an endpoint and a percentile.
Talk to me
No form and no mailing list. If you disagree with something I wrote, or want to tell me how you solved it, the conversation goes straight to me.