Cost overruns are the recurring invoice on the table whenever the military promises advanced autonomy will change warfare. The headline numbers vary by program, but the root causes follow a familiar pattern: immature requirements, vast hidden software effort, brittle supply chains, and acquisition cultures built for hardware milestones rather than iterative software delivery. The result is a portfolio that is more expensive and slower to field than planners expected.
Anyone who has integrated perception, planning, and control stacks into a prototype knows the math does not stop at the airframe or hull. You can buy a hull, air vehicle, or chassis on a line card. The real cost sits in the stack above it: compute, sensors, communications, data labeling, simulation rigs, distributed testing, cyber hardening, and the continuous engineering to keep models working in the real world. The Government Accountability Office found that some services estimated acquisition costs for uncrewed systems without accounting for the necessary digital infrastructure and sustainment, understating the true life cycle bill.
Software is not a mere line item. It is the dominant driver of cost growth and schedule slips on today’s complex weapon systems. GAO’s 2023 assessment of DOD programs flags software development delays, supplier disruptions, and quality control problems as primary drivers of new schedule slips and increased program costs. Programs that balloon in software scope routinely see R&D and integration budgets expand well beyond original baselines because software amplifies interdependencies and testing needs. Treat code as a trivial add on and you will pay for that hubris in rework and schedule extensions.
Concrete examples matter. Major modernization efforts that involved heavy software integration have produced large overruns and late fieldings. The F-35 Block 4 modernization, for example, showed how long software-driven efforts can shift cost and schedule assumptions and create opaque accounting of where money went. That pattern is the cautionary tale autonomy projects keep repeating when they swap avionics and payloads or keep adding capabilities midstream.
Another predictable source of overruns is insufficient systems engineering up front. Programs that enter development without mature technologies or without stable integration plans invite discovery-phase shocks later. For unmanned maritime systems the Navy estimated billions to acquire vehicles but did not fully cost the AI and information systems needed to operate them. GAO recommended stronger portfolio management, clearer prototype evaluation criteria, and full life cycle cost estimates before committing to production quantities. When acquisition timelines and budget commitments outrun knowledge about the autonomy stack, spending rises and outcomes fall.
Industry and service leaders are not blind to the problem. Part of the answer embraced in 2023 was to shift toward smaller, attritable systems bought in bulk and developed with more commercial practices. The Department of Defense’s Replicator initiative, announced in August 2023, explicitly aimed to field many lower cost autonomous assets quickly as an alternative to protracted, expensive flagship programs. That pivot acknowledges the arithmetic: cheaper, modular platforms plus repeatable software delivery can be more affordable than single, bespoke systems with monolithic software efforts. But the approach only works if the department also budgets realistically for the enabling software and sustainment infrastructure.
Where programs go wrong in practice is predictable and fixable. First, requirement creep and late capability adds must be constrained. Every new capability requested after development start multiplies integration and verification effort across sensors, comms, and behaviors. Second, acquisition needs to treat autonomy as a software-intensive system. That means funding and scheduling for simulation fidelity, large-scale regression testing, continuous integration pipelines, cyber resilience testing, and data management in the initial program baseline. Third, portfolio management matters. When services plan dozens of prototypes and production lines independently, they lose economies of scale in shared software, tools, and infrastructure. GAO recommended consolidating oversight of related efforts so that common elements are funded and matured once, instead of reinvented across programs.
From the trenches I would add five practical rules to keep autonomy budgets honest:
- Cost the digital infrastructure up front. Include simulation farms, data ingestion, annotation, compute tenancy, and long term model retraining as explicit line items. Do not assume those are incidental sustainment costs.
- Force knowledge gates before committing to production. Prototype performance in operationally realistic environments must be demonstrable and measurable before scaling hardware buys. Use pass fail metrics for autonomy behaviors, not vague maturity language.
- Budget for operational experimentation and failure. Attritables can fail in service. That is acceptable only if lifecycle costs and replenishment are planned. Unplanned losses create political pressure to overengineer or to stop programs altogether.
- Adopt iterative software practices and contract incentives that reward delivered software capabilities and maintainability rather than milestone paperwork. The companies that ship frequent, tested releases tend to discover and fix corner cases earlier and cheaper.
- Make sustainment visible. Autonomy systems do not sit on a shelf once delivered. They require continuous ops engineering. Treat sustainment budgets as equal partners to procurement budgets.
There is also a political dimension. Large, legacy acquisition programs carry institutional weight and established suppliers. Autonomy favors fast, modular companies and new supply chains that do not always fit existing contract vehicles. That cultural mismatch can push services back toward large, bespoke designs because that is how budgets and authorities flow today. If policymakers want cheaper, faster autonomous capabilities they must align requirements, authorities, and incentives to reward iteration, openness, and reuse.
Cost overruns in advanced autonomy projects are not inevitable. They are the predictable consequence of underestimating software, underfunding infrastructure, and overpromising on novelty without sufficient prototyping. The fix is technical, managerial, and cultural: stop treating autonomy as a payload and start treating it as a complex, software-defined ecosystem that must be resourced end to end. When program offices do that, and when Congress and the services demand realistic baselines and knowledge-based transition criteria, autonomy can deliver mass and capability without bankrupting the modernization account. Until then expect high invoices, delayed rollouts, and more programs reinventing the same expensive mistakes.