Does AI speed up development? Using the GDS Service Standard as a testing ground

Does AI speed up software development, especially in a digital service context? My thesis is that it doesn’t: modern software development is about much more than writing code, which AI does speed up. But is that “much more” that takes a lot of time and share of the total effort.

So I started asking: how can we think about this in a structured way, leading maybe one day to creating clear measurements of how much the use of AI in software development speeds it up?

I first looked at Eric Ries’ Build-Measure-Learn loop. This is a framework described by Ries in his book “The Lean Startup” and as you can imagine all coding happens in the “Build” arc. This is the part that gets sped up by AI. But this characterisation only offers a rather crude measure because it doesn’t get specific enough about what happens in each arc.

As I was looking for ways to make this measure a bit more precise, I had a a Eureka moment. I was preparing for running a GDS (Government DIgital Service) Service Assessment, and I just had it – in front of me: the GDS Service Standard can be a great way to start thinking about where exactly AI makes development faster.

If you haven’t come across it, the GDS Service Standard is a set of 14 points that UK government teams use to create and run public services. It was published in 2019, replacing an earlier 18-point version, and it sits on top of an agile lifecycle of discovery, alpha, beta and live.

Image source: Gov.uk

Services are assessed against the standard by a panel of peers at key points in that lifecycle, mainly at the end of alpha and before going live. Most of the 14 points are not about technology at all.

Image source Alphagov Github

(Note: I’ve been a Technical Assessor since 2020, and I’ve assessed over a dozen services.)

Each element in the standard can be roughly decomposed in discrete elements. What we can therefore do is ask: what does AI do to every entry of the standard?

Here’s a summary, with a verdict on the impact of AI

1. Understand users and their needs — Low impact

While AI can helps summarising and synthesising interview notes, tagging research, drafting discussion guides, the hard bit is recruiting users, especially those who are hard-to-reach in digitally excluded communities. If a service is for real, human users (not AI Agents), it takes time to observe their behaviour. You cannot generate primary evidence about people.

2. Solve a whole problem for users — Low impact

Again, AI can help map user journeys, or summarising policy and legislation, when applicable. But the hard part in understanding an end-to-end process is often about navigating organisational boundaries, e.g. ownership across teams, distributed funding, departmental politics.

3. Provide a joined up experience across all channels — Low impact

AI can surely draft or help draft consistent content for each channel, or it can be used to analyse call-centre transcripts. The alignment of operations, especially when contact centres or legacy paper processes are involved, is human change which takes time.

4. Make the service simple to use — Partial impact

Prototyping becomes faster with AI, with more variants in a shorter time span, so it can be helpful in testing simplicity with users. It can also help simplifying text. But to know which variant or text works requires user research and usability testing, which move at human speed. And more variants can actually mean a longer research queue, so watch out for the impact of AI introducing delays.

5. Make sure everyone can use the service — Partial impact

AI-driven automatic accessibility checks using WCAG makes things much faster. This, however, doesn’t remove the need to test with users living with disabilities. Assisted digital routes can’t be automated.

6. Have a multidisciplinary team — No, or possibly negative, impact

I loathe to repeat myself but: AI doesn’t replace user researchers. In part, it can replace designers, content designers or policy experts, but there are many reasons not to do this, including the production of meaningless slop that only works in appearance. On this topic, by the way, there was an excellent talk at TRGCON, which I’ll link to as soon as possible.
But note that if you start cutting non-developer roles, you’ll have no one running the slow parts of the loop.

7. Use agile ways of working — Partial impact

Admin tasks in Agile sprints can definitely be sped up by AI: issuing tickets, taking notes, creating show-and-tell summaries. But Agile works through feedback cadence and team decisions. A sprint is bounded by learning, not by typing text or code. Interesting, googling about this, I found this DORA 2025 report; its central finding is that AI is an amplifier: it strengthens good ways of working and magnifies dysfunctional ones. It doesn’t create agility. (DORA 2025 announcement)

8. Iterate and improve frequently — Partial impact

This is the crucial point of this blog. The build step of each iteration gets shorter. But to measure and learn, you still need real users, real data and time for behaviour to emerge.

9. Create a secure service which protects users’ privacy — Mixed impact

As we know from the hype in the media around Mythos and other security-oriented models, code scanning, threat-model drafts, and generating security tests can be massively sped up by AI. But, at least in the public sector, if we’re talking about user information (and, in most cases, we are) we still need a legal basis check, Data Protection Impacts Assessments, signing off of risks, in short human-driven, legally required governance. You don’t have to be a fan of governance to say that we can’t do without it unless legislation changes. And the AI tools themselves raise new data-protection questions.

10. Define what success looks like and publish performance data — Low to partial impact

You can build dashboards in a few minutes, and spot trends, with good AI. But the definition of success is a value judgment that sits, usually, with policy owners. What gets faster is presenting them with data, maybe even in real-time. But the impact is more about design than production: performance analysis in production exists already, and the slow bit that can be made faster is the development of the data pipeline, not the taking of actions after they have run.

11. Choose the right tools and technology — Partial impact

AI can help run quick spikes and comparisons, reducing the time to develop options to evaluate and buy. But procurement has its own timeframes, which are there to protect the interest of suppliers to be informed about opportunities and ask questions about what they’re bidding for. And let’s not mention the issues with lock-in, which still apply in the age of AI.

12. Make new source code open — High impact, with caveats

Anyone who’s used Claude Code, Codex, or similar platforms, knows how great these tools are at churning out good documentation, READMEs, preparing code for release, scanning for secrets. This is the highest impact beyond writing code. But let’s not forget that provenance and licensing are tough legal matters, especially those around generated code. Not to mention the risk of publishing code no one understands, which requires a code review step that reduces the positive impact in this area.

13. Use and contribute to open standards, common components and patterns — High impact, with caveats

Pretty much as per point 12. Point Claud Code at the GOV.UK Design System and common platforms (Notify, Pay, etc), and it will reuse them pretty well. Minor point: this also means less code reuse. Maybe this matters less in the age of AI-driven coding, but it’s worth mentioning.

14. Operate a reliable service — Mixed impact

An approach to resilience of services is still needed. It often requires support models that can span years, on-call rotas, and well-understood escalation patters. This can’t be replicated by AI, although AI does speed up the recovery cycle by facilitating triage, log analysis, the running of runbooks, and the development of infrastructure as code configurations and scripts.

Conclusion

The final tally is about 2 high, 6 partial or mixed, 6 low or none. As expected, the two high ones (12, 13) are the most code-heavy elements of the standard.

The Service Standard was written to stop teams building the wrong thing well. While AI makes building cheaper, what it does speed up is writing code. But in complex digital services, coding is just part of the process, which is limited by users, organisations, governance and time.

Speeding up the build step without widening the real bottleneck doesn’t shorten the loop, it just moves the queue. Unreviewed code can pile up, research backlogs grow, assurance gets overloaded. So AI, if we ignored the non-code parts, comes with a risk of building the wrong thing faster.

Many of those non-coding parts, though, are required by best practice and, in some cases, legislation. We can’t just forget them. So, overall, I don’t think that digital service development can’t be sped up massively by AI.

But this post is not about taking sides and say “AI doesn’t speed things up”: what matters the most is supporting a way to have an informed conversation about this topic in a way that helps us produce evidence. Looking at the issue of “AI speeding up development” through the lens of an established framework like the GDS Service Standard can help us build evidence and measures.

The timing is good, too: GDS is currently evolving the Service Standard, moving it away from a one-off assessment checklist towards something that supports a service across its whole lifecycle. If AI is going to change how we build public services, the next version of the standard is the right place to work out how we evidence that, and GDS is asking teams across the public sector to contribute. I’d encourage anyone with data or experience on this to get involved. Which raises the question I’ll leave you with: should the next version of the Service Standard say anything about AI, and if so, should it be about how fast we build, or how well we learn?