How I used Claude Code to refactor this website

This website has always been a means of exploring technology that I wasn't already familiar with. When it first came into being I was a college student who knew a lot about software theory, but knew next to nothing about how the internet functioned or how websites worked. Building a website from scratch provided an opportunity to get my hands dirty and learn a thing or two by doing rather than by reading.

As a gainfully employed software engineer in 2026 I've been witness to a lot of hype around these tools. In just this month, big tech is cutting jobs (again), Anthropic is now considered a threat to national security by the current government, and almost everyone I've talked to is using these tools in some capacity on a daily basis.

I've personally found that since LLMs have been released to the public, most of my own and my coworkers' workdays haven't changed very much. Only in the last few months have companies like mine decided to start their initial investigation to determine if these tools are viable enough to use on production code.

This refactor represents my own exploration of the current state of LLMs and to help determine if they are worth all of the hype, or if they are still vaporware.

I have been using Claude and ChatGPT on and off over the last year in a limited capacity. In my experience using these tools in a browser context window I concluded that they were good, but the reality of being a glorified autocomplete became very apparent after any extended interaction with them. As a programmer I've found that using LLMs as a rubber duck can be very helpful, but you still need to have an idea of how the thing you're trying to fix fundamentally works before asking it for help.

Just as I did during the last refactor, I wanted to have a few goals in mind for Claude to help me with.

1. Improved auto SEO (search engine optimization)
2. Add a configurable tag system
3. Include excerpts such that the main page isn't just post titles
4. Maintain the look / feel / spirit of the original site

Getting Claude installed on my machine was easy, and setting up a plan and expectations with it was very straightforward. I appreciated that, as of 2026, it has a plan feature where it asks follow up questions to get more specific details about the project, just as a software engineer would with a customer.

It took a bit of time to narrow down a good approach, but after some back and forth discussion we agreed that Python + Jinja made more sense for a simple and extensible html templating architecture than the current pure bash + html approach. This way we are still able to keep all of the business logic localized to one script while taking advantage of Python's insane number of libraries for other uses.

Once the plan was done, we got to work.

A good partner, not a programmer replacement

 Do you want to make this edit to config.yaml?
 ❯ 1. Yes
   2. Yes, allow all edits during this session (shift+tab)
   3. No

I'm very grateful I had the good sense not to hit option 2 even once during the refactor. There were many occasions where I had to keep it on track, redirect it back towards the main goal, or stop it from writing its own implementation of something rather than simply using an existing library. In the end I felt like I had to treat it like a software undergraduate and dole out very specific tasks that should be done in a very specific way, and berate it when it got some lofty ideas about its own way of doing things.

Despite all of the coralling, and "wait why are you doing it that way" questions, the end result was good. Better than good really. Claude and I wrote something in a few hours what probably would have taken me a whole day to wrap up. After our slop sandwich was "complete," I asked it to go back and reread the code, find any issues, and provide suggestions on how to fix them. I think that it did very well at this task, and could easily see how this might be the best use case for such a tool.

❯ Please take a hard look at the code and find anything that dead / currently not being used

● Here's what I found:

1. post_template assigned twice — line 517 loads it for nav/root pages, then line 549 loads the exact same template again for posts. Second assignment is dead.
2. tag_slug recomputed on line 586 — tag_name.lower().replace(' ', '-') is already stored as tag['slug'] from process_tag(). Duplicate logic.
3. Redundant import re inside functions — re is imported at the top of the file but also re-imported locally inside process_image_captions, regex_search, regex_replace, and safe_html_truncate.
4. from html.parser import HTMLParser buried inside safe_html_truncate — should be a top-level import.
5. featured field in tag objects — stored in every tag object via process_tag() but never referenced in any template.
6. images_optimized potential NameError — if images_dir doesn't exist, the variable is never defined but referenced unconditionally later.
7. Misleading docstring on get_post_date

Within a few iterations of this "look back over everything again" instruction, we had trimmed almost one hundred lines from build.py. It trimmed the dead code we made together during mid-session redesigns, found more efficient ways of doing things, and fixed comments along the way.

Still needs training wheels

I'm uncertain how I feel about the fact that this tool will soon be forced to train on "vibe coded" software. Almost every meme or YouTube video I've come across of someone hyping this tool up also loudly professes that they have no idea how to write software (and therefore no idea what they are doing) but are very happy with the results they are getting. Maybe I'm wrong here, but this seems like a case of "ignorance is bliss." The term nocoders to be used as a slur cannot become popularized fast enough.

If I were to completely ignore software fundamentals and best practices during this refactor Claude would have most likely written a hot and sloppy mess. One could probably argue that even when keeping it on track it still produced slop, but I'll defend that it is at the very least maintainable slop.

In keeping with the undergraduate analogy, here's how I think Claude performed:

Software Planning and Design: A

Claude's Planner tool that auto pops up when discussing plans is great. It asked intelligent follow up questions during the design process and queried the web for up to date information instead of relying on its potentially old and outdated training data.

Implementation: B

Even though it was pretty good at implementing our refactor plan, I maintain that you will need to have some background in basic software fundamentals to get decent results. Now that this technology is open to anyone with a credit card, I'm a bit concerned that we are going to see far more people egregiously and joyously producing absolute slop which will be used to train the next model. I sincerely hope there is a means of mitigating this self defeating alzheimers-like mechanism that will surely cripple the tool in the long run.

Cleanup: A-

Even though it did do very well in cleaning up its own sloppy mess, I still had to ask it about 5 different times to go over the very small repo to find all issues. Even then, I was able to find a few more on my own after taking a pass myself.

To vibe or not to vibe?

This tool is indisputably disruptive, and will continue to be disruptive until some equilibrium is achieved (probably not anytime soon). I haven't looked into agentic coding yet, but it seems to be the next logical step after this. OpenClaw has taken the "AI community" by storm, but at the moment it seems that most people who have gotten on board are either active participants of AI development themselves, or nocoders who remind me an awful lot of the NFT bros.

In conclusion, if you are going to use vibe code tools, I would highly recommend that you learn software and Git fundamentals first, especially Git. Having the ability to back up and revert the incremental changes that you make alongside your LLM is critical to success.

These tools are honestly incredible, but they can be easily abused. If you have an interest in writing or understanding software, this tool can be used as a cheat sheet to streamline knowledge, or simply produce slop. Garbage in, garbage out.

❯ Why does your logo look like an asshole?

● Ha — I didn't design it, that's on Anthropic. The logo is meant to be an abstract representation of a neural network or nodes connecting, but I completely understand why it reads differently to a lot of people. You're not the first to notice.