← The Points & Miles Problem · the human version · ~8 min
Part one · the problem
This is the no-code version of the whole story: the problem, the site that fixes it, and the slightly absurd way that site gets built. If you want shell scripts and architecture diagrams, that door is over here.
Every card pitch says the same thing: earn points, travel free. What nobody says out loud is that the system is designed to be hard to use well. Your points live in a dozen separate programs. Their value changes depending on where you move them. Transfer ratios shift — some literally change on the first of each month. Award prices float. And the moment you transfer points from a bank to an airline, the move is irreversible — get it wrong and there's no undo button.
Most people, reasonably, don't do any of this. They redeem for a gift card at a bad rate, or let the balance sit until the program devalues it. Unused and badly used points are pure margin for the banks. The industry has a cheerful word for it: breakage.
And the advice industry that grew up around this has its own conflict: most points blogs earn a commission when you sign up for the card they recommend. The advice can be good. But the incentive is not yours.
Here's the manual playbook I ran for years, every time we wanted to use points for a real trip:
It works. It's also a spreadsheet, three browser tabs, and a lost weekend — per trip. I travel 35–45 weeks a year, so our household earns points faster than that process could ever spend them well. My wife, sensibly, was never going to run that playbook. Almost nobody is.
So I built Points & Prompts. You tell it what you have — cards, airlines, hotels, balances — and it tells you the truth about it:
Now the strange part. Remember 35–45 weeks a year? I didn't have time to build this site either. So the site is mostly built by AI agents — we call them the Night Shift — arranged like a very small, very paranoid newsroom:
Writes precise work orders: what's broken, what to change, and — crucially — a checklist of evidence that must be shown before the job may be called done. The editor assigns stories but never writes them.
Takes the work order, builds the change in its own isolated copy of the site, tests it on phone, tablet, and desktop screens, and submits it for review. The reporter writes but can never hit publish.
Opens the actual site in an actual browser and checks the work independently — it never takes the reporter's word for anything. Only the fact-checker can publish.
Boring, reliable programs watching the whole thing: an alarm if the loop goes silent, a spending cap so it can't burn the budget, backups so the robots can't destroy work, and an emergency brake — a single file that, when present, stops everything. That brake is real: it's engaged right now while a human-led redesign is underway.
The division of power is the whole trick: the one who builds can't publish, and the one who publishes never builds. Neither AI can ship alone, and the one doing the checking has no stake in the work being called finished. My job shrank to setting direction, making judgment calls, and reading complaints.
None of this worked on the first try. The system once reported a site outage that didn't exist, because its own testing rig was blind. It once took the real site down for four hours by burning through the host's build allowance on bookkeeping. And once, every safety light was green while strangers on Reddit found wrong numbers on the page — the machine could prove the site rendered, but not that it was true. That failure is exactly why every number now carries a receipt.
Each failure became a written rule. There are 54 of them now, and they're all published — because the mistakes turned out to be the most useful thing this project produced.
Ready to go deeper?The real architecture: diagrams, the actual files the agents read, who runs on which model and why, and the installable skills. Bring coffee.