---
title: Human in the Loop
date: 2026-07-04T12:21:40Z
modified: 2026-07-06T16:56:38Z
permalink: "https://dgw.ltd/2026/07/04/human-in-the-loop/"
type: post
status: publish
excerpt: ""
wpid: 1245
categories:
  - AI
  - Code
  - Design
  - Systems
series:
  - Fifty Years, Same Argument
featured_image: "https://dgw.ltd/wp-content/uploads/2026/07/3-Human-in-the-Loop-bw.jpg"
---

Recently, [Ford announced](https://www.theverge.com/transportation/956316/ford-quality-jd-power-ranking-ai-automated-mistakes) it had rehired around 350 engineers. There’s an irony in that, given this series began with a post called “Fordism with a Toyota Badge.”

Not because of a downturn. Because the company had spent several years trying to replace experienced engineering judgement with AI-driven design and validation tools, and the result was the worst quality and recall record Ford has had in years. Charles Poon, Ford’s VP of vehicle hardware engineering, put it plainly: they thought introducing AI and adjusting the design requirements would automatically produce a high-quality product. It didn’t. The veteran engineers who left took decades of pattern recognition with them, the instinct for spotting a problem three steps before it became a failure, and none of that instinct made it into the training data before they walked out the door. The AI didn’t fail randomly. It confidently repeated mistakes no experienced engineer would have allowed, because the thing that would have caught them was gone.

Ford has now hit number one among mainstream brands in JD Power’s 2026 quality ranking – its first time since 2010, though it’s third overall behind Porsche and Genesis. The way they got there was by undoing the experiment. They put the humans back.

I don’t think this is a story about cars or even about AI.

## The problem has never been new

I’ve spent two posts working through this, and the thing I keep landing on is that none of this is new. Papanek was making the same argument in 1971. Seddon was making it in 2008. Russel in 2024. The mechanism that produced bad public service websites is the same mechanism that just produced a 16-year quality low at Ford. Command and control. Optimise the process, lose sight of the purpose. The names change. The argument doesn’t.

But I want to be clear about something, because I’ve slightly oversimplified it across the last two posts by treating Papanek, Seddon, and Russell as one continuous argument. They’re not quite the same thing, and the difference matters for what comes next.

Papanek’s discipline was ethical. He believed the designer has a responsibility to discover and define the real problem – not simply accept the brief as given. His most famous example is the [nine-cent radio](https://capacify.wordpress.com/2014/09/09/a-nine-cent-radio/) – a tin can, paraffin wax, and a wick, built to bring weather warnings and disease information to isolated communities with no access to power or literacy. A genuine answer to a genuine need, built from almost nothing. Papanek’s point was that the designer doesn’t get to wait for someone else to define the problem. You go out and find it, then design for that.

Seddon’s discipline is different, and in some ways more demanding. He doesn’t think good intentions or professional judgement are enough. Go and study demand. Stand at the point of contact. Find out what people actually need before you assume you know – because even a designer trying to uncover the “real” problem can still mistake it. Seddon would say Papanek’s ethical instinct is necessary but not sufficient. You also need the discipline of evidence.

Russell’s discipline is different again. The Landscape isn’t a hunch dressed up as an argument – its method is demand data: real-user monitoring, CrUX and HTTP Archive numbers, pulled from actual devices on actual networks. Russell went and looked, at scale. That’s genuinely closer to Seddon’s discipline than a design brief ever is.

Where it’s worth being precise, is what happens with that evidence once it’s gathered. The data proves the harm – JS-heavy defaults exclude people on cheap devices and slow connections. What follows from it, though, is another question: get rid of client-side JavaScript almost entirely, ship HTML, and the outcomes improve. To his credit, Russell doesn’t stop at the architecture – he also goes after the regime that produces it, telling managers to stop hiring for framework skills, set a latency budget per project, and issue leadership the same cheap devices real users carry. That’s Seddon’s territory as much as Papanek’s. But as we see from Papanek and Seddon, even the right architecture and the right process still aren’t the same thing as asking. Nobody asked the person renewing a parking permit whether they’d prefer server-rendered HTML, hired-for-fundamentals engineers, or a latency budget. They’d prefer the thing that works.

That’s worth holding lightly rather than as a rule. If a site doesn’t work at all on the device most people actually own, making it load is unambiguously an improvement – you don’t need a demand study to know that. The interesting edge is further along: once it loads, whether “better” still needs checking against real demand, or whether the diagnosis has earned enough trust to act on directly.

## What GDS got right

In November 2015, Obama wrote personally to Mike Bracken, the man running GDS, thanking him for the help GDS had given in building the US Digital Service in its own image. The following year Britain topped the UN’s e-Government Development Index. New Zealand and others copied GDS’s open-source code. This wasn’t a small, scrappy team doing nice work nobody noticed. It was, briefly, the global benchmark.

[Then it got hollowed out](https://public.digital/pd-insights/blog/2020/11/the-sad-tale-of-britains-government-digital-service) – Francis Maude’s own word for it, the minister who’d backed GDS from the start. Not because the people changed or the method stopped working. Because the system conditions around it changed. GDS had power to set standards and control spending across departments, and permanent secretaries hated it for exactly that reason – one called GDS staff “blue-jean kids” trampling on departmental fiefdoms. Departments would agree a project with GDS, then quietly launch their own version anyway. Two attempts were made to persuade the prime minister to remove Maude. After the 2015 election he was replaced, GDS lost the political backing that had protected it, and within months Bracken left.

You can draw a straight line from that loss of authority to the failures that followed – a [£495m Capita contract](https://www.nao.org.uk/reports/investigation-into-the-british-armys-recruiting-partnering-project/) to run army recruitment that never hit its targets, and the moment in 2020 when it emerged that part of the test-and-trace data pipeline was running through Excel, hitting the old .xls row limit and silently [dropping 15,841 positive cases](https://www.theregister.com/2020/10/05/excel_england_coronavirus_contact_error/) from contact tracing. It isn’t a simple decline story, though: Universal Credit’s technical backbone, rebuilt by GDS coders after a 2013 reset, scaled through a [tenfold single-day spike](https://dwpdigital.blog.gov.uk/2020/12/14/dwps-agile-response-to-covid-19-scaling-universal-credit-to-meet-demand/) in claims during the pandemic without falling over; [GOV.UK Notify has sent 12 billion](https://gds.blog.gov.uk/2026/02/05/more-than-a-helpdesk-user-supports-role-in-helping-gov-uk-notify-send-12-billion-messages/) messages since 2017. Capability didn’t vanish. None of that is a story about worse engineers. It’s a story about what happens when the body with the authority to insist on better gets quietly stripped of the authority to insist on anything.

This is Seddon’s point made at the scale of an entire government department: people’s behaviour is a product of the system they sit inside. GDS in 2013 and GDS in 2020 were not full of different kinds of people. They were sitting inside different system conditions – one with real authority to enforce standards, one without.

GDS succeeded because it refused to treat the service and the process as the same thing. “Start with user needs” wasn’t a values statement on a wall. It was Seddon’s demand analysis, basically – go and find out what people are actually trying to do, then build the smallest thing that does that, then test it with real people, then change it. The process served the purpose because the process was built around studying demand first.

The [Government Design Principles](https://www.gov.uk/guidance/government-design-principles) are still the gold standard for developing products. GDS was and still is awesome, they produce products for users that solve real problems. I used GOV.uk’s Passport service recently to approve a someones passport application (a nice quirk of being a company director) all on my phone, 4G – it was flawless – took a couple of minutes from email notification and the process fully completed and approved on his side. Incredible.

That’s the thing that’s never changed, and it’s also the thing that’s hardest to protect. It’s not that we lost some special knowledge. It’s that the regime – permanent secretaries, the targets, the sprint velocity, the Figma sign-off, the developer experience metric – makes studying demand inconvenient, and convenience usually wins, unless something with real authority keeps insisting otherwise.

The agency Obama wrote that letter to Bracken about has its own postscript now. The United States Digital Service, modelled on GDS, was [gutted in February 2025](https://en.wikipedia.org/wiki/US_federal_agencies_targeted_by_DOGE) – several dozen people dismissed by email, told USDS “no longer has a need for your services.” Of those who remained, 21 resigned together a fortnight later rather than stay. By November that year, the unit that had absorbed much of what was left of it no longer existed either.

## Ask the user. Still.

So here’s where I land, two posts in, and it’s frustratingly simple given how much I’ve written to get here.

Ask the user. Understand what they need. Study demand at the actual point of contact, end to end, not just the bit your team owns. Critique the process before you trust it. Define the outcome in the user’s terms, not the sprint’s terms.

None of that requires a framework decision. None of it requires choosing a side in the SPA-versus-server-rendered argument. It requires going and looking, the way GDS went and looked, the way Seddon’s case studies went and looked, the way Ford – eventually, expensively – discovered it needed actual engineers back in the room.

## What this looks like in the browser, today

Here’s the part that actually cheers me up. We are not short of tools. We’ve had most of the good answers for years – we’ve just been busy building component libraries instead of using them.

Restful URLs still work. The back button still works, for free, if you don’t fight it. `<meta name="view-transition" content="same-origin">` gives you smooth page transitions without a router. `navigator.serviceWorker.register` gives you offline support and instant repeat loads without a framework. `<script type="speculationrules">` prefetches the next page before the user clicks it. None of this is exotic. It’s HTML and the platform, doing what it was built to do, on a connection and a device that most of the industry stopped designing for around 2014.

CSS has quietly become extraordinary while everyone was looking at JavaScript. `:has()`, `@container`, `grid-template-columns: subgrid`, `@keyframes`, `prefers-reduced-motion: no-preference` so the animation respects the person who asked for less motion, custom-property-driven animation sequences – built entirely in CSS, no runtime cost, no hydration, nothing to ship to a phone that’s already struggling. The platform got really good.

In 1991, the worlds first web developer uploaded a [.html](https://info.cern.ch/hypertext/WWW/TheProject.html) file to the WWW and it worked. It still works today. And it’s responsive.

None of this is a prescription, in the way Russell’s conclusion edges toward one. It’s an observation: the technically humble option is usually also the option that actually gets tested against real demand, because it’s cheap enough to build twice, show someone, and throw away.

## The loop, with the human back in it

“Human in the loop” in AI safety usually describes a checkpoint – a person who reviews the output before it ships. That’s not quite what I mean. A checkpoint at the end doesn’t fix a process that never asked the right question at the start. Ford’s AI tools weren’t missing a review stage. They were missing the engineer who would have caught the problem three steps earlier, because that engineer had already left.

There’s a Seddon point I’ve skated past in both of these posts that belongs here. He doesn’t just say study demand. He says the people doing the work – the dustman, the agent on the phone, the engineer who’s shipped a dozen product cycles – hold knowledge nobody above them has, and the entire architecture of command and control is built to strip them of the authority to act on it. Not because anyone decides to silence them. Because specialisation, scripts, and sign-off chains quietly move the authority to decide somewhere else, usually upward, usually to someone further from the work.

That’s what was actually missing from Ford’s production line. Not a checkpoint. The 350 people who knew, three steps ahead, that something was wrong – and who’d had the standing to act on it before they were the ones who left. It’s what GDS lost when permanent secretaries won back control of standards they didn’t have to meet themselves. It’s what the USDS engineers refused to give up when they walked rather than stayed.

Putting the human back in the loop means putting them at the start, with real authority to act on what they know – not as a reviewer signing off someone else’s output, but as the person whose judgement the process is actually built around.

This is also, I think, the real danger in training AI on the lost decade’s output, more than the bytes and the load times I wrote about in the last post. It’s not just that the code is bloated. It’s that the code was produced by a process that had already stripped the authority away from the people who knew better – the developer who could see the accessibility problem but wasn’t in the sign-off meeting, the engineer who flagged the edge case in a ticket nobody read. None of that judgement made it into what got shipped, so none of it is in what the model learned from either. Russell’s data shows what the lost decade built. What’s missing from it is the knowledge that never got listened to while it was being built – which is exactly the knowledge a checkpoint at the end of an AI pipeline still won’t recover.

## Use the tools. Point them at demand.

None of this is an argument against the tools. I use them. An LLM that scaffolds the dull parts, an agent that takes a properly-defined task and runs it end to end – these are good at what they’re good at, and pretending otherwise would be its own kind of dishonesty. The problem was never the tool. It wasn’t the framework either. It was reaching for either one before anyone had asked what the thing was actually for.

The discipline is the same as it has always been. Know why you are pointing the tool at the problem, and know what a good outcome looks like – in the user’s terms and the business’s, not the demo’s and not the sprint’s. Those two things are the same thing, in the end: a service that resolves the demand the first time is cheaper to run than one that generates a year of failure demand behind it. Seddon’s phrase for that was managing value drives out cost. It applies to an AI pipeline exactly as it applied to a council call centre.

Point an agent at “build a visitor parking permit service” and it will hand you back the one that already exists – bloated, framework-heavy, and ready to fall over the first time someone with a cracked screen and one bar of signal actually uses it, because that is the average of everything it was trained on. Point the same agent at what you found when you went and studied the demand – six siloed systems, an address that should be proved once and not six times, a person who has ninety seconds and no patience – and it can build something genuinely better, faster than you could alone. Same tool. The entire difference is in what you knew before you opened it.

That is the human in the loop. Not a person watching the machine work. A person who did the studying the machine can’t do, decided what good means for the people on both ends of it, and is using the tool to get there faster – rather than letting the tool decide, from a training set that never thought to ask, what “there” even is.

Papanek would have called that ethics. Seddon would have called it studying demand. Ford just spent several years and a recall record finding out the expensive way. We’ve known this since 1971. We’re going to keep relearning it, at increasing cost, for as long as the regime makes it inconvenient to just go and ask.