Data is the application

Agentic coding has changed the pace of building software in a very obvious way. Features can land in days. Design tweaks can happen in hours. A layout, a template, a flow — all of it can be rebuilt, rolled out, and changed again with a speed that would’ve felt absurd not long ago.

But there’s one layer that doesn’t get the same treatment: data. The author can work from a phone, remote into a coding environment, and happily keep iterating on everything else. If a screen confuses people, the next deploy fixes it. If a bug slips through, it gets patched. If a feature goes in the wrong direction, it can be abandoned. The cost of being wrong is low, so trying three versions starts to feel normal.

Data is different because there’s no clean undo button. There are mitigations — soft deletes, down migrations, backups — but they restore code or structure, not the lost information itself. Event sourcing gets closer, since the system can be rebuilt from events like OrderPlaced or AddressChanged, and even replayed into a fresh table if a migration breaks things. Still, that only works if the event was captured in the first place. And an append-only log has its own traps, especially when users want their accounts deleted.

That’s why the author treats data work as something that belongs at a desk, not on a couch. A screen can be remade in an afternoon. A user’s answer cannot. In Snapkin’s case, once someone tells the app that the white blob on a breakfast plate is skyr, that knowledge is gone if it isn’t stored.

Jeff Bezos’ old “one-way doors” idea fits neatly here. Agentic coding has turned most product work into two-way doors. The danger is moving one-way door decisions at two-way speed. That means migrations, storage format, backup strategy, recovery, privacy, retention — all the boring stuff that actually decides whether an app still means anything after the next deploy.