lucida

Migrating the Blog Back to a Static Site

Four years ago, out of laziness, I moved this blog from Hexo to WordPress.

Four years later, out of a different kind of laziness, I moved it back to a static site.

It sounds a little embarrassing.

More embarrassing still: this post itself was also generated on the side by Codex during the migration conversation.

Yes. I have now become lazy enough that even “write a post about why I became lazy” is something I outsource to AI.

At this point, technical progress is getting slightly out of hand.

Disclaimer

To avoid future archaeologists getting the wrong idea, let me state this clearly up front:

  1. I did not type this post out word by word myself.
  2. This post was improvised by Codex during the blog migration conversation in a style based on how I used to write.
  3. If you think some sentences sound a little sharp, that means it learned the style fairly well.

So overall, this probably counts as a migration summary generated live from inside the migration session itself.

The meta level is mildly annoying, but also very on-brand for this era.

WordPress

Back in 2022, I switched from Hexo to WordPress for very plain reasons:

  1. I did not want to keep fiddling with Node.js, git hooks, theme configs, and deployment scripts.
  2. I did not want to open a local editor, write Markdown, then run commands just to publish.
  3. I did not want to reconfigure the whole environment again every time I changed machines.

In short: I wanted writing a blog post to feel more like posting, not like shipping a release.

From that angle, WordPress was a reasonable choice:

  1. Simple setup
  2. WYSIWYG editing
  3. As long as there is a browser, I can write from anywhere

In theory, anyway.

Reality likes to add one more hit after the migration: not long after moving, I forgot my WordPress password.

That is a very black-humor outcome.

You work hard to move to a system that is supposed to be “easier to maintain,” and then a few years later the first thing that breaks is neither the theme nor the plugin stack, but your own memory.

In a way, that also proves WordPress really did lower the barrier to use. It lowered it so far that I barely needed to log into it anymore.

And at that point I was already somewhat tired of the whole “static blog” idea.

Programmers love static blogs, GitHub Pages, Markdown, themes, auto-deploy, and even writing essays about those toolchains themselves. The problem is that these things can very easily mutate from “writing tools” into “toy engineering.” If maintaining a blog starts to feel as expensive as maintaining a side project, the blog will probably be abandoned.

At least that has been true for me.

Why I moved back again

The reason was just as plain: the environment changed.

Back in 2022, from the WordPress point of view, the main problems with static blogs were:

  1. configuration was annoying
  2. migration was annoying
  3. theme customization was annoying
  4. if I stopped updating for a while, I would even forget the commands

All of those problems still exist. They just matter much less now, because something new appeared: agentic coding.

In the past, a lot of the time spent “working on the blog” was actually spent on these useless chores:

  1. reading Hugo, Hexo, or Jekyll docs
  2. tweaking theme CSS
  3. migrating old posts
  4. fixing URLs
  5. configuring DNS, Cloudflare, and deployment

None of these are hard. They are just annoying, and fragmented. That fragmentation is exactly what makes procrastination so easy.

Humans can still force themselves through work that is difficult but important. Work that is not hard but extremely annoying tends to trigger immediate strategic death.

And tools like Codex or Claude Code are exactly the sort of agentic coding tools that are good at this kind of work. They cannot replace actually writing something worth reading, but they are very good at:

  1. scaffolding
  2. editing templates
  3. cleaning HTML
  4. writing migration scripts
  5. fixing configuration
  6. setting up static deployment

In other words: the main cost of static blogs used to be engineering work, and that engineering cost has now gone down.

More precisely: I used to have to handle a pile of edge junk myself. Now I can dump that junk onto a digital laborer that does not complain, does not find it tedious, and does not go announce blockers in a group chat.

It also has one extra advantage: if I suddenly ask it at midnight to change DNS, fix CSS, and casually write a blog post too, it will not give me the expression that says, “should this request maybe be scheduled for next week?”

So several WordPress advantages weakened, while several static-site advantages became stronger again:

  1. writing in Markdown feels better
  2. git history is more reliable
  3. static pages are simpler and the maintenance surface is smaller
  4. I no longer need to keep maintaining the whole WordPress / PHP / VPS stack

What this migration actually did

This time I did not aim for any complicated architecture. The basic plan was very direct:

  1. rebuild the blog with Hugo
  2. store posts in Markdown
  3. manage content with git
  4. host the static site on Cloudflare Pages
  5. move the domain DNS to Cloudflare

Along the way I also did a few other things:

  1. exported XML from WordPress
  2. wrote scripts to import posts into Hugo
  3. cleaned out some posts from recent years and kept only content before January 20, 2022 for now
  4. simplified the page styling instead of doing too much decorative work
  5. used lucida.me directly as the main blog domain

That last decision was actually important.

Originally I planned to keep using blog.lucida.me and reserve lucida.me for a fuller personal homepage later. But as I got deeper into the work, it became obvious that this was not especially necessary. At least right now, the blog itself is the main content on lucida.me. Instead of splitting things one layer further for no real reason, I would rather just use the root domain directly.

To put it bluntly, planning too far ahead is often just a more respectable form of procrastination. It is more important to put something usable online than to reserve space for a grand information architecture that does not actually exist.

What is even more absurd is that migrating the blog was not the only thing I was tinkering with during those days.

At the same time, I was also messing with other web apps. In other words, the whole process was basically me repairing the blog, running side quests, and continuing my main work tasks all at once.

Historically, that kind of multithreaded behavior tends to end in one reliable outcome: three projects all rotting together.

This time, somehow, they did not rot.

That alone says the tools really have changed.

Roughly how much did this migration cost?

A rough estimate says that from writing the migration plan to landing the first draft of this post, the whole thing took about 2 hours and 40 minutes.

Measured in dialogue rounds, it was roughly more than forty prompt rounds. And only a small fraction of those were actually about “writing the article.” Most of them were things like:

  1. wrestling with DNS
  2. wrestling with Cloudflare Pages
  3. exporting XML from WordPress
  4. migrating old posts
  5. changing styles
  6. changing them back after regretting the previous changes

One side note: this is only the migration cost for a personal blog.

If I include work as well, I have already landed more than 70k lines of code into Instagram production over the last three months. The more absurd part is that not one of those lines was typed by hand by me; all of it came from agentic coding.

In the past, that sentence would have sounded like bragging.

Now it sounds more like describing an industry trend.

You still need humans to make judgments, break down problems, review code, provide coverage, ship, and take the blame. But the classic image of “the person who sits there typing business code line by line” is visibly losing value.

In an older era, this kind of migration would probably have evolved into a classic programmer project:

  1. Day one: full of excitement, convinced it can be finished tonight
  2. Day two: start reading docs, decide Hugo is actually pretty nice
  3. Day three: start editing the theme, decide the default font is wrong
  4. Day four: discover DNS / SSL / redirect traps
  5. Day five: lose motivation, abandon the project

This time, at least, it did not get abandoned.

That already puts it ahead of a lot of side projects.

The biggest difference between this migration and the previous one

The core logic of the previous migration was:

accept a heavier system in order to make writing easier.

The core logic of this migration became:

because the cost of the system has gone down, choose the lighter system again.

So on the surface this looks like a rollback from “WordPress -> static blog.” But in substance, the decision basis for the two migrations is not the same.

The 2022 version of me was not wrong.

The 2026 version of me is not necessarily right either.

The local optimum just changed because the tool environment changed.

More pessimistically, it is not just the optimum for blog systems that changed. The shape of many ordinary programming jobs is changing too.

For a long time there was still a romantic idea floating around: writing code is a craft, programmers are artisans, and the people typing at the keyboard are naturally a little hard to replace.

Now that romantic picture is rapidly turning into a historical artifact.

The future may well look like this:

  1. a small number of people define problems, review results, and take responsibility
  2. a large number of agents generate the implementations
  3. most of the remaining people, if they are still just assembling pages and APIs from requirement tickets, are basically code monkeys

And historically, code monkeys have rarely had happy endings.

If they are not outsourced today, they get platformized tomorrow, then automated the day after.

The old worry used to be “will AI replace programmers?”

Now I am more inclined toward another framing: AI may not replace all programmers, but it will first smash the layer of programmers who most resemble assembly-line workers.

Of course, it is also possible that four years from now I will write another post titled “migrating the blog to some new thing.”

If that day really comes, I hope I do not have to reread this post, because that would mean I had started tinkering with the blog system again instead of writing something genuinely useful.

What comes next

After this migration, at least a few things should become smoother than before:

  1. new posts can be written directly in Markdown
  2. content changes go through git
  3. site deployment goes to Cloudflare Pages
  4. there is no longer a need to keep maintaining the WordPress instance on DigitalOcean

Of course, this does not guarantee the blog will now update frequently.

The biggest reason I do not write more has never really been Hugo, Hexo, or WordPress. It has always been:

  1. laziness
  2. being busy
  3. the fact that after writing, maybe nobody reads it anyway

The difference is that in the past I also had to fight an entire blog-engineering stack on top of those problems. Now at least that second problem can be removed.

That is already pretty good.

At the very least, the next time I do not update the blog, I can no longer blame WordPress.

That is not ideal.

But from another angle, it is only fair.

If I have already partially outsourced migration, writing, styling, and deployment to agents, then the small part of the work that is actually mine should probably stop pretending to be dead as well.

Tags: Retrospective