I spent 25 years as a federal contractor, much of it delivering software acquired through the Department of Defense acquisition process. At no point did I feel that the way the government acquired software was particularly well aligned with how we actually built it. Over time, I began to suspect that our customers felt the same way.
The acquisition process placed considerable emphasis on documents. Requirements specifications, interface specifications, test plans, and such were the artifacts around which progress was measured and reviews were organized. The working software sometimes seemed like an afterthought, despite being the thing the customer was ultimately paying for.
That’s not to say those documents were unnecessary. We needed requirements, interface definitions, and documentation. But there was a difference between the artifacts that satisfied contractual obligations and the work that actually moved the software forward.
In my previous post on AI and waterfall development, I considered whether AI-assisted development might make more extensive upfront specification economically attractive again. That got me thinking about another aspect of the acquisition process. What happens when the cost and duration of implementing software change substantially, but the processes used to procure it don’t change at the same rate?
Federal software acquisition has been the subject of reform efforts for decades. The government has legitimate obligations concerning competition, accountability, security, and the expenditure of public funds. Those obligations don’t disappear because software becomes easier to produce. But the processes developed to satisfy them also impose costs, and those costs don’t necessarily decline when implementation becomes less expensive.
The Defense Innovation Board addressed the mismatch between hardware and software acquisition in 2019, arguing that software required different management practices, with greater emphasis on delivery speed and shorter feedback cycles. DoD responded with its Software Acquisition Pathway in 2020, providing an alternative to traditional acquisition processes. In March 2025, the Secretary of Defense directed that it become the preferred pathway for software components of business and weapon systems, encouraging Commercial Solutions Openings and Other Transactions where appropriate.
Reform is underway, although the economics of software implementation may be changing faster than the reforms can take hold. A 2024 Government Accountability Office report provides an interesting look at procurement administrative lead time, or the period between issuing a solicitation and signing a contract. For DoD awards above $250,000, the overall median declined from 41 days in fiscal year 2019 to 32 days in fiscal year 2022. Orders placed through existing contract vehicles had a median of just 21 days, while information technology awards had a median of approximately 25 days.
New contracting arrangements told a different story. New definitive contracts had a median of 97 days, and new indefinite-delivery vehicles took 179 days. Among awards of $50 million or more, median procurement lead time increased from 185 to 255 days over the period examined.
These figures don’t establish that procurement takes longer than software development. They exclude the time spent defining requirements or planning an acquisition before solicitation, and they don’t measure development duration for the software purchased. They also don’t cover all the alternative acquisition mechanisms DoD increasingly uses. They do show that procurement isn’t uniformly slow, with longer lead times often associated with larger, more complex contracting arrangements.
AI could change the relationship between those procurement schedules and implementation time. A GitHub Copilot experiment found that developers completed a bounded programming task 55.8% faster with AI assistance. A larger study across three enterprise development environments found an average 26% increase in completed tasks. METR’s research found a different result: experienced developers working in familiar, mature codebases took longer with the AI tools available in early 2025.
Those findings concern development tasks rather than complete federal software programs. Integration, security testing, deployment, and sustainment remain substantial activities. Still, even uneven reductions in implementation effort could alter the economics of delivery. If implementation gets cheaper while procurement and verification change less, those activities account for a greater share of the total cost, even without any increase in what the government spends on them.
Much of federal technology contracting is priced, directly or indirectly, on labor. Even when a contract isn’t billed by the hour, cost estimates and proposals often depend on assumptions about labor categories, staffing, hourly rates, and the effort required to complete the work.
Under time-and-materials arrangements, fewer hours can mean lower government expenditure but also lower contractor revenue for a given deliverable. Under firm-fixed-price arrangements, a contractor that becomes more productive generally retains the savings during the contract, with competition potentially passing some of those gains to the government later. Cost-reimbursement contracts have their own allocation of risks and incentives.
Hourly billing represents a relatively small portion of DoD obligations. A GAO study found that time-and-materials and labor-hour contracts accounted for approximately 1% of DoD obligations during fiscal years 2017 through 2021, compared with about 11% for civilian agencies. Labor estimates still matter in other contract types, including fixed-price proposals.
If AI allows a smaller team to produce the same capability in less time, historical assumptions about the labor required to deliver that capability may become less useful. Those estimates need to reflect the actual productivity of the tools and people performing the work. An April 2026 executive order established fixed-price contracts with performance-based considerations as the federal default, subject to exceptions and approval requirements. That policy direction could complement AI-assisted requirements engineering, which may make it less expensive to prototype alternatives, clarify expectations, and develop acceptance criteria before soliciting proposals.
A contractor can price a known, verifiable outcome more confidently than an open-ended obligation whose requirements remain uncertain. AI can’t eliminate uncertainty about what an agency needs or how a solution will behave in its operating environment. Fixed-price contracting also leaves technical risk intact. Contractors may account for uncertainty through higher prices, restrictive change provisions, or decisions not to bid.
Agencies may nevertheless be able to invest more effort in defining and validating the capability they need while leaving contractors greater flexibility in how to produce it. This brings me back to the documents I spent so much time producing early in my career.
Specifications and acceptance criteria can be valuable tools for producing reliable software. They can also become contractual artifacts whose completion is treated as progress independently of whether the resulting software meets the customer’s needs. AI may make producing those documents much easier, although the quantity of documentation has little bearing on whether the acquisition succeeds.
Value would come from better specifications that can be connected to independently verifiable results. If AI helps an agency describe what it needs, evaluate alternatives, and establish meaningful acceptance criteria, those activities may become more useful than monitoring the number of developers assigned to a contract or the volume of documentation they produce. The government still needs independent evidence that a system works, meets its requirements, and can operate securely. Faster code generation could increase the importance of verification if it produces more software than existing review processes can adequately examine. The question is how much of the activity surrounding that evidence actually contributes to confidence in the delivered capability.
For much of my career, the acquisition process seemed to dictate how software development was organized. AI may create an opportunity to reconsider that relationship, particularly if implementation labor becomes less important relative to the expertise and assurance needed to deliver working software.
We don’t yet have comparable procurement and development timelines for the same federal software projects. Such evidence would help establish where acquisition is becoming a constraint. Different parts of the process respond to different economic pressures, and there’s little reason to assume they’ll all change at the same rate. If the cost of building software changes substantially, it may be time to reconsider how software is purchased and how to primarily align spend around specification, verification, and validation.
Header image: Battleships of the Future cut away from Popular Mechanics in 1940. Image Credit: Creative Commons.
