1. Introduction
Most technical writing shows up with the wrong attitude. A blog post acts like a final verdict. It looks finished and sure of itself, leaving no room for the idea that it might be wrong. The comments sit way below, like an afterthought nobody cares about. This series flips that around. Every document here is just a proposal. It lays out a clear position, so you can spot where you disagree. It treats your disagreement as a way to make things better, not as noise.
2. Why this form
Back in April 1969, Steve Crocker had to send notes to the people building the ARPANET. He worried that a real “specification” would sound too bossy coming from a grad student. So he called the notes Requests for Comments instead. That name was basically a hedge, but it turned out to be the smartest design choice in the whole series. A document that asks for objections tends to get them, and a document that gets objections tends to get better. This format has kept ideas alive and working for over fifty years, mostly because it never acted like it was done.
The borrowed conventions here are not just for show. I number the documents so I can’t quietly edit a bad argument out of existence. I date them so an argument about tooling from two years back looks like what it is: something from two years back. And I publish a status field so the gap between “I believe this” and “I’m just thinking out loud” is stated plainly instead of left for you to guess from the tone.
3. Scope
The topic is mostly about how you build software when models do part of the work. Writing the code is no longer the hard part. The model can do that now. The hard part is judgment: what to build, and how to move fast without losing safety.
What I leave out: model benchmarks, release news, and guesses about the next eighteen months. Other places cover that well already, and it ages badly in a series that keeps its old documents around on purpose.
4. How to comment
Comments go on the document itself, in a thread under the Request for Comments heading at the foot of each post. You need a GitHub account to post there. Each thread is a GitHub Discussion in a public repository, so readers can raise questions, corrections, or new ideas where other readers can see them. This document is the one exception: it has no thread of its own.
Good comments get folded into the document, with a note about the change. Or I answer them in a follow-up that the original piece then links to. GitHub keeps the full history, so nothing quietly vanishes. A comment that adds a new idea is the best outcome here.