The Bus is Leaving...

The Bus is Leaving...

Ten months ago, I sat across from Dave Wennergren on the Accelerating Government podcast and said something I believed then and believe more forcefully now: getting AI-accelerated coding tools into the hands of government developers is the single most impactful thing agencies can do to improve delivery outcomes. Not AI strategy documents. Not governance frameworks. Not pilot programs. Tools. In the hands of the people who build things.

In the ten months since, I've watched agencies prove me right by doing the opposite.

The Failure Pattern

The pattern is depressingly consistent. An agency stands up a task force. The task force spends months evaluating tools that were state-of-the-art when the evaluation began but are a generation behind by the time procurement clears. Meanwhile, leadership attention drifts toward flashier AI narratives: chatbots for citizen services, predictive analytics dashboards, autonomous decision-making systems that exist mostly in vendor slide decks.

The core technical teams — the developers, the architects, the engineers who actually build and maintain the systems — get nothing. Or worse, they get a constrained, outdated tool deployed behind so many guardrails that it's functionally useless.

ICF's AI Impact at Scale report quantified what practitioners already knew: federal agencies take an average of 6.7 months to move from concept to prototype. Another 10 to 17 months to reach production. That's nearly two years from idea to operational capability. In the same window, commercial teams using agentic development tooling are shipping production systems in weeks.

The Brookings Institution confirmed the structural barriers: workforce capacity constraints, risk-averse culture, procurement and funding challenges. These aren't new observations. They're the same barriers that have plagued federal IT for two decades. What's new is the cost of inaction. The gap between government delivery speed and commercial delivery speed isn't linear anymore. It's exponential.

Tools First, Strategy Second

I'm not speaking from theory here. I've been leading AI-accelerated development adoption since Amazon Q Developer launched, and I was building with Kiro before it was publicly announced. I've watched these tools hit a maturity that accelerates teams like a railgun when applied with discipline — only to be completely eclipsed six months later when the next wave arrives. The velocity of improvement is itself accelerating. Every month an agency delays deployment, the gap between what their teams could be doing and what they are doing widens further.

Government technology leaders have the sequence wrong. They want strategy before tools. They want governance before experimentation. They want a comprehensive AI plan before a single developer gets access to a coding assistant.

This is backwards.

You don't need a strategy to give your developers better tools. You need a purchase card and a security review. The strategy emerges from what your teams learn when they're actually using the technology, not from what a working group imagines the technology might do.

The data supports this. Microsoft's Copilot in Government Cloud Community (GCC) environments runs 6 to 12 months behind the commercial release. In GCC High, that gap stretches to 12 to 18 months. By the time agencies deploy what they procured, the commercial sector has moved two product generations ahead. The tool your developers finally get access to is already the tool that commercial developers have abandoned for something better.

This isn't a procurement problem dressed as a technology problem. It's a leadership problem dressed as a procurement problem. Leaders who understand the imperative find ways to move. Leaders who don't, hide behind process.

The Value Stream Is the Real Bottleneck

Here's what makes this particularly absurd in 2026. Agentic development tools have compressed the building phase of software delivery from months to days. Production-ready code that previously required weeks of engineering effort can emerge from a well-structured afternoon with the right tooling. The development phase is no longer the constraint.

Which means the absurdity of the surrounding process becomes impossible to ignore.

When software can be built in days, spending months to define requirements is indefensible. Taking quarters to procure the development environment is a failure of imagination. Performing archaic risk analysis that assumes waterfall delivery timelines while demanding agile outcomes is organizational incoherence. And sustaining a 6-to-18-month ATO process for systems that could be rebuilt from scratch in the time it takes to authorize them — that's not risk management; it's self-sabotage.

The delivery risk doesn't live in the code. It lives in the entire value chain: the requirements definition, the procurement cycle, the security theater, the operational integration, the sustainment model. Accelerating one link in the chain while leaving the rest unchanged doesn't produce faster outcomes. It produces a faster engine bolted to a stationary frame.

The Question That Matters

If you're in a technology leadership position overseeing programmatic development, the first question should be straightforward: Do my teams have the tools to be competitive for the type of delivery objectives I expect?

If the answer is no, nothing else you're doing matters. You cannot optimize what you haven't enabled. No amount of governance, strategy, or organizational redesign compensates for a developer working with yesterday's tools against today's timeline expectations.

The second question is harder: If accelerated technology delivery doesn't help when the rest of the value stream is still optimized for 18-month cycles, how do I partner with others to align toward faster end-to-end outcomes?

That question places the modernization discussion exactly where it belongs: outside the tent of IT and into the hands of agency leadership. This is not a CIO problem. This is a mission delivery problem that happens to require technology.

The Powell Precedent

In 2001, Colin Powell arrived at the State Department and found that employees had to stand in line for a single shared dial-up terminal to access the internet. He declared himself the agency's chief information officer, ordered 44,000 internet-capable computers, earmarked over $110 million, and made it happen. Not because he had a technology strategy. Because he understood that you cannot conduct foreign affairs in the information age without giving your people access to information.

The imperative today is identical in structure and greater in urgency. You cannot solve your agency's most challenging problems if your technical teams lack the tools the private sector considers baseline. You cannot iterate toward better outcomes if each iteration takes two years. You cannot compete for talent if your development environment looks like it was frozen in 2019.

Get On or Get Off

"How do we get from idea to outcome in less than a week?" That should be the mantra. That's the bus. And the bus is leaving.

We are seeing it happen in specific cases. Isolated programs where leadership understood the imperative, broke through the process barriers, and enabled their teams. But they're too few to be measurable. They stand out as outliers rather than exemplars. They represent best practice without being accepted practice — and those two things are very different.

The agencies that figure this out will attract the best talent, deliver the best outcomes, and justify their budgets with measurable results. The agencies that don't will spend years explaining why their AI strategy hasn't produced anything while their commercial counterparts ship the future.

The tools exist. The evidence exists. The only missing ingredient is the will to act on both.