The code is the only document: the mid-market path to the ADLC.

One person knows why

Sixty employees. A system that has been in production for nine years. And no specification of it anywhere. There is a backlog, there are tickets, and there is a README that stops being true around the third heading. The only complete record of what the system does is the code. The record of why it does it lives in a handful of people, and for any given part of the system it is usually just one of them. Ask about billing and everyone points you to the same person.

That arrangement worked, and for a good reason. The right person was in the room. Someone proposes a change, the person who knows says it will break invoicing for the Austrian customers, and the change gets reshaped before anyone opens an editor. No document was needed, because the check was a person.

Then that person leaves. For their area there is no second opinion, because there never was one. Or an acquirer’s due diligence team asks for a description of the system and nobody can produce it. Or the team starts using agents, begins shipping four times as many changes, and the few people who can answer can no longer be in every conversation.

Peter Naur described this in 1985. A program is a theory held by the people who built it, and the code alone does not carry that theory. Mid-market companies have been running on the theory and skipping the write-up. That is cheap until the people holding it disperse. Agents make that happen sooner, because an agent arrives at every task with no theory at all and does not know which question to ask.

There is nothing to start from

Part 2 followed the enterprise path, and that path starts with documents. Requirements, traceability matrices, specifications an analyst has maintained for years. They record what was approved rather than what runs, which is the problem, but they are still a real seed. Connect them to the code, work through the discrepancies, and the result is richer than anything the code alone would give you.

Here there is no seed. So the picture has to come out of the system itself.

Recovering it is hard, and there is a number for that

This is where being straight matters more than a pitch.

A 2023 dissertation at the Karlsruhe Institute of Technology took on exactly this problem of recovering the links between requirements and the code that implements them, in projects where nobody ever recorded them. It beat the previous best methods and reached an F1 score of 55.5 percent. Adding a large language model gave no improvement over simple word embeddings. The author’s own conclusion was that on large projects every approach, including his, is still far from what full automation would need.

So anyone offering you a button that reads your repository and returns a correct specification is describing something nobody has actually demonstrated. What has been demonstrated is the opposite. Models produce plausible output even when their context is wrong, and they do not raise a hand about it. A 2026 benchmark of 1,304 coding tasks found that the strongest models degraded the most on unclear input and never flagged the ambiguity.

Extraction that a person confirms is a different proposition. To see why, look at what extraction actually returns.

Three statements, and only one of them is right

Take an ordering system with per-customer pricing. Extraction reads the code and proposes statements about what the system does. Here are three of them, of a kind you will recognize.

• The one it got right. “A customer on an annual contract is billed at the contract rate even when the list price changes mid-term.” True. It found four places that implement it, including a nightly reconciliation job nobody remembered was involved. This is the common case, and the reason to do any of this. The statement was correct, and the evidence was more complete than the team’s own memory.
• The one it got backwards. “Orders above £50,000 require manual approval.” The code says so. The code has said so since 2021, behind a feature flag that was switched off when the finance system took over approvals. It is in the repository, and it is not the behavior of the system. Extraction reads code, and dead code reads exactly like live code.
• The one it invented. “Customers in the enterprise tier receive a 15 percent volume discount.” There is no tier and there is no such rule. There are three named customers with hand-written exceptions, and the model generalized from them. This is the dangerous class. The statement is well formed, plausible, and would be waved through by anyone reading quickly.

None of that is an argument against extracting. All of it is an argument that a person has to sign each statement before it counts for anything.

Reading a proposed statement and rejecting it takes a minute. Writing the same statement from nothing takes an afternoon and a meeting.

Confirming is a different job from writing

That gap is the whole economic argument for this path.

The people who hold the theory are never going to write a specification. They have never had time, and they are not going to find it. What they can do is read a proposed statement and answer yes, no, or not quite. The feature flag costs one of them ten seconds. The invented tier costs twenty. Neither answer required anyone to compose anything.

Confirmation also leaves behind something the old conversation never did. Once a statement is confirmed and linked to the code that implements it, the link is re-checked as the code moves. The person who confirmed it does not have to remember it, stay at the company, or be in the next meeting. That is the point at which the theory stops living only in heads.

You do not confirm the whole system

The instinct is to extract everything and confirm everything. That is how this becomes a project nobody finishes.

Change is not spread evenly. Parts of the system have not been touched in four years. Other parts are edited every sprint. Extract broadly and shallowly, then confirm deeply only where change actually lands. Your version control history already knows where that is, and asking it costs an hour.

Then take the next real change request and run it against the confirmed part. That is the test worth running, because it tells you whether what you confirmed covers what you actually work on. If the impact map comes back thin, it has just told you which area to confirm next.

What this looks like with POLYREQ

Confirming is the work, so it has to be quick.

POLYREQ reads the code and any documentation you have, and returns records rather than a document. Every process, rule, screen, endpoint and table is a record with an ID and a version. You review one record at a time instead of reading a specification.

Each record shows the code it came from. So the question stops being whether somebody remembers how annual contracts are billed. It becomes whether the four places on screen do what the record says. That takes seconds, and it works the same when the answer is no.

The answer becomes a versioned change to the record. Reject the approval rule because the flag has been off since 2021, and that decision is still on the record a year later, with the name of whoever made it.

Records nobody can answer stay open with an owner. That is how you find out which parts of the system have no living expert left.

Confirmed records stay linked to the code, and the links are re-checked as the code changes. A change that breaks one shows up as a finding instead of a surprise months later.

What this costs if you wait

None of this is an argument that having no documents is a good position to be in. It is a worse starting position than the enterprise one, which at least has something written down to argue with.

What it has instead is a deadline.

Extraction proposes statements. Only somebody who knows the system can confirm them. The feature flag switched off in 2021 is not recorded in the code. It lives in the memory of the person who switched it off. When that person goes, the statement still gets proposed and nobody left can say whether it is true. The choice then is between accepting it unverified and working it out from scratch. That is the 55.5 percent problem again, this time with nobody to check the answer.

So the price of this work is not fixed. It rises every time one of those people leaves, and it rises faster once agents are making changes nobody has fully absorbed.

The encouraging part is small, and it is real. Nobody is being asked to write a specification. The people who already know are being asked to read a list and answer yes or no, while they are still here to answer.