I spent five days straight on my website.
Not writing articles. Not thinking about strategy. Just the site itself — the layout, the structure, the things a normal person would set up once and forget. I kept finding one more thing that wasn’t right.
On day five, I noticed something: my articles had no social sharing buttons.
Obviously, I thought. I should fix that. It’ll take ten minutes.
I installed a plugin called Sassy Social Share.
Then I refreshed my homepage.
What I Saw
The layout was gone.
Not broken in a minor way. Gone. Sections stacked on top of each other. The hero video background — which had taken real work to position correctly — collapsed into a flat mess. The stats strip ran vertical instead of horizontal. The card grid was a single column. Everything that had been carefully arranged was now arranged by gravity alone.
I had just spent five days building something. And in about thirty seconds, I had destroyed it.
I sat there for a moment just looking at it.
Then I did what I’ve started doing in situations like this: I opened Claude and asked for help.
What AI Actually Did
I’m going to be honest about something. I don’t fully understand what the AI diagnosed or how it fixed it.
I understand the general explanation it gave me: my WordPress theme doesn’t load a file called wp-block-library.css, which is where all the block layout rules live. Without it, Gutenberg’s layout classes — the things that make a three-column grid actually display as three columns — don’t do anything. They’re class names attached to nothing.
The plugin installation had apparently triggered a cache refresh that made this underlying problem visible. The homepage had always been fragile. I just hadn’t seen it yet.
The fix was to take every layout rule and write it directly into the HTML as an inline style — a workaround that bypasses the missing stylesheet entirely. The AI applied this to every affected element across the page. One section at a time. Then it verified that each fix worked.
Before touching anything, it made a backup. It created a Python script that could re-upload the homepage. It wrote a maintenance guide explaining every change it made and why.
The homepage worked again. Better than before, actually — more stable, because nothing depended on the missing stylesheet anymore.
It took a few hours. I contributed approximately zero technical skill to the process.
The Part That Hasn’t Left My Mind
Here’s where the story gets more interesting to me than the crash itself.
After everything was fixed, the AI told me something I hadn’t considered: don’t update the WordPress theme. Any major update could re-introduce the CSS problem. Don’t install new plugins carelessly. Don’t touch the page structure in the WordPress editor — the layout lives in the HTML file now, not in Gutenberg blocks.
My homepage is maintained through a Python script and a local HTML file. The AI manages the logic. I run the script when I publish a new article.
This is not how I imagined managing a website.
I’ve been building things online since the early days of Wix and basic HTML. I ran a goji berry website for six years. I understand the general principle of: you build a thing, you own the thing, you change the thing when you want to.
Now there’s a section of my site I’m genuinely nervous to touch.
The Question I’ve Been Sitting With
I’ve committed to running this blog for five years. That commitment is real — I wrote about it in my building in public experiment, and I meant it.
But five years is a long time to rely on any single tool.
What happens if Claude becomes unavailable? If access gets blocked? If the model gets deprecated and the replacement doesn’t understand the context? What happens to a website that’s partially managed by an AI that no longer exists in the same form?
I don’t have a clean answer.
What I have is this: the AI anticipated the question and tried to address it before I asked. It created documentation detailed enough that another AI — any AI — could read it and pick up where this one left off. It wrote everything out: the root cause, the specific CSS rules, the script locations, the API credentials, the exact commands.
“If you ever need a different AI to handle this,” it told me, “give it this file. It has everything.”
I found that surprisingly thoughtful. And slightly unsettling. It was preparing for its own absence.
What I’ve Actually Learned
There’s a version of this story where I conclude that AI is dangerous because it creates dependency. I don’t think that’s right.
I’ve created dependencies before — on WordPress itself, on plugins, on hosting providers. None of them provided documentation. None of them thought ahead about what happens if they’re gone. Most of them, frankly, were harder to exit from than this.
The more honest conclusion is simpler: I’m not the sole operator of this site anymore. I’m something more like a co-owner who handles the content and a collaborator who handles the infrastructure. That’s a new arrangement, and I haven’t fully sorted out how I feel about it.
What I know is this: the homepage is stable. The backup exists. The documentation is written. And if the day comes when I have to explain this situation to a different AI — or figure it out myself — I at least have a trail to follow.
That’s more than I had when I ran the goji berry website for six years without a plan.
Some dependencies are worth having. I just hadn’t expected this one.
This is part of my 180-day building in public experiment — documenting everything honestly, including the moments where I’m not sure who’s actually running things.
Leave a Reply