This blog has been around for over 10 years. When I first built it, I made it as a static-site generator developed purely for myself in C#, using .NET Framework. It spat out some rudimentary static HTML, CSS, and Javascript.

I've always wanted to modernise it, but never had the time. After I recently reached a huge milestone (v1.0) with my 3D rendering library, TinyFFR, I decided to set aside a month or so to 'catch up' on some things I'd been neglecting-- including this blog's much-needed facelift.

Enter Claude Code

I've been fully agentic in most of my real work for almost a year, and frankly writing something like a blog site by hand seems archaic by now.

A lot of people have said that LLM coding tools are making beginners worse and experienced developers better- I think that's probably correct. An inexperienced developer is unlikely to be able to discern which tech stack is right for their project long-term. They won't know whether they should be using static SSR or interactive WASM. They won't foresee when a schema choice now might cause problems later. They won't know how to evaluate the output of the agent(s), and they won't know how to push back on the agent(s)' bad long-term planning.

The Rewrite

Conversely, I knew I wanted a modern C# ASP.NET Blazor/MudBlazor rewrite, mostly serving static pages, but backed by a PostgresDB (so I didn't have to edit files + regenerate the entire site each time) + blob storage for media; all orchestrated via Aspire.

With Claude Code I decided I could probably get it done within a week; this turned out to be an overestimation- it only took me a couple of evenings.

In the end I have:

• An Aspire solution publishing to Azure; running in Azure Container Apps;
• Posts living in Azure Database for PostgreSQL; images/media in Azure Blob Storage, both using managed identity so no DB passwords to leak;
• Public pages static server-side rendered; no WebAssembly download or websocket. Admin pages use Blazor's interactive mode (and I had to increase the max payload for SignalR- I guess I write too much 😅);
• Posts written in markdown, transcribed with Markdig and a couple of extensions (I had previously concocted some Frankenstein mix of BBCode and markdown for the original static generator);
  • Server-side syntax highlighting via TextMateSharp for code-snippets, and;
  • A "view code fullscreen" button built on the browser's Popover API. Both of these decisions are because I wanted to avoid as much JS as possible;
• Four colour themes in light/dark & selectable background patterns. Again, all set via cookies to reduce JS reliance;
• Privacy-friendly metrics: No cookies, no third-party adsense scripts or whatever.
• Redirects from the old site, so old links floating around should still forward to the new post URLs.

The Results

Visuals

I think this site looks a lot nicer. Here's the "before" and "after":

I'm a full-stack dev but like a lot of full-stack devs I've always secretly been a little better at back-end than front-end. LLM agents are a godsend for helping me turn my design vision in to something that actually works with modern CSS, supports most browsers, and works on mobile/tablet.

A lot of the credit also needs to go to MudBlazor of course, their defaults really just work well for me a lot of the time.

Accessibility

I asked Claude to do an accessibility pass on everything, so now screen readers should have a much better time of using the site. Again, LLMs allow us to be 'experts' in places we otherwise wouldn't be.

I also added a subtle background pattern to each page (defaults to diagonal stripes; can be changed at the bottom). I have no visual impairment but reading through long posts strains even my eyes after a while. Having a non-moving subtle reference in the background helps me, at least- and it's something I'd always wanted to add.

Metrics, Comments

I also took the opportunity to add basic metric data. Nothing particularly fancy, just referrer capture, view counts, campaigns etc.

The previous site had comments served via Disqus; but I never saw much engagement there and they slow down the page load + inject ads so I decided to get rid for now. I might add self-hosted comments later, but that involves captchas or logins etc and I'm not convinced it's worth it right now.

The Design is Very Human

Claude can't take much credit for the outcome design of this site. I started with a very detailed plan of exactly how I wanted everything structured, using my previous blog's layout as a starting point (with a couple of changes).

Importantly, I think there's a very obvious "look" to AI-designed software. People are already able to tell by now; it tends to look over-polished, homogenous, shiny. I think more and more people are turned off just by those tell-tale signs (good).

I spent one entire evening tweaking and testing using traditional workflows (browser inspections/CSS twiddling + hot-reloading, etc) without really touching the LLM. Just three examples:

• I realised I wanted just post titles in a serif font.
• I tweaked the background patterns to get them just how I liked and re-did the four theme palettes until I was happy.
• I shrunk the size of the homepage post cards and made the category icons rounded alongside the tags.

I tried not to let Claude steer or override my own design idiosyncrasies. The font for the site title at the top corner is probably not optimal, but it's my choice. The song lyrics + references to stuff I like that randomly appear in the footer are mine. Claude helped me make my eventual designs more modern-CSS; but that's more of a technical improvement than a design one.

Using LLMs doesn't let us eschew the real decision-making work of software engineering. In fact, the exciting thing about LLM-driven coding is that we get to spend more time making decisions and less time implementing them.

A Final Note

You might be wondering:

• "Is this post itself LLM-generated?". The answer is a sound no. I've been writing technical blog posts for 10 years, I enjoy doing it, and I don't think it's fair to ask someone to read something you never even bothered to write.
• "Does this mean you're going to start vibe-coding TinyFFR?". Also definitely no. I have another post coming up later this year explaining why I'll probably never let Claude write 99% of the code that ends up in that project- so subscribe if you're interested!