Short answer
#The position, stated plainly
1ADK is built on coding agents. The entire product depends on one running an analysis competently, and this site is not going to argue that they should be used less.
The argument
AI lets a company create software faster. Understanding has to keep up with that speed. Every mechanism companies previously used to build understanding — code review at reading pace, the slow accumulation of familiarity, the fact that writing something forces you to understand it — assumed a rate of production that no longer holds.
This is not a warning about AI. It is an observation about a bottleneck moving. The constraint used to be how fast software could be written; for a lot of companies it now is how fast anybody can find out what was written.
#What is actually different
Compared with a conventional legacy system, this one has an unusual and slightly disorienting shape.
| Conventional legacy | AI-built | |
|---|---|---|
| Documentation | Exists and is out of date | Often extensive, generated, and never verified by anybody |
| Somebody to ask | They left | They are here and did not read it either |
| Code quality | Usually the visible complaint | Frequently good, and beside the point |
| Consistency | Consistent in its own strange way | Three solutions to the same problem in three places, each locally sensible |
| Age | Years | Months, sometimes weeks |
| What is missing | The understanding decayed | The understanding was never created |
The last row is the one that changes what you do. There is no stale document to correct and no departed expert to blame. There is simply a system, and the question of what it contains has never been asked by anybody in a form that produced a durable answer.
#How this shows up
Usually not as a crisis. As a series of small moments where a normal question turns out to be surprisingly hard.
- Somebody asks what the product depends on and the honest answer takes a day to produce.
- A new developer asks why there are three different ways of doing the same thing, and nobody knows.
- A component is found that nobody remembers requesting.
- Generated documentation exists, reads well, and contradicts the code in a place somebody happens to check.
- A change in one place breaks something in another place with no apparent connection.
- Somebody asks "what did we ship last month" and the answer is a list of pull requests rather than a description.
None of these is an incident. Together they are the shape of a company that has production software and no technical memory of it.
#What to do first
-
Get an explicit inventory
What components exist, what each is for, what depends on what. Derived from the system rather than from anybody's recollection, because in this situation recollection is unusually thin.
-
Separate what was read from what was inferred
This is the specific thing that matters here. An agent explaining a system produces observed and inferred statements in identical prose. Insist on the distinction being recorded.
This is exactly what evidence is for: a claim either names a file and a line range or it is marked as inference.
-
Check the generated documentation against the system
Where a README, comment or design note disagrees with the code, that gap is where somebody's mental model is already wrong. Treat existing documentation as a claim to be tested, not as a source.
-
Find the duplicated approaches
Three implementations of the same idea is the characteristic signature of fast agent-assisted work. Each is usually fine; the cost is that a change has to be made three times and somebody will only make it twice.
-
Confirm the edges
External services, authentication on inbound webhooks, retries, timeouts, what happens on failure. These are the areas where a plausible implementation and a correct one look most alike.
-
Analyse again after the next big push
Given the rate at which the system changes, the comparison between two analyses is worth more here than almost anywhere else.
#The checks worth running once
A short list with a high hit rate on systems built quickly.
Data and money
- Where is customer data stored, and what leaves the system? Outbound integrations are the ones nobody remembers adding.
- What happens to a payment or an order the provider never confirms? The unhappy path is the one that gets generated rather than designed.
- Is any operation safe to repeat? Retries without idempotency produce duplicates under exactly the conditions retries exist for.
Access and edges
- Does every inbound webhook verify who sent it?
- Which endpoints are public, and was that intended for each one?
- Are there credentials anywhere in the repository or its history?
Operational
- What runs on a schedule, and what does each one do? Scheduled work is the category that most often has no owner at all.
- Can somebody who did not build it deploy it?
- Has a backup actually been restored, rather than merely configured?
The full production checklist is the longer version, arranged as something to work through before a system built this way takes real traffic.
#Working with agents deliberately
None of the above argues for slowing down. It argues for one habit: whenever an agent produces a substantial amount of a system, have something derive an account of what now exists, and keep it.
Done well, this is close to free — the agent that wrote the code can produce the account. What it needs is a form that separates observation from inference, requires open questions to be stated rather than filled in, and is kept somewhere the next analysis can be compared against. That is precisely what 1ADK's Evidence Package format is, and there is nothing stopping a team from doing the same thing themselves.
#Where 1ADK helps, and where it does not
Where it helps
- Turning an agent's understanding into something durable and checkable.
- Separating what was read from what was inferred.
- Making the shape of a fast-moving system visible between releases.
- Surfacing generated documentation that disagrees with the code.
- Recording what nobody could confirm, rather than filling it in.
Where it does not
- Reviewing code quality. It records what exists, not whether it is good.
- Finding security vulnerabilities. It is not a scanner.
- Testing anything. Nothing is executed.
- Telling you whether the architecture was a good idea.
- Deciding what to consolidate. It shows you the three implementations; the judgement is yours.
Questions people actually ask
That is the wrong question for an owner, and the answer varies too much to be useful. The thing that reliably changes is not code quality — it is that far less of the system passed through a human mind on the way to production, so the understanding that used to be a by-product of writing it was never created.
Yes, and it will do a good job. Two limits: it cannot reliably tell you which parts of its explanation it read and which it inferred, and it holds nothing afterwards — ask again next quarter and it starts from zero, with no way to compare the two answers.
Not necessarily today. The exposure is specific: you cannot answer questions about your own system without re-deriving the answer each time, and nobody can tell you what changed between two months. Whether that matters depends on whether anything is going to happen to your team, your suppliers or your product.
It scales with how much of the system a person actually read. Line-level completion accepted by a developer reading each line is close to hand-written. A subsystem generated in an afternoon and merged after a skim is the case this page is about.