Short answer
#Where to start from
Two things are true at once, and holding both is the whole of a sensible position.
- Building with coding agents is a real advantage. Your product exists sooner, cost less, and can be changed faster. That is not a compromise you made; it is a genuine gain.
- One thing did not come with it. Understanding used to be a free by-product of somebody writing every line. When most of a system arrives faster than anybody reads it, that by-product does not appear, and nothing replaces it automatically.
So the question is not whether to have built it this way. It is: what does the company now have to do deliberately that it used to get for nothing?
#The nine questions
Every one has a plain-language answer, and several you can pursue yourself.
What is in there
- Can somebody name every part of the product and say what each does? In a system built quickly this list frequently contains something nobody remembers asking for.
- Is there anything running that nobody remembers requesting?
- Do we know everything that runs automatically, on a schedule? The category with the highest ratio of “nobody knew that existed” to size, and the one that fails silently.
What has been checked
- Has a person verified the documentation that exists? Generated documentation is fluent, extensive and indistinguishable from documentation somebody checked. That last part is the risk.
- When a payment or an order fails, do we know what happens to it? The unhappy path is the part that gets generated rather than designed.
- Has anybody gone through the list of what is reachable from the internet?
What happens next
- Could somebody who did not build this take it over — and what would we hand them? The answer is often “nothing”, which is different from “something out of date”.
- Can anybody say what changed structurally in the last two months?
- What does nobody here currently know about our own system? A confident “nothing” about a system nobody read is itself the answer.
#How to read the answers
You cannot evaluate the technical content. You can evaluate the shape, and that is usually enough.
| Question | A good answer | An answer to follow up |
|---|---|---|
| Has anybody verified the documentation? | "Partly — I checked the payment section and two claims were wrong" | "It was generated from the code, so it is accurate" |
| What runs on a schedule? | A list, with an admission that the console and the code disagree | "Just the usual maintenance jobs" |
| What do we not know? | Three or four specific things | "Nothing significant" |
| Could somebody else take this over? | "Yes, in about X weeks, and the hard part would be Y" | "The code is clean, so it would be easy" |
The pattern: calibrated uncertainty is a good sign; total confidence is not. Nobody knows everything about a real system. An answer with no gaps in it is an answer that has smoothed them over — and in a system nobody fully read, that is the most likely failure.
#How to raise it
The framing that works is not "did the AI do this properly". It is: "we built this fast, which was right — what did we skip that we now need?" That is a question with a good-faith answer, and most engineers will give you a better list than this page could.
The reason that lands well: it is true, it credits the decision rather than second-guessing it, and it treats the gap as a normal consequence of speed rather than as a failure by anybody.
#What is genuinely better
Worth saying, because a page of questions reads as a page of concerns.
- The system can be explained on demand. An agent that can read the whole codebase can answer questions no individual could — provided somebody asks and keeps the answer.
- Producing a technical picture is now cheap. What used to be a consultancy engagement is an instruction. The whole of this page is a smaller problem than it would have been five years ago.
- Changes are faster to make once you know what to change, which raises the value of knowing.
Which is the honest summary: the same technology that created the gap is also the cheapest way to close it.
#What goes wrong
Deciding the answer is to stop using AI.
Instead The speed is a genuine advantage. Add the deliberate step that used to happen for free.
Asking for more documentation.
Instead Ask whether anybody has verified what exists. Volume is not the problem.
Accepting “the code is clean” as an answer to a question about understanding.
Instead They are different properties. Clean code that nobody has read is still code nobody has read.
Treating this as a competence question about your team.
Instead Nobody did anything wrong. The mechanism that used to produce understanding did not scale with the speed of production.
Waiting for a problem to appear.
Instead Several of these fail silently by construction — you find out when somebody outside the company tells you.
#What this does not cover
What this does not do
- Whether the code is good. Not a question you can answer, and not the one that matters most to you.
- Security. Two of the nine touch on it; a security review is a separate exercise with a specialist.
- Intellectual property in generated code, which is a real and unsettled legal question.
- Hiring and team structure, which is a different conversation entirely.