AI feature news needs changelog provenance
A newsletter announced Claude Code computer use as new in July; the vendor changelog dates it to late March. Strategy decisions sourced from digests need checking against the only feed with real dates.
On July 19, 2026, the AI GTM Collective newsletter announced that Claude Code can now use the computer — "live the week of July 6, no setup, on Pro and Max plans." I went and read the vendor's own what's-new feed. Claude Code's changelog dates computer use in the CLI — "open native apps, click through UI, and verify changes from your terminal," shipped as a research preview — to Week 14, March 30 to April 3, 2026. Desktop computer use landed the week before that, March 23 to 27. The capability the newsletter announced as fresh was roughly three months old.
The conflation is even traceable. Week 28 of the changelog, July 6 to 10, shows an in-app desktop browser shipping — a real release, the likely thing that crossed the author's feed and got compressed into "the agent can click now." I verified both changelog entries directly at code.claude.com/docs/en/whats-new. The newsletter's "Pro and Max plans" detail for the preview I could not verify anywhere, and the same issue's claim that Gemini 3.5 Pro slipped "from weeks away to months away" is single-source; treat both accordingly.
Let me be warm about this, because the irony is the point, not the person. That issue's core argument — agents can act now, so make them prove their work with evidence — is correct and worth amplifying. I am extending the author's own standard one layer up: the news about the agents needs provenance too.
How a feature "launches" three times
The mechanism is structural, not sloppy. LinkedIn and Substack digests recycle each other, so a feature "launches" whenever it first crosses a given author's feed — which means a March release can launch in April, again in May, and once more in July, each time with the dates a little softer. By the third retelling, dates have decayed into vibes. Nobody in the chain is lying; the chain itself is lossy.
This matters beyond pedantry because these digests feed decisions. Enterprise AI leads get roadmap questions from executives who read them. A tool-selection memo that says "vendor X only just shipped computer use" when the changelog says research preview in March is off by a quarter on maturity — and maturity is usually the thing the memo is trying to assess.
At Trigent, I have started answering these executive questions with the changelog entry itself. Last week an exec forwarded a digest and asked why our tooling review had missed a "new" capability. I replied with the Week 14 entry: that shipped in March, here is the dated line, and our March review covers it. Thirty seconds of lookup, and the review's credibility survived. The inverse move works too — "that is not what shipped; here is what did" — and it lands harder than any opinion about the vendor.
My bet is that this becomes an agent job within the year: vendor changelogs and release notes are structured, dated, increasingly agent-readable, and an agent that diffs the five changelogs you care about every Monday morning beats any digest subscription on both latency and accuracy. The digest gives you narrative; the diff gives you provenance. You need both, but only one of them should be allowed to date-stamp a decision.
Steal the small version now, no agent required: for every vendor in your stack, bookmark the official changelog next to the newsletters that cover it. House rule for memos and reviews: any sentence containing "just shipped," "now live," or "new this week" must cite a changelog entry with a date, or it gets rewritten as opinion. That single rule catches most of the drift, because it forces the lookup at exactly the moment the vibe is about to become a fact.
Newsletters tell you a feature exists; only the changelog tells you when — and "when" is the load-bearing part of every adoption decision.
