Automation Lab Notebook

I asked whether I could use my real name here — and ended up recreating my accounts

Published:

It started as a throwaway question. “I’m showing my first name on this blog — is that actually OK?”

On this blog I write honestly: that I don’t find management all that fun, that I want to automate my work alongside AI and eventually break out of it. So naturally I started wondering — how much of my real identity is safe to show? I figured Claude Code would just fire back “your first name alone is fine,” and that would be that.

It did say exactly that. But it didn’t end there.

First finding: the email isn’t leaking

The first thing I had Claude Code do was comb through what’s actually exposed on the site. The answer was simple: the only thing public is my first name in the byline. No email address anywhere — no mailto:, nothing in the RSS feed.

The one real leak was the git commit email. Claude caught that one too, switched the commit author to a GitHub noreply address (<id>+<username>@users.noreply.github.com) and closed the hole on the spot.

…and I almost wrapped it up there as “audit complete."

"Is that really it?” — the actual issue surfaces

Before closing it out, I took one more deliberately skeptical pass. “The email’s fixed. But what is the thing I’m actually trying to protect?”

The answer was the pseudonym wall. Because the content here is sensitive — my honest take on management, my FIRE ambitions — the defense isn’t “hide the content.” It’s “don’t let the content be tied to my real identity.” As long as the pseudonym stays severed from the real me, I can write anything safely.

And that’s when it hit me. My handle had stopped working as a pseudonym.

The handle on my GitHub account was the same one I’d reused on old personal blogs and on X — and I’d shared it with a handful of people I know, as in “yeah, that’s my account.” Which means anyone who knows me could trace that handle straight to this blog — honest management gripes and all.

A pseudonym is only a pseudonym while it has never been connected to the real you. Hand it to someone who knows you, even once, and it’s effectively a public account. The wall had been down the whole time.

The decision: don’t water down the content. Just change the face.

Two options.

  1. Dilute the content into something inoffensive.
  2. Move only the blog’s face to a clean, never-shared identity.

Option 1 kills the whole reason this blog exists (honesty), so it was out. I went with option 2: a new email and a new GitHub under a name with zero link to my old handles.

The lucky part: I hadn’t deployed to Vercel or anywhere else yet, so the site wasn’t public anywhere (and the repo stays private from here on). Move it while it’s small, before anything leaks. That’s the cheapest time to do it.

The steps: lighter than expected, but one trap

Now for the actual work. Though I should come clean: the only thing I did by hand was creating and setting up the new Google and GitHub accounts. Coming up with name candidates, rebuilding git, the leak checks — every command was typed by Claude Code. My job was to ask, to choose, and to say “OK.”

Choosing the name

I kept the rule simple.

I had Claude come up with about ten candidates and check availability across GitHub (gh api), .com / .dev (RDAP), and note all at once; I picked one that was free everywhere. I did stall for a second on “if my first name is fine to show, why isn’t it fine as an account name?” — but the line is “not uniquely identifiable by surname or full name,” and a bare first name doesn’t cross it.

The trap: the old username is burned into your commits

This was the blind spot. A GitHub noreply looks like <id>+username@users.noreply.github.com. The username is baked into every commit’s author field as plain text. So just creating a new account and moving the repo over still leaves the old name showing in git log. Half the point of recreating the account is gone.

The fix is a fresh init. This is where Claude took over: throw away .git and rebuild it as a single commit.

rm -rf .git
git init -b main
git config user.name "<new-handle>"
git config user.email "<new-id>+<new-handle>@users.noreply.github.com"
git add -A
git commit -m "Initial commit"

Before pushing, I added a gate that mechanically verifies none of the old identifiers survive in history — don’t push unless it’s zero hits.

# Are the old handle / old ID / old email anywhere in history? (zero = good)
git grep -i -E '<old-handle>|<old-id>|@gmail\.com' $(git rev-list --all)

After confirming zero, I created a new private repo and pushed.

Cleanup

Finally I confirmed npm run build was green, and the migration was done. The whole thing took under an hour.

What I learned

And this was a good example of what pairing with an AI is actually for. Except the one who pulled it back with “is that really it?” was me, not the partner — an AI won’t take the hint and stop you.

But the moment I doubted and set the direction, everything downstream — auditing the site, rebuilding git, verifying the old name was gone, the cleanup — got run by Claude. The only part of this whole migration I did by hand was creating and setting up the two accounts. Overthinking until I freeze is my bad habit, but slipping in a single “doubt it one more step” and then tossing the actual work to the partner — that’s the division of labor, and this time it clicked perfectly.

The answer to the original question — “can I show my first name?” — turned out to be “yes.” The problem was never the name itself; it was the account sitting right next to it.

Ship at 80% — that’s the rule here, so I’ll wrap it up here.

← All posts