--- title: The Code That Fed the Machine date: 2026-07-04T12:21:35Z modified: 2026-07-06T16:48:09Z permalink: "https://dgw.ltd/2026/07/04/the-code-that-fed-the-machine/" type: post status: publish excerpt: "" wpid: 1244 categories: - AI - Code - Design - Systems series: - Fifty Years, Same Argument featured_image: "https://dgw.ltd/wp-content/uploads/2026/07/2-The-Code-That-Fed-the-Machine-bw-scaled.jpg" --- You’ve moved house, and somewhere on the list is a visitor parking permit so the BT engineer can install the broadband connection. You find the council website. There are three parking pages and none is obviously the right one. You pick the most plausible, create an account, and find the system doesn’t recognise your new address yet. You come back later. The account hasn’t kept what you were doing. You start again. While you’re there, you look up a neighbour’s planning application. The portal loads and you find the application, but the one document you want to read isn’t on the page – it’s folded inside a panel marked “Documents” that’s collapsed by default, so it looks as though there’s nothing to see. You expand it. There are fifty-four files. Every one is named the way the architect’s office saved it – `238_S1300_PR_ELEVATIONS.pdf`. You download five and open them all to find the one that actually details the application. An hour and a half has gone. You found the planning document in the end. The parking permit – the thing you actually sat down to do – you didn’t: the system never accepted your new address. You swear, a lot and you’ll have to call them tomorrow to resolve it. That call is failure demand: Seddon’s term for contact generated not because you need something new, but because the system failed to resolve your need the first time. The council will log it as a support request – categorised, assigned, tracked. The dashboard will show the team is busy. Nobody will ask why you called. ## This isn’t one bad website The planning portal. The parking permit system. The benefits calulator. These aren’t outliers. They are the default. [Alex Russell](https://infrequently.org/series/reckoning/) spent many years documenting what the web actually looks like from the outside – not from a MacBook on a fast connection in an open-plan office, but from the devices most people actually use. The numbers are not subtle. JavaScript payloads shipped to mobile grew substantially over the decade, per HTTP Archive’s own tracking. The cheap Android phones that represent the majority of new device sales barely got faster over the same period. The gap between what the industry built and what most people could run got wider every year. [28% of US adults](https://infrequently.org/2024/08/the-landscape/) in households earning under $30,000 are smartphone-dependent – the phone is their only internet access. The public services they need most are increasingly built on framework stacks that assume a broadband connection and a device bought in the last three years. They aren’t. The people who most need these services are the least likely to be able to use them as built. We created failure demand – sites that don’t load or work – to satisfy a different system: developer experience. This is not a technical failure. It’s a design failure. The web was built, during the lost decade, for the person building it. Worse still there often isn’t even a call centre to call now, it’s probably a web form and if you are lucky you might even get an email acknowledging your submission. ## How it happened The tools got better at the wrong things. React made it easier to build complex interfaces. It also made it very easy to ship a megabyte of JavaScript to render a page that could have been HTML. Next.js made that easier still. The framework became the default not because it was the right tool for the job but because it was what developers knew, what bootcamps taught, what job listings asked for, what the component library was built in. Developer experience became the metric. If it was fast to build, it was good. If the hot reload was snappy, it was good. If Lighthouse scored green on a gigabit connection, it was good. Whether it worked on a £80 Motorola in a benefits office waiting room was not the metric. That person wasn’t in the room when the metric was chosen. Figma made it easy to produce something that looked (almost) exactly like a finished product without it being one. The design system was beautiful. The prototype was pixel-perfect. The handoff was clean. What never got tested was whether any of it worked for the person it was supposed to serve – on their device, on their connection, in their circumstances, trying to do the actual thing. The process optimised itself. The purpose got left in the backlog. ## The planning portal is a monument None of that is an accident, and none of it is unusual. Every planning portal I have used works much the same way, and the detail is the argument. Before you ever reach an application you face a search screen with a dozen fields, where filling in too many returns zero results – the most reliable route to the results page is to search for almost nothing and wade through whatever comes back. The fields fight you. One marked “address” wants the whole thing, formatted its way. One marked “street description” turns out to mean nothing more exotic than the street name. Nobody tells you. You learn it by failing. And yet nothing here is broken in the way that throws an error. Every page loads. Every button works. It is a completely functional system for doing something slightly to the side of what you actually need – built to satisfy a procurement specification written by people who have never tried to find a planning application. The file-size limits don’t match the file sizes the guidance asks you to produce. The session timeouts are shorter than the time it takes to read what you’re being asked. The error messages tell you what went wrong without telling you how to fix it. They are also, in many cases, genuinely old. Built in the mid-2000s on frameworks that made sense then, maintained by contracts that make replacement expensive, holding data that makes migration complicated. The technical debt is structural. The user experience is the debt made visible. These were the systems Seddon was talking about in 2008. The visitor permit system is the other half of the lesson – what Russel was talking about to in 2024. Quite often a rebuild of an earlier clunky system built on ASPX or something – newer, shinier, broken in the opposite direction. It greets you with a clean four-step progress bar and a tidy summary card: permit type, duration, vehicle limit, cost. Then, to take a single pound for three hours of parking, it hands you off to a third-party payment processor in a completely different visual language. Alongside it sits a separate “Contact Us” form whose “Subject line” dropdown is empty. It’s been rebuilt, recently, in something modern, and it still doesn’t work _as a service_ because the rebuild restyled the interface without redesigning what sits behind it. The journey looks smoother. The underlying logic – separate systems that don’t share data, each wanting you to prove who and where you are over again – is unchanged. Shiny front end. Same failure demand underneath. ## The training data problem AI coding tools are trained on code. The code they are trained on is the code that exists. The code that exists is the code the lost decade built – React-heavy, DX-optimised, framework-first, accessibility bolted on as an afterthought, performance treated as a nice-to-have. That’s the corpus. React sits at 83.6% of front-end framework usage ([State of JS 2025](https://www.infoq.com/news/2026/03/state-of-js-survey-2025/)) and 44.7% among all developers surveyed by [Stack Overflow 2025](https://survey.stackoverflow.co/2025/technology) – second only to Node.js. Millions of repos, millions of data points, one default the model has seen a billion times. AI design tools are trained on design. The design they are trained on is the design that exists – on Dribbble, in component libraries, in the Figma files that got exported and shared and referenced. That design was largely produced for client sign-off rather than user need. It was produced at 1920px for a desktop that most users don’t have. It was produced to win pitches and pass reviews and close tickets, not to be used by a 58-year-old trying to apply for a blue badge on a phone with a cracked screen. This is the codebase AI is learning from. This is the design canon it considers normal. A Borges’ Library of Babel of React Hooks. When you ask an AI to build you a council planning portal, it will build you the planning portal that already exists – because that’s what planning portals look like in the training data. It will do it faster. It will do it more confidently. It will do it without the human who might have said: wait, has anyone actually tried to use this? Same mechanism, different corpus. Take Claude, possibly the most advanced coding agent, they released something called ‘design-sync’ only the other day: _Claude Design (beta) and Claude Code now sync both ways. Hand off a design and edit directly on the canvas, or start in Claude Code and sync projects from your terminal._ I [tried it on a project](https://dgw.ltd/2026/07/02/draw-me-like-one-of-your-json-files/) and got this message: ``` /design-sync converts a JS/React design system - one whose dist/ compiles to a standalone browser bundle exposing components at window..* - so the claude.ai/design agent can render them live and emit React code your engineers ship. ``` React says no (not for the first time). Even among React’s own users, “design systems” is the second most common thing they build with it, after web apps ([State of React 2025](https://2025.stateofreact.com/en-US/usage/)). The tool isn’t inventing a bias. It’s reflecting one back at you. QED. ## The human who isn’t in the room The lost decade removed the human from the loop incrementally. The user researcher went first – a cost, not a core function, same goes for a11y. Then the developer in the discovery session. Then the designer who understood the codebase or at least the tradeoffs between functionality and aesthetics. Then the QA process that tested on real devices. The tooling can take care of it – `npx create-next-app`. Install Tailwind. Engineer a solution and code away all the awkward questions. Scale the process. Each removal was a cost saving. Each removal was a small increment of failure demand baked into the next release. AI doesn’t remove the human incrementally. It removes the human as the default. The pipeline runs without them. The code gets written, the interface gets generated, the thing gets shipped – and somewhere downstream, a person on a £80 Android tries to get a visitor parking permit and the session times out and they call the council and the call gets logged and the dashboard shows the team is busy. The argument doesn’t change. The speed does. The researcher, the developer, the designer, the QA process – none of them just did tasks. They held things nobody else saw: the accessibility problem, the edge case, the “has anyone tried this” instinct. None of that made it into what shipped, which means none of it is in what the model has learned from either. Part three is about what it looks like to put that knowledge – and the authority to act on it – back in the loop.