The fundamentals AI does not replace (and that now matter more)

There is an idea going around that with agents writing code, fundamentals matter less. Our experience is the exact opposite: they matter more, because now something writes fast, never gets tired, and lacks the intuition that comes from having been burned.

These are the four that saved us most often.

Idempotence

An idempotent operation is one you can run ten times and end up with the same result as running it once.

With long-running processes and automatic retries, this stopped being academic elegance. A workflow retrying after a crash will repeat steps. If "create the subscription" is not idempotent, the client ends up with three subscriptions and you end up in an awkward conversation.

Our data seed is idempotent. Our data migrations are idempotent. Playbook tasks check whether they already ran before running. That is not tidiness: it is the only way retrying can be safe.

Migrations, not manual changes

It is tempting to open the production database and run an ALTER TABLE. It works, it takes ten seconds, and nobody finds out.

The problem shows up later: local and production drift apart silently, and the day you discover the difference is always the worst possible day.

Every schema change goes through a versioned migration. Data changes too. Last week we reorganized the service structure in our catalog, which meant moving a product between categories and creating a new table. It could have been five minutes of manual SQL. It was three migrations, written, reviewed, and applied in order. When it is time to do it in production, it will be one command instead of an act of faith.

Soft deletes

We do not delete records. We mark them with is_active: false or status: deleted.

The immediate reason is the obvious one: recovering something deleted by mistake. But the one that proved more valuable is different. A genuinely deleted record takes its history with it: who created it, what orders it was tied to, why it existed. With soft deletes that history stays, and you can consult it when a client asks about something from eight months ago.

There is a real cost: every query has to filter. We pay it happily.

Fail early and loudly

Our services do not start if a secret is missing. They do not start with a default value, they do not log a warning and carry on: they do not start.

This came from a classic episode. There were development fallback values, things like dev_secret. Convenient, until a misconfigured deploy reached production with the fallback in place, apparently working fine and signing tokens with a secret that lived in the repository.

We removed every default. Now, if something is missing, the process dies at startup with a message saying exactly what is missing. It is annoying the first time you set up an environment and it is peace of mind every day after.

Why this got more important

An agent writes plausible code at high speed. It will propose the DELETE instead of the soft delete, the manual schema change instead of the migration, the default value instead of the error. Not out of carelessness: because those are reasonable solutions if you do not know the system's history.

Fundamentals are precisely that history, compressed. And somebody has to know it in order to tell when plausible is not enough.