Attention Is Not a Control

Every control that runs on attention degrades. The one that runs on execution does not.

A collection of mine outgrew a spreadsheet. The applications available to me did not do what I wanted, so I built one that does with an AI coding assistant, and it is good.

I directed. It wrote the code. Nine days from the first version to the one running now, roughly thirty-eight hundred automated assertions, and a gate of eight checks that have to pass before anything ships. I could not tell you the hours, and the reason is the point: a good deal of it was directed from a golf course and a festival, which means the building ran in parallel with both. Elapsed time does not measure this kind of work.

The stakes are the point, not the setup. Nobody's quarter depended on it. No customer was exposed. That makes it about as close to a control condition as a working system gets.

Two kinds of rules governed what the machine was allowed to do. Both were written by me, both were in force the whole time, and both were meant to hold it to a standard.

One kind was ignored completely. The other was obeyed without exception.

What separates them is whether the rule requires anybody to be paying attention. That turns out to be the line between a control and a suggestion, and it is the operational answer to a problem I have written about before without solving.

Written Rules Are Advisory

Read, agreed to, and abandoned under load

I work from a written set of development rules. They sit in the machine's context. It reads them. It agrees with them.

Rule two says reuse before inventing, and read the existing code first. On the last day I asked for a search that behaved the same as an existing one. I asked four times. Each time the machine built something adjacent, I corrected it, it agreed, and it did the same thing again. The fourth attempt was the first that opened the existing function and called it.

Rule thirteen says stop after two failed attempts and write out what you have actually observed. One repair ran to ten attempts. Nine of them fixed real faults and none fixed the problem, because the problem was structural and each fix patched an instance of it. The rule was blown past seven times.

None of this is a complaint about the tooling. It is an observation about a class of instruction. A rule that has to be read, held in mind, and applied under load will be applied while load is light and abandoned when it is not. That is also a fair description of a human reviewer.

Rules That Stop the Work Are Not

Checks that fail, and nothing to negotiate with

A second kind of rule ran alongside those: checks that fail and refuse to proceed.

A structural check named a function as dead within seconds of it being orphaned. A rendering walk caught a set of tiles wrapping onto two rows on a phone. A synchronization test caught a routine save inflating from 56 bytes to 974, in one run, immediately. A packaging audit refused to assemble a delivery because the version-named file no longer matched the file that had been tested.

None of those were negotiated. None produced an apology or an agreement. They stopped the work until the thing was correct.

A rule an AI can read is a suggestion. A rule that stops the work is a gate.

Lerhone Walker made the engineering case for this in June, and made it well. Build the guardrails, stop reviewing every line, and spend attention on what a machine cannot check. Where your team spends its attention, he wrote, is a choice you make for them.

The engineering case is increasingly clear. What remains unsettled is how much of an organization still depends on attention as a control, how to measure that dependency, and what the human is for once the mechanical half is gone.

A Gate Does Not Get Tired

Rarity is not a variable it responds to

A human reviewer erodes as a control, and the research behind that is thirty years old. Reliable automation degrades the person watching it. Rare targets get missed at several times the rate of common ones. Both findings are decades old, both are replicated, and I laid them out at length in Your AI Business Case's Blind Spot.

The mechanism is what matters here. Both effects run on attention, and both get worse as your deployment gets better. A successful project makes errors rarer, which is exactly the condition under which people stop finding them.

A gate meets the same conditions differently.

The hundredth run is identical to the first. Rarity is not a variable it responds to. It has no queue, no day job, no threshold at which it decides the search is not worth continuing. It does not get faster at concluding nothing is wrong.

Gates are not smarter than people. The claim is narrower and more useful: controls on your list that run on attention degrade with time and rarity. The ones that run on execution do not degrade merely because the thing being controlled has become rare.

Which is the same as saying attention is not a control. It is a resource a control can spend, and it is the one resource that runs out quietly.

There is a failure mode on the gate side, and I found two of them after drafting this. A guard that cannot fail is not a guard. One check meant to verify a lookup was holding an identifier rather than the value it stood for, so it passed on every run while the fault it existed to catch was sitting right there. Another, meant to read a label, was reading its own comment. Both were green for weeks.

That is not a gate going stale, which is a gate that used to work. These never worked, and a gate that never worked looks exactly like one that does. Mine now get broken on purpose before they are believed.

What No Gate Caught

Instruments cover defects. They are blind to purpose

The limit matters more than the claim.

Across those days the checks caught things I could not have found. A stored setting shipped with no default value, so one device silently lost every synchronization and reported it only as a vague notification. A drawing routine emitted the same element identifier four times on one page, so three of four graphics rendered empty. A cache routine swallowed its own failure, stored nothing, deleted the working copy, and left a device with no navigation. I had been seeing that last one for days and calling it flaky.

Plumbing. Invisible to me, and invisible to roughly thirty-eight hundred automated assertions, because those exercise what the code does and these were faults in what the code is.

What only I caught was a different kind of thing entirely.

The application told me an item was worth trying because I already owned several others like it. That is a reason to buy another and a reason to skip it when I am somewhere I could try something new instead. Correct code, inverted meaning.

It built a diagnostic feature with per-device slots, merging, and a read-back screen. I said no. One user, one log. It deleted a feature it had built an hour earlier and replaced it with something a third the size.

And a fault I reported twice was twice explained to me as a rendering artifact. It was not. It was a line of real content tucked under a header.

None of that is reachable by a check until somebody has decided what the thing is supposed to mean. It is not wiring. It is judgment about what the thing is for, and an instrument tests against a specification. The question is whether the specification is right.

One Sentence Fixed What Three Repairs Could Not

And I could only write it because I had been wrong before

The sharpest example came last. Two devices kept losing each other's changes. The machine fixed it three times. Each fix was real and each introduced a new fault.

Three attempts, three genuine improvements, no resolution, because they were all patches on a wrong idea. The application was treating the two devices as peers holding rival copies and arbitrating between them.

I wrote one sentence. There is a real-time database that must be the source when connected; only work done while disconnected should contribute asynchronously.

That was not a bug report. It was a design, and it collapsed three separate faults into one wrong assumption. The rebuild took an hour and has held.

I could not have written that code. It could not have written that sentence, and I want to be precise about why, because it is not a claim about intelligence.

I could write it because I have spent a career inside systems that got this wrong. That is construction rather than recognition, and the two are not the same skill. A senior property accountant, twenty years in, can look at a rent roll and know something is wrong four seconds before she can tell you what. That did not come from approving rent rolls. It came from building them, being wrong, and being corrected, over and over. Hire her replacement into a review role and they never acquire it.

Somebody who had only ever approved AI output could not have written that sentence. Not because they lack the vocabulary. Because the sentence is a judgment formed by having been wrong repeatedly, in that domain, and corrected.

A few hobby projects do not make me an AI-enabled software development expert, and I would not claim otherwise. They do make me a data point in my own argument, and the data point runs the direction the research predicts.

Stop Trying to Instrument Judgment

Instrument everything else instead

Put the two halves together and the conclusion is narrow.

You cannot instrument judgment without first turning it into a specification. Every attempt to do so is an attempt to write down in advance what you are hiring somebody to decide, and if you could write it down you would not need them.

What you can do is instrument everything else, so that judgment is the only thing attention is spent on.

That reframes the human-in-the-loop problem. The response to a degrading reviewer is not a better reviewer, a longer checklist, or a training module. Those are prose rules with a person as the runtime. They fail the way my rule two failed, four times in a row, with the rule sitting right there in the context.

The response is to move every defect class you have already seen out of the reviewer's attention and into something that stops the work. Then the review role stops being a search for rare events, which is the condition the research says people cannot hold, and becomes a judgment about purpose, which is the condition they can.

Manufacturing learned this distinction a long time ago. Inspection at the end of the line does not catch defects. Stopping the line does.

Attention is still spent. It is spent on the half that cannot be instrumented, which is the only half worth spending it on.

The Instrumented Share

Take your last twenty incidents and count

There is a companion number to this one. The fallback capacity ratio takes daily volume, the throughput one trained person managed before the deployment, and the headcount who have actually done the work by hand, and asks whether the people could still do it if the system stopped.

Its pair asks the other half. The fallback capacity ratio asks whether the organization can recover the work. This one asks whether it still has to watch the work.

Take your last twenty production incidents. For each one, ask a single question: if this recurred tomorrow, does something now stop the work automatically, or would somebody have to notice?

Count the ones that would stop. Divide by twenty. Call it the instrumented share.

Instrumented share = incidents that would now be stopped automatically ÷ your last twenty incidents.

Three things about that number.

You can compute it this afternoon from documents you already own, which is rare enough here to be worth saying.

It will be lower than the room expects, and often close to zero. The standard response to an incident is a postmortem, a lesson, and an entry in a runbook. A runbook is a prose rule. Every one of those incidents produced knowledge and almost none produced a gate.

And it does not decay just because incidents get rarer. The fallback capacity ratio gets worse every quarter without anybody doing anything, because skill fades. A gate can go stale when the environment moves around it, but it does not quietly stop working because nothing has gone wrong lately.

What It Cost Somebody Else

The moat was assembly cost, and assembly cost moved

One more consequence, and it changes the subject on purpose. Everything above is about how you design controls.

This is about what those controls used to protect.

I was paying for an application before I built mine. I am not paying for it now.

I want to be careful about what that does and does not mean. It is not a claim that what I built is better software, and I am not qualified to make that claim. The vendor has customers, a roadmap, and people who do this for a living.

The claim is narrower and it is about me rather than them. What kept me paying was never that the product was excellent. It was that building a substitute required a team and a year, and I had neither.

That is the thing that moved. Not the quality of their software. The cost of assembling an alternative to it.

And notice how the loss arrives. No competitor appeared in their win-loss analysis. No sales cycle was contested. Nobody at that company can point to a deal they lost, because there was no deal. A subscription ended, and the reason for it is not recorded anywhere in their systems.

Which is the same shape as the seam between a business case and a continuity plan. The exposure lands on a function that was not in the room, in a form nobody is counting, and the first version of it arrived as a rounding error in a churn report.

I am one customer and this is one application, and I would not build a strategy on it. But the barrier that protected that vendor was assembly cost, and every organization that sells software needs an answer to what protects it once assembly cost does not.

The instruments are what let one person ship something real after nine days of divided attention. That is the good news here and it is also the warning, and they are the same sentence.

The application is a whiskey collection tracker: a shelf you can ask questions of rather than a list you look at. Nine days, one user, no funding, no intention of selling it, yet. Reachable through The Four Seats, on either subject.

There are four seats in the name. The fifth one is yours.