Using AI to Upgrade This Website

Part of my job is understanding where technology is going, not theoretically, but practically enough to make good decisions for our teams, and form balanced opinions for myself. I have been investing time with AI-assisted engineering.

I picked a project I’d been putting off: updating this website. I used to use this site to talk about some of the iOS development I’ve done in the past.

Rebuild the Hugo setup, upgrade the Congo theme, check in on the AWS CDK code, and get something deployed. It’s the kind of work that sits on the backlog, right behind cleaning the shed. Tedious config changes, dependency upgrades, a bit of DNS, some CloudFormation. Exactly the kind of thing AI is great at.

I used Claude. Here’s what actually happened.

What worked well #

What would have taken me a focused afternoon — reading changelogs, tracking down deprecations, debugging TypeScript compilation errors — happened in a couple of hours of back-and-forth. Claude held context across the whole session, remembered what we’d already changed, and made sensible decisions without me having to re-explain the project each time.

The CDK upgrade is a good example. We went from v2.73.0 to the latest version. That meant updating the CLI, the lib, TypeScript, fixing three separate compilation errors that cascaded from the upgrade, migrating a deprecated API, and switching from Origin Access Identity to Origin Access Control. Done correctly, with explanation, in one thread. That’s genuinely useful.

Claude also caught things I hadn’t asked about. It noticed the public/ directory was tracked in git when it shouldn’t have been. It flagged the root domain CNAME as technically invalid DNS. After some prompting, it suggested dynamically resolving the ACM certificate ARN rather than hardcoding it. A real improvement, not a cosmetic one.

Where I had to check the work #

Claude made several mistakes during the session. None were catastrophic, but all of them required me to catch them.

It committed localhost URLs into source control. The site was built with hugo server, which bakes localhost:1313 into the output, and those files were committed to git. Claude is an eager Git committer. I noticed because the diff looked wrong. A developer who wasn’t paying attention may have pushed that to production.

It got version numbers wrong. When upgrading CDK, Claude used the CLI version number for the library package, which doesn’t exist. The error only surfaced on npm install. Small, but it added a round trip.

It fixed errors reactively rather than anticipating them. The TypeScript upgrade required three separate fixes, each discovered only after running the build. A more experienced approach would have anticipated these from the TypeScript version delta upfront.

It deployed before verifying the certificate ARN existed. The CDK stack referenced a hardcoded ARN that had been deleted. This only came to light after a failed CDK deployment and rollback. Claude fixed it, but the right move was to verify before deploying. I prompted it to do so, and it spat out a script prior to the CDK runnning to check the stack for existing certs.

The git rebase missed a commit. After cleaning up authorship on all commits, one was left untouched because it was used as the rebase starting point. I noticed this in the git log history.

What this tells me about AI in engineering teams #

The pattern is consistent: Claude was effective at doing the work, but needed supervision at verification steps. It didn’t pause to ask whether something should be checked before proceeding, the way a cautious engineer would. It was confident.

That’s not surprising, and it’s not disqualifying. It means AI assistants function more like a very capable junior engineer than an autonomous senior one. They need code review. They benefit from someone who knows what correctly done looks like.

For engineering leaders thinking about AI adoption, a few practical observations:

The productivity gain is real, but it shifts where the skill matters. Writing the code, tracking down the right API, debugging compilation errors gets faster. Feedback loops are quicker. Reviewing the output, catching subtle errors, knowing when something looks wrong. You need engineers good at that kind of scrutiny.

Juniors and seniors will have different experiences. A senior engineer pairing with AI gets a productivity multiplier because they have the context to catch mistakes. A junior engineer may produce work that looks correct but contains errors they don’t have the experience to spot.

The gap between syntactically correct and actually working is still yours to close. Claude could write the CDK stack. It couldn’t tell me the CloudFormation deployment was going to fail before it did. That gap is where engineering experience still lives.

Conclusions #

I am very optimistic about AI tooling. Claude got better as context improved, but I still found myself checking and approving scripts prior to execution. That’s likely my background kicking in.

AI is not a replacement for engineering judgement. It’s an incredibly useful tool for engineers who already have that judgement, one that reduces friction on the parts of the work that are tedious rather than hard. Getting my website updated wasn’t hard. It was just low on my priority list because of the overhead. That overhead is now much lower, and shrinking by the minute.

I’ll keep using it. I’ll keep reviewing. I’ll keep paying attention to patterns of mistakes, because understanding where AI gets things wrong is part of what it means to use it well.