Chan's AI Weekly
The week in AI, curated and explained in five minutes. I write it with Claude Code, on my own machine, from a pool of the week's industry signals — and I read every issue as a subscriber before it goes anywhere.
I'm showing you the workflow on purpose. The AI in it isn't a secret to hide behind a byline — for the engineers who read this site, how a person and a model actually divide the work is the interesting part. Here is exactly how an issue gets made.
The weekly process · 5 stages
A script pulls roughly fifty of the week's AI industry events — launches, model releases, research, funding, company moves — from a set of curated feeds, plus the week's notable product launches from ProductHunt. Aggregator wrappers are stripped as the pool is built, so what lands in the pool is the original story and its link, never the middleman that surfaced it.
I open the pool in Claude Code and we work through it together. Claude reads all of it, checks the ones worth including against the live web so the summary describes what the original actually says, picks the week's lead story, groups the rest into themed categories, and writes the copy. It drafts against a house style guide that lives in the repository — the section order, the length limits, the voice, the words that are banned — so the format holds steady week to week instead of drifting with whatever the model felt like that morning.
The draft renders as the real email and lands in my own inbox first. I read it the way you will, then send it back for changes: a lead that buried its point, a summary that overstated a launch, a category that was really two. This is the quality gate, and it is a person — nothing goes out that I have not read end to end and decided is worth your five minutes.
Taste is mine; the boring correctness is enforced in code. Before the issue can render or send, a validator proves it matches the published issue schema field by field — every link an absolute URL, every headline inside its length limit, no stray keys. Then a leak guard scans every line of display text: it fails the run on any aggregator attribution and on any non-English text that slipped through from a source. Either check failing stops the send.
The issue is written to this site as a structured record and published to the archive first, so the permanent copy exists before the email does and every link in your inbox has somewhere to land. Only then does it broadcast to subscribers — Monday, New Zealand time.
The editorial constitution
The title, the tagline, and the section labels — The Big Story, the themed quick-hit categories, Tools & Launches, From the Blog, In Brief — are brand constants in code. They are never regenerated. You learn the shape once, then read every issue in the same order.
A link dump is easy and useless. Every item says what happened and why it matters to someone building software this week, and the lead story gets a paragraph of that reasoning outright. It's written for practitioners and people who follow the field closely — so the technical terms stay, and the empty adjectives go.
A hard rule, enforced by a script rather than by good intentions — the newsletter never names the feeds it reads. Each event is stripped of its aggregator the moment it's fetched, and a final scan fails the send if any attribution phrasing, or any untranslated text from a source, survived into the copy. You get a link to the original story, never a name-drop of where I found it.
Two different kinds of gate, on purpose. Judgment — is this the right lead, is this summary fair, is any of this worth reading — is mine, made on the rendered email. Everything a machine can verify without taste, the machine verifies: schema validation and the leak scan both have to pass, and a thin week gets no issue rather than a padded one.
The rules Claude drafts against aren't in a private prompt. They live in the repository's editorial guide, with the section contract, the length limits, and the banned words spelled out. When the newsletter changes, you can read the diff.
One note on the older issues
This is the second version of the newsletter. The earliest issues in the archive were made a different way: a fully automated pipeline argued one thesis a week and scored its own draft on five axes, holding anything below the bar instead of sending it. Those issues still carry their scorecards where you can see them. In July 2026 I moved to the process above — a person reading the draft turns out to be a better gate than a model grading itself.