Open Source

npm now has staged publishing. A package version goes to a queue rather than straight to the registry, and a maintainer has to approve it with 2FA before anyone can install it. Five commands — stage publish, list, view, approve, reject — and crucially, CI can stage without 2FA while the human supplies it at approval.

GitHub's framing is that it closes an entire class of CI takeover publish attacks, and that looks right. If your pipeline is compromised, the attacker can now push a version into a queue, which is a great deal less interesting than pushing one to every machine that runs npm install.

What makes this worth noting here rather than filing under routine supply-chain news is the shape of it. Everything else in this space is racing to remove human steps. This deliberately adds one, at the exact point where the cost of being wrong is highest and the cost of the delay is lowest. That is the correct trade, and it is nearly the opposite of how agent tooling is being designed — where the pitch is precisely that you do not have to sit in the middle.

The scepticism in the responses is fair, though. Adnan Khan is right that people should turn it on immediately; the doubters are right that most won't. An opt-in control adopted by the maintainers who were already careful does not move the number that matters. And a human approving a staged release under time pressure is the same human from the approval-fatigue study — the mechanism only works while the queue is short enough that looking at it still feels like a decision.

Turn it on anyway. Needs npm CLI 11.15.0 and Node 22.14.0.

This is from February and I keep coming back to it, because the quotes have aged better than the proposals have. GitHub PM Camilla Moraes opened a community discussion on maintainers "dedicating substantial time to reviewing contributions that do not meet project quality standards" — the options on the table included letting maintainers disable pull requests outright, restrict them to collaborators, delete them from the interface, and attach some kind of attribution when a tool wrote the code.

The line worth stealing is Jiaxiao Zhou's:

Review trust model is broken: reviewers can no longer assume authors understand or wrote the code they submit.

That is the actual problem, stated in one sentence, and it is not a spam problem. Code review has always run on an unwritten assumption: whatever else is wrong with this patch, there is a human on the other end who can explain it. Take that away and review stops being a conversation and becomes an inspection. The economics get ugly fast, because inspection does not compress the way conversation does.

Xavier Portilla Edo's estimate — "1 out of 10 PRs created with AI is legitimate" — is the kind of number I would normally push back on, since it is one maintainer's gut feel rather than a measurement. But nobody in that thread disputed the order of magnitude, and the people in that thread do this all day.

GitHub's own Matthew Isabel pushed back on counting AI-generated PRs at all: "A bad or off-topic PR is a bad PR, regardless of where it came from." He is right in principle and wrong in practice. Provenance was never worth tracking when writing a bad patch cost the sender an afternoon. It is worth tracking now that it costs them ninety seconds, because the cost asymmetry between sender and reviewer is the whole ballgame.