Code as Data Governing and Evolving Large-Scale Codebases in the Era of AI (early release) (Bryan Friedman, Pat Johnson, Olga Kundzich)（Z-Library）

【One-Line Pitch】 A concise, framework-driven report on treating source code as structured, queryable data so that large, multi-repository software estates can be governed, secured, and safely evolved—especially as AI agents start writing and changing code at machine speed. Best for engineering leaders, architects, and senior engineers responsible for sprawling codebases. 【Book Arc】 - **Opening (~0%–6%)**: Frames the core problem—source code is one of an organization's most critical assets, yet it is largely ungoverned compared to customer data, producing technical debt, security exposure, stalled modernization, and unreliable AI automation. Introduces the "code as data" thesis and the book's structure. - **Early (~6%–31%)**: Diagnoses the "unknowable multi-repo software estate." Traces how software outgrew the single-repository assumption (services, shared frameworks, dependency graphs) and why today's tools—search, static analysis, SCA, architecture registries, spreadsheets—give incomplete representations that cause false positives, alert fatigue, and stale data. Ends with a self-assessment: if you can't answer several routine questions about your estate within an hour, you have a code intelligence gap. - **Early–Middle (~31%–44%)**: Extends the problem to AI agents. Coding agents inherit the same context deficit, inferring what they can't know—fast, confident, and sometimes wrong. Argues the fix is not slowing agents down but improving the systems they operate within, and states the book's audience and scope. - **Middle (~44%–56%)**: Introduces the Lossless Semantic Tree (LST) as the enabling representation—lossless, semantic, and tree-structured, achieving compiler-accurate type resolution across the full classpath. Explains its three layers (markers, syntax, type attribution) and its honest handling of unresolved types and unparseable files. - **Middle (~56%–63%)**: Moves from model to practice: building LST artifacts, incremental builds, serializing LSTs for portfolio-scale work ("parse once, query many times"), and the recipe as a deterministic query-and-transformation language that can run across many repositories at once. - **Late (excerpts do not cover)**: The table of contents lists later chapters on unified codebase views, understanding software beyond the SBOM, semantic program analysis for security, governing AI models/agents/generated code, and turning code-as-data into automated action—but these chapters are marked unavailable in the excerpts, so their content is not summarized here. 【Key Takeaways】 - **Code is an ungoverned asset** (Opening): Organizations manage customer data rigorously but leave source code unmanaged, which directly fuels technical debt, security exposure, and unreliable automation. - **The multi-repo estate exceeds human comprehension** (Early): Thousands of repositories, billions of lines, and millions of transitive dependencies mean no single team can hold the system in their head—and repository-scoped tools were never designed for estate-wide reasoning. - **Existing representations are structurally incomplete** (Early): Text, ASTs, dependency inventories, and architecture catalogs each capture only part of the picture, producing false positives, alert fatigue, and drift. - **AI agents inherit the same context problem** (Early–Middle): Agents reconstruct understanding from the outside in, inferring what they can't know; this is expensive, inconsistent, and scales uncertainty with velocity. - **The LST is the proposed foundation** (Middle): A lossless, semantic, compiler-accurate tree that resolves types, generics, and dependencies across the classpath while preserving formatting—and honestly marks what it cannot resolve. - **Serialization turns ephemeral builds into queryable assets** (Middle): Persisting LSTs per repository enables portfolio-scale questions—like which services are affected by a shared library change—to be answered in minutes. - **Recipes make change deterministic** (Middle): Reusable, composable transformations traverse LSTs to search or remediate across many repositories, emitting structured data tables as a byproduct—unlike probabilistic AI suggestions. - **The goal is grounded autonomy, not slower agents** (Middle): Accurate shared representation lets agents act with authoritative context while preserving human oversight of cumulative, estate-wide change. 【Reading Tips】 - **Deep-read Chapters 1–2** (the only available content): they carry the full argument—problem diagnosis, the LST model, and the recipe mechanism. Treat the rest of the table of contents as a roadmap, not as material you can currently study. - **Use the "impossible questions" list as a diagnostic**: if your team can't answer three or more within an hour, that is your concrete starting point before adopting any tooling. - **Skim the historical framing** (IDE era, grep, Tree-sitter) on a first pass; the durable value is in the representation and governance argument, not the chronology. - **Watch for the LST's honesty property**: the placeholder-for-unresolved-types behavior is a design principle worth carrying into your own tooling evaluations—knowing what you don't know. - **Take away one action**: identify a portfolio-scale question (e.g., a shared library API change) that no single repository can answer, and use it to test whether your current tooling closes the gap. 【Coverage Limits】 This guide is based on an early-release sample covering roughly the first two chapters; later chapters on unified codebase views, SBOM alternatives, semantic security analysis, AI governance, and automated action are listed but unavailable, so their specific claims are not summarized.