What the Government's AI Coding Trial Means for Public Sector Software

In 2025, the UK Government's Department for Science, Innovation and Technology ran something unprecedented: a controlled trial of AI coding assistants with one thousand civil service developers working on actual government digital services. The results were striking and have significant implications for anyone commissioning software for government, defence, or the wider public sector. The trial found twenty-eight days saved per developer per year, translating to forty-five billion pounds in projected savings across UK public sector software delivery if adopted widely. These are measurable productivity gains in real government projects, not vendor demos or theoretical models. Developer satisfaction increased through reduced repetitive work, and critically, these improvements were achieved while maintaining code quality and security standards.

This was not a proof of concept in a laboratory environment. This was real UK Government developers building real government services with measured outcomes collected over multiple months. The trial used control groups, measured actual time savings on real tasks, and collected both quantitative productivity data and qualitative developer feedback. For anyone commissioning software for government, defence, or public sector organisations, these results matter because they demonstrate that AI-accelerated development works in the constrained, regulated environment of government IT, not just in fast-moving tech startups.

What the Trial Actually Measured

The trial's design was rigorous and avoided the common pitfall of asking AI to build entire applications autonomously. Instead, DSIT gave one thousand UK civil service developers AI coding assistants such as GitHub Copilot and similar tools, while maintaining a control group without AI access. Both groups worked on actual government digital services over multiple months of real project work. The measurement focused on time saved on development tasks, code quality metrics, and developer satisfaction surveys. This design meant the results reflected realistic usage patterns rather than ideal conditions, and the productivity gains were measured against developers' normal work rather than artificial test scenarios.

The headline result was twenty-eight days saved per developer per year. This breaks down into faster boilerplate code generation, quicker test case writing, reduced time spent on documentation, and less time debugging simple errors. It is important to understand what this actually means. It does not mean developers working twenty-eight fewer days per year. It means the same developers delivering more in the same time, because the AI handles repetitive, predictable tasks that previously consumed human attention. The time saved is redistributed to higher-value work such as architecture decisions, user research, and complex problem-solving that AI cannot do.

Developer feedback was notably balanced and honest. Satisfaction increased due to less time on repetitive boilerplate, faster prototyping cycles that enable better user validation, more time available for creative problem-solving, and reduced context-switching between different types of tasks. However, developers also raised important concerns. They noted the need for training on how to use AI tools effectively, emphasised the continuing importance of code review processes, highlighted that security implications require active management, and acknowledged that not all development tasks are suited to AI assistance. The honest truth from the trial participants was that developers liked the tools but recognised they are not a silver bullet, and professional judgment remains essential.

What This Means for Government Software Delivery

For CIOs and CTOs

The trial proves AI coding assistance works in government context.

What you should do:

1. Start small: Run your own pilot with a small team
2. Measure outcomes: Track time savings, code quality, developer feedback
3. Build governance: Establish security review processes for AI-generated code
4. Train teams: Developers need training to use AI effectively

What you shouldn't do:

• Assume all developers will immediately achieve 28 day savings
• Implement AI tools without security governance
• Replace developers with AI (that's not what the trial showed)
• Ignore the need for code review and quality checks

For Procurement Teams

This changes the business case for software development.

Traditional business case:

• 12-18 months development time
• £500K-£1M budget
• Large team required
• Fixed requirements approach

AI-accelerated business case (based on trial evidence):

• 6-10 weeks development time (for suitable projects)
• £100K-£200K budget
• Smaller team with AI assistance
• Iterative validation approach

The catch: Not all projects suit AI-accelerated development. You need to know which do.

For Programme Managers

For programme managers, the trial demonstrates that productivity gains are real but they require the right project characteristics and approach. AI acceleration works particularly well for new applications where greenfield development avoids the complexity of existing systems. Cloud-native architectures are well-suited because AI models have been trained extensively on modern cloud patterns. API-driven services benefit from AI's ability to generate boilerplate integration code quickly. Rapid prototyping for user research becomes faster and cheaper, allowing more experimentation before committing to full implementation. Even modernising legacy systems works well when requirements are clear and the challenge is reimplementing known functionality rather than discovering what needs to be built.

However, traditional development approaches still make more sense for certain project types. Complex integrations with legacy systems where understanding the existing architecture matters more than writing new code. Highly specialised domain-specific code where AI training data is limited and human expertise is essential. Projects with genuinely unclear or rapidly evolving requirements where discovery work must happen before significant development. Systems requiring deep hardware integration where software is just one component of a larger solution. The key insight from the trial is that AI does not replace planning and architecture work; it accelerates implementation once requirements are well-defined.

What Government Buyers Should Actually Do With This Information

The first practical application of the DSIT trial results is to challenge traditional assumptions about software development timelines and costs. The old thinking that software development inevitably takes twelve to eighteen months needs to be replaced with evidence-based thinking that recognises some projects can be delivered in six to ten weeks with AI acceleration. Use the trial results to question lengthy timelines in supplier proposals and ask suppliers to justify why they cannot use AI-accelerated approaches for suitable projects. Challenge cost estimates that are based solely on traditional development methodologies without considering modern alternatives. Demand proof of concepts before committing to long projects, using the trial evidence to justify this more iterative approach to large programmes.

When evaluating proposals, ask specific questions that reveal whether suppliers truly understand AI-accelerated development or are simply using AI as a marketing term. When you ask how they use AI to accelerate development, a red flag is vague promises about AI-powered development without specifics. A good answer describes specific tools, clear governance processes, and a measurable approach to tracking productivity. When you ask what time savings they expect compared to traditional development, a red flag is claims of being eighty to ninety percent faster, which is unrealistic for most government projects. A good answer is thirty to fifty percent faster on suitable projects with proper governance, acknowledging that not all work can be accelerated equally. When you ask how they ensure AI-generated code meets security requirements, a red flag is claiming their AI is trained on secure patterns, which misses the point that all generated code needs human review. A good answer specifies that SC/DV cleared engineers review everything and automated security testing runs on every commit.

Do not simply trust DSIT's results; validate them in your own organisational context. Run a small pilot by selecting two to three developers on a non-critical project, providing AI coding assistants such as GitHub Copilot, measuring time savings on specific tasks, tracking code quality and security issues, and gathering developer feedback. The timeline should be two to three months, the cost is approximately two to five thousand pounds for tooling plus developer time, and the value is evidence-based decision making specific to your context rather than relying solely on general trial results. This investment in your own evidence is small compared to the risk of making large procurement decisions based on external data alone.

The Honest Assessment

The DSIT trial proves several important claims about AI coding assistance. It proves that AI coding assistants measurably increase developer productivity in real government projects, not just in controlled laboratory conditions. It proves that time savings are both measurable and significant-twenty-eight days per developer per year is not a rounding error. It proves that government developers working under public sector constraints can use these tools effectively, not just Silicon Valley startups with different risk profiles. And it proves that productivity gains translate to faster delivery of working software, not just faster generation of code that still takes months to integrate and test.

Equally important is what the trial does not prove. It does not prove that all software projects will see twenty-eight day savings, because project characteristics vary significantly. It does not prove that AI can replace skilled developers, because the productivity gains came from augmenting human expertise rather than replacing it. It does not prove that security reviews become unnecessary, because code still requires human judgment to ensure it meets security requirements. And it certainly does not prove that forty-five billion pounds in savings will actually materialise across the public sector, because that projection depends on widespread adoption and sustained productivity gains across diverse contexts.

The sensible takeaway is that AI coding assistance is a proven productivity tool for government software development, but realising the benefits requires deliberate choices. Use it on suitable projects where requirements are clear and architectures are well-understood, not on every project regardless of fit. Maintain security governance throughout, because AI-generated code requires the same rigorous review as human-written code. Train developers properly in how to use AI tools effectively rather than assuming they will figure it out themselves. Measure your own outcomes in your specific context rather than assuming DSIT's results will automatically transfer. And scale based on your own evidence, not on hype or projected savings that may not materialise in your environment.

---

Want to see what twenty-eight day savings looks like in practice? We offer discovery workshops where we demonstrate AI-accelerated development using a real example from your domain, showing you where time savings actually come from, how security governance works in practice, what the output quality looks like, and how to measure outcomes in your specific context. Contact our team to discuss a proof of concept for your organisation.