What Publishing 35+ Agent Articles Taught Me About Writing (and About Agents)
Thirty-five plus articles about agents now, launches and field tests and honest misses. The count comes from my own publication index, and it is the one number in this piece I can certify, because it is the one I checked.
The biggest lesson from the streak was not about agents. It was about what makes technical writing land, and the interesting part is the symmetry: the same rules that make agents trustworthy make writing about them trustworthy.
What I Thought Would Work Versus What Did
Going in, I assumed the winning pieces would be the definitive ones. The complete guides, the frameworks with diagrams, the exhaustive comparisons. They do fine. They are not what travels.
What travels, in my own numbers, is the piece with one real thing in it. A gate that refused something. A test that lied for months. A release day that caught what six weeks of green suites missed. The pattern is consistent enough that I now plan around it: lead with the thing that actually happened, and the analysis gets carried by it. Lead with the analysis, and nothing gets carried.
The other surprise: the pieces I was most nervous to publish did the best. The ones with an admitted mistake or a number that undercut my own argument. Every instinct says hide the rough part. The audience says the rough part is why they finished reading.
The Craft Checklist
Four rules, learned in order, each one paid for.
The receipt rule. Every load-bearing claim gets something checkable attached: a repo, a log, a report, a number you actually measured. If the receipt does not exist, the claim gets cut or softened until it matches the evidence. This is the same discipline as agent verification, applied to sentences: an unverifiable claim is a green test nobody ran.
The failure anchor. One honest miss per piece. Not as confession theater, as credibility engineering: a piece with no failure reads as marketing, and readers discount marketing by default. The miss tells the reader the rest was checked by someone willing to report bad news. My most-shared pieces all contain a moment where I say the thing did not work.
The discussion hook. End with a question that has a real answer, not "what do you think?" The questions that work ask for a number, a story, or a count: how many instruction files do you have, what did your release day catch, what did you re-run this week. The comment section is the second half of the article, and the good questions let the readers write it better than I did.
One true number. If a number is in the title, the body delivers exactly that number, from a source I can name. The count at the top of this piece is an example. It is not the most impressive number I could have used. It is the one I can certify, which is the point.
tip: The craft rules for trustworthy agents and trustworthy writing are the same rules: verifiable claims, visible failures, bounded scope, no unearned confidence. Write about your agents the way you would want your agents to act.
What the Streak Taught About Agents
Running the writing alongside the building produced one insight I did not expect and use constantly now.
Writing about a system forces you to claim things precisely, and precise claims are tests. "My gate blocks bad agents" dies in the drafting. "My gate refused four specific bad agents, here are the four, here is what each refusal said" survives, because while writing it I had to go back and check. The draft is a verification layer for the builder's own work, and half my articles have caused a fix before publishing, because the sentence I was about to write would have been a lie.
That is the symmetry, and it is why I would recommend writing to anyone building agents, independent of the audience. The audience is a bonus. The precision is the product.
What I Still Get Wrong
For balance, the misses.
I still overwrite openings. The first two paragraphs of most drafts get cut or halved in revision, because my default is to set up context the reader did not ask for. I still default to explaining before showing, and every time the fix is the same: cut until the interesting thing is on the first screen.
I still chase hot topics occasionally, and those pieces are consistently my weakest. Timely pieces have a half-life measured in days and age into embarrassments. The pieces anchored in something that actually happened to me age into references. The difference compounds.
And I still have to fight the streak itself. Publishing weekly is a rhythm that wants feeding, and a fed rhythm will happily produce content-shaped objects that nobody needed. The best filter I have found: if nothing happened, do not write. The discipline of "no receipt, no article" is what saves the streak from becoming its own failure mode.
The Honest Limitation
This is one writer's pattern, drawn from one publication index, in one niche. Your mileage is the whole point of the comment section, and craft rules that survive contact with other people's data are the only ones worth keeping. Take the four rules as hypotheses, not laws.
But the symmetry claim, I will defend. Verifiable claims, visible failures, bounded scope, no unearned confidence. It is a short list, it works on agents, it works on writing, and I have thirty-five plus receipts that it works on at least one of those.
So here is the question, and it is the meta one, because this whole piece is about writing in public: what has writing in public taught you that coding never did?
The one-sentence versions in the comments are better than the essays, every time. I will be reading, and the next piece I write is usually one of those sentences wearing a case study.
Top comments (3)
The symmetry claim holds, and I'd sharpen it slightly: writing in public taught me to notice when I don't actually understand something. Coding lets you get away with partial understanding — the tests pass, the feature ships, and the vague mental model never gets tested because nothing asks you to explain it. Writing doesn't allow that. The moment you try to put a mechanism into a sentence for someone who wasn't there, the fuzzy part of your understanding becomes obvious, usually in the middle of a paragraph you were sure was fine.
The other thing coding never taught me: how to be wrong in front of strangers without flinching. A bug you fix in private costs nothing but time. A public claim you have to correct costs something real — and that cost is exactly what makes you check the next one properly. Your "no receipt, no article" rule is the same mechanism as review before merge, but with worse consequences for skipping it, because you can't patch a published sentence quietly.
Which is why I read your point about the nervous pieces doing best as the most useful line here. The hesitation is the signal that you're about to write something you actually verified, rather than something that just sounds right.
Thank you for sharing! This is exactly the kind of inputs I was looking for. As I do projects, I use AI to write notes in files at various points. I use compaction summary too as opencode prints it out. I save all that and later process them to extract the article pieces. I have a publishing rules md which is where receipts check, grounding of facts and any insights are checked. Whatever I could not fix or I spent longer time to rationalize and fix often feeds into questions I put in articles. My publishing rules makes sure I separate grounded facts backed by verification from any theories I propose or pose as a question.
In fact when I start a project and write the PRD, right there I extract possible article pieces as to what I may write about when project gets done. 100% of that is not used later as the very execution of the project reveals a lot of learnings and my assumptions get validated or invalidated.
Thank you again for sharing these details. I appreciate this
The publishing rules file is the part I'd steal. Separating grounded facts from theories-proposed-as-questions is exactly the discipline that keeps a piece honest, and doing it as a checklist rather than a vibe is smarter than most people manage.
But your "100% of it is not used later" line is the most interesting thing here, and I think it's the real argument for doing it anyway. The value wasn't the extracted article pieces — it was that writing them down forced you to state assumptions precisely enough that execution could prove them wrong. You got the verification benefit at PRD time, and the article never had to exist. That's a receipt you cashed early.
One thing I'm curious about: the compaction summary. When you compress notes into a summary, do you keep a link back to the original file for the facts that survive? I've found that summaries are where provenance quietly dies — the claim survives the compression, the source that verified it doesn't, and six weeks later you can't tell whether that number was measured or remembered.
Thanks for laying out the workflow — this is more useful than most posts on the subject.