Five reels · five formats
Twenty seconds is enough to
get the idea. Not the caveat.
Every reel below is true. Every reel below is also missing something — the exception, the second-order cost, the bit a senior engineer would say out loud if they were standing behind you. Twenty seconds has no room for it. This page does.
Each one is unpacked in a different shape, because a database trade-off and a security hole don't want to be explained the same way. Watch the reel, then read the part that didn't fit.
Redis or Postgres?
Posted 7 July · "Redis lives in memory. Postgres lives on disk."
The reel gives you the split in one line: memory is fast and forgetful, disk is slower and permanent. That's the right instinct. But nobody picks a datastore from an instinct — you pick it per piece of data. So here it is as the table you'd actually reason with.
| What you're storing | Put it in | Because |
|---|---|---|
| A login session | Redis | Read on every request, and losing it just means logging in again. |
| A payment record | Postgres | Losing one is an incident, not an inconvenience. |
| A rate-limit counter | Redis | Written constantly, worthless an hour later. |
| A user account | Postgres | It has relationships, and you'll want to query it in ways you haven't thought of yet. |
| A cached API response | Redis | It's a copy. The original still exists. |
Read the right-hand column again and you'll notice the question was never "which database is better". It's can I regenerate this if it vanishes? Yes means Redis is on the table. No means it belongs somewhere durable, and the speed problem gets solved with a cache in front — which is why most real systems run both, and why the reel ends where it does.
What didn't fit in 21 seconds
"Pull the plug and it can forget" is doing quiet work with the word can. Redis does have persistence: RDB snapshots write a point-in-time copy, and AOF logs every write. Turn AOF on and a crash costs you a second of writes, not everything.
So why is Postgres still the durable one? Because durability isn't a feature you switch on, it's a promise about what a successful write means. When Postgres says a transaction committed, that's on disk. Redis, in its default configuration, tells you "OK" the moment it has the value in memory — the snapshot happens later. Both can be tuned toward the other. Neither ships pointed that way, and the default is what you'll be running at 3am.
Where your login token sleeps
Posted 9 July · "One of these is an open safe."
This one deserves to be walked rather than summarised, because the danger isn't a fact to memorise — it's a sequence. Five steps, none of which require anyone to be clever.
- 1 You store the token where you can reach it.
localStorage.setItem('jwt', token)— because you need to attach it to requests, and this is the obvious place to put it. - 2 Something runs a script you didn't write. A dependency updates. A third-party widget loads. A comment field renders unescaped HTML. It only takes one.
- 3 That script asks for the token, politely.
localStorage.getItem('jwt'). There's no permission check. There's no prompt. It's the same API you used, and the browser cannot tell you apart. - 4 It posts it somewhere. One
fetch()and the token is on a server you've never heard of. - 5 Nothing happens. No error, no failed login, no alert. Your logs show a valid token making valid requests, which is exactly what they'd show if it were you.
Now change one thing. Put the token in a cookie marked HttpOnly and re-run the
sequence. Step 3 breaks: document.cookie returns an empty string. The token is
still sent on every request — the browser does it — but JavaScript is no longer allowed to
look at it. The attacker's script keeps working. It just can't see anything worth taking.
What didn't fit in 22 seconds
Moving to cookies closes one door and opens another, and it would be dishonest to leave that out. Because the browser now attaches your token automatically, any site can make the user's browser fire a request at your API and it will arrive authenticated. That's CSRF, and it's the exact flaw that localStorage accidentally protects you from.
SameSite is the attribute that pushes back, but it's worth being precise about
how far it goes, because it's routinely oversold. Lax — the modern browser
default — withholds your cookie from cross-site sub-requests and cross-site form POSTs, but
it still sends it when someone clicks a link into your site. So a state-changing
GET endpoint is still reachable from another site. Strict closes
that too, at the cost of users arriving logged-out from every external link.
And "same site" means the registrable domain, not the origin: anything at
*.example.com counts as you. One neglected subdomain and the protection is
inside the tent. Treat SameSite as a strong first layer — keep CSRF tokens on
anything that changes state, and never put a state change behind a GET.
The file that stops you repeating yourself
Posted 11 July · "Still re-explaining your code every session?"
An AI assistant starts every session having never met your codebase. You know this, so you
explain. Then tomorrow you explain again. A file in your repo root — CLAUDE.md or
AGENTS.md — gets read at the start of every session, and the explaining stops.
Here's the same request on both sides of that file.
Without the file
> install zod
$ npm install zod
added 1 package
# wrong package manager.
# you notice in review, or
# you notice in CI, or
# you don't notice.With the file
> install zod with npm
CLAUDE.md: use pnpm, not npm
$ pnpm add zod
doneLook closely at the right-hand column: the user asked for the wrong thing and got corrected. That's the whole value. Not a faster assistant — an assistant that knows one fact about your project that you didn't have to say out loud today.
What didn't fit in 23 seconds
The reel shows the file working. It doesn't show the far more common outcome, which is a memory file that gets read and changes nothing. The difference is not length or formatting — it's whether a line can be checked.
"Write clean, maintainable code" cannot be obeyed or disobeyed; there is no diff you
could hold against it. "Every file under src/payments/ needs a test in the
same commit" is either true of a change or it isn't. Write rules a machine could grade,
and the file starts working. Write encouragement, and you've made a wish.
The model is not the moat
Posted 17 July · "A raw model predicts text. A harness gets work done."
"Harness" is jargon, and jargon is only useful once you can point at the parts. A model on its own takes text and returns text — it cannot open your file, run your test, or find out whether it was right. Everything that closes that gap is the harness. Four parts:
Read the error → edit the file → run the tests → read the result → go again. A model that answers once is autocomplete. A model that can check its own work and try a second time is something else entirely.
Edit, run, search. Without them the model is guessing at what your code says. With them it can go and look — the difference between a consultant who's read your repo and one who's read about repos.
What carries between turns and between sessions: your conventions, the decision you made an hour ago, the thing that's already been tried and failed. Reel 03 is one slice of this.
Where a human says yes. The loop's whole job is to move fast; the gate's whole job is to decide what's allowed to leave. Anything that touches production, money or customer data stops here.
Swap the model underneath all four and you get a modest improvement. Swap the harness and the same model behaves like a different tool — which is why "which model is smartest" is a less interesting question than it sounds.
What didn't fit in 24 seconds
A loop is only as good as the thing that judges each pass. If the check is a test suite, the loop converges on working code. If the check is the model's own opinion of its work, it converges on confidence — and a wrong answer delivered with more conviction each round is worse than no loop at all.
So the useful question about any AI setup isn't how many tools it has. It's: what does it run to find out it was wrong, and can that thing actually fail?
Latency or throughput?
Posted 24 July · "Confuse these and you optimise the wrong thing."
One analogy, pushed until it breaks — which is the honest way to use an analogy.
Latency — how long one journey takes.
$ ping api.example.com
64 bytes: time=14 ms
64 bytes: time=15 msOne request: 14ms. Two seats. Fast for whoever is in it.
Throughput — how much arrives per hour.
$ wrk -c100 http://api/
100 connections
requests/sec: 8,500Slow to start, stops everywhere, moves a town's worth of cargo.
Now push it. A user staring at a spinner is in the sports car — they do not care that you served 8,500 other people this second. A nightly job processing two million rows is the freight train — nobody is watching it, and finishing before morning is the only thing that matters. Same infrastructure, opposite definitions of "fast".
What didn't fit in 22 seconds
The analogy hides a trade-off. Batching, queuing and bigger connection pools all raise throughput by making individual requests wait — you build a longer train, and the first passenger sits on the platform. Push utilisation toward 100% and latency doesn't rise gently, it goes vertical, because every new request now queues behind a busy server.
Which is why an average is the wrong instrument. Track the slow tail — p95, p99 — because the mean is happily reporting "fine" while one request in twenty times out.
Why this page exists
The caveat is the actual craft
Anyone can learn that Redis is fast and cookies are safer. Knowing when the rule stops being true is the part that takes years, and it's the part that short-form video is structurally bad at carrying. So the reels do the hook and the page does the honest version.
New explainer most days on Instagram; the longer written ones live in the library.