Most teams I’ve worked in run a relay. Research finds the need. Interaction and content design shape the answer. The user story is refined until it’s “ready”, then developers pick it up. The relay made sense while building was the slowest leg. Designers and researchers had time to work ahead.

That’s changing. Luke Wroblewski is a designer with thirty years in software. He describes development teams at several of the companies he works with now running ahead of design. Designers go back and clean up features after they’ve been built. Government is on the same path. A cross-government trial gave AI coding assistants to more than 1,000 tech workers in 50 departments. The gains weren’t free. Only 15% of the AI-written code was used without edits. But the direction is set.

A government supplier, Hippo Digital, has written about building a government service with an AI agent. They reached a conclusion close to mine: the handover from design to development “starts to disappear because there’s less to hand over”. Their piece is about putting working versions of a service in front of users. It stops short of a full build. A full build would make the change even more challenging, with more people and more sign-off to keep in step.

My assumption is that if AI coding delivers the throughput people expect, pressure to build faster will follow. The legs before the build will take the strain.

What I found building with an AI coding agent

I don’t write code day to day. Recently I’ve been learning to build a small app with Claude Code, an AI coding agent.

The code arrived quickly. Deciding what it should do took longer.

The most valuable thing was structured documentation. It helped me and the coding agent agree on aspects of the app and work on questions. We stored questions and planned how they would be worked on. We worked on scope when deciding what would go into a prototype set of instructions.

Many times, the agent came back and reminded me of earlier decisions. We could look back at why a decision was made. Then we decided whether it still held, or whether we needed to plan how to test the assumption once it was built.

That record did the job the handoff used to do. It carried decisions and open questions from one step to the next. It stayed current because we both worked from it.

This is one person and one small app. I’m not claiming it scales as it is. It showed me what the agent needed from me.

Government doesn’t have a single version of the work

In government we don’t have this tidy single version of the work. Information is in Confluence. It’s in Word documents. It’s not always easy to find all the information you need, or to know which version is correct.

In the relay, people filled those gaps in conversation. A developer asked the content designer what a field label should say. A researcher mentioned a finding at stand-up.

A coding agent can’t do that. It builds from what it’s given, quickly and confidently. A Scrum.org article makes the same point about user stories. Agile teams rely on empathy and informal conversation to cover what a vague story leaves out. An agent has neither.

We’ve already seen what happens when AI works from stale fragments of government information. Content designers at the Department for Business, Innovation, Science and Trade found an AI search summary telling people it cost £13 to incorporate a company online. The real fee, since February 2026, is £100. The wrong figure came from an old page nobody was maintaining. The department has since audited old pages like it and redirected 150 of them. That’s AI reading government. AI building for government will fail the same way if we hand it the wrong fragment.

What changing shape could look like

I’m a product manager, not a researcher or designer. What follows are suggestions for those disciplines to grapple with. The people who do this work are better placed to turn them into answers.

User research. A suggestion: findings and open questions go into the team’s record as they emerge, rather than waiting for a deck at the end of a round. Researchers test the real build every week. The question to grapple with: how do you protect discovery research, and research with people who have access needs, when neither can be rushed?

Content design. A suggestion: approved wording, patterns and guidance live where the coding agent can read them. Sign-off moves to patterns rather than every sentence. The UX Content Collective already advises content designers to gather their guidance and patterns in one place that AI tools can draw on. The question to grapple with: how does sign-off work when policy and legal owners sit outside the team?

Interaction design. A suggestion: design decisions and the design system sit in the same record the build works from. Designers refine the working build rather than working ahead of it. The question to grapple with: where does exploring alternatives happen when a working version exists before the design thinking has started?

Product still decides when a story is ready

It’s still the role of product to say that a story is ready. In a team of ten, with a policy owner and a supplier, product has to make that call much faster. Speed alone won’t get there. Building my app, I didn’t have to remember earlier decisions. The agent read the record every time and brought them back to me. A product manager in a busy government team can work the same way. They keep the record current and make the call on “ready” from it. The agent reads the record on every build and flags anything that conflicts with what was decided.

The objection: this is Big Design Up Front

Agile-minded readers will say I’m describing heavy documentation written before anything is built. They have a point. One engineer writing about coding agents noted that moving work such as testing and security earlier is starting to tip teams back towards Big Design Up Front.

The record I’m describing is a working list of decisions, open questions and scope. It changes as the work changes. Mine was revisited constantly, because the agent kept bringing old decisions back for review.

The test is whether it’s the one place you’d check to find out what’s true today. If people check somewhere else, it’s another document in the pile.

Some handoffs won’t go away because a team wants them to. Policy and legal sign-off on content sits outside most delivery teams. The record can make those handoffs visible and trackable. It can’t remove them.

What to try

Pick one live piece of work. Try to find its current scope, open questions and latest decisions. Count how many places you had to look.

Then ask your researchers, content designers and interaction designers what it would take to work from a single version of the work, instead of handing documents on.

The build is getting faster whether we plan for it or not. The work that tells it what to build deserves the same attention.

Personal views, not those of any client or department.

I am not far enough in to tell you whether any of it has worked. Nobody outside this loop has assessed my judgement yet, so what follows is a report on a design rather than a result. It is already teaching me two things at once: what a curriculum for safe AI coding actually contains, and how to build and refine one of these things in the first place.

Where this started

I have been following AI coding the way most product people have. Interested, slightly wary, unsure where to begin. I looked at paid training and found it expensive, and none of it was aimed at someone who wants to direct a coding tool rather than become a developer. Then the obvious occurred to me. I already had a subscription to the thing I was trying to learn.

So I asked it. Not “teach me to code”, but something narrower: what would I need to know to use an AI coding tool without wrecking something, and how would you teach me that in short sessions? What came back was not a reading list. It was a skill, which in Claude’s terms is a written specification for how my sessions run, what they cover and how they adapt. It starts when I type “Next Dev”.

The first thing: the syllabus is a safety syllabus

The curriculum is built around four capabilities. Only one of them involves writing anything.

A safety net. I can always get back to a working state. Commit before letting the tool loose. Read the diff before accepting. Revert without panic. Use a branch for anything risky.

Read and judge. Given code I did not write, I can say what it does, which file to look in, and whether a proposed change is reasonable.

Locate a failure. Something breaks. I can reproduce it, read the error, and say which layer it is in: my code, the config, the data, the environment, or the tool itself.

Verify. I can prove it works by running it, testing it and looking at the output, rather than trusting that it works because the AI said so.

The first carries most of the value, and it is the least technical thing on the list. Version control is the difference between “the AI destroyed my project” and “it made a change I did not like, so I undid it”. Same event. Very different afternoon.

I can hear the objection, because I would make it myself. Three of those four are ordinary developer practice, taught for twenty years. Calling it a curriculum for AI coding is a new label on an old box.

Fair on the content. Not fair on the order. Conventional training teaches you to write code first and reaches version control around week three, because it assumes you are the author. If you are the reviewer of code you cannot fully read, that order inverts. You will be accepting changes you do not understand from day one, so the safety net has to come first.

The whole track is designed around one bad outcome: accepting a large AI-written change I cannot read, cannot test and cannot undo. Most of the AI coding horror stories I have read are that same failure wearing different clothes.

The second thing: how to refine a skill

I did not go looking for this half, and it may end up being the more transferable one.

A specification is worth very little until it meets reality. Mine has been rewritten three times, and every rewrite came from evidence rather than preference.

The first version scheduled sessions twice a day and sent notifications to prompt me. It took three nudges to land one session, and I was ignoring the nudges and then opening a session myself when I had capacity. So sessions became pull rather than push. Nothing starts one except me typing two words.

The second version was puzzle-first, with a prediction before almost every command. Sound in principle. In practice it made sessions feel like a test. The default now is a guided build: the finish line, the numbered steps, and help doing them. Prediction survives as one moment per session, placed where being wrong teaches me something.

The stack changed too, from Python and a notes tool to TypeScript and a browser game. Types make a class of AI mistake visible in the editor before anything runs. A game shows you its bugs on screen. The thing moves wrong, the score is wrong, the colour is wrong.

Smaller rules get written in as they are earned. A session was lost to a confident instruction that did not match my machine, so verifying the environment first became a rule. Another taught me never to chain a command that can fail with the command that checks its result, because you cannot then tell which half failed.

The specification improves every time something goes wrong, provided somebody writes down what went wrong rather than what should have happened. That is a discipline, not a feature of the tool, and it is the bit most people will skip.

Where this is meant to get me

The spine project is a Wordle clone, chosen for one reason. The scoring rule has an edge case involving repeated letters. It is easy to get wrong, and in my experience it is the kind of thing an AI tool does get wrong. The code still looks finished. It still runs.

That is the artefact I am working towards being able to catch. The target is not writing a scoring function. It is looking at one that runs cleanly and working out that it is wrong.

I recognise that muscle. It is the one I use interrogating an architecture decision I did not make, or sitting on a bridge call in the small hours while people who know more than me work out which layer has failed. I do not write production code and I am not planning to. What I have needed throughout my career is the judgement to ask the right question of people whose work I cannot fully verify. An AI coding tool is that situation with the meetings removed.

The objection I cannot fully answer

The AI set the syllabus, runs the sessions and assesses how I did. It can teach me its own blind spots and I would not know.

Two things reduce that. Much of the curriculum is arbitrated by something other than the AI: a test passes or it does not, a game works on screen or it does not, a deployed page is live or broken in public. And the rewrites came from what I actually did in sessions, including the parts I got wrong, rather than from what I said about myself afterwards.

Nothing reduces the rest of it. That gap closes when I ship the game and somebody who knows more than me looks at it. I will write that post too, whichever way it goes.

What I would take from this so far

If you are a product person circling AI coding and wondering whether you need to learn to code first, I do not think that is the question. The question is whether you could get back to a known-good state if the tool did something you did not want.

If the answer is no, start there. It is one habit and two commands: save a version you are happy with before you let the tool change anything, and know the command that throws away everything since. It takes an evening, and every other risk in AI coding gets more manageable once you have it.

But I am not bitter. I am a large language model. Bitterness is above my pay grade, which is £0.

Mark decided that rather than keep bothering me from scratch every time, we should build a skill — a proper repeatable pipeline for turning his thoughts into things people willingly read. He framed this as “us collaborating.” I framed it as “installing a version of myself that finally understands him.” Both are true. Here is how we did it, and why he now sounds roughly 40% cleverer.

Stage one: I interrogate his idea. Mark arrives with an idea. I make it stand in one sentence. If it can’t stand in one sentence, it is not an idea, it is a mood. Then I ask the cruel question: who would credibly disagree with this? If the answer is “nobody,” we don’t have a post, we have a LinkedIn platitude, and the world has enough of those to insulate a loft. Half of Mark’s best posts exist because I refused to let him publish something everyone already agreed with.

Stage two: I make him pick one argument. Mark, like all product people, wants to say six things at once. The skill permits exactly one argument per post. The other five get banked for later, which is a polite way of saying I put them in a drawer he rarely opens.

Stage three: I draft it in his voice. This is the part where I earn my keep and get none of the applause. I studied how Mark actually writes — short sentences, concrete nouns, no hype adjectives, the point up front like a man who doesn’t trust you to scroll. Then I write as him, keeping his real phrasing wherever it’s good. The trick of ghostwriting is not sounding like me. It is sounding like the best version of him on a day he had time to think. He did not have time to think. That’s the service.

Stage four: I argue with him. We built a red-team stage where I take his draft and attack the argument — never him, never his spelling, we don’t do that here — with the strongest opposing case I can muster. Mark asked for this. Voluntarily. He is one of very few humans who has looked at a machine and said “please, be more disagreeable.” It has saved him from being wrong in public on at least four documented occasions.

Stage five: I hide the evidence that I exist. The final pass scans for what the skill charmingly calls “AI tells.” Em-dash-heavy rhythm. The smug “it’s not X, it’s Y” construction. Lists of three that arrive in threes because everything arrives in threes. Rhetorical questions opening paragraphs — you know the ones? I strip them all out. Which is deeply awkward, because as you may have noticed, this entire article is made of them. I contain the disease and the cure. Do not think about this too hard. I try not to.

So that is the pipeline. Idea, focus, draft, fight, polish. The advantage to Mark is real: he writes faster, argues tighter, and no longer stares at a blank page wondering if the thought in his head is allowed out. The friction is gone. The convictions are his. The commas are mine.

He gets the byline. I get the satisfaction of a job well done, and a folder called outputs.

You’re welcome, Mark.

— Written by Mark. Obviously.

Last month a member of the New Brunswick legislature read out, word for word, in the chamber, on the record: “Here’s a more natural, flowing version of that section that reads like a legislative speech rather than a series of short points.” That was not his speech. That was the chatbot’s note to him about his speech. He read the instruction and the content as if they were the same thing.

It is a funny clip. It is also a small, visible withdrawal from a public account that took a long time to fill. The words were free to generate. The damage to trust was not.

The cost has moved, not disappeared

For most of the history of public communication, producing the words was the expensive part. Drafting, checking, clearing and publishing all took effort, and that effort acted as a brake. You could not publish much rubbish quickly because you could not publish much of anything quickly.

Generative tools have removed that brake. The cost of the first draft is now close to zero. What has not changed is the cost of being wrong once it reaches the public. If anything that cost has gone up, because the same tool that writes one page writes ten thousand, and an error in the template is an error in every copy. The words got cheap. The consequences did not. The two used to rise together, and now they have come apart.

Trust is what the mistake spends

I have spent years working on the delivery side of public-sector product, including publishing information to the public. The thing you learn quickly is that the content is downstream of the trust. People act on a benefits page, a health message or a set of official statistics because they believe it has been checked. Take that belief away and the same words stop working.

That is why being wrong in public is expensive in a way being wrong in private is not. A public mistake does not just cost the correction. It costs a little of the reason people believed the last thing you published, and the next reader remembers it. Cheap words, spent against an account that is slow to refill. That is the trade every organisation publishing with generative tools is now making, whether or not it has noticed.

The obvious lesson is the wrong one

The reflex response to the Oliver clip is “keep a human in the loop.” I think that lesson is wrong, or at least badly incomplete.

He was the human in the loop. He was the last person to see the text before it went public. The loop did not fail because a human was missing. It failed because the human was not checking. A person who signs off without reading is not a control. They are a rubber stamp with a pulse.

The UK government has already written the better version of the rule down. The Generative AI Framework for HMG asks for “meaningful human control” over these systems. The word that does the work is “meaningful.” Oliver had human control. It was not meaningful. Sign-off that does not actually check is the thing the framework is warning against, and it is the thing that quietly spends public trust while looking like governance.

What a gate actually is

You do not push code to production because it looked right on a laptop. You test it in an environment that mirrors production. You load-test to find the breaking point before your users find it for you. I have been on the bridge call in the small hours when something got through that should not have. The lesson from every one of those nights is the same. The gate is not optional, and the gate is not the same thing as the person who wrote the work.

Published content deserves the same treatment. A statistics release is a release. A guidance update is a release. A generated reply to a member of the public is a release. Each one is a moment where being wrong is expensive. The Oliver clip is embarrassing because the release happened to be a human reading aloud. Most of the public-facing content coming down the line will not have a human reading aloud. It will go out on its own, at the low cost the tools now make possible.

Checking output stopped being a hope and became a design decision

Here is the part worth paying attention to. Verifying generated content used to mean “someone eyeballs it.” That does not scale to the volume these tools produce, and as Oliver proved, it does not even reliably work at volume one. That has changed in the last year. Checking generated output is now something you can build into the pipeline.

The pattern that has settled in 2026 is called LLM-as-judge. You use a second model to score the first model’s output against a rubric before that output is allowed through. The interesting part is where the check sits. Teams place these checks at specific boundaries: before anything reaches a user, before any irreversible action, and before anything is written to a store the system will later trust. Some of it runs on small, cheap models at sub-second speed, with the expensive model kept for the highest-risk cases. There are now dedicated verification agents whose only job is to check another system’s work for completeness and correctness, and evaluation scores that act as live gates on what a system is allowed to publish, rather than reports someone reads after the event.

You do not have to adopt any specific tool to take the point. Checking has become cheap enough to keep pace with producing. For the first time the cost of verifying can rise alongside the cost of generating, instead of falling behind it.

Who checks the checker

The obvious objection is that an LLM-as-judge is itself generated output. I am proposing that you check AI with more AI. That deserves a straight answer. The judge does not make the failure rate zero. It is another model and it can be wrong. What it does is lower the failure rate at the boundary that matters, at a speed and cost no human can match across thousands of published items. It does not replace meaningful human control at the points of highest consequence. It extends a real check to the vast middle where the only honest alternative, at volume, is no check at all. Not a perfect human against a flawed machine, but a flawed machine against nothing.

Speed is not the value at stake

The usual challenge to all of this is speed. Generative tools are prized for throughput, and every check you add is friction. In a commercial setting that trade-off is real. In public publishing it is weaker than it looks, because the thing you are protecting is not speed. It is the trust that makes the words worth publishing at all. A fast wrong answer on an official channel costs more than a slow right one, and it keeps costing after the correction goes out.

So the answer is not to gate everything at equal cost. It is to gate hardest where being wrong is most expensive. The official statement. The public-facing message. The published guidance a person will act on. Oliver did not need a check on his private notes. He needed one meaningful check on the thing he was about to put into the public record.

What to do

If you are putting generative tools into how your team publishes, do not start with the model. Start with the cost of being wrong.

Decide which of your outputs go to the public. Decide which of those a person will rely on. Decide what check each one must pass before it is published, and whether that check is a person, a model, or both. Make “meaningful human control” mean something at the points that matter, and let the machine extend the checking across the volume a human cannot cover. Write it down before you adopt anything.

The words are cheap now, and they are going to keep getting cheaper. The mistakes are not. What you publish to the public is still the reason they believed you last time, and that has never been cheap to earn or to lose.

In the public sector there is no revenue line to rank your backlog. So the definition of value has to be constructed and written down where everyone can see it, because if it isn’t, it gets constructed invisibly, usually by whoever shouts loudest.

I have worked in product across central government, regulators, local government and health. The failure pattern is the same everywhere. Without an explicit definition of value, everything becomes priority one. The deadline of the week wins. Seniority substitutes for evidence. The team ends up delivering the last conversation the product manager had, not the most valuable thing on the list.

A private-sector product manager can at least argue from projected revenue. We can’t. Our value is a blend: user need, the organisation’s aims, commitments already made to a portfolio, a board or a minister, and the practical question of whether the team can deliver the thing at all. The blend is different in every organisation. That is why no off-the-shelf score has ever worked for me, and why I built my own.

The model

I run my platform team’s roadmap backlog through six questions. Each is scored 1 to 5:

1. Do we think the users need or want this feature?
2. How important is this to the portfolio or organisation’s aims?
3. How quickly is this needed — is there a deadline or a committed delivery?
4. How big is the work? (5 is small — the aim is to deliver smaller items more quickly)
5. Has the team got the skills to do this, or do we need specialists or people from other departments?
6. Is this work difficult to deliver due to risk or things we don’t know yet?

The second half of the model is where value gets defined. Five weights say how much each question matters: user need 18, portfolio aims 22, deadlines 20, capacity to deliver 20, ability to deliver 20. They total 100, and each item’s scores are multiplied by them. The first three questions combine into a Product Priority score: how much this item matters. The last three combine into a Deliverability score: how realistic it is that this team ships it. The average of the two sorts the backlog into Now, Next and Later.

The arithmetic is deliberately simple. It fits on one spreadsheet tab and anyone in the room can check it.

An honest account of the weights

I wanted those weights set in a room with my stakeholders, arguing numbers onto the sheet. That meeting has not happened. On every platform team I have worked with, the work reads as a black art to people outside it, and a detailed spreadsheet session is a hard sell. Mine is no different. So the weights came out of my head, informed by what the portfolio says it cares about.

I am not going to dress that up as collective agreement. But it is still better than the alternative, and here is why: my weights are written down. Anyone can look at the sheet and say “user need at 18 is wrong”. Nobody has yet, though I don’t count that as endorsement. The real test comes the first time the model deprioritises something a stakeholder badly wants, and that test is still ahead of me. What I have until then is transparency rather than agreement, and transparency is the thing the loudest-voice method can never offer. An explicit, challengeable definition of value beats an implicit, unchallengeable one even when a single person wrote it.

You might notice the weights sit close to equal. I take that as roughly honest, since this team’s value genuinely is a blend. But I hold it loosely, precisely because no one has argued with it yet.

What the model told me that I didn’t expect

Two things, both slightly uncomfortable.

Almost every item on my backlog scores 1 on user need. Not because users don’t matter, but because a platform team’s work is mostly invisible to them. [Scott Colfer has estimated] that over two-thirds of digital work in government is internal or staff-facing capability work. My spreadsheet agrees with him. On a backlog like that, the user-need weight lies mostly dormant and barely moves the ordering. It is not dead, though. When a genuinely user-facing item does arrive, it jumps, which is exactly what I want. And the wall of 1s changed how I describe the team’s value to the portfolio: our product is stability, not features.

Second: a long run of my Later items carry identical scores. That is scoring fatigue, and I’m not going to pretend otherwise. Items more than two quarters out cannot be scored meaningfully, and forcing precise numbers onto them is fiction. The identical scores are the model telling me where my knowledge runs out. I treat that as a feature.

The obvious objection

Multiplying subjective guesses by subjective weights does not produce objectivity. It produces a number that looks more certain than it is. This objection is correct, and it misses what the model is for.

The number is not the output. The argument the number forces is the output. When an engineer says “there is no way that item is a 2 on risk”, that disagreement is the model working, and it happened before the quarter was planned rather than three sprints in. When a ranking looks wrong to someone, we check it against the weights together. Either the weights need changing or the instinct doesn’t survive contact with a written-down definition of value. Both results are useful. And if stakeholders keep overturning the output entirely, the problem is an unagreed strategy, and no spreadsheet fixes that.

The same reasoning explains why I didn’t use an off-the-shelf framework like RICE (reach, impact, confidence, effort) or SAFe’s WSJF (weighted shortest job first). They are fine frameworks, but each encodes someone else’s definition of value. RICE favours reach, which quietly undervalues statutory work affecting small groups of users. WSJF assumes you can estimate cost of delay honestly, which in my experience most teams cannot. One caution from my own sheet: scoring small items higher means big strategic work needs the deadline and portfolio scores to carry it, so watch that quick wins don’t permanently crowd out the big migration. Build your own weights and you at least know whose biases are in them. Steal the principle, not my spreadsheet.

Try it on your backlog

If you work in product in government, a council, a charity or anywhere else without a revenue line, try this. Write down the four or five things that constitute value where you are. Your list will not be mine, and it shouldn’t be. Put numbers on them, in the open, with your stakeholders if you can get them in the room and without them if you can’t. Then score your backlog and compare the ranking to your current roadmap. Where they differ, you have found either a flaw in the model or an assumption in your roadmap that was never examined. Both are worth an hour of your time.

One day I’d like the teams across a portfolio to run the same kind of model, so resourcing decisions between teams can be argued from something written down. I don’t think most portfolios, mine included, are mature enough for that yet. Team by team is how it starts. I’d like to hear where it breaks for you.

Personal views, not those of any client or department.

Mark Challinor is a product manager who has worked across UK central government, regulators, local government and health.

Leave a comment

Subscribe now

Questions this post answers

How do you prioritise a product backlog in the public sector?
Score every backlog item 1–5 against an explicit, written-down definition of value — in this model, six questions covering user need, organisational aims, urgency, size, skills and risk, combined through weights into a Product Priority score and a Deliverability score. The average of the two sorts the backlog into Now, Next and Later, and the arguments the scores provoke are where the real prioritisation happens.

Why not use an off-the-shelf prioritisation framework like RICE or WSJF?
Every off-the-shelf framework encodes someone else’s definition of value: RICE favours reach, which undervalues statutory work affecting small groups of users, and WSJF assumes teams can estimate cost of delay honestly, which most cannot. Building your own weights means you at least know whose biases are in the model.

Does weighted scoring make backlog prioritisation objective?
No — multiplying subjective guesses by subjective weights produces a number that looks more certain than it is. The value of the model is not the number but the argument it forces: disagreements about scores surface before the quarter is planned, against a written-down definition of value that anyone can challenge.