We used AI to build 1.1 million lines of production code.
We had 18,000+ test functions. We had 13 explicit architectural rules enforced at every commit. We had dashboards. We had health endpoints. The health endpoint said HEALTHY.
Then we built a behavioral verification system — a lie detector for software — and pointed it at ourselves.
It found 3 completely silent data pipelines, 82 runtime violations, and a calibration engine that had been returning hardcoded default values for months. All while every test passed and every dashboard showed green.
This is the story of how we discovered what we now call silent wiring — and why we believe it exists in every codebase where AI writes production code.
The Setup: Everything Looked Perfect
CleanAim® is an AI governance platform. We build infrastructure that helps engineering teams verify and govern AI systems. And yes, we use AI extensively to build that infrastructure — over 1.1 million lines of code with AI assistance.
By every traditional measure, the system was healthy. Our CI pipeline ran 18,000+ test functions on every commit. Our architectural linter enforced 13 explicit rules about how components should interact. We tracked code coverage. We ran static analysis. We had a health endpoint that external monitors checked every 60 seconds.
Every signal said the same thing: this system is working.
Think of it like a hospital where every patient chart shows normal vitals — blood pressure, heart rate, temperature, all green. The nurses are calm. The monitors aren't beeping. Everything looks fine.
But nobody checked whether the IV drips were actually delivering medication.
The Experiment: What If We Verified Behavior?
In late January 2026, we were building a behavioral verification capability for our clients. The core idea was straightforward: instead of just checking whether code compiles and passes tests, verify that data actually flows through the system the way the architecture says it should.
Not "does the function exist?" but "does the function actually execute, produce meaningful output, and deliver it downstream?"
We had the methodology ready. We had the tooling working. And then someone on the team asked the question that changed everything:
"What if we run this on ourselves first?"
So we did.
The Discovery: Three Silent Pipelines
Within hours, the verification system classified every critical data flow in our production codebase into three categories: ACTIVE (data flows and produces meaningful output), STALE (data flows intermittently or with degraded quality), and DEAD (the pipeline exists in code but produces nothing meaningful at runtime).
The results were brutal.
Three data pipelines were completely silent. The code existed. The handlers were registered. The event subscriptions were in place. If you read the source code, everything looked correctly wired. But at runtime? Nothing. No data moved. No meaningful output was produced. The handlers were registered but never fired.
This is the pattern we now call silent wiring: code that is wired together but silently does nothing. It's the software equivalent of a smoke detector with no battery — it's installed, it's visible, it passes every visual inspection, but it will not save you when there's a fire.
Eighty-two runtime violations were identified. These weren't crashes or errors — they were behaviors that looked correct on the surface but diverged from what the architecture specified. Functions that executed but caught exceptions silently. Event handlers that processed events but wrote nothing downstream. Logic that ran successfully but produced outputs indistinguishable from doing nothing at all.
And then there was the calibration engine.
Our system includes a calibration component that's supposed to compute values based on real incoming data. We had 99 calibration results in production. Every single one was a hardcoded default value. The calibration engine was running. It was producing outputs. It was writing rows to the database. But every value was a placeholder that had never been replaced by an actual computation.
The tests for this component? All passing. They verified that the function returned a value of the correct type and within the expected range. The default values happened to satisfy both conditions perfectly.
Why Traditional Testing Didn't Catch This
This is the question every engineer asks: how did 18,000+ tests miss this?
The answer reveals a fundamental gap in how we verify software — a gap that gets wider the more AI-generated code you ship.
Unit tests verify functions in isolation. They check that given input A, function B returns output C. Our unit tests for the calibration engine confirmed it returned a numerical value between 0 and 1. A hardcoded default of 0.5 passes that test perfectly.
Integration tests often mock the very connections that fail. When you test an event-driven pipeline, you typically mock the event source and verify the handler processes a synthetic event. You're testing the handler logic, not whether real events reach it in production. Our integration tests confirmed the handler could process events — not that it did.
Health endpoints check infrastructure, not behavior. A health check confirms the service is running, the database is reachable, and memory isn't exhausted. Ours reported HEALTHY because all of those things were true. The fact that three pipelines were producing zero meaningful output doesn't register as an infrastructure failure.
Code coverage measures execution, not effectiveness. We had high coverage numbers. The calibration engine code was executed during tests. But executing code with mock inputs that return defaults is very different from processing real data into computed results.
This is the behavioral verification gap: the space between "tests pass" and "system actually works." Traditional testing verifies that components function correctly in controlled conditions. Behavioral verification asks whether the system, as a whole, produces the outcomes its architecture promises.
The Four Failure Types We Classified
After analyzing what we found, we classified the failures into four distinct types. Every engineering team using AI-generated code should know these:
1. Subscribed But Never Fires. The handler is registered. The event subscription exists in the codebase. At runtime, zero invocations. The wiring looks correct in the source code, but the event bus configuration, the topic naming, or the message routing means the handler never receives a message. This is the most dangerous failure type because it's completely invisible — no errors, no logs, no indication that anything is wrong.
2. Fires But Produces Nothing. The function executes. You can see it in the logs. But it catches exceptions silently, returns early on edge cases, or writes to a destination that nothing downstream reads. The activity creates the illusion of functionality — the system looks busy, but no meaningful work is being done. Like a factory where the machines run all day but the conveyor belt leads to an empty room.
3. Produces Defaults Instead of Data. This is what our calibration engine did. The function runs, produces output, writes it to the database — and every value is a hardcoded placeholder. No errors. No warnings. The schema is satisfied. The data types are correct. But the actual computation never happened. This is particularly insidious because downstream systems consume the defaults without knowing they're not real computed values.
4. Runs Without Diversity. The system is active and producing output, but the output shows zero behavioral variety. We found 1,218 evolution cycles where the same mutation type was applied every single time — activity that looked productive but was functionally a monoculture. The system was running, but it wasn't doing the thing it was designed to do.
The Fix: 112 Issues in One Sprint
Once we classified the failures, fixing them was remarkably fast. In a single sprint, we resolved 112 issues across the codebase. Every critical data flow was reclassified from DEAD or STALE to ACTIVE.
The speed of the fix is itself an important data point. These weren't deep architectural problems. They weren't design flaws. They were wiring errors — connections that looked correct in code but didn't work at runtime. The kind of errors that AI coding assistants are particularly prone to creating, because AI generates code that is structurally plausible but hasn't been verified against actual production behavior.
The hardest part wasn't fixing the problems. It was finding them.
Why This Matters Now
Here's the context that makes silent wiring an industry-wide issue, not just our story.
Developers estimate that 42% of committed code is now AI-generated or assisted, according to Sonar's 2026 State of Code Survey. Developer confidence in AI code accuracy has collapsed — only 33% of developers now trust AI-generated code's accuracy, per Stack Overflow's 2025 Developer Survey, down from over 70% favorable sentiment just two years earlier. Research from ICSE 2024 found that GPT-4's accuracy drops from 85.4% to 62.5% when class-level code with contextual dependencies is involved — exactly the wiring that connects systems together.
The pattern is clear: AI is excellent at generating individual functions and components. It produces code that compiles, that follows patterns, that passes unit tests. But when it comes to the connective tissue between components — the event subscriptions, the pipeline configurations, the cross-service integrations — accuracy drops sharply. And the failures don't produce errors. They produce silence.
Every team shipping AI-generated code at scale almost certainly has silent wiring in their codebase. Not because the AI is bad, but because no existing tool checks for this specific failure mode. Static analysis tools like SonarQube see code structure, not runtime behavior. Monitoring tools like Datadog excel at infrastructure observability — latency, throughput, error rates — and have recently added data quality monitoring for warehouse tables, but still cannot verify that the content of data flowing through application pipelines is meaningful versus default values. Contract testing tools like Pact verify the shape of messages, not whether the messages are actually sent.
The gap exists because the tools were designed for a world where humans wrote every line of code and intuitively understood the end-to-end behavior of the systems they built. In a world where AI generates nearly half the code, that intuitive understanding breaks down — and so does the assumption that passing tests means the system works.
What We Do About It Now
We fixed 112 issues in our own codebase. Then we productized the methodology.
CleanAim® Silent Wiring is a behavioral verification system built on three layers:
First, you declare your topology — data flow declarations that define every expected path before code ships. This is the architectural contract that says "data should flow from A to B to C, and produce meaningful output at each stage."
Second, you verify continuously — liveness probes that check whether those flows are ACTIVE, flag them as STALE when quality degrades, and alert on DEAD when a pipeline goes silent. This runs continuously in production, not just at test time.
Third, the system learns and predicts — compound learning that gets better at anticipating which wires will break next, based on patterns across deployments and codebases.
The result is what we call a Silent Wiring Score — a single metric that tells you how much of your system is actually working versus how much is silently failing. It's the metric we wish we had before we ran the first diagnostic on ourselves.
Try It On Your Codebase
If you're an engineering team shipping AI-generated code in production, the question isn't whether you have silent wiring. The question is how much.
We offer a Silent Wiring Diagnostic — a structured engagement where we assess your AI-assisted codebase for exactly the failure types we found in ours. You get every critical data flow classified as ACTIVE, STALE, or DEAD, a failure type analysis showing which of the four patterns you're exposed to, and a prioritized set of fix recommendations.
Because the hardest part isn't fixing silent wiring. It's knowing it's there.