The Human Patch

Published: 2 July 2026

Every broken system has a person holding it together. The better they are at it, the less anyone notices the system is broken.

You’ve met this person. They maintain a private spreadsheet because the official system can’t answer a basic question. They know which three fields on the eleven-field form actually matter. They re-key data between two platforms that were supposed to be integrated years ago. They keep a personal knowledgebase with everything they’ve ever done, and when a process fails, and it fails on schedule, they absorb the failure so smoothly that the process gets the credit for working.

Wherever there’s a gap between what a system does and what people actually need, the gap doesn’t stay open. Someone gets stretched across it.

That person is the human patch.

Patches that hold don’t get fixed

I noticed this early on a school helpdesk. Our ticketing system was enterprise-grade on paper but a labyrinth in practice, built for an organisation a hundred times our size. We adapted, learned which fields mattered, kept device history somewhere else, and built the folklore that let us close tickets fast enough to get students back to class. The official process lived in the documentation, but the actual process lived in our heads. The distance between the two was us.

Effective patches kill the urgency for real fixes. The organisation feels no pain, because a person is absorbing it. Dashboards stay green, SLAs are met, tickets get closed as usual. The cost doesn’t land on a ledger; it lands on a random Thursday. Design debt rolls downhill until it settles on whoever sits closest to the problem, and their compensating work remains invisible precisely because it works.

People keep discovering this figure and giving it new names. David Graeber called them duct tapers, employees whose “jobs exist only because of a glitch or fault in the organisation; they are there to solve a problem that ought not to exist.”¹ Tanya Reilly called it glue work: noticing who’s blocked, catching what’s been handwaved in a design document, the unglamorous effort that decides whether a project succeeds, done by people whose job description says something else.² Richard Cook, writing about hospitals, put it most bluntly: “human practitioners are the adaptable element of complex systems.” Safety isn’t a property the system has, but something people create, moment to moment, through adaptation.³ Anthropology, software, medicine: same person in the middle.

Meanwhile the structure only grows. Every incident adds a form field, an approval step, a mandatory category, and nobody’s job is to delete the steps. Process even becomes a shield when things go wrong. “We followed the procedure” is a complete defence, whether or not anything got fixed. Rigid structure accretes, humans flex to compensate, and after a few years the organisation can no longer tell which parts of their process are load-bearing or theatre, because the human patches make all of it look like it works.

We were warned in 1983

None of this is a new observation. Lisanne Bainbridge published “Ironies of Automation” in 1983. The designer who views the operator as unreliable and tries to design them out, she wrote, “still leaves the operator to do the tasks which the designer cannot think how to automate.” Worse: “by taking away the easy parts of his task, automation can make the difficult parts of the human operator’s task more difficult.”⁴ Automation doesn’t remove the human. It reassigns them to the residue.

Michael Hammer made the organisational version of the argument in Harvard Business Review in 1990: companies “use technology to mechanize old ways of doing business. They leave the existing processes intact and use computers simply to speed them up.” His conclusion earned its title, “Don’t Automate, Obliterate”: “It is time to stop paving the cow paths.”⁵

Both warnings are older than the web browser. We spent the following three decades paving cow paths anyway, and now we’ve found a way to do it that looks even more like progress.

Now do it again, with AI

The 2020s version of the mistake goes like this: don’t fix the process, and don’t keep paying the person absorbing it either. Replace them with a model.

The pitch works because the human patch looks like pure cost. Their compensating work never appeared on a balance sheet, so removing it looks free. But you can’t calculate the return on eliminating work you never measured.

Replacing the human patch with AI doesn’t remove the inefficiency. It removes the only element of the system that was adapting to it.

The patch is more than a ticket processor. They exercise judgment and notice when the policy doesn’t fit the case, escalating the thing that smells wrong, doing the four undocumented steps that make the official five work. A language model dropped into that seat inherits the broken process with none of the judgment but all of the confidence.

We’re a few years into this experiment, and now the results are arriving.

Klarna spent early 2024 telling everyone its AI assistant was doing “the equivalent work of 700 full-time agents.”⁶ Fifteen months later, CEO Sebastian Siemiatkowski told Bloomberg the company was recruiting humans again: “As cost unfortunately seems to have been a too predominant evaluation factor when organizing this, what you end up having is lower quality.”⁷

Air Canada’s website chatbot invented a bereavement fare policy that didn’t exist. When a grieving customer relied on it, the airline argued before a tribunal that the chatbot was “a separate legal entity that is responsible for its own actions.” The tribunal called that “a remarkable submission” and ordered the airline to pay.⁸

Closer to home, Commonwealth Bank declared 45 customer service roles redundant because its new voice bot had supposedly reduced call volumes. Call volumes actually rose; staff went onto overtime and managers picked up phones. The bank reversed the decision in front of the Fair Work Commission, conceding the roles weren’t redundant after all.⁹ The bot didn’t remove the work. It hid the work, briefly, from the people that count it.

The aggregate numbers tell the same story. An MIT report found 95% of enterprise generative AI pilots produced no measurable P&L impact.¹⁰ Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027.¹¹ Researchers even coined a word, “workslop,” for AI-generated output that looks like work but shifts the real effort downstream; surveyed workers spent nearly two hours cleaning up each instance they received.¹² That last one is the whole pattern running in reverse: the AI creates the gap, and a person downstream absorbs it.

I want to be precise here, because this is not an anti-AI argument. I build with these models daily, and I’ve written before about the kind of ambient assistance I think is worth building. The failures above share a shape: AI aimed at the person instead of the problem, and each organisation automates the patch and keeps the wounds.

Simple first

John Gall wrote the rule in 1975: “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work.”¹³

Taken seriously, that’s an order of operations.

Simplify first. If a process only functions because a human patch is holding it together, the process is the bug, and the person is telling you exactly where it is. Streamline until a new starter can learn it in a day.

Structure second, and only where it earns its place. Every form field, approval step, and mandatory category should justify itself to the person doing the work, not the person reporting on it. A step that exists so a manager can feel informed is a tax on everyone downstream of it.

Automate last, and only what already works. Toyota has run manufacturing this way for seventy years. They call it jidoka, “automation with a human touch”: machines that stop and surface problems for human judgment, applied to processes that were improved and standardised first.¹⁴ They understood that automating a mess just gives you a faster mess.

And through all of it: ask the patch. The people compensating for your systems hold a complete, current map of everything broken in them. They maintain it involuntarily, every day, for free. It’s remarkable how rarely anyone asks to see it, and how often the same organisation will pay a consultancy to rediscover a tenth of it.

This is the principle I build software by: reduce friction for the person in front of the problem, trust their judgment, and make the system absorb the complexity instead of the human. It’s the entire reason Nosdesk exists.

A system that needs a human patch is telling you where it’s broken. You can fix the system, or you can swap the person out for something that will never complain about it. Only one of those fixes anything.