AI Codebase Deep-Read & Reverse Engineering

Part 5 kept returning to a single enabling capability: reading an entire legacy codebase, completely enough to recover every rule and fast enough to do it before the experts leave. That reading was, for decades, the immovable bottleneck in understanding a legacy system. This part is about the thing that moved it — the AI codebase deep-read — what it does, what it can’t do, and why human review isn’t an add-on to it but part of its design.

The bottleneck it breaks

Understanding a legacy system has always been gated by one slow, unglamorous activity: a human reading the code. Not skimming the parts they’re changing — reading enough of the whole to know how it fits together, where the rules live, what depends on what. On a system of any size, done properly, that takes months, and it competes against every other demand on the few people who can do it. So it’s rarely done properly. Teams read the slice in front of them, rely on the experts for the rest, and discover the parts no one read at cutover.

The deep-read attacks exactly that bottleneck. AI can read an entire codebase — application code, copybooks, stored procedures, JCL, configuration, and whatever documentation exists — end to end, and draft an account of what it does. The claim worth stating precisely, because overclaiming here is how the technology gets oversold: this is an analysis-time gain, roughly 10× faster than manual review — a pass that took twelve weeks taken down to about two. It is not a 10× productivity boost on the whole program, and it doesn’t make the cutover safe. It removes the slowest, most knowledge-dependent step, and it does it while the experts are still around to check the result.

What it actually produces

A deep-read isn’t a summary. It’s a structured, navigable account of the system as it really is:

• The dependency and call graph — what calls what, what depends on what, where the real coupling is hiding versus where the architecture diagram claims it is.
• Data flows and state — where data is read and written, which stores are authoritative, where the same fact lives in multiple places that may have drifted apart.
• Execution and ordering — for batch-heavy systems, the job graph: what must run before what, and the timing constraints that only matter at quarter-end or month-close.
• Edge cases and undocumented rules — the highest-value output: the branches, the special cases, the business rules that were never written down, surfaced as candidate findings.

Each finding is tied back to the specific code it came from. That traceability is the point: the output isn’t a black-box opinion you take on faith, it’s a set of claims each of which can be checked against its source. “No trust-us” starts here.

To make that concrete, picture the kind of finding that matters most. In a billing module, a deep-read surfaces a branch that waives a late fee when three conditions all hold: the account has been active more than a set number of years, the payment lands within a short grace window, and a specific flag is set on the customer record. No comment explains it. No spec mentions it. The engineer who added it for one important customer left years ago. A manual review would only catch this if someone happened to read that exact branch closely, and a static analysis tool would report the branch as complex without ever saying what it does. The deep-read describes it in business terms, cites the lines it came from, and flags it as a candidate rule for a human to confirm. That rule is precisely the kind of thing a from-scratch rewrite silently drops and ships as a regression. Surfacing it before the rebuild is the whole value.

Why this is reverse engineering, not static analysis

It’s worth being precise about what’s new, because the industry has had code-analysis tools for a long time. Traditional static analysis is genuinely useful: it finds complexity hotspots, security patterns, dead code, defect signatures. But it operates at the level of form — it can tell you a function is 400 lines with a cyclomatic complexity of 60. It can’t tell you that those 400 lines implement the credit-limit exception for strategic accounts.

The deep-read works at the level of meaning. It reverse-engineers behavior and intent: not just “this branch is complex” but “this branch handles the case where a payment arrives inside the grace window.” That semantic layer — describing the system in the business’s own terms — is what makes the output usable for recovering rules and planning a modernization, and it’s what static analysis, for all its value, was never built to do. The two are complementary; the deep-read adds the layer that matters most for preserving knowledge.

The three ways to understand a legacy system line up like this:

	Manual expert review	Traditional static analysis	AI deep-read
Coverage	The slice a person had time for	The whole codebase	The whole codebase
Speed on a large system	Months	Fast	Roughly 10x faster than manual, in our experience
What it tells you	Meaning, if they read it	Form: complexity, patterns, defects	Meaning: behavior, intent, rules
Recovers undocumented rules	Yes, where read	No, not its job	Yes, as candidate findings
Traceable to source	In the reviewer’s head	Yes	Yes, every finding cites its code
Can be confidently wrong	Yes	Rarely, it reports facts	Yes, which is why review is built in
Bottleneck it removes	None, it is the bottleneck	Never removed it	The reading itself

The deep-read does not replace either of the others. It removes the constraint that made expert review too slow to finish, and it adds the semantic layer static analysis was never designed to reach.

Why human review is built in, not bolted on

Here is the part that separates an honest use of this technology from a reckless one. The deep-read produces drafts, and drafts can be wrong. The AI can misread intent, mistake a dead branch for a live rule, miss context that lives outside the code, or state something with a confidence the evidence doesn’t earn. Treating its output as verdict would just replace one unreliable source — fading human memory — with another, and call it progress.

So the deep-read is structured around review from the start:

Stage	What it contributes
AI deep-read	Reads everything; drafts findings at scale; cites the source code
Senior-engineer review	Confirms real rules vs. fossils; corrects misread intent; resolves contradictions
Original-author validation	Supplies the why; flags what the code can’t reveal — where the author is still available
Parity validation	Proves the recovered behavior against the running system, slice by slice

The AI does the reading; people and evidence do the deciding. This isn’t a hedge bolted on for comfort — it’s the design. The technology’s real contribution is that it makes comprehensive review possible at all, by doing the reading that humans never had time to finish, then handing experts a concrete draft to react to rather than a blank codebase to excavate. The judgment stays human; what changes is that the judgment now operates on the whole system instead of the part someone managed to read.

What a deep-read can’t do

The deep-read has limits that matter, and naming them is part of using it well. It reads what’s in the code, so anything the code doesn’t contain, it can’t recover — the why behind a rule, a constraint enforced by an external system, an undocumented dependency on a partner’s behavior. It can be confidently wrong, which is precisely why nothing it produces is trusted unverified. And it accelerates analysis; it does not by itself make a modernization safe — that’s the job of parity validation, which proves behavior against the running system rather than against the AI’s reading of it. The right mental model is a tireless, fast, literal-minded engineer who has read every line and remembers all of it — but who has never spoken to a customer, sat in a planning meeting, or seen the system fail at 3 a.m. Enormously valuable, and not the final word. Pretending otherwise would be the same overclaim the parity discipline exists to prevent.

Where this leads

A deep-read produces a true picture of the system today — but a picture taken today starts drifting tomorrow, the same way the old documentation did (Part 2). The recovered knowledge is only worth capturing if it stays true as the system keeps changing. Part 7, Living Specs — Documentation the Team Owns, is about the form that knowledge takes so it doesn’t become next year’s drift.