Silent wiring
Integration code that exists, runs, and reports success while the data it was written to move is absent, empty, fake, or so uniform it carries no information. The wire is there. You can read it, trace it, and watch it light up in your monitoring. It is just silent.
That is the whole of it. The rest of this page is where the term came from, why it needs one, and what to do about it on a Monday.
A species of silent failure
Silent failure is the family: code that produces wrong behaviour with no crash, no hang, and no error message. Researchers at Polytechnique Montréal went through 1,168 closed Keras-related issues in the TensorFlow repository and found 77 reproducible silent bugs (Tambon et al., Empirical Software Engineering, 2023; preprint arXiv:2112.13314). The shape is documented. It is studied. It is not solved.
Silent wiring is one member of that family, not a competing coinage. It is the member you get when the code that fails is the integration code: the seams between the parts of a system rather than the parts themselves. The handler and its subscription. The producer and its consumer. The fallback and the thing it is meant to fall back from.
Each piece can be correct. Each piece can be reviewed and pass. The seam between them is the place where nobody, person or model, can reliably verify runtime data flow from static context.
Why "wiring"
Because it behaves like house wiring rather than like a broken appliance. An inspector who checks that wires exist will find plenty of them. An inspector who checks that current flows will find a mess.
The failure that cost me the most looked exactly like that. Every outlet wired, every breaker on, and the power company had quietly disconnected service at the pole. Everything inside the house checks out. The problem could be upstream of anything you would have thought to inspect.
The four shapes it takes
There is not one shape. There are four, and the property that makes them expensive is this: each one is invisible to the check that catches the one below it. You fix the first, feel clever, and walk straight into the second, which your new check reports green on, because it genuinely is green on the thing that check measures.
- The handler that never fires. Registered, configured, discoverable, and it never runs. Your monitoring watches for failures. This produces an absence, and absence does not page anyone.
- The handler that fires and does nothing. It runs, the counter climbs, the liveness probe is green and right to be. It writes to a table no consumer reads.
- The handler that fires, writes, and lies. Right table, right format, right schedule, month after month, every value different from the last. Fresh and fake at the same time.
- The handlers that all quietly agree to be the same. Every individual output valid and computed. The failure exists only at the population level, and no per-row check will ever see it.
Each one gets a section of its own, with the signal it gives off and the check that finds it, on the four failure types. The story of finding them is the field note Four ways code can run, write a row, and still do nothing.
It is not only an AI problem
Worth saying plainly, because the term invites the opposite assumption. Every incident of this kind I went through for the book was caused by people: experienced developers who understood their systems, on teams with monitoring, post-mortems and institutional knowledge of why each handler existed and what it was for. They still produced wiring that failed silently.
Martin Fowler made the point in 2017, before AI code generation existed: event notification makes it easy to build a nicely decoupled system and lose sight of the larger-scale data flow while you are doing it. He was describing a human tendency, eight years before it happened to me.
Silent wiring is not an AI problem. It is a verification problem, and it has been killing production systems since well before AI wrote its first line of code.
What AI changes is the rate
Four mechanisms, and none of them is a quality problem. The code I am describing was genuinely good.
More seams. AI coding agents produce more event-driven architecture than human teams ever did, not because they are worse at coding but because they are trained on modern patterns. Microservices, pub/sub, CQRS, event sourcing. That is what capable output looks like. A less capable tool would write a monolith full of direct function calls, and there would be less wiring to verify and louder failures when it broke. The sophistication is the reason the problem scales.
The bugs are the right shape. The dominant defect in AI-generated code is not a syntax error or a crash. It is a logic error: a handler filtering on a slightly wrong field, a catch block swallowing the one exception that mattered, a subscription to an event name that does not exist. Syntax errors crash. Type mismatches get caught by the compiler. A logic error passes every structural check and then produces a counterfeit result at runtime, or no result at all. The model's dominant failure mode and silent wiring's enabling condition are the same thing.
The feedback loop selects for quiet. Code that crashes gets rejected. Code that runs clean gets accepted. Code that runs clean and is quietly wrong also gets accepted, because the wrongness is not visible in the diff you are reviewing. I was doing this myself for the whole of the build. I approved handlers because they did not throw, and never once asked whether what came out of them was real.
Nobody goes back. AI agents add; they do not refactor. Tell one to add an event handler and it creates an event handler. It does not check whether that event already has one, or consolidate two that overlap, or notice that the layer underneath went dead months ago. GitClear analysed 211 million changed lines of code and found that refactoring dropped from a quarter of all changes to under a tenth as AI adoption accelerated. The dead wiring stays in the wall, and the next pass adds more on top of it.
The obvious question is whether better models fix this, and I do not think they do. The problem is not intelligence, it is observability. When an agent writes a handler it sees the handler's code. It does not see the running system, or whether events are flowing, or whether the table is filling up. You would not expect the world's best electrician to wire a house correctly blindfolded, and the blindfold is the problem, not the electrician. Making the model smarter makes the code and the test smarter together, and the test still verifies what the code does rather than what it should have done.
AI is the faster plane. Nobody argues that jets are bad planes. Everyone agrees they need better instruments.
Why your existing tools will not catch it
This is the part that genuinely surprised me, because I assumed somebody had already solved it, the way you assume the smoke detectors in your hotel have batteries. I spent two weeks looking. Three categories of tool sit right next to the problem, and each one answers its own question brilliantly.
- Static analysis (SonarQube, CodeRabbit, Qodo) reads your source and tells you the handler is well written. Well written and working in production are not the same claim. It checks the blueprint, not the building.
- Observability (Datadog, New Relic, Honeycomb) watches throughput, error rates, latency, freshness. A handler that silently drops events produces no abnormal throughput, no errors and no latency spike. It just does not do its job. The stack sees the trucks leave the depot. It does not see the doorstep.
- Orchestration (Temporal, Dagster, Inngest) guarantees that your workflow completes, and retries it when it does not. A handler writing a plausible number every five minutes completes successfully every single time. Durability is not correctness. Finishing is not the same as being right.
Draw it as a matrix and the gap stops looking like an oversight. Verification splits two ways: structural versus behavioural (is the code built right, or does it do what it claims?) and static versus runtime (before it meets live traffic, or against real data in flight).
| Static | Runtime | |
|---|---|---|
| Structural | Static analysis Reads the source. Tells you the code is built right. | Observability Watches the running system. Tells you traffic is moving. |
| Behavioural | Your test suite Checks what the code does, against inputs you invented. | Behavioural verification at runtime. This quadrant is empty: nothing general-purpose occupies it. |
Three of those quadrants are occupied, some of them by billion-dollar companies. The fourth, the one that asks whether data actually flows end to end in production right now, has nothing general-purpose in it. Not underserved. Not early. Empty.
That is not a failure of engineering. Every product I evaluated was built by people solving a problem they understood completely. You do not build detection for a question nobody is asking.
The industry is not missing a feature. It is missing a question.
How to check, in the order that works
The encouraging part is that you do not have to solve the hard version. Defining "correct" for a distributed event pipeline is a genuinely open research problem, the oracle problem, and Barr and colleagues surveyed 694 publications on it before concluding that the field still considers it open. You do not need to solve that. You need four much smaller questions, asked in this order, because each one only becomes meaningful once the one before it has an answer.
- Is it firing? One timestamp per handler,
last_event_at. If it reads never, stop here and fix that. - Is it writing? Row counts on the target table, read from the consumer's side rather than the writer's.
- Is the output real? Compare the variance you are actually seeing against the variance a real computation would produce.
- Is the output diverse? Distribution across the population, not validity row by row.
Fix and check, not fix and ship. Every one you repair should be followed within the hour by the next question down, because the types mask each other. Three of my four failures shared one upstream cause, and the two below it could not surface at all while no events were arriving in the first place.
The uncomfortable question is not whether your AI-generated code has silent wiring. It is whether you would know.