When code becomes cheap, your data model is the only thing with permanent weight

AI-assisted coding changes the cost structure of building software without changing what's irreversible. That asymmetry is the thing worth paying attention to.

Mattias Geniar makes this point cleanly in Data is the application. Layouts, flows, bugs, translations: all two-way doors now, fixable in a deploy. But the data layer doesn't move that way. A migration that truncates a column can be reversed in code; the data that was in that column is gone. An event you never recorded can't be replayed. A user's answer to a one-time question exists only once.

The pace mismatch is the risk

Before agentic coding, a team that was slow to ship features was also slow to make data decisions. Everything had roughly the same friction. Now the friction is heavily skewed: a new screen might take an afternoon, but a poorly considered schema change carries the same cost it always did.

That mismatch creates a specific failure mode. When almost everything around you moves fast, the thing that doesn't can start to feel like an obstacle rather than a checkpoint. The temptation is to match the pace everywhere. That's when you walk through a one-way door at two-way-door speed.

Good software teams have always known to be careful with migrations. The point here is that the relative care required has gone up, even if the absolute difficulty hasn't changed.

What you choose to store defines what you can build

There's a second implication that gets less attention: the fields you decide to store shape what your product can ever do, not just what it does today. A field stored carefully is one you can build on. A field stored sloppily is a liability—something to protect, back up, and eventually delete. A field never stored is permanently absent.

This is where data modeling becomes a strategic decision, not just an implementation detail. When code is effectively disposable, the data model is the one artifact that compounds. It accumulates meaning as users interact with it. You can't regenerate that from a prompt.

Slow down exactly here

The practical implication for small teams is straightforward: use the speed AI gives you on everything it applies to, and protect your deliberation budget for data. That means:

• Schema changes get a written plan, not just a migration file. What happens to every existing row? How do you verify it worked? How do you roll back without data loss?
• Storage decisions are explicit. If you don't actively decide to store something, you haven't decided at all—you've just deferred.
• Privacy and retention are part of the data model, not an afterthought. How long something is kept, who can see it, and what happens when a user deletes their account are questions the schema has to answer.

None of this is new engineering advice. What's new is the context: when everything else in your stack iterates in hours, the data layer is where your judgment actually lives. Treat it accordingly.

Sources

• Data is the application (original)
• Found via the TLDR newsletter