On March 31st, researcher Chaofan Shou posted to X that Anthropic “leaked a map file in their npm registry”. The wrong artifact was able to move through build and publication without being caught. Given Anthropics' own engineers have said AI now writes most of their code, one can’t help wondering whether Claude Code had a hand in the packaging mistake.
It’s easy to think of incidents as something that starts when dashboards turn red or when users leak source code. The real value in this story is thinking about what teams can do to catch this kind of risk before it turns into a larger incident.
Pipelines contain important signals
One of the things teams often miss is that the pipeline is already full of useful signals. Commits, merges, deployments, build metadata, environments, artifact sizes. The issue is that the information is often treated as background noise until something goes wrong. This gets more important as more and more code is written with AI assistance. Sure, it speeds up writing code but it also makes it easier to ship risky code and artifacts faster than ever before. According to GitGuardian, 28.65 million new hardcoded secrets were found in public Github commits in 2025, a 34% increase from 2024. More surprisingly, they found Claude Code co-authored commits leaked secrets at twice the baseline across all public Github commits.
This is the kind of problem release-aware workflows are meant to solve. Rootly’s Pulse workflows are built around the idea that these code-change events are not just passive logs. A push, merge, or deployment can be treated as an operational signal. Because signals rarely arrive with a giant warning, it’s important to have systems in place that are able to surface them. Instead of waiting for something downstream to break, teams can use those signals to gate publication, notify responders, create visibility, or even pre-declare incidents when a change looks risky enough to justify attention.
Turn those signals into action with tools like Rootly Pulse Workflows
Early warnings only matter if teams do something with them. If a pipeline can surface risky changes, those changes should be able to trigger a response. That does not mean every anomaly needs a full incident process. It can be something lighter: routing the change for review before it spreads further, notifying the right person, opening a coordination space, or flagging follow-up work.. Additionally, a service or code path already involved with incidents may deserve extra visibility or closer monitoring during rollout. In practice, this is the kind of workflow tools such as Rootly Pulse are meant to support, turning code-change events into actionable signals instead of remaining as just passive logs.
Release reliability is part of incident management
In the Claude Code leak, one obvious signal was the release artifact itself. Version 2.1.88 included a nearly 60mb map file in the public npm package, while the previous release did not include a source map file at all. A system watching for risky release patterns could have flagged it for review or stopped the release until someone confirmed it was expected.
Reliability is not just about recovering when production breaks. It is also about whether the systems that build, package, and ship software are safe and predictable. If a risky artifact can move through those systems unnoticed, ultimately the process has failed. The encouraging part is that this is the kind of failure a stronger process can catch earlier. The signals are usually already there; the challenge is building systems that treat them as worth acting on before they turn into a public spectacle.
