I am useless at frontend. Completely useless – that is the main reason I started using WordPress all those years ago for my website creation needs. WordPress being a free and open-source Content Management System (CMS) had the added benefit of it taking care of backend stuff as well.
For someone who wants to tweak functionality and actually work with the source code, WordPress is unfortunately a nightmare. With all the plugins, themes and the interaction between these WordPress became more and more difficult to work with. It came to the point where load times as well as functionality suffered, something that affected my side-project TailSense especially.
A migration was needed for TailSense, but as almost all of my WordPress based sites are hobby projects there was no case for paying frontend developers to do a migration to a better solution. What a great happenstance then, that when I started planning for the migration of TailSense, Claude released Claude Code via Command Code Interface (CLI)!
What felt like a daunting and impossible task suddenly became possible; it did take much more time than I thought it would, but I learned a lot along the way about how to work with, test and evaluate LLM generated code, and how to deploy safely using GitHub. And much more – a longer review of how to work with MLOps, LLMOps and AIOps is forthcoming; this article will focus on the TailSense migration and learnings along the way of working with Claude Code CLI.
What is TailSense again?
TailSense is a project I started sometime around 2020/2021-ish. The thought initially was to create a pet app, then a website for price comparison. I had recently adopted two house cats, and wanted to create a project around the sphere of cats and pets. I stopped developing the site after a while, as I found WordPress to be suboptimal, especially the theme I had chosen which took unacceptable amount of time to load.
Planning
The first phase involved research, and a fair share of trial and error. Which tech stack should I use? How do you take the daunting task of creating a price comparison engine including machine learning in a language you don’t know using Vibe Coding? How do you prompt an LLM correctly to give you design drafts? How do you carry out testing and quality assurance if you don’t have hands-on QA/tester experience?
I learned rather quickly the importance of having a CLAUDE.md file for context and a PLAN.md as a roadmap containing goals and list of completed phases.
I set up a total of 10 goals, encompassing re-creating the price comparison engine, re-design and testing.
I also realized I (at least now as I learn how to “co-operate” with Claude Code) I needed a Human-as-a-judge testing phase prior to approval, something that weeded out certain edge cases and issues. The automatic tests and unit tests was something I left for Claude Code to carry out, and it was added to the CLAUDE.md file.
Tech stack
Quite honestly, the choice of tech stack was not optimal but one taken out of necessity; I would have preferred a few JavaScript or php files and zero libraries, but as mentioned at the start of the article I don’t have frontend experience, so I went to ChatGPT and asked for a comprehensive research report on “best practice” regarding frond-end development. I added information about TailSense to the prompt and asked for a chapter indicating which tech stack would best fitting to migrate the site from WordPress.
After a few iterations, a final research paper with a migration plan was born and the tech stack I chose in the end was – to no surprise of any one – React and Next.js. Why? I needed speed, mobile friendliness, something the LLMs had been trained on extensively and something I can tweak myself. Honestly, I could have just as well gone with say TypeScript. I was rather tech stack neutral, when I started the migration journey – I was open to anything that was not a messy mix of plugins and themes in a CMS.
Failures
So eh, yeah. Claude Code did annihilate my database once, and created files/made edits I had not ask for. These issues where 100% on me and where due to bad prompting and the lack of guiding docs. I added the files DATABASE-SAFETY.md, FILE-SAFETY.md and INCIDENTS.md with rulesets indicating what is allowed and not, and incidents that would be used for avoiding certain types of and duplication of solutions (e.g. avoid loops where the LLM would suggest using a bad solution that had been tried with a bad outcome).
Key takeaways
The key take-away is … there aren’t really any. Traditional guides on how to work with new systems or frameworks is not really applicable to tools like Claude Code, agentic coding, Vibe Coding or whatever you wish to call it. Trial and error is key, and having a basis as a coder helps tons (I know Python, SQL, a wee bit of HTML and CSS, and Kotlin) and knowing the basics of algorithm theory.
Prompting skills and docs indicating rule sets, context, architecture etc helps.
Keeping logs daily as well as committing to Git are crucial; shit happens regularly, and both you and your digital coding buddy need to keep track of what has happened and old commits to fall back to.
The migration may be done, but as with everything, there is always something to tweak; I will updating the structure and design of some articles, and new functionality, create documentation and delete some legacy test files and scripts from Github. To be continued.
Comments are closed