Skip to content
Article reader Listen + reading controls
LISTEN + READ YOUR WAY

Article reader

Preparing the reader…

0:00 0:00
Reading settings
Text size
100%

The first deliverable from generative coding should be understanding

The most dangerous sentence in a modernization program may be, “We know what this system does.”

Usually, someone knows what the system is supposed to do. Operators know the screens and workarounds. A few engineers know where the brittle integrations live. Program managers know the contracts and milestones. Cybersecurity teams know some of the exposed surfaces. The source code knows all of it at once—but in a form no single person can hold in mind.

That is why the emerging market for generative coding matters to government for a reason deeper than writing software faster. Its first serious public-sector use may be helping an organization recover a working model of the technology estate it already owns.

This week's modernization report is really about uncertainty

The U.S. Government Accountability Office (GAO) reported last week that the Technology Modernization Fund (TMF) had invested about $1.03 billion in 68 federal information-technology projects through fiscal year 2025. Twenty-four projects expected combined savings of approximately $1.06 billion. Eleven had realized $13.5 million, while most of the expected savings were scheduled for fiscal year 2027 or later.

The early savings figure should not be read as a verdict on the fund. Thirty-seven projects were designed to produce other value, including reduced security risk, and many investments are still active. The more revealing detail is why some completed projects missed their savings targets: agencies cited removed functionality and migration costs that proved higher than planned.

Those are not merely budgeting problems. They are signs that a modernization team learned something important about the old environment after the estimate had already become a plan.

The pattern is familiar. A legacy application may appear to perform one business function while quietly supporting dozens of interfaces, reports, exceptions, batch processes, security decisions, and downstream users. A migration estimate prices the visible system. Delivery encounters the accumulated institution.

GAO's 2025 review of critical federal legacy systems makes the scale of that problem difficult to dismiss. Eight of the eleven systems it identified used outdated programming languages, seven operated with known cybersecurity vulnerabilities, and several agencies lacked complete modernization plans. The list included a 60-year-old Department of Defense (DoD) system and Treasury systems written in Common Business Oriented Language (COBOL) and assembly language.

Age is only part of the difficulty. A system becomes hard to replace because years of policy, operational judgment, data relationships, and local repair have been compressed into its behavior. The code is not the whole institution, but it has become one of the institution's most durable memories.

Developers do not begin with typing

Popular demonstrations of generative artificial intelligence (AI) make software development look like an act of composition: describe a feature, receive code, run it, and revise. That works when the problem is bounded and the surrounding environment is simple enough to fit inside the exchange.

Enterprise change begins differently. Before editing a large system, an engineer has to reconstruct a mental model. Which components participate in this behavior? Where does the data originate? What calls this interface? Which convention is intentional? Which apparent duplication is carrying a hidden compatibility requirement? Who understands the failure mode that appears only at the end of a reporting cycle?

Research on developer work has documented this burden for years. LaToza, Venolia, and DeLine found that developers invest substantial effort recovering implicit knowledge and maintaining mental models. Sillito, Murphy, and De Volder catalogued the many questions programmers must answer while performing a change task. The difficult work is not confined to writing the new lines. It is discovering the relationships that make a safe change possible.

This is where a knowledge graph can become more than fashionable architecture terminology. A knowledge graph represents entities and the relationships among them: a service calls an interface; a field is consumed by a report; a package implements a control; a test covers a behavior; a repository belongs to a team; a decision introduced a constraint. Hogan and colleagues' survey of knowledge graphs emphasizes their value for integrating and querying diverse, changing collections of information.

Applied to software, that structure can help an engineer ask questions across files, services, dependencies, documentation, tests, and history instead of searching each source separately. More importantly, it can give many agents and many people a shared representation of the estate they are changing.

The graph is not truth simply because it is a graph. It can be incomplete, stale, overconnected, or confidently wrong. Its usefulness depends on lineage, versioning, access control, validation, and an explicit record of uncertainty. But a maintained graph can make the unknowns visible earlier—before they appear as migration cost, missing functionality, or operational surprise.

A new class of coding system is moving comprehension into the product

Blitzy is one company making this architectural argument publicly. Its documentation describes an ingestion process that analyzes an existing codebase for architecture, patterns, and domain terminology; produces a reviewable technical specification; develops an Agent Action Plan showing intended file changes; and performs runtime validation before proposing a pull request. The company's founders describe a knowledge graph used to ground long-running, coordinated agents in the codebase and its dependencies.

Those are company claims, not independent proof that the system will understand a particular federal estate or satisfy a particular mission, security boundary, or authorization. They are nevertheless evidence of an important product shift. The unit of value is moving from a clever code completion toward an evidence-producing system for understanding, planning, changing, and validating software at estate scale.

That shift is unusually relevant to government. Federal agencies do not suffer only from a shortage of code. They suffer from systems whose knowledge has become expensive to recover, modernization plans that cannot see every interdependency, and delivery organizations that must preserve mission continuity while changing the machinery underneath it.

The immediate opportunity is therefore not “let an agent rewrite the government.” It is to use this class of system to reduce the cost of knowing what must be true before a rewrite, refactor, consolidation, or migration begins.

Kessel Run shows how quickly the front of the process is changing

The Air Force is already testing what faster development feels like. In June, Kessel Run brought Airmen and civilian leaders into a two-day, hands-on AI development course. Participants moved from a user story to a deployed application, and instructors compared the result with work that might previously have taken four to six months. Kessel Run leadership also emphasized that the training helps acquisition professionals evaluate the timelines vendors propose.

That is a meaningful change in the economics of a prototype. It does not eliminate the economics of production.

Kessel Run's larger work makes the distinction clear. The organization builds resilient command-and-control software intended to create operational decision advantage. Its Aerospace Readiness Enterprise System effort is bringing together previously siloed aircrew-management systems, multiple major commands, a proposed common data layer, and an eventual user base of roughly 149,000 Airmen. The Air Force has paired competitive prototyping with direct operator feedback while warning that early concepts are not the final product.

AI is flattening the cost of the first draft. The enduring public-sector problem is integrating that draft with a mission, an installed estate, a security model, an acquisition program, an operating organization, and a body of users who cannot stop working while the technology changes.

Generative coding becomes strategically important when it helps with that second problem.

What estate-scale comprehension could accomplish

The most promising public-sector use cases begin before autonomous implementation.

Recover institutional memory

A system can map architecture, interfaces, business rules, dependencies, test coverage, ownership, and change history into a navigable technical model. Engineers can challenge that model; operators can identify missing behavior; program teams can expose places where the documented system and the practiced system diverge.

The result is not just better documentation. It is a shared object around which developers, cyber professionals, acquisition teams, and mission owners can resolve different understandings of the same estate.

Improve the modernization estimate

Before promising a migration schedule, a team can identify high-coupling components, unsupported dependencies, fragile build paths, duplicated capabilities, hidden consumers, and functions with weak tests. The first estimate will still be uncertain, but its uncertainty will be attached to named parts of the system rather than buried inside a contingency percentage.

This is where the connection to the new TMF report becomes practical. If higher-than-expected migration costs and removed functionality reduce expected savings, then earlier discovery of dependencies and behavior has economic value even before an agent writes production code.

Make bulk change safer

Many public systems carry large backlogs of repetitive but consequential work: framework upgrades, dependency replacement, vulnerability remediation, interface changes, accessibility improvements, policy updates, and technical-debt reduction. An estate model can help identify the full change surface and coordinate proposed work across repositories.

Generation should still terminate in customer-controlled review. The National Institute of Standards and Technology Secure Software Development Framework treats secure development as a set of organizational practices across preparation, protection, production, and vulnerability response. An agent does not inherit permission to bypass those practices merely because it can produce more code.

Preserve a usable technical baseline

Modernization programs often pay repeatedly to rediscover the same estate. A maintained technical model can improve onboarding, transition between contractors, incident response, architecture review, and future acquisition. It can also reduce dependence on the handful of people who know where the difficult truths are buried.

That does not make experienced people less important. It moves their contribution from answering the same archaeological questions toward correcting the institutional model and making the decisions that automation cannot own.

The first pilot should test understanding

Government buyers should resist beginning with the largest possible code-generation demonstration. A better evaluation uses graduated autonomy and makes comprehension the first acceptance gate.

  1. Observe. Give the system read-only access to a representative estate. Ask it to produce architecture, dependency, dataflow, build, test, and ownership views with source-level provenance.
  2. Interrogate. Use questions that experienced maintainers already know are difficult. Measure answer accuracy, evidence quality, uncertainty, access control, and freshness—not merely response speed.
  3. Recommend. Ask for a bounded change plan that names affected components, assumptions, risks, tests, and rollback conditions. Let engineers reject or revise the plan before execution.
  4. Sandbox. Execute the approved work in an isolated environment without production credentials. Preserve the complete relationship among the request, plan, source version, agent actions, tests, and resulting artifacts.
  5. Propose. Deliver the work through a pull request into customer-owned continuous integration (CI), including withheld tests, security analysis, human review, and the ordinary release authority.
  6. Integrate deliberately. Expand authority only when the evidence shows lower total effort and acceptable risk. A successful generation is not yet an operationally accepted capability.

The scorecard should include time required to answer estate questions, coverage and correctness of the system model, reviewer effort, defects found before and after acceptance, change failure and rollback performance, and the amount of legacy functionality actually retired. Generated lines of code are an activity measure. They are not the mission outcome.

Buy the evidence, not the magic

The acquisition model matters as much as the technical model. A federal pilot should require portable outputs: architecture and dependency views, specifications, plans, decision records, source changes, tests, provenance, build instructions, and known limitations. The agency should be able to retain and use what it learned even if it does not buy the next phase.

The Department of Defense Instruction governing the Software Acquisition Pathway calls for iterative delivery, user engagement, cybersecurity, test, and continuous planning. Estate-scale AI should strengthen that operating model, not create a parallel route around it.

The central buying question is not whether an autonomous system can generate an impressive volume of software. It is whether the system can make the estate more legible, make a proposed change more reviewable, make evidence easier to preserve, and reduce the combined effort required to reach an accepted mission outcome.

If it can, the value begins before generation and survives after the agent stops.

Understanding changes the modernization frontier

The federal government does not need another promise that old software can be replaced quickly once everyone agrees on the requirements. The hard part is that the requirements, dependencies, exceptions, and operational truths are already dispersed across code, people, processes, and time.

Generative coding will matter most when it can help assemble that picture without pretending the picture is complete.

The most valuable system may not be the one that writes the most code. It may be the one that helps an agency know what it owns, why it behaves as it does, what can change, what must remain, and how to prove the difference. Once the estate becomes legible, generation can accelerate implementation. Without that understanding, speed is simply a faster way to discover old surprises.

Sources and research trail

READER-NEUTRAL SUBSCRIPTION

Follow Field Notes via RSS.

Copy this address into the RSS reader you already use. New notes will appear there automatically—no account, email address, or tracking required.

Open the feed