AI & code quality · July 31, 2026 · 11 min read
Ten software engineering principles AI code keeps missing
AI writes working software surprisingly well. It also writes software that charges a customer twice and lets one user read another’s records.
Kaustav Acharya
Founder
On this page — 6 principles
Most of the code we review now was written by an AI. That is not a complaint. It is the reason a build that used to cost three months costs weeks, and it is why our quotes have come down.
But it fails in a pattern — the same ten places, over and over. AI is excellent at the path where everything works, and careless about every path where something does not. A founder cannot read the code. A founder can ask the ten questions below.
Principle one
Doing the same thing twice should not count twice
A customer clicks Pay. The connection stalls. They click again. They are charged twice. Nobody wrote a bug — the code did exactly what it was told, twice.
For your developer
Every mutating endpoint that can be retried needs an idempotency key stored with a unique constraint, and a replayed key must return the original result rather than doing the work again.
Ask this
“What happens if a customer double-clicks the pay button?”
Principle two
Logged in is not the same as allowed
AI is good at checking you are signed in and careless about checking the thing you asked for is yours. Change the number in the URL and you are reading someone else’s invoice.
For your developer
Authorisation belongs at the data-access layer, not the route. Scope every query by owner and never trust an id from the request.
Ask this
“Can I see another customer’s record by changing a number in the address bar?”
Principle three
Money is not a decimal
Store money in floating point and a tenth plus two tenths stops being three tenths. It shows up first as a penny out, then as an audit that will not balance.
For your developer
Integer minor units, or a decimal type with an explicit scale. Never a float, and never a rounded intermediate value.
Ask this
“What type is the amount column, and what happens on a three-way split?”
Principle four
Everyone is in a different hour
A report that runs at midnight runs at a different moment for every user. Deadlines land a day early for someone, and nobody can reproduce it.
For your developer
Store UTC and convert at the edge. Keep the original timezone where the intent matters, such as a recurring appointment.
Ask this
“Whose midnight is midnight?”
Principle five
Two people at once
Two staff open the same record and both save. The second silently overwrites the first, and nobody knows anything was lost.
For your developer
Optimistic locking with a version column, or a constraint that turns the conflict into a visible error rather than a silent overwrite.
Ask this
“What happens if two people edit the same thing at the same time?”
Principle six
Half-finished is worse than failed
A process that writes to three places and dies after the second leaves your data in a state nothing knows how to read.
For your developer
One transaction where the store allows it. Where it does not, a saga with explicit compensation — and a way to see work that is stuck.
Ask this
“If it fails halfway through, what does the data look like?”
Principles seven to ten
Retries, unbounded queries, secrets and no way to look back
Retries without backoff that turn a blip into an outage, queries with no limit that work on a hundred rows and fall over on a million, credentials committed to the repository, and no log that lets anyone reconstruct what happened. Full text of all four is in the copy deck.
On this page