Most of an app can afford to be a little slow, a little clunky, and still get forgiven. Checkout can't. What you're actually selling in that flow isn't a UI — it's time-to-goal. Every architectural choice in there either protects that number or quietly taxes it.
There's a point where a type stops protecting you and starts being a puzzle you have to solve again every time you touch it. I'm not a type wizard and I've stopped trying to be one — because on real React codebases, the complexity that pays for itself is a much shorter list than the internet suggests.
Nobody writes agent rules once and walks away — they write them, then keep adding. A line here after a bad run, a paragraph there after a near-miss. Six months later the file contradicts itself, and the agent is following the version of your project that stopped existing in March.
A carousel with next, previous, and a row of dots. No animation. I remember thinking: is this it? Then I watched my own first thirty seconds of typing and realized the task wasn't measuring whether I could build a slider. It was measuring the order I do things in.
React 19 hands you pending state for free, and that's genuinely nice. But a finished spinner is not a finished request. AbortController is the piece almost nobody reaches for — not because it's hard, but because it looks scarier than it is. Here's the small, boring version that covers most of what you need.
An agent that feels better after a prompt change may still be getting worse. Without a small set of realistic tasks, explicit expectations, and recorded failures, agent improvement is just a sequence of impressions.
A long transcript can remember everything and still help with almost nothing. Durable agent memory is the small set of current facts, decisions, and lessons that makes the next run start from a better baseline.
Autonomy is not a single setting to turn up. A useful agent knows which decisions it owns, which ones it can reverse, and which moments need a human before the next step.
An agent cannot reason about information it cannot reach, and a vague tool description turns a precise capability into a guessing game. Tool design is not plumbing around the model. It is part of how the agent thinks.
A capable model with the wrong context is still a bad agent. The useful part of an agent is not the model in isolation, but the project knowledge, rules, tools, and decisions that shape what it can see before it acts.