Why vibe‑coding matters (and what it isn’t)
Estimated read time: 7 minutes
A compression worth caring about
AI assistance matters for public sector product management because it collapses the time between intent and something real. It’s not just that delivery teams can move faster; it’s that more of the multidisciplinary team can express ideas as working software early enough to make contact with reality while the stakes are still low.
What used to take months can now be achieved in days. A concept that might once have languished in a backlog can get built in a morning and tried with real users by the afternoon.
This acceleration matters because improving services can tangibly improve people’s lives – getting a payment to someone sooner, reducing avoidable contact, making a form less frustrating, giving caseworkers tools that load straightaway. If we can do that faster, we should.
But it’s worth being clear about what’s actually changing, because there are two accelerations happening at once, and one deeper consequence.
Two accelerations, one consequence
First, those who wouldn’t call themselves technical can increasingly build runnable, testable services – not just describe them. Product managers can bring an end-state into view instead of making slideware. Policy colleagues can express intent as rules you can run and levers you can pull. Ops can sketch an operating model as a walkthrough you can actually step through. Content can generate variants and see how they behave in context. Those things used to wait on a dev team to translate them. Now they can exist early, while the questions are still alive.
Second, engineers can use the same tools to compress delivery and feedback loops: less boilerplate, less waiting, more iterations with proper tests and controls. That doesn’t diminish engineering; it changes where the effort goes. Some of the typing shrinks, but the craft of making things robust, secure, accessible, observable and maintainable becomes more central.
There was once a chasm between “a sketch on the wall” and “something real in front of users”. AI-assisted delivery narrows it from both sides. The outcome is not that engineering disappears; it’s that the whole team can collaborate in the medium of software sooner, and therefore argue less about hypotheticals and more about what actually happens.
And that’s the deeper consequence: the unit of delivery becomes even more plainly the team. Not policy then delivery. Not design then build. Not a relay race of documentation. A multidisciplinary team working in the same medium, able to get to something testable quickly, and then to learn together from what reality feeds back.
Where misunderstanding creeps in
This is the moment where some people reach for the phrase vibe coding, and it’s exactly where misunderstandings creep in. From here on, when I’m talking about the disciplined practice, I’ll mostly say AI-assisted delivery – and I’ll keep vibe coding for the cultural shorthand and the low-rigour end of the spectrum.
And vibe coding also isn’t synonymous with flimsy “demo-ware”. Some people hear the phrase and picture shiny-but-hollow prototypes: impressive screenshots that crumble under real policy, real data, real accessibility needs, and real operational constraints. That is one end of a spectrum, but it’s not the whole story. Yes, plenty of vibe-coded artefacts are throwaway sketches, but AI assistance can also generate code that’s close enough to production to warrant taking seriously.
Other phrases are starting to emerge – and agentic engineering is a good one for what’s happening in the more narrow confines of the engineering discipline: orchestrating agents, scrutinising output, keeping the quality intact. But what I’m trying to name is the operating model for public services: the way we work collectively to work in the same medium and add public value more quickly. In government the ‘clever’ bit is rarely the code. So that’s why I’m using AI-assisted delivery. Because this is a team pursuit.
The bar doesn’t move
AI-assisted delivery isn’t theatre, and it isn’t a shortcut; it’s a powerful new tool in our toolkit – but only when used responsibly and intelligently. It doesn’t eliminate the need for empathy, context, or wise decisions. If anything, it amplifies them: when code can be produced at the speed of thought, the limiting factor becomes whether we are building the right thing and whether we are upholding our duties to users. It can supercharge delivery, but it only delivers public value when it is guided by sound judgement, inclusion, and evidence.
It isn’t a licence to bypass hard product thinking or abandon good practice. The real work was never just writing code: it’s making sense of what people need, agreeing the right response, and then proving – through evidence and iteration – that we’ve met it. That proof is still the priority; because when you can build quickly, you can also build the wrong thing quickly.
The dividing line isn’t the tool; it’s whether the work meets the bar: reviewed, tested, accessible, secure, supportable, measurable, and safe to put in front of the public.
So the discipline becomes: what is this for? If it’s experimentation, treat it like an experiment: learn, document, discard. If it’s headed towards live, then build it as if it will have to survive contact with reality – because it will.
Another way to put it: we now have a more powerful engine in the delivery vehicle. It can dramatically increase our speed, but the steering wheel remains in human hands – guided by the Service Standard, by user research and iteration, and by the hard work of navigating policy, risk, and operational reality. AI assistants can generate code; they cannot own consequences. They do not reliably know what is ethical, accessible, or appropriate in context. That accountability remains ours.
So this is not a replacement for human-driven product management and service design; it’s an augmentation. It can collapse the time between idea and reality – so long as we keep checking those realities are desirable, fair, and effective.
Public sector teams can now potentially respond to change faster than ever: a new policy intent or emerging user need can be met with something working in days, and tested early with real users – in the open, where assumptions can be challenged. That rapid policy-to-delivery cycle is a dream of digital government – now it’s within reach. But to seize it, we have to dispel any notion that vibe coding is “cheating” or “hype” or just “demo-ware”. It’s neither a silver bullet nor a trick; it is simply the next evolution of agile tooling.
It still requires discipline.
High speed doesn’t change the core of what we do: do our users benefit, and do outcomes improve? AI assistance increases our capacity to try; product leadership must increase our capacity to learn: fast feedback loops, effective measurement, and firmly held standards. It can let us practice our core values faster, which is a compelling proposition for public good, but it isn’t a shortcut around those values. If anything, the faster we go, the more carefully we must steer.
When ‘the service’ isn’t a webpage
There is another shift underneath all of this: what we mean by “the service” is becoming less stable.
In the GDS era we earned trust by getting good at the web: clear journeys, fewer dead ends, pages that matched policy, transactions that worked. That work still matters. The public will still meet government through letters, phones, walk-ins, and third-party front doors.
But increasingly the thing that changes people’s experience won’t always be “a service” in the familiar sense. It might be rules expressed as code. An API used inside someone else’s interface. A shared component that quietly shapes outcomes across multiple journeys. An agent operating through a channel we don’t own. Sometimes it will be invisible unless it fails.
That changes the craft. We’re no longer only designing pages and flows. We’re designing behaviour in systems: how decisions get made, how exceptions get handled, what happens on a bad day, and how trust is sustained when the user never sees the machinery.
So yes: build the front door well. But treat the deeper layers as “the service” too, because that is where fairness, explainability, and operability either exist…or don’t.