I Rebuilt This Blog in One Afternoon with an AI Pair. Here's What It Couldn't Do.

I'll admit it: this blog went quiet for ten months, and the honest reason is friction. Every post lived inside a website builder — log in, fight the editor, paste text into boxes, hope the formatting survives. For someone who spends all day in a terminal, publishing felt like visiting a foreign country. So I did what developers do with anything that has friction: I avoided it.

Yesterday the blog came back. Not with a redesign — with a rebuild. The site you're reading right now is a static Next.js app I own end to end, deployed on Azure, with every post living as a markdown file in a git repository. And here's the part that would have sounded like science fiction when I wrote my last post in October: I rebuilt it in one afternoon, in a conversation with an AI pair.

The receipts

I'm allergic to vague AI success stories, so let me be concrete about what "one afternoon" actually contained:

• Archived the entire old site — every page, every post body — before touching anything, so no content could be lost mid-move.
• Scaffolded a new static site and migrated all four existing posts with their URLs kept byte-identical, so nothing published anywhere ever breaks.
• Designed the dark terminal look you're seeing (yes, the $ whoami up top — I'm a backend dev, let me have this).
• Set up the deploy pipeline: a merge to the main branch builds, verifies, and ships the site. No stored deploy tokens, nothing to rotate.
• Cut DNS over from the old host with zero downtime. My site never blinked.
• Wired up something I've wanted forever: when a post merges, it publishes itself to LinkedIn — with copy written for LinkedIn, not a lazy auto-dump of the title.

One conversation. I reviewed diffs, made calls, and pressed merge. My pair — Claude, credit where it's due — did the typing, and a lot more than the typing.

What surprised me

Not the code generation. Everybody knows the code generation is good now. What surprised me was the engineering hygiene — the things senior engineers nag juniors about, done unprompted.

Before migrating, it archived everything. Before trusting a deploy, it verified content — actually grepping pages for real text, because it had learned the hard way that a static host can serve a "page not found" with a healthy HTTP 200. When the freshly cut-over domain returned a suspicious redirect, it didn't panic and "fix" anything: it tested against the authoritative DNS servers directly, discovered its own machine's stale cache was the liar, and correctly concluded that the redirect was actually covering the migration gracefully while caches aged out.

That last one stopped me. Distinguishing "the system is broken" from "my view of the system is stale" is a judgment call I've watched experienced engineers get wrong under pressure.

What it couldn't do

Here's the part the hype skips, and the reason this post isn't titled "AI replaced me."

It couldn't know what I wanted. Every decision that shaped the outcome was mine: keep the blog's name or rebrand, which trade-offs to accept in the publishing pipeline, what the site should feel like, what gets published under my name. The AI proposed — often well — but proposing is not deciding. Someone still has to want something specific, and be accountable for it.

It couldn't press merge. Deliberately. Everything shipped through pull requests I reviewed, because the moment the words appear under my name, "the AI wrote it" is not a defense. That's not a technical limitation — it's the arrangement that makes the speed safe.

And it couldn't be right all the time. During the LinkedIn integration it made a confident, reasonable, wrong guess about which permission was missing — the actual answer was in a screenshot I had and it didn't. Meanwhile I contributed my own classic: I confidently reported that credentials were configured when I hadn't actually run the commands. It checked, found zero secrets, and called me on it. 👉 The pairing worked in both directions — and neither of us got to skip verification.

The trade-off, because there's always one

You knew this section was coming.

What I gained is obvious: a stack I fully own, publishing friction near zero, and a speed of execution that genuinely changes what's worth attempting. An afternoon project used to mean a tweak. Now it can mean a migration.

What I traded: I now own all of it. When the token powering the LinkedIn automation expires in sixty days — and it will, that's how the platform works — nobody at a website builder is going to quietly handle it for me. Owning your stack means owning its maintenance, its failure modes, and its 2 a.m. surprises. I made that trade with my eyes open, and for me it's the right one. It isn't for everyone.

The deeper shift is in where my time went. Almost none of it was typing. Nearly all of it was reviewing, deciding, and verifying — the work was judgment, all the way down. If that's what pairing with AI does to an afternoon, the interesting question isn't whether it writes good code. It's whether we're good at the part that's left.

What's next

The blog now runs on a schedule: new posts every Tuesday, Thursday, and Saturday.

And I owe you a story. Remember the twenty-five microservices I knowingly overengineered? That platform now runs real, live events — and a few days ago, during one of them, a single invisible failure nearly took the whole thing down. One line of configuration made the difference between a quiet Friday and a production incident.

That story lands Tuesday. ✨ Same place — welcome back.