Code creation was never the bottleneck for government

At this moment, there is a team in a government department that believes they can deliver changes to a service that could make life easier for users, and save taxpayers money. The change would take hours to write. Getting approval to deploy it will take weeks or months. During that time, citizens gain zero benefit from code that is ready and waiting.

This pattern repeats across government, every day.

And yet, across the country, dozens of departments are investing significant time and energy into selecting the “best” AI coding assistant. Business cases are being written. Procurement plans drafted. Time saving analysis is being undertaken.

This isn’t the wrong move. But if we’re honest, it’s not the highest value target for AI.

With AI code generation, government would be solving part of the problem that’s visible, measurable, and comfortably within control. The real bottleneck (the approval queues, risk-averse governance, and the months-long journey from working code to live service) is harder to visualise, subtly political, and difficult to fix.

And unfortunately, the system of work frequently rewards preventing a visible mistake over achieving a more rapidly realised gain. A failed deployment can create headlines and headaches. A delayed one just creates a queue.

Rational people make rational choices inside irrational systems. So they optimise what they can measure, instead of what matters.

Sadly I believe AI coding assistants feed into some of our worst instincts. Managers are becoming fixated on how many lines of code AI can write per minute and how many licences can be deployed by an arbitrary date, as if code creation is the part of the system that’s not working.

These behaviours aren’t new. If anything, AI is giving individuals an opportunity to revert to outdated practices. Consider, for example, the government AI tender split into exploration, development, and operations, with separate vendors required for each lot, as if defined in a pre-2009 DevOps Days world.

But, when government can’t deploy improvements quickly, real people pay the price.

The Green Deal, 2010’s flagship energy efficiency scheme, took years to develop and ultimately failed to meet its goals. Core assumptions about human behaviour weren’t tested until implementation of the full scheme was well under way. By then, the ship had sailed. The cost wasn't just financial, it was a wasted opportunity.

That’s a pretty substantial example, but change doesn’t occur exclusively on a programme level. Services should grow, shift, and evolve every single day.

When this change is stymied by process it has a measurable impact on us all.

From the single parent who spends 40 minutes on the phone today because a benefits form is still broken, to the small business owner who abandons a grant application because the service doesn’t work on the first try.

This is the daily, human price of an ineffective path to production.

When we zoom out, the scale of inefficiency is scary. The State of Digital Government Review estimates £45-87 billion per year in unrealised savings and productivity, equivalent to 4–7% of all public sector spending.

The bottleneck isn’t writing code, or a lack of it. It’s getting it into the world.

Having worked with a range of organisations to visualise their path to production over the past few years there are patterns that reoccur. A team has a good idea. They build it in days or weeks. Then it sits in queues.

Security review, compliance documentation, infrastructure provisioning, a change approval board that meets monthly, three or four sign-offs from people who've never been anywhere near the service. Most of which is handled via tickets, emails, and calendar invites.

By the time the improvement reaches the public, the context window has also frequently changed and various learning opportunities have evaporated. No rapid feedback. Limited iterative improvement. Greatly reduced value.

This isn’t a developer productivity problem. This is a shipping problem.

During COVID, Test and Trace, despite its well-documented flaws, showed what happens when urgency forces the system to operate in a different gear. Teams tested ideas in 24 hours, learned fast, and iterated.

And, while the pace of work during that time may not have been sustainable, many individuals working across government still reflect on COVID as a period where teams truly showed what was possible. One engineer I worked alongside even remarked “That’ll show ‘em” when they delivered an entire service within days - from idea to reality.

For some reason in a post-COVID world we preserved the bureaucracy, but not the speed. Why do we need an emergency to deliver value sooner?

Maybe it’s because the current governance model is designed to minimise visible risk, not maximise citizen value.

This is where AI could have a far greater impact.

AI coding assistants do help. They increase confidence, reduce toil, and, when integrated well, enrich the craft of development. They are, in many ways, the studio apprentices helping the artist prepare the canvas.

But improving the creative process doesn’t matter if the gallery doors stay locked.

Current government approaches to AI coding assistants are thoughtful. They include governance, training, champion networks, community learning, reusable artefacts, and shared code. This will almost certainly improve developer experience, onboarding, and morale. It will chip away at contractor costs. These are good, worthwhile goals.

But the biggest leverage point isn’t in writing code more effectively. It’s in removing the friction that stops value reaching the public.

So, why not imagine AI capabilities that auto-generate compliant documentation from code, rather than teams writing it weeks later. Capabilities that provide real time policy and security rule validation inside the IDE. AI that can continually test resilience, performance, and accessibility during development. Reduce the average risk exposure window by automating assurance. Lower the cost of experimentation so testing ideas becomes routine.

Except you don’t have to imagine any of this. These capabilities exist.

What’s missing is the green light to get them adopted, and champions in the heart of government to paint this picture.

We also need champions that collaborate and reduce fragmentation. AI sprawl is a growing issue, and while departments individually assess coding assistants and adopt their own bespoke approach, we could be unifying around common patterns that optimise away our shared bottleneck across government.

While nobody would accept a mandated platform, common guardrails and accelerators that make the right path the happy path would be a step in the right direction. 

Shared, centrally stewarded capability that accelerates the path to production.

A Blueprint for Modern Digital Government points towards this, but ownership is still unclear. Someone needs to be accountable not just for “tooling adoption” but for whether government can ship.

This starts with measuring what matters. From the median time to value, to average experimentation delay. This would likely expose that writing code isn’t in the top five blockers, and that governance wait time dwarfs coding time.

For service teams in government, technical proficiency is almost entirely outshone by their ability to navigate bureaucracy. It’s why Delivery Managers are frequently the unsung heroes of many teams, and why I explicitly wrote about the necessity of enabling teams to deliver value in my book Delivery Management, with a focus on outcomes rather than output.

The success of digital public services was never defined by who could create code fastest. It always comes down to teams who can test, learn, and iterate continuously in alignment with real user needs.

Emerging technology can help us do this more effectively. And coding assistants can play a part.

But the real prize lies in applying AI to the constraints that hold government back. Governance, assurance, compliance, resilience, and testing. The parts that currently restrict flow.

By all means, improve the creative process. But the urgent priority is opening the gallery doors.

Code has no value until it has users, which means there’s art in the delivery.