The Detector Retires the Competence

A container refuses to start. The error names the entrypoint script: no such file or directory. The script exists. It is executable. It is sitting right there in the image, and you can print it to the terminal and read it.

Someone spends the afternoon on that script.

The script was never the problem. I have watched this failure eat an afternoon, and the mechanism is well known. A line-ending conversion rewrites every newline in the file, so the first line no longer reads #!/bin/sh but #!/bin/sh followed by an invisible carriage return. The kernel goes looking for an interpreter with that name, does not find one, and reports the failure against the only filename it has. The error is accurate and useless. It points at the file, because the file is what failed. It cannot point at the cause, because the cause was a setting in someone's environment three steps earlier.

What is interesting is the conclusion you draw at the end of the afternoon.

The tempting conclusion is that developers ought to know about line endings. Write it up. Add it to onboarding. Put it in the wiki, in the section nobody opens.

What actually fixed it was one line in a .gitattributes file pinning the repository's line endings, committed once. After that, nobody needed to know. Not the person who lost the afternoon, not the next hire, not the person who joins in two years and will never hear the story, because there will be no story.

That is the whole argument, and I want to make one question routine: not who needs to know this? but where does this risk live? The answer has to be a check path, a runtime signal, or a person's name. Never "we hope someone remembers."

I published an essay about competence twelve weeks ago. This one contradicts it in one important place, and I will get to that.

Software's competence problem was solved in a factory

Occupational safety settled this argument before any of us were born, and software has never read the memo.

NIOSH's Hierarchy of Controls has five rungs — elimination, substitution, engineering controls, administrative controls, personal protective equipment — sorted by a principle the standard states outright: the top three "control exposures without significant human interaction," while the bottom two "rely on human compliance." The ladder is ordered by how little the control depends on a person doing the right thing.

Training is an administrative control. Fourth of five. It shares its rung with written procedures, shift rotation and warning signs, and it sits exactly one rung above handing someone a mask and hoping it fits. A century of industrial safety practice has concluded that "we told them, and they know" is the second-weakest thing you can do about a hazard.

Nearly every argument about competence in software — including the one I made in May — is an argument about how to do rung four well.

I want to keep a version of this ladder for software, and it needs four rungs, not five:

1. Eliminate. The failure class cannot occur. The feature is deleted; the architecture makes the bug impossible; the invalid state cannot be expressed.
2. Guardrail. A machine enforces it — a type, a check, a limit, an operation that refuses to do the dangerous thing, a runtime signal with a defined response. It fails loudly, or it cannot fail. It is always executable, never a sentence in a document. (Containment — rollback, canaries, feature flags — is a second axis rather than a lower rung. An automatic rollback depends on nobody, so it is rung two. A rollback that lives in a runbook somebody has to remember to open is rung four, and the fact that it is called a rollback does not help.)
3. Competence. A named human holds it, and the holding is verified by an external check they cannot grade themselves.
4. Reminder. Unverified human memory. A wiki page. A rule everyone agreed to.

I should be honest about what I just did, because it is the kind of move that wins arguments dishonestly. That is not NIOSH's ladder. I took the single administrative rung and split it into two — competence and reminder — which has the convenient effect of moving competence up a place. Normalise my four rungs back onto the standard five and competence does not land third of four. It lands fourth of five, tied with the wiki page it thinks it is better than.

I want the split anyway. An unverified human control has an unknown failure rate. A verified one has a measured failure rate. That is a real difference in kind: a control whose failure rate you cannot state is not a control, it is a hope. It is worth a rung. It is not worth the middle of the ladder, and any framework that puts it there — mine included, until recently — has quietly promoted the thing it should be trying to need less of.

The bottom rung needs a sharper definition too, because "written down" is not what makes something weak. The most successful safety intervention of this century is a checklist. Haynes and colleagues put a nineteen-item surgical safety checklist into eight hospitals in 2009 and watched the death rate fall from 1.5% to 0.8%; it is now recommended by the WHO and national policy in more than twenty countries. If reminders are so feeble, why did that work?

Because the surgical checklist is not a reminder. It has an enforcement point. The operation does not proceed until someone reads it aloud, with the team stopped and a named person responsible for running it. That gating is the entire mechanism. The same nineteen items in a binder that surgeons are encouraged to consult would have saved nobody.

So rung four is not "a rule that is written down." Rung four is a rule with no enforcement point. Attach a gate to a checklist and it climbs the ladder; detach the gate from a guardrail and it falls down it.

The software translation of that is sitting in your pull requests right now. Every code review comment you have made twice is a lint rule you have not written. The comment is rung four: it works only while you keep noticing, personally, forever. The rule is rung two. The distance between them is usually an afternoon, and the reason it does not get spent is that making the same comment a third time feels like work and writing the rule feels like a detour.

And rung four is allowed. Some risks are cheap and rare and genuinely do not earn a control. The rule is only that choosing a reminder must be a logged, deliberate decision rather than the thing that happens when nobody decided anything. The defect is not choosing a reminder. The defect is relying on one without knowing you are.

Rung four also has an evidence problem. Parasuraman and Manzey's review of the automation-complacency literature found that complacency shows up in experts as readily as in novices and "cannot be overcome with simple practice," and that automation bias — accepting a machine's output when it is wrong, and failing to act when it stays silent — "cannot be prevented by training or instructions."

Your competence list is a variable

Here is the consequence, and it is the reason this essay exists.

What your team must hold unaided is not a property of your domain. It is the set of failures your machines cannot see. Ship a detector and the competence it required stops being anyone's job — not delegated, not automated, retired. Nobody holds it because nobody needs to.

Safety engineering has been precise about this for thirty years, and I would rather borrow the vocabulary than pretend I invented an axis. IEC 61508 sorts every failure into four boxes along two axes: safe or dangerous, detected or undetected. The category the entire discipline organises itself around is dangerous undetected — the failures that matter and that nothing notices. There is a metric for how much of that category your own diagnostics catch, called diagnostic coverage, and the standard quotes target bands of 60%, 90% and 99%. And the standard improvement move, described in the literature in almost these words, is converting dangerous-undetected failures into detected ones.

That is this essay's claim, written thirty years earlier by people who work on things that explode.

It also gives the residual a definition sharper than any I had. Your competence list is your dangerous-undetected set. Not a philosophy of craft, not a rubric, not a statement about what a real engineer ought to know. An inventory of what your diagnostics do not cover. It is specific to your codebase, it is dated, and it moves the moment you build something.

Take the concrete case. A framework's development mode lets you push a schema change straight into your local database. Production does not work that way — production needs a committed migration file. So a developer adds a field, everything works locally, the tests pass, the review passes, and the deploy fails in production, or worse, succeeds against a schema that has quietly diverged. The competence this demands is real and unglamorous: remember that dev mode lies to you here. It has to be taught to every new hire, it decays, and it is invisible until the day it isn't.

Now write a check that runs before every push: ask the framework to generate a migration, and fail if the generated file contains any actual schema statement — because its presence means the committed migrations are behind the code. Twenty lines of shell.

The competence is gone. Not delegated to a junior, not written up more clearly, not automated in the sense of someone still supervising it. Retired. It is not on anyone's list any more, it will not be taught to the next hire, and it cannot decay.

Every engineer already believes in better checks. What almost nobody prices is the second return: each check you ship deletes a line from onboarding, permanently. That is why "what must my team know?" is the second question and not the first.

The reason competence can be defined as a leftover at all is that something else is doing the positive work: contracts. A contract is a promise the system makes — to a user, to another service, to an operator. A risk threatens a contract. A guardrail enforces one. A test verifies one. And a competence is the part of holding a contract that no machine currently covers. Without that anchor, "the residual" is just whatever is left over, which is precisely the trap Bainbridge identified in 1983: automate the parts you know how to automate, and the human is left holding whatever could not be automated — a residual arrived at by subtraction rather than by design. The proposal in this essay is to choose it instead.

The obvious objection to all of this is that the top rung is unaffordable — that eliminating a failure class is a nice idea for people with infinite budget. Android is the counterexample, and it is public. Over roughly six years of moving new code to a memory-safe language, memory-safety bugs fell from 76% of Android's vulnerabilities to 24%, and dropped below 20% for the first time in 2025; in absolute terms, from 223 in 2019 to under 50 in 2024. Google puts the vulnerability density of the Rust code at roughly a thousandth of the C and C++ estate.

But the numbers that matter for this argument are the boring ones. Rust changes at Google show a ~4× lower rollback rate, spend about 25% less time in code review, and need about 20% fewer revisions than comparable C++ changes. Eliminating the hazard class did not cost velocity. It bought velocity. The strongest control on the ladder turned out to be the cheapest one to live with — and the reason is not mysterious: the reviews got shorter because there was less for a human to notice.

Structure decides how much you can retire

There is a dependency running under all of this that I have been quiet about, and it is the one an experienced engineer will find first.

Could a detector exist? sounds like a question about the risk. It is mostly a question about your codebase.

Consider why the migration drift check above is twenty lines of shell. Because the framework offers a seam: one command, defined output, a file you can grep. Or take a component that can exhaust a shared resource. You can guardrail it — refuse below a floor, prune before writing — only if every use of that resource passes through one place. Scatter them across fourteen call sites and there is no guardrail left to build. The hazard is identical in both codebases. The control is available in only one of them.

That generalises further than it first looks. In a module with tangled state you cannot make the invalid state unrepresentable, because there is no single place the state is constructed. In a system with no boundaries you cannot write a rule forbidding a boundary violation, because there is nothing for the rule to name. Without seams there is nothing to instrument, nothing to stub, nothing to assert against. Cohesion and coupling set the ceiling on your achievable diagnostic coverage. Every control needs somewhere to attach, and structure is the thing that produces attachment points.

So refactoring is not tidying that happens when a sprint has slack in it. It is what raises the ceiling on everything else in this essay, and in most codebases it is the highest-leverage safety work available — because it does not remove one hazard, it makes a whole class of controls buildable that were not buildable last week.

I want to be blunt about the misreading this essay invites, because it is the one that would cost it the readers most able to act on it. Nothing here says structure stops mattering once you have checks. The argument runs the other way. Badly factored code has a low ceiling on how many competences it will ever let you retire, and no amount of enthusiasm for automation raises it. Someone who has spent a career on cohesion and coupling has been building the surface that every control in this essay bolts to, whether or not the work was ever described that way. The payoff for it is not that the code looks good. It is that a competence you would otherwise be teaching to every new hire forever collapses into twenty lines of shell.

The procedure: walk the ladder on a real task

All of that is useless without something you can run on a Tuesday, so here is the procedure. Six questions, in order, stopping at the first one that resolves.

The order is the whole point, and I want to flag why, because I have shipped a decision framework for this before and it was arranged differently. My previous essay's dial asked who does this task? first — you, the model, you with the model watching. This asks what rung can this risk bear? first, and the question about a human is the last one, reached only after every machine question has failed. Same inputs. Inverted order. The inversion is the argument.

1. Can I delete it? Does this feature, field, flag or code path need to exist at all? The cheapest control is the one with nothing left to control. This is the question everyone skips, so ask it out loud once per task or you will never ask it.
2. Can I make the failure unrepresentable? Not "will I be careful" but: is there a type, a schema, a narrower interface, an invariant that makes the wrong state impossible to express? This is refactoring, and it belongs on rung two. Most of what a careful engineer does to a module under the name of design is hazard elimination that nobody scored as safety work.
3. Does a detector or guardrail already exist? A type-check, test, lint or runtime signal that fails loudly on this mistake — or an operation that already refuses to do the dangerous thing. Then delegate the work and trust the control. Review the output against the contract rather than skimming it, and move on.
4. Could one exist, and can you build it inside this task? Then the task is not "hold this competence." The task is build the control — a check or a guardrail — then delegate. This is the step that shrinks the list, and it is the one that gets skipped under deadline pressure in favour of a human promising to be careful. Note that the answer is not a property of the risk. It is a property of your codebase: a control needs a seam to attach to, and whether one exists was settled by whoever last shaped this module.
5. Is the failure silent, consequential, and uncovered? All three, and no control you can afford today changes that. Then you hold it — nothing else will — and you file the detector you did not build, on the same commit.
6. Is this your first build in this domain? Then hold it once, with someone watching, whatever the stakes. Never rent your first build. This is bounded and dated, not permanent.

Otherwise: delegate. Absent a named reason from five or six, holding is the defect.

One property of the list is easy to miss and does a lot of work: it is not seniority-blind. Run it over a two-year developer's week and question six fires on nearly everything, because nearly everything is a first build. Run it over a ten-year developer's week in a domain they own and it almost never fires. Same six questions, no separate policy — an apprenticeship falls out of the procedure rather than being bolted on beside it. A framework that told juniors to delegate by default would be indefensible, and this one does not; the reason is structural rather than a concession.

"File it as debt" stays a slogan unless the debt has a shape, so give it four fields and no more: the failure that is currently silent; the check that would make it loud; where that check would run — pre-commit, CI, or a runtime signal — and who is holding the competence until it exists.

That last field is the uncomfortable one, and it is deliberate. It puts a name and a date on every hold. It converts "this is subtle, I'd better own it" from a permanent state into an open ticket with an owner. When the check ships, the row closes and the name comes off. A hold with no detector debt attached is a hold that will still be there next year, and so will the person carrying it.

One distinction before the examples, because "check it" is the mushiest of the three buckets:

• Reviewing the output — did this satisfy the contract? Cheap, frequent, necessary, and it builds no competence whatsoever. It is consumption.
• Checking the competence — can you produce or reason this unaided? Rare, deliberate, and the only check that proves you own anything.

"I reviewed the diff" is not "I can do it."

Six tasks, six different answers

Run the procedure on real work. I have deliberately chosen six that end in six different places, because a set that all resolved to "hold it" would prove the opposite of everything above, and a set that all resolved to "delegate" would be an advertisement.

A settings flag nobody has flipped in a year. Two code paths, two test matrices, a configuration surface that can be set wrong in production, and exactly one value anyone has ever used. Question one wins immediately, and it is worth savouring how much disappears with the flag: who tests the other path, who documents it, who remembers how it interacts with the retry logic, whether it is still correct after last quarter's refactor. Verdict: eliminate. Free, and it is the answer nobody reaches for because deleting things does not look like engineering.

A function that takes four booleans. The behaviour is needed, so question one fails. Question two lands: the failure mode is two transposed arguments at some call site, which is silent, survives review because the types match, and no test catches the particular transposition nobody imagined. Replace the four booleans with a small set of named cases the type system enumerates, and the wrong call stops compiling. Every senior engineer reading this recognises the move: it is interface segregation, and they would file it under good design rather than under safety. It is both, and the second filing is the one that gets it prioritised. Verdict: design it out. Note what happened to the competence — "remember the argument order here" was a genuine thing a human carried, and it no longer exists to be carried.

A writer that appends to a disk shared with backups, logs and media. When the disk fills, the box stops serving anything. The writes are needed, and "too much accumulated data" is not a state you can make unrepresentable, so questions one and two fail. Question three fails too — nothing catches it today, and the tempting move at this point is to skip ahead and call it a hold, which means somebody remembering to watch the disk. Question four is there to stop you. The control is a self-limiting write: check free space, prune before writing, refuse below a floor, emit a headroom signal. It cannot fill the disk, so nobody has to remember not to. Verdict: build the guardrail, then delegate. And note carefully what the human ends up owning: not "watch the disk," but the ability to design that control. The competence is the capacity to push a risk down a rung, which is a very different thing from holding the risk in your head.

Add a nullable field to a database-backed model. Question three splits the task in half. The field config, the admin component and the generated types are loud — the compiler and the tests will catch you. The migration is silent. So the answer is not "hold the migration knowledge": it is question four. Build the drift check — generate a migration, fail if the generated file contains a single schema statement — then delegate the entire task, migration included. One afternoon of shell script, once, against a competence that would otherwise be taught to every hire forever. Verdict: build the detector, then automate. This is the whole thesis inside a single ticket.

Add a message type to a contract several services consume. Questions one through three fail in every direction at once. A message published to a topic with no authorisation grant is dropped silently. Consumers that were never updated to the new version drift until something breaks weeks later. A change to the envelope shape breaks a service that will not rebuild until someone touches it. Question four is where this one is decided, and it is decided on cost: the controls exist in principle — a grant check, a consumer-version check, a lint forbidding hand-copied contract types — and building three of them across several repositories is not something that fits inside this ticket. So you land on five. Verdict: hold — and file all three as detector debt on the same commit. And say the quiet part: "almost nothing here is rentable" is a statement about this codebase's diagnostic coverage on this date, not a statement about the technology or about how serious the work is. Build those three checks and most of this task becomes delegable next quarter.

A change to the last-resort supervisor that restarts everything else. There is no net beneath it. The thing that would alarm you if this failed is the thing you are changing, so a mistake is silent by construction — and unlike every case above, there is no runtime detector to build, because any runtime detector would depend on the component under test. What you can build is a drill: kill it, confirm the restart, script that. But a drill is a test-time oracle, not a net. The competence stays held, because the drill runs on Tuesdays and the failure happens on Saturday. Verdict: permanent floor. Held, marked must-stay, and never scored as a failure to automate. This matters for how you measure the whole programme: a metric that rewarded shrinking the competence list without exception would eventually reward automating the watchdog, which is optimising directly into the ditch.

Five of the six ended somewhere other than "a human must know this." Of the two involving a human at all, one is temporary — build three checks and it moves — and one is permanent. I picked six that land in six different places, so the distribution on its own proves nothing; what it shows is the range of answers available before "somebody must know this" becomes one of them. Run your own six now, and again in six months. The distribution should move. If it hasn't, nobody built anything.

What my last essay got wrong

Renting Competence went up twelve weeks ago. Most of it I still believe. One thing in it was wrong in a way worth naming precisely.

It was not that the essay ignored over-caution. It didn't. It has a section titled AUTO is real, with preconditions, which says flatly that "a framework with no AUTO is just 'do everything yourself' and is rejected by reality," and it tells you that broad shallow knowledge is now free and that renting most competences is fine as long as you are honest about it. Both failure modes are named.

The problem is that only one of them was enforceable. The essay gave the de-skilling side detectors — touchpoints, external checks, first-build rules — and gave the over-holding side nothing but good advice. One side had machinery and the other had intentions, which means only one side was real. A framework that names two failure modes and can only catch one is not balanced; it is a framework with a blind spot and a paragraph of disclaimer over it.

Under-delegation is also not a mass failure of adoption. Roughly 90% of developers report daily use of AI tools in DORA's 2025 research; 84% of Stack Overflow's 2025 respondents use or plan to use them. And the tools work: three randomised controlled trials across 4,867 developers at Microsoft, Accenture and a Fortune 100 firm found a 26% increase in completed tasks, concentrated in less experienced developers, who gained 27–39% against 8–13% for seniors. Meanwhile trust is falling in both surveys — 46% of Stack Overflow's respondents no longer trust the accuracy of what they get, up from 31% a year earlier. Nobody is refusing the tool. They are using it and not believing it.

Which is the actual shape of the problem. Generation got cheap and verification did not. Sonar's survey of more than 1,100 professional developers puts AI-assisted code at 42% of what they commit, finds that 96% do not fully trust it, and finds that only 48% always verify it before committing — which means the majority are making a case-by-case call about when to check, using judgment, unaided, on precisely the question people are documented to be worst at self-assessing. 38% say reviewing AI-written code takes more effort than reviewing a colleague's.

The constraint has moved from writing to checking, and checking is being paid for with human attention — the weakest control on the ladder. That is not a workforce that needs telling to be more careful. It is a workforce that has been handed a verification bill it cannot pay by hand. You can pay for verification with attention, which does not scale and cannot be audited, or with detectors, which do and can.

So the mechanism for the over-holding side has to be something a busy reviewer cannot rubber-stamp. A checkbox asking "did you consider whether this could be delegated?" will be ticked without reading by week three. The fix is to stop gating the hold and start gating the reason: any claim that a surface is silent, consequential and uncovered must produce a detector-debt row naming the check that does not exist. The output of the gate is a backlog item, not a permission slip. Anyone can rubber-stamp a checkbox; nobody can rubber-stamp a backlog that never shrinks — and the count becomes derivable from open rows rather than maintained by hand in a document that rots.

Two honest carve-outs, or the rule is wrong in practice.

Holding for growth is legitimate. Sometimes a developer should learn something the model could do entirely, because they will need it in six months, or because the technology punishes shallow understanding and renting it produces exactly the shallowness it punishes. That is a real reason. It just has to be signed off, dated, and excluded from the risk arithmetic, so that "I'm learning it" cannot quietly become an unbounded licence to hand-code everything.

First build stays mandatory, which is my answer to the sharpest objection to this whole essay. My previous piece drew a distinction I have not repeated here: skill never built, the developer who has shipped a dozen features in a domain they never understood, with no earlier competence to atrophy from because none was ever formed. "Delegate by default" is exactly the policy that could make that worse. Question six is the guard: your first build in any domain is held, watched, and not negotiable, and the growth carve-out is where apprenticeship lives. That is a smaller answer than the problem deserves, and the longer treatment is in the earlier essay.

One claim I am dropping: that the ceiling for delegation is exactly the de-skilling line. It is not knowable. My own previous essay argues that skill-never-built is invisible by construction, and you cannot maximise up to a boundary you cannot see. What I can do is check whether anyone on the team has produced anything unaided this quarter — which is a worse instrument and an actual one.

Certifying what is left — and how not to

Once the residual is small, verify it, because self-assessment does not work and the exam is the only part of the ladder that measures a human.

Do the cheap things first. They are the ones I have actually run.

Read the gaps out of merge history. Near-zero cost. Go through a developer's real commits over a quarter and ask, of each, what it demonstrates and what it dodges. You learn more in an hour than any exam will tell you, because it measures what someone does in flow, which is the thing you actually care about. Start here, every time.

Then AI-off oral probes, with no build at all. Half an hour, a whiteboard, and questions with a defined right answer: Where does this code run? What leaks across that boundary? Frozen or offline — how would you tell the difference? Does this change force a version bump? Cheap, repeatable, and they catch most of what matters.

Then, and only then, the exam. I have not run it. I have designed it, and I am describing it because the design decisions transfer even if the instrument never gets built. Priced honestly, it is a working scaffold with only the risky surfaces stubbed or deliberately broken and all the delegate-able plumbing provided; a harness that injects each failure condition; a grader-only answer key; and — because pass bars must not become rehearsable — a parameterised harness rather than a scripted one, varying the injected conditions between candidates. Half a day for the candidate. Two to four senior-weeks to build, plus permanent decay, because it is derived from a risk register that changes. Amortised over one or two sittings a year. Most teams should not build this, and saying otherwise would be dishonest.

If you do run it, grade two ways, labelled and never blurred: mechanically, where a harness injects a condition and checks the outcome, and by answer-key judgment, a calibrated interview against a key the candidate never sees. The second half is what catches someone who ships plausible code and cannot say why it works.

The failure modes are more useful than the design, so:

Don't lead with it. Reaching for the exam first means spending senior-weeks to learn what merge history would have told you in an hour.

Don't make it a from-scratch build. Then you are testing grit and stamina, which the whole framework says to delegate. Scaffold everything that is not the risky surface.

Don't grade output alone. Include the question "what did you delegate, and why?" — and mean it. A candidate who hand-built everything and cannot name what they would have handed over has failed. This is the one item on the exam with no pre-LLM equivalent; the certification traditions I know of were designed on the assumption that doing more of the work yourself was strictly better. That assumption is dead, and the exam has to encode its death or it will quietly select for the wrong ditch.

Don't use it for hiring, firing or performance review. It is a promotion gate for unsupervised ownership of something with no net beneath it, or a response to a confirmed de-skilling incident. Turn it into a punishment device and people optimise for it, and you have built an expensive rung-four control.

Don't test what a detector could catch — and notice what that implies. This is the self-liquidating part, and it resolves the sharpest objection to the exam. If you can build a harness that mechanically grades a failure, you can usually build that same harness as a test. Which means the mechanical half of your exam is a to-do list for your CI, and it should shrink every year as its items graduate into checks that run on every commit. What stays exam-only is the judgment half, because no harness grades "would this force a version bump" or "what would you delegate."

That also settles a contradiction I would otherwise be carrying. If the ladder says push everything down to a machine, why does the exam ask a human to build a self-limiting write by hand? Because it certifies the ability to produce the control — the capacity to push a risk down a rung — not the practice of holding a risk in your head instead of guardrailing it. Those look similar on the day and are opposite in intent.

Don't claim more than it certifies. It certifies "can, under exam conditions, unaided." It does not certify "does, in flow, with the tool open." AI-off is unenforceable over hours, so keep the sitting short and lean on the proctored conversation.

Which leaves Parasuraman and Manzey's objection, the one that should have been bothering you since the first section. Automation bias cannot be prevented by training or instruction. So why would certification help?

It doesn't help with automation bias, and I should not pretend it does. That failure mode happens in flow, and the exam explicitly does not measure flow. What the exam measures is whether there is a model underneath the fluency — something to be biased away from. Automation bias with a model is an error, and errors can be caught. Automation bias with no model is not an error; it is the permanent state. And certification is not training in any case. It is a proof test: it does not instruct anybody, it measures, and it converts an unknown failure rate into a known one for the one channel on the ladder that has no diagnostics of its own. That is precisely — and only — the argument for splitting rung three from rung four. If the proof test does not happen, the split collapses, and competence really is just a wiki page with a person attached.

Two corrections to the record, both cutting against things I have said.

The manual-flying claim was wrong. In Renting Competence I wrote that pilots' manual skills decay measurably within two months without practice, citing Casner and colleagues. That is not what the study found. Testing airline pilots in a 747-400 simulator, they found instrument scanning and manual control skills mostly intact even when pilots reported little recent practice. What degraded was the cognitive side — knowing what to do, and the decision-making that manual flight demands — and its retention depended on how actively pilots stayed engaged in supervising the automation.

The correction improves the argument, which is why it costs nothing to make. What atrophies is the model, not the motions. The model is exactly what a residual competence list contains, and exactly what reviewing a diff does not exercise.

And I have been leaning on METR too hard. Its finding — that experienced developers were 19% slower with AI tools while believing they were 20% faster — is the single most quoted number in this discourse, mine included. It is 16 developers, in mature repositories they knew well, in a preprint whose authors explicitly decline to generalise, and it measured self-assessment of speed, not of skill. It is the closest measurement I have and it is not a measurement of the thing I want. The claim it actually supports is narrow: people are poor judges of their own performance with these tools. For the stronger claim — that fluent reading is mistaken for understanding — Bjork and Bjork on desirable difficulties and the fluency illusion is the better citation, and it has always been the better citation.

Where the analogy breaks

I have been borrowing from a discipline that has an advantage I do not have.

A factory can enumerate its hazards. There is a finite list of energy sources in a building — electrical, thermal, kinetic, chemical — and a competent engineer can walk the floor and find them. You cannot enumerate the hazards in a software system. The state space is unbounded, the interactions are emergent, and the failure that takes you down next year has not been invented yet.

Every mechanism in this essay operates on a register of known risks. The procedure walks a ladder for a hazard you have already identified. The debt row names a detector for a failure you have already characterised. The only mechanism that finds an unregistered hazard is the incident — which is reactive by definition, and expensive by construction.

The thing that finds a hazard nobody has written down is a person with a model of the system in their head, noticing that something does not fit.

So: inside the register, competence is a fallback. Outside it, competence is the hazard-identification layer, and there is no rung for that at all. The real bottom of the ladder is not "a risk with no control." It is a risk nobody has thought of, and nothing on the ladder addresses it, including mine. I do not have a resolution. It is the honest bound on the argument.

It also has a consequence I did not expect, and it follows from everything above. The better this programme works, the higher the fraction of remaining competence that is hazard identification — because the enumerable risks get machines and the unenumerable ones cannot. Shrinking the list does not only shrink it. It changes what is left, toward the part no detector finds and no exam grades.

Turning the rule on this essay

The rule underneath everything above is: every defect must be caught by something other than a human noticing.

Apply it to this essay.

Six mechanisms. One is a machine, and it does not exist yet. Everything else in this essay is a human noticing on a schedule, which is the thing the essay tells you not to rely on.

A methodology is a rung-four artifact by construction: there is no methodology that catches itself, and any document telling you how to work depends, in the end, on someone remembering to work that way. The only thing a methodology can honestly do is convert itself into rung-two artifacts over time, and the only honest metric is the conversion rate. Mine is one in six, and the one is unbuilt.

Which has to change what I ask of you. Take two of the six and leave the rest. The procedure survives because it runs at the moment of decision, where forgetting is its own punishment. The detector-debt row survives because its output is a backlog item, and a backlog item persists without anyone remembering it. The other four — the hold count, the task-start check, the incident harvest, the exam — all require a human to remember on a schedule, and I have spent this essay telling you what that is worth. Don't adopt them until you have a machine for them.

So the sentence this essay was built to earn has to be aimed here first: if you cannot name the detector, you have written a reminder and called it a methodology. I have written a reminder.

The question stays the same, and it is the only part of this you need to carry: where does this risk live? A check path, a runtime signal, or a name. If the answer is a name, write down the detector that would retire it, and the date you will build it.

Then go build that instead.

Borrowed and new

Almost all of the machinery here is borrowed, and it matters to say from whom. The Hierarchy of Controls is NIOSH's, unchanged except for the four-rung compression I argued for and flagged. The detected/undetected classification and diagnostic coverage are IEC 61508's. Poka-yoke — design the task so the slip cannot happen, or is caught the instant it does — is Shingo's, from 1963, and his catalogue of 112 shop-floor devices, most costing under a hundred dollars, is the standing rebuttal to the idea that guardrails are expensive. The ironies of automation are Bainbridge's, and hers is the sharpest idea in this essay. Management of change — you may not remove a control without re-opening the hazard it retired — is not a metaphor but a regulation, OSHA 29 CFR 1910.119(l). "Make it a pipeline check, not a wiki page" is SRE folk wisdom. And AI-off, externally graded certification is not an innovation; it is how every professional certification worked before any of this.

What is mine is narrower than I would like. Shrinkability as a concept belongs to IEC 61508 and is thirty years old; what I have not seen elsewhere is the mapping — that what a human must know is the dangerous-undetected set, and that diagnostic coverage therefore prices a competence list. The ladder-ordered procedure is not novel in its buckets but in its order: the question about a human comes last. And grading delegate judgment — the exam item that fails a candidate for holding everything — is the one item I know of with no pre-LLM equivalent.

Sources

• NIOSH / CDC, Hierarchy of Controls — the five rungs, and the ordering principle that the top three work "without significant human interaction." cdc.gov/niosh
• IEC 61508 — the safe/dangerous × detected/undetected classification, diagnostic coverage, and the 60/90/99% target bands. Risknowlogy summary , exida position paper
• Parasuraman & Manzey (2010), Complacency and Bias in Human Use of Automation: An Attentional Integration, Human Factors 52(3):381–410 — complacency in experts "cannot be overcome with simple practice"; bias "cannot be prevented by training or instructions." journals.sagepub.com
• Bainbridge (1983), Ironies of Automation, Automatica — the residual arrived at by subtraction. overview
• Haynes et al. (2009), A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population, NEJM 360:491–9 — death rate 1.5% → 0.8%. nejm.org
• Google (2025), Rust in Android: move fast and fix things — memory-safety share below 20%, ~1000× density reduction, 4× lower rollback rate, ~25% less review time, ~20% fewer revisions. blog.google
• CISA/NSA/FBI, The Case for Memory Safe Roadmaps — eliminating the class as policy. cisa.gov
• Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System — 112 devices, most under $100. taylorfrancis.com
• OSHA, 29 CFR 1910.119(l) — management of change as a written, mandatory procedure. osha.gov
• Cui, Demirer, Jaffe, Musolff, Peng & Salz (2026), The Effects of Generative AI on High-Skilled Work, Management Science — three RCTs, 4,867 developers, +26.08% completed tasks. pubsonline.informs.org
• DORA (2025), State of AI-assisted Software Development — ~90% daily use; 30% report little or no trust in AI-generated code. dora.dev
• Stack Overflow (2025), Developer Survey — 84% using or planning to use AI; 46% no longer trust the accuracy of AI output, up from 31%. stackoverflow.blog
• Sonar (2026), State of Code Developer Survey, 1,100+ professional developers — 42% of committed code AI-assisted; 96% do not fully trust it; only 48% always verify before committing; 38% say reviewing AI code takes more effort than reviewing a colleague's. sonarsource.com
• METR (2025), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — 19% slower, believed 20% faster; 16 developers, and it measured speed. arxiv.org/abs/2507.09089
• Casner, Geven, Recker & Schooler (2014), The Retention of Manual Flying Skills in the Automated Cockpit, Human Factors — manual control largely retained; the cognitive side is what degrades. journals.sagepub.com
• Bjork & Bjork (2011), Making Things Hard on Yourself, But in a Good Way — desirable difficulties and the fluency illusion.