David Yates.About ten years ago, I looked at the Ghost blogging platform that originally powered this website and asked myself why. Why was I running a dynamic application on server hardware to serve a website that was completely non-interactive to everyone but me? Why was it necessary that every time someone visited a page on the site, server-side code would execute to pull content from a database and slot it into an HTML template, dynamically assembling a page that was identical to the one seen by the last visitor and would be identical to the one seen by the next visitor?1
The only answer was that I liked having the user-friendly admin panel and post editor that was accessible from my browser. Ghost even had this neat feature where you could append /edit on the end of a URL and, if you were logged in, this would immediately take you to the editor for that post.
Then a new version of Ghost came out and made a UI change to the editor that I found really annoying and that was enough to get me to move to a Hugo-generated static site.
My new site architecture gave me more theming and structural flexibility, cheaper hosting and less maintenance, all for the price of losing my online editing interface. Being a technical guy, I was pretty happy to just write my posts locally in Vim with hugo server for preview, and make the occasional edit through GitHub’s web interface when that wasn’t available.
From then on, I became an advocate for using static site generators to host blogs, marketing sites, documentation and other sites that don’t maintain significant user state. Where specific points of interactivity are needed – say, a contact form – that can be handled with a single-purpose hosted endpoint; it doesn’t require bolting on a whole application server and database. You can, of course, go too far with this – I’ve spoken before about the pitfalls of platforms like Firebase that encourage building highly interactive apps without server-side code by letting clients directly access the database.
But if your website mostly serves the same pages to everyone, you’ll probably be fine with pre-generated HTML. The trouble comes in when people need to edit it.
Programmers love writing Markdown in text files. We all think it’s simple and intuitive, but that’s because we’re always thinking about the parser.2 We’re also very happy to track our changes with Git. Most ordinary users are not going to use their favourite text editor to write content in Markdown and make commits to the site repository.
So you’re gonna need a WYSIWYG editor and probably an admin panel, i.e. a CMS. The default choice is WordPress: a dynamic web application that uses server-side PHP and a database to store and manage content, settings and all the machinery around them. Ghost follows the same model.
There are other approaches. A headless CMS can give you a WordPress-style editing experience while keeping the public website static. In my experience, most headless CMSes tend to lack important features, not provide a polished editing experience, require extensive edits to your templates, or impose lock-in by making the CMS database rather than the site repository the single source of truth for content.3
Enter the coding agent.
Some of the earliest impressive results from coding agents were static HTML pages, and they are just as capable of building with static site generators, which give you all the benefits of working with static HTML pages along with the structure and consistency enabled by separating content (Markdown files) from presentation (HTML templates). There have always been advocates for maintaining your site by just uploading a bespoke, standalone HTML page whenever you write something new. Coding agents make this even easier, but I’m a stickler for consistency and pages that link to each other.
Using a coding agent not only allows you to harness the many speed, flexibility and security benefits of static site generators, but also means that you can author your site content however you want and let the agent figure out how to import it. While I’m perfectly happy to author everything by editing Markdown files in Vim, others may prefer using Google Docs or MS Word, or maybe they like to write everything out by hand in a notebook and take pictures of it with their phone. Any of those inputs can now be fairly seamlessly integrated into a static site by a coding agent, without the user having to put stars for bold.
And if the workflow of writing content in a Google Doc and then prompting an agent to import it is a little too ad-hoc, you can instead use the same agent to vibe-code a tool for the purpose – a headless CMS, even.3 The structure of, for example, a Hugo codebase, enables agents to safely and efficiently edit and build sensible tools for it.
To my mind, this means that a lot of websites can stand to be radically simplified. Get rid of your dynamic app logic and your database, replace the whole thing with static HTML files, get a result that’s cheaper, faster and more secure, without sacrificing ease of use. Coding agents free us from the need to anticipate every action a user might want to take when editing a website and pre-build a GUI for it.
This applies to more than just websites.
dwm, a tiling window manager and part of the Suckless project, is explicitly designed around the idea that the most elegant way to configure software is to change its source code.
↗dwm is customized through editing its source code, which makes it extremely fast and secure - it does not process any input data which isn’t known at compile time, except window titles and status text read from the root window’s name. You don’t have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C, to customize it for your needs: you only have to learn C (at least in order to edit the header file).
Differences, dwm.suckless.org
Before coding agents, this sort of thing was pure programmer asceticism. Historically, I’ve always preferred window managers that bloat their codebases with the ability to read config files. But editing the source is way lower cost now – I am currently running a slightly modified version of Niri because I needed a small feature it didn’t contain. Before coding agents, I wouldn’t have bothered.
Most software probably still needs configuration files, but because an agent can make both configuration and code changes, the case for permanently bolting custom editing interfaces onto software has weakened. Architectures that separate the editor from the thing being edited – say, a static site with a headless CMS – become more attractive. Where editing interfaces aren’t replaced by agents entirely, they can instead be bespoke, external and, in many cases, ephemeral tools.
We hear a lot about vibe-coding slop cannons and the pitfalls of software that grows at the speed of prompting, but we can also use coding agents to shrink software. Replacing a WordPress site with a Hugo site is one way – there are many others.
Coding agents allow us to create a lot of software quickly. What’s even more revolutionary, though, is that they allow us to throw a bunch of it away.
For the sake of argument, we’re going to ignore the concept of caching. ↩︎
Sometime before Slack introduced WYSIWYG input, I recall being subjected to a passionate rant from a project manager about how Slack was “a coding tool” because “you need to put stars for bold”. On another occasion, I recall watching, bemused, as a friend carefully copy-pasted and edited my formatted text in a shared Markdown doc instead of just typing the asterisks himself. The people yearn for a button with a B on it. ↩︎