Short answer
#Why these twenty-eight
Chosen for hit rate, not for completeness.
A person reading every line of a system performs a large number of small checks without noticing: what happens if this is null; is this endpoint meant to be public; does this get retried; who calls this. Those checks are not part of any process — they are a side effect of reading.
When most of a system arrives faster than anybody reads it, none of them happen. The list below is what those incidental checks look like when they have to be done deliberately, ordered by how often they find something.
#Money and data
Six checks
- What happens to a payment or an order the provider never confirms? The single highest-yield question. Reconciliation is the classic missing piece: money taken, nothing recorded.
- Is any operation that can be retried safe to repeat? Retries without idempotency produce duplicates under exactly the conditions retries exist for.
- Where is customer data stored, and what leaves the system?
- Is anything written to a destination configured outside the repository? A file path or URL from an environment variable that nobody has looked at.
- Are amounts handled in a form that cannot lose precision?
- Is there any path that deletes data with no confirmation and no recovery?
#The unhappy paths
Five checks
The happy path is usually thorough. This is where fast builds are thin, because a failure mode has to be imagined rather than described.
- What happens when an external call times out?
- What happens when the queue backs up, or a worker dies mid-job?
- What happens when two requests arrive for the same thing at once?
- Is a partial failure left in a consistent state, or half-applied? A multi-step operation with no transaction boundary is the commonest source of “impossible” data.
- Does a failure produce anything a human would see — a log, an alert, a status? Silent failure is the expensive kind.
#External edges
Five checks
- Does every inbound webhook verify who sent it? A webhook endpoint with no signature check is an unauthenticated write to your database.
- Is every external dependency listed, with whose account it is in?
- Do outbound calls have a timeout? A call with no timeout can hold a request, then a worker, then the pool.
- Is there anything outbound that nobody remembers adding?
- What breaks, and how visibly, if each external service is down for an hour?
#Access and exposure
Five checks
- Which endpoints are reachable without authentication, and was that intended for each one? Go through the list explicitly. This is where a generated route file surprises people.
- Does an authenticated user only see their own data? Missing ownership checks look exactly like working code in every test where one user exists.
- Are there credentials anywhere in the repository or its history?
- Are debug modes, verbose errors and development tooling off in production?
- Is anything that should be internal exposed on the public internet — an admin panel, a queue dashboard, a database port?
#Operations
Four checks
- What runs on a schedule, and what does each one do? Check the codebase, the cloud console and the crontabs. They rarely agree.
- Can somebody who did not build it deploy it, from the instructions alone?
- Has a backup been restored, rather than merely configured?
- Is there a way back from a bad release that somebody has actually used?
#Understanding
Three checks
- Has anybody verified the documentation the agent generated? Take five specific claims and check each. Extensive unverified documentation is worse than none, because it is believed.
- Is there a written account of what the system is made of that somebody could check?
- Is there a list of what nobody can currently confirm about it? A confident “we know everything” about a system nobody read is the finding itself.
#What goes wrong
Reviewing the code line by line before launch.
Instead Work the seven areas above. Line-by-line review of a large generated codebase is slow and misses exactly the structural questions on this list.
Assuming the tests cover it.
Instead Check what the tests actually assert. Generated tests frequently assert the implementation rather than the requirement, and therefore pass whatever the code does.
Trusting the generated README.
Instead Test five claims from it. If two are wrong, treat the whole document as a claim rather than as a source.
Treating this as a one-off pre-launch exercise.
Instead Re-check after each significant push. A system built this way moves faster than the checks stay valid.
Reading the list as an argument against coding agents.
Instead It is an argument for the checks a human reader used to perform incidentally. The speed is a genuine gain; the checks now have to be deliberate.
#What this does not cover
What this does not do
- Security testing. Several items here overlap with security hygiene; none of it is a penetration test or a vulnerability scan.
- Performance and load. Nothing here tells you how the system behaves under traffic.
- Legal and regulatory obligations, which depend entirely on what you do and where.
- Architecture quality. This establishes that a system is safe to run, not that it is well designed.
- Test adequacy beyond the one check above.