KIMI 3 just shipped with open weights.
The benchmark arguments have already started, and I'm going to skip them. They'll be settled by people with more GPUs than me, and in six weeks something else will have shipped anyway.
The part that seems least in dispute is the part that changes things: the weights are on your disk, and they run on your hardware.
Think about what that removes. Not capability: friction, and a particular kind of it. Until now, putting an autonomous agent into production usually meant your data left the building. That tends to summon people. A security review. A data-processing agreement. Someone in procurement. An API key that somebody had to provision and could take away again.
None of that was fast, and none of it was fun. But notice what it quietly did. To get through it, you had to describe the system out loud. What it reads. What it writes. What it touches when it fails. You had to put that in a document and hand it to someone who was going to read it.
That gate was never checking whether your agent worked. It was asking whether the data was allowed to leave, which is a different question. But it forced a description, and a description is most of what makes a system legible to the people responsible for it.
Weights on your own hardware remove the boundary. Which is good; it's the reason a lot of us wanted this. It also removes the description, and I don't think anything has replaced it yet.
So here's roughly what the next few months look like. Agents get stood up by people who no longer need to ask anyone. The backend engineer who wires one into the deploy pipeline over a weekend. The data team that leaves one watching a queue. The platform group that quietly replaces three cron jobs with something that reasons about them. Not reckless people: ordinary people doing the ordinary thing, which is shipping.
And nearly all of that is new integration code. Handlers. Subscriptions. Producers and their consumers. Fallback paths for when the main path doesn't run. Most of it written by the model itself, reviewed by a person who reads the diff but not the seam, merged on a Tuesday afternoon.
Multiply that out. That's the wave.
Now: when that goes wrong, what does it look like?
You already have an answer ready, and I think it could be the wrong one.
Ask most engineers and you get the loud failures. The model hallucinates. The agent deletes something it shouldn't. The endpoint times out at 3 a.m. and the pager goes off. These are real, they're bad, they're well covered, and they share one enormous mercy that few of us ever think to be grateful for.
You find out.
There's a second category, and I'd argue it's the one more likely to cost you. It doesn't crash. It doesn't throw. It never pages anyone at 3 a.m., in either direction, and that is precisely the problem. It tends to pass your test suite. Not by luck. By construction.
I know that category is real because I shipped one. It ran in production for two months while I looked at the evidence of it most weeks and concluded, every time, that everything was fine.
Two months of a number I was proud of
Since 2023 I've been building the plumbing between AI models and the things that use them: 1.1 million lines of production code across two complete builds. The kind of system where the real question isn't does the code compile. It's does the data actually flow.
We ran a calibration engine. Its job was to measure whether our AI's confidence scores meant anything: when the model says it's 80% sure, is it right 80% of the time? Boring, important, the kind of internal instrument you build once and then trust.
It had been writing records for two months. Right table. Right format. Right timestamps. One row roughly every five minutes, right on schedule. Over seventeen thousand of them.
The handler that was supposed to write those rows never fired. Not once. In two months.
A cold-start fallback (a safety net, built for first boot when there's no history to average yet) had quietly become the only thing writing to that table. It had nothing real to compute, so it did what a moving average does when the input stops: it decayed. Smoothly. Plausibly. It drifted downward for about a month, much the way a real instrument settles as it finds its level, and then it died in place and stayed there for thirty-three more days.
Here's the part that should bother you more than the two months.
Every value in that table was different from every other value. Ten thousand distinct numbers. Nothing wrote a constant. Nothing wrote a default. If you'd gone hunting for the obvious tell (a column full of the same figure, a flatline, a suspicious round number), you'd have found variety, nodded, and closed the tab. Every freshness check we had reported green, and reported it correctly, because the data genuinely was fresh. It was fresh and it was fake at the same time.
If you'd asked me during those two months whether our calibration engine was running, I wouldn't have hedged. I'd have pulled up the table, shown you seventeen thousand rows across sixty-three days, and told you it was fine.
I'd have been wrong. Confidently. With evidence.
That's the failure mode. Not the system broke. The system produced a convincing artifact of working, and my own diligence was the thing that made me sure. I checked. There was data. I moved on.
It took me two months to look properly. I built the thing.
What was standing between me and that
Before you file this as a story about a sloppy team, here's the inventory of what was supposed to catch it.
Eighteen thousand tests: unit, integration, property-based, contract. Eighteen architectural rules, five constitutional laws and thirteen forbidden patterns, enforced in CI on every commit. 419 automated checks in total. The audit system inside that ran 100 of them across eleven quality dimensions, and one of those dimensions was learning-loop completeness. Its entire job was to verify that predictions led to outcomes, outcomes led to learning, and learning led to improvement. That was the dimension. That was what it was for.
It passed.
The health endpoint said HEALTHY. Every dashboard was green.
I'm not listing that to impress you. I'm listing it because it's the only part of this story that's about you: none of it caught anything. Not one check. If your team ships faster than that with less scaffolding than that (which is a lot of teams, and was a lot of teams even before agents got easy to stand up), then the useful question probably isn't whether I was careless.
There's a reason eighteen thousand tests caught nothing, and it's worth sitting with. The same model wrote the handlers and wrote the tests for those handlers. So the tests verified what the code did, not what it should have done. The test on that calibration handler checked that it returned a number between zero and one. It did. Pass. The handler wrote junk; the test confirmed the junk was correctly formatted. Both were structurally flawless. Both were behaviorally useless. And I'm not sure a better test was available to it, because it had no model of what the handler was supposed to do, only a copy of what it did.
The same system wrote the exam and graded itself. Of course it passed.
One last detail, and it's the one that made me stop debugging and start writing. That system was a rebuild. The first version was human-guided: simpler architecture, direct function calls where data needed to move, not elegant, not sophisticated. Zero of these failures. The rebuild was AI-generated end to end, more sophisticated, more thoroughly tested. Four. One team, one codebase, one domain.
The architecture changed too, and I want to be straight about that rather than wave it past you. But it changed because of who was writing it. And the sophistication is not a confound here, it's the mechanism. Broken code crashes and lights up your dashboards. Code this good fails quietly.
That's still one data point, and I'll say so before someone else does.
It has a name already
The family this belongs to is called silent failure, and it's been named and studied for a while. This is not a gap in the literature. Researchers at Polytechnique Montréal went through 1,168 closed Keras-related issues in the TensorFlow repository and found 77 reproducible silent bugs: defects that produced wrong behaviour with no crash, no hang, and no error message for the user. (Tambon et al., Empirical Software Engineering, 2023; preprint arXiv:2112.13314). The shape is documented. It's studied. It isn't solved.
So I'm not trying to coin anything. I want to name one specific member of that family, because I think it has a distinct signature and a distinct fix.
The species I kept hitting shows up when AI writes the wiring: the integration code between components of a system it can't see end to end. The handler and its subscription. The producer and its consumer. The fallback and the thing it's meant to fall back from. Each piece correct. Each piece reviewed. The seam between them is where neither a person nor a model can reliably verify runtime data flow from static context.
I started calling it silent wiring. The wiring exists. You can read it, trace it, watch it light up in your monitoring. But what's moving through it is absent, or empty, or fake, or so monotonous it's useless. The wire is there. It's just silent.
It isn't only mine. Once I had the shape, I went looking in other people's incident reports and post-mortems, and it's there: event subscribers that never fired, pipelines producing convincing fakes, handlers registered and never called. Different companies, different stacks, different scale. The shape keeps coming back the same.
And to be clear about blame, because it matters: the code was good. Genuinely good, not good-for-AI good. I'd argue the failures were invisible because it was sophisticated enough to look right at every layer. Broken code crashes and lights up dashboards; sophisticated code fails quietly. A team writing that same architecture would likely have had the same blind spot. The model didn't invent a new kind of mistake. It writes more wiring, much faster, and the unverified surface area grows faster than most of us thought to measure.
Which brings us back to the wave
Two things change when a frontier model ships open-weight.
The volume. Every deployment that used to need a review is now a weekend. More agents, more handlers, more seams, more places for the wire to be there and be silent. This subject gets more urgent, not less, and it gets more urgent quickly.
And there may be no one left to call. When your model was a hosted API there was a vendor on the other end. An SLA. A status page. Someone with a commercial reason to tell you when something was wrong. Not much, but not nothing. Weights on your own hardware come with none of that. No provider, no attestation, no third party who will ever tell you the thing is working. Whether your system is doing what it appears to be doing is now largely your problem, and this is the failure mode where you'll be certain it is, right up until you check.
That's not an argument against open models. I think the wave is good, and I'd rather have the weights than the vendor. It's an argument that the verification burden moved onto you, and I suspect most teams haven't noticed, because nothing has gone red.
Where to start
One question, and stop accepting the answer you're currently accepting.
Not: is this handler running? But: is this output the product of computation at all?
Those sound like the same question. They aren't, and the gap between them is where I lost two months.
Pull ten records from your most critical table: not the newest one, ten across a span. Line them up and look at the spread. If real work should produce variance and you aren't seeing variance, you have something to investigate. And if you can't tell what "real" looks like for that column, that is the finding: your team currently can't distinguish your system working from your system faking it.
There are four distinct shapes this takes, and each is invisible to the check that catches the one below it. I've written up all four (the symptom, why ordinary monitoring misses it, and the check that catches it): the four shapes, one at a time. The prompts I use to make a coding assistant surface its own integration seams instead of quietly papering over them are in a free prompt pack. The long version, with the field manual attached, is a book called Silent Wiring, on Leanpub shortly.
And if you'd rather have someone else run this over your system than run it yourself, that's a thing I do.
The uncomfortable question isn't whether your AI-generated code has silent wiring. It's whether you'd know.