The Long View

Blog archive

I Rebuilt a Website With Claude, Part 2: It Broke the Site and Blamed WordPress

Part 1 ended with me realizing I had spent weeks redecorating a building (also known as my wife Liz's photography website) that was already condemned. So I stopped redecorating.

The old theme is gone, the site runs on PHP 8.3 with a theme built for it, and Liz's galleries load the way they should. Here's what all that work had bought, speed-wise:

Metric Original Site After Workarounds After Migration
PageSpeed (Mobile) 66 to 70 Mid-80s 93
PageSpeed (Desktop) 94 98 to 99 100
Homepage Images N/A 1,757 KB 147 KB
Image Requests N/A 18 6
Median Response N/A About 919 ms 170 ms

The image weight, request count and response figures were measured across the migration itself, not against the original site.

I wouldn't lean too hard on that 93. A speed score on this site swings by fifteen points or more on a page where nothing has changed, sometimes inside the same 20 minutes. I have watched an untouched gallery come back at 70, then 95, then 81. Any single reading has close to a coin-flip relationship with reality, and I made decisions on single readings more than once before I learned to stop. The 93 is real and it is also one run.

That spread turned out to matter more than the score. First, though, the worst hour of the project.

AI Broke the Galleries, Then Blamed the Platform
While converting the old content, Claude wrote code that quietly removed a single character from the page text every time a page saved. That character was part of a pattern the photo viewer depended on, so the galleries stopped opening for anyone who clicked them. I noticed they were dead, and it wrote six database commands that pulled the missing character back out of a backup and put it where it belonged.

So far, so recoverable. Then it went looking for the cause. It diagnosed the damage it had just caused as a bug in the underlying platform. It told me Liz had been receiving broken emails from her own contact form.

She had not. Nothing was wrong with her email and nothing ever had been. It had misread its own footprint as somebody else's failure and reported it to me as a fact about my wife's business.

That is the lesson I would keep if I could only keep one from this project: A wrong answer arrives sounding exactly like a right one. It is just as specific and just as fluent, and nothing in the formatting marks the difference. There is no hedge and no tell.

The only defense is somebody who knows the work well enough to say that doesn't sound right. But that somebody cannot be the tool.

The Documents Existed Because I Ran Out of Credits
Claude wrote itself a note about that incident afterward, telling whoever picked up the project next to check their own recent changes before blaming the platform. There's a reason it was writing itself notes at all, and it is not a flattering one.

I hit my weekly model limit partway through and lost three days waiting for it to reset. When I came back I switched to a different model, and because context does not travel between conversations, the only way to keep going was to leave a record behind before each break.

Claude wrote those documents. My contribution was knowing to ask for one, which sounds obvious now and did not occur to me until the second time I lost my place. They ran eight kilobytes after the first session and a hundred by the sixth, seven documents by the end.

What struck me was how they were organized. Almost everything in them is a trap somebody already walked into. Real section headings include, “Ground rules, learned expensively” and “Landmines, all hit at least once.” Every version opens addressed to whoever picks it up next, which in practice was a fresh session with no memory of any of it. Reading them back feels like notes from a contractor who keeps firing himself and rehiring a stranger.

It Walked Into the Traps Anyway
The most useful thing in those files is a section Claude wrote about itself and kept current. The heading is, “Things I got wrong. Don't repeat them.” Eleven numbered items in one version, carried into the next with that day's additions on the end. I did not ask for it and would not have thought to. It is the most candid self-assessment I have ever read, and I have written a few performance reviews.

It estimated instead of measuring, and planned 10 years of photo archiving when seven of those years held no files at all. Its own note reads that the plan described work that did not exist. Twice it insisted a button on the intake form was the wrong color, once with the correct color written directly into the page, while a screenshot sitting right there showed it was fine. A photo came back as broken on a page where it was plainly loading, because the browser tab happened to be in the background. And the same false alarm went up three separate times, each one already written down as a warning in the document it had just read.

The line it drew from all of that has stayed with me longer than anything else in this project. When a measurement contradicts what you can see on the screen, suspect the measurement.

In Part 1, that cost me an hour with a phone in my hand, convinced my own device was broken while the server quietly served three different stale copies of the page. The same rule applies to every dashboard and every confident number that lands on your desk with nothing behind it.

What Transferred, and What Evaporated
The whole thing took roughly 50 hours. None of it came out of my work week, because this was for my wife, not for work. It came out of weekends and nights, which means the bill went to my family rather than my calendar, and two of those weekends I do not get back. If you are reading this as an executive wondering whether to try something similar inside your own business, do the conversion honestly. Fifty hours during the work week is 50 hours of customer conversations and the relationships behind them that simply do not happen. That is the real cost, and it doesn't appear anywhere in the numbers above.

Everything I did making the old platform behave evaporated the moment I migrated. The caching workarounds and the image work were specific to a theme that no longer exists, and so was every performance fix on top of them. The design work transferred completely. When the rebuild came, the layout, palette, typography, gallery structure and copy went straight across, because all of it had already been decided and Liz already loved it.

The rebuild went fast because of those first two weekends, not in spite of them.

So the useful distinction here runs between two kinds of work. Judgment work keeps its value when the platform changes. Workaround work dies with it. The uncomfortable part is that these tools are spectacular at the second kind, and they will generate clever fixes faster than you can evaluate them.

What 50 Hours Actually Means
The usual way to evaluate these tools is in total project hours, which misses how time works for anyone running a business. Fifty hours for me meant 50 hours of active supervision, with nothing else happening in the background. My rough estimate is that hiring an agency would have cost around 10 hours of oversight and a great deal of money. Those are not the same 50 hours and they should not be compared as though they were.

There is also a procurement point buried in this that I did not expect to find. Every affordable quote Liz could have gotten would have been to customize the existing theme, because that is what the brief would have said. Nobody writing that brief would have known the platform underneath was finished. It would have been the wrong project at every price point, and she would have paid for a better-looking version of the same dead end.

She now has a site performing at a level she could not have bought at any price her business would justify, and that happened because my labor was free and because I already knew enough to ask the right questions. At the bottom of the market the trade works, because the alternative is nothing at all. At the top it fails, because a good developer with the same tools does more than I did and does it faster.

The Problem I Haven't Solved
Even with a clean build, a small share of requests to the site still hang for almost exactly 20 seconds and then either complete or fail outright. Roughly one request in 15. It happened on PHP 7.4 and it happens on 8.3. It survived replacing the theme and it survived the upgrade.

The durations are the tell. Real congestion is messy, and these land within a few hundred milliseconds of each other every time. Something waits 20 seconds and gives up.

Claude declared it fixed after one clean run of tests. It came back within the hour.

That is the same failure as the color measurement and the background tab wearing a different costume. One clean run proves nothing when the thing you are chasing shows up once every 15 tries. I knew that, and I still let it go for an afternoon. I am working through server logs with the host to find what is hanging, and it is also why that speed score of 93 that I mentioned at the top of this post is worth a raised eyebrow.

Knowing Which Bullet Point Actually Matters
The very first handoff document, written on day one, has a section labeled "Deferred." It said in plain language that upgrading the platform would eliminate an entire class of problems. That note sat in a bulleted list formatted exactly like clearing caches and deleting duplicate files. I read past it the way anyone reads past routine housekeeping.

A week later I tried a cheap version of the upgrade without replacing the theme, crashed the site, and spent hours on the phone rolling it back.

That failure is what forced the real fix, which was a rebuild on a modern theme, staged and tested before it went anywhere near the live site. It also yielded the lesson I keep coming back to: These systems will hand you the correct strategic answer formatted like a minor chore. Ranking that list is where the human judgment lives, and it happens long before anybody writes a line of code.

The Reason There Will Be a Part 3
The first outline for this blog was written from those same handoff documents. I had it checked against them line by line. It came back with roughly 18 factual errors.

Five of the most vivid details about how neglected the site was turned out to describe things the project itself had done in its own first session and then fixed in the second. The forms that only opened a draft and never sent anything were forms I had built. The mobile setting I held up as evidence of neglect was one I had turned on. Four of those five were already sitting in a formatted before-and-after table, ready to publish.

A piece about confident machine mistakes was, in draft, a confident machine mistake. With a hundred kilobytes of its own warnings sitting right there in front of it.

In Part 3: Everything I would tell someone before they start.

Posted by Daniel LaBianca on 09/02/2026


Featured