This is a first draft. I have used Claude on this blog for two days. I will come back to this post when I have used it for two months.
The stale posts Link to heading
This blog had five posts. The oldest was from 2021 and described hosting on AWS with Cloudflare for DNS. I have not used AWS for these sites in years. Two more were about my career, written in a hurry, and one of them said “currently leading” about a job I left in 2023. The other two were drafts I never finished.
I knew all this. Knowing it did not get the posts rewritten. What got them rewritten was having something to argue with.
What I asked for Link to heading
I opened Claude Code in the blog repository and asked it to look at the 2021 post, look at the Terraform and workflows I use today, and tell me how to write about the difference.
It came back with an outline and a list of things it had noticed in my infrastructure that I had not: a site deploying twice on every push, a plan step with no concurrency guard, a lockfile with only macOS hashes. Then it asked me two questions and waited.
That pattern held for two days. It did the reading, proposed, asked, and did nothing to a post until I said apply.
The rules Link to heading
Before any of this I had written a CLAUDE.md for the repository: no adverbs, no passive voice, no filler openers, no em dashes, short paragraphs, name the specific thing.
Rules I had read about and never followed.
Claude followed them.
Every time I wrote a paragraph and handed it over, it came back with a list: line number, which rule, my sentence, its sentence, as a diff.
It applied nothing until I said yes.
Then it committed my version and its version as two commits, so git diff between them shows where I drift.
I drift in the same four places every time. Adverbs of time: initially, later, mostly. Two clauses joined by a comma where a full stop belongs. Explaining why I left something out. Praise words where a detail should be: stunning, extremely, next level.
I did not know that about my writing before. I know it now because the diff shows it twelve times in a row.
The hosting post Link to heading
The 2021 post became a post about Cloudflare Pages, Terraform, R2 for state and GitHub Actions. My first reaction to the draft was that it read like it was written for senior engineers. I said so. The next version explained each tool in three sentences with a link to the official documentation, and moved the how-to into a companion repository where every commit is one step of the setup.
Then it left comments in the post, <!-- Yogesh: ... -->, at the places where a story of mine belonged.
Why I left AWS.
Where I got stuck.
What I built next.
I filled them in, it ran the rules over my additions, and we went again.
The companion repository is live. Getting it live took three wrong tokens, one bucket that no longer existed, and an account permission I had forgotten. Each one showed up as a bare authentication error. Claude found each by testing the token against the API and telling me which call failed, and the README now has that check in step 5 so the next person skips the hour I lost.
The post has Dutch and Marathi versions. There is a rule for those too: product names, commands and code stay as they are, engineering words like state, plan and apply keep their English form, and falling back to English beats a translation that shifts the meaning. A script checks that a translation carries every heading, code block, link and table of the original, and the build fails if one is missing.
The career posts Link to heading
The two career posts were harder, because the problem was not structure. The problem was me.
I asked Claude to read them against my resume and tell me what was wrong or missing. It found the wrong tense, two jobs I had never written up, a resume pasted raw into the end of chapter 2 with headings in capitals, and a handful of sentences that were boasts. “I can proudly say I can understand process of any kind.” “I have proven it to myself.” It rewrote those as claims with evidence instead of claims with volume, and told me which ones it had changed and why.
It also softened a few things I did not want softened, a clash with a colleague, a promotion that went elsewhere. I read the diff and put the edges back. That is the part of the process that has to stay with me.
Chapter 1 went from 1650 words to 2650, all of it stories I would not have written without a comment asking for them.
The first computer I sold.
A generator overhaul at three in the morning.
The rm -rf /* on a production server, told in the order it happened.
What it got wrong Link to heading
It read “company technician” as the manufacturer’s technician. It let two of its own adverbs through and caught them on the second pass. It offered a reason why Backstage does not fit large organisations, in a comment marked optional, and the reason was not mine. I wrote my own.
None of these got into a post. All of them would have, if I had said apply without reading.
What changed on the site Link to heading
While the posts were open, the site got a copy button on code blocks, GitHub’s syntax colours in light and dark, one font file instead of twenty, an “Updated” line under the date, a draft marker only local builds show, comments through GitHub Discussions, and post lists that show every post in every language. Each of those was a question I asked in passing and an answer I checked in the browser before it went in.
What I think so far Link to heading
The value was having my own rules enforced by something that does not get tired of enforcing them, and that shows me the diff every time.
I still write the first version. It still reads worse than the second. The gap is smaller than it was two days ago, and I can see it.
More when there is more.