Foreword: The kairos moment and the changing material
Estimated read time: 3 minutes
Public service teams are at a kairos moment: a time when a new technical capability invites us to rethink almost everything about how we build and deliver services. But our centre of gravity isn’t swayed by “AI magic”. It rests on civic values we already know to be true: start from user needs; follow evidence over hunches; prize outcomes over outputs; prefer pragmatism to hype; fix the basics; and above all, put human worth and inclusion at the core. These are the ground we stand on when anything new arrives.
The “material” of digital development itself is changing. AI-assisted development collapses the time between intent and software: we can describe what we want in natural language and see working systems emerge at remarkable speed. Over the last year, this has moved from novelty to normality. Teams can now go from an idea to software in hours rather than weeks.
You’ll sometimes hear this called vibe coding. In the rest of this document I’ll use that label sparingly, because the bigger shift is not a vibe – it’s a capability: AI woven through the disciplines we already rely on, from engineering to policy to operations.
The biggest change is not simply that engineers can go faster – it’s that more people can now shape software as a medium. And that medium won’t always look like a page in a browser.
And it will arrive unevenly. Some people will meet us through chat and apps; others through phones, letters, Jobcentres and third-party front doors. Delivering omni-channel services means being agnostic about channels but highly opinionated about ensuring unevenness doesn’t turn into unfairness.
Policy, ops, analysis and content can now express intent as something runnable, not merely describable. That collapses much of the old translation layer where ideas waited weeks to become concrete. The consequence is profound: multidisciplinary teams don’t just collaborate around plans; they collaborate around deployed code. This will change how teams work, how roles overlap, and what “multidisciplinary” looks like in practice.
That’s why our rigour matters. This isn’t about knocking together flimsy prototypes or automating away the craft of coding; it’s about accelerating responsible development. Used well, with peer review, testing, accessibility, security and operational thinking baked in, AI assistance can produce production-grade software quickly and safely.
But the point of this shift isn’t faster code. The point is quicker value in real users’ hands, consistent with the Service Standard: showing the thing sooner, learning sooner, and iterating based on evidence.
There is a particular hazard in this moment: when software can be conjured quickly, it becomes easier for leaders to confuse a working thing with a ready thing. A prototype can look like a service. It can feel “almost done”. And that is exactly when public sector judgement matters most, because the distance between a demo and a duty-of-care service is not measured in pixels. It’s measured in evidence, operability, accessibility, lawful data handling, and the humility to say “not yet” even when the screen looks convincing.
I’ve tried to write this as a manual for the world we’re in rather than to catalogue fast-changing tools. Digital services may be becoming more malleable, but our responsibility is to shape them toward human benefit. This document aims to help the public sector do that – harnessing the potential without losing what makes our services safe, fair, and trustworthy.