The Claude Code Leak and What It Tells Us About Shipping AI
Two things happened in the developer ecosystem this week that, on the surface, have nothing to do with each other. The more you think about them together, the more they start to look like the same problem showing up in two different places.
On March 31, Anthropic accidentally included the full source code of Claude Code in a release package. A user spotted a 59.8MB file that had no business being there, opened it, and found the internals of Anthropic's flagship coding assistant. Within hours it was spreading across GitHub. By the time Anthropic began issuing DMCA takedowns, the code had replicated across 8,100 repositories. Programmers used AI tools to rewrite it in Python and Bash to dodge the copyright claims. Consultancy Systima called it correctly: "The source is, for all practical purposes, permanently public."
Anthropic confirmed the cause was a release packaging error, not a breach. No customer data was involved. But the files exposed things Anthropic would have preferred to keep private — an anti-cloning technique built into the tool, a mode that strips AI authorship evidence from output, and references to an unreleased autonomous agent mode called "KAIROS." That's meaningful competitive intelligence that every rival company now has access to.
The same week, a hacker targeted the axios NPM package in an attempt to distribute malware to millions of downstream users. Axios has over 50 million weekly downloads. It sits inside React apps, Node backends, internal tooling, and build pipelines at companies that barely know they're depending on it. Targeting a package at that layer doesn't require compromising anyone's systems directly. You compromise a dependency they already trust, and the malware travels automatically with the next install.
The thing both incidents have in common
Neither of these required a sophisticated attack. The Claude Code leak was a missing validation step in a release script. The axios attack targeted infrastructure that most engineers treat as invisible — dependencies that arrive transitively, from packages that pull in other packages, none of which anyone reviewed in detail.
What connects them is that code ended up somewhere it shouldn't have, or running in ways nobody intended, because the people responsible for catching it didn't have a clear picture of what they were actually working with.
That's the problem that's getting harder to solve as teams rely more heavily on AI to write code. When a developer authors a function themselves, they carry a mental model of every decision they made. When an AI generates a block of code, that mental model usually doesn't transfer to whoever reviews the PR. The diff looks reasonable. The tests pass. The change ships. But does anyone on the team actually understand what they just merged?
We've seen this pattern with clients. AI-assisted development is genuinely faster, but the speed creates a gap between what gets written and what gets understood. A PR that would have taken an afternoon now takes an hour, but the review still takes ten minutes. The code volume is going up faster than the scrutiny, and the gap between the two is where things go wrong.
The habit worth building
The answer isn't to slow down AI usage or add more approval gates. Both of those approaches trade away the speed benefit without fixing the underlying problem, which is that review processes weren't designed for the volume and opacity of AI-generated changes.
What works is treating AI-generated code with more deliberate attention, not less. Reading a diff means understanding it, not scanning it. If there's a section of a PR that a reviewer can't explain in plain terms — what it does, why it does it, what happens if it fails — that's the section that needs more time before it gets approved. Writing tests for AI-generated logic, specifically tests that verify edge-case behavior and not just the happy path, is a forcing function for that understanding. It's hard to write a meaningful test for code you don't understand.
The same principle applies to dependencies. Knowing what packages your project actually runs, which ones have active maintainers, and what changed between the version you're pinned to and the latest release isn't glamorous work. But it's the kind of awareness that makes the difference between catching an axios-style supply chain attack and finding out about it from a security advisory after the fact.
Anthropic's mistake was a process gap — a release script that could include internal source code without anyone catching it. The fix isn't being more careful. It's having a check that doesn't depend on anyone remembering. The same logic applies to code review and dependency management. Build the habits, then build the automation that enforces them when the habits slip.