Every other post on LinkedIn these days seems to be along the lines of “WordPress is dead – I vibe-coded a website in 10 minutes”. Rather than actually respond to any of those engagement-bait posts, I wanted to write about it.
Are we really saying “Vibe-coding”?
Firstly, I promise not to use the phrase “vibe-coding” again – it gives me the Ick (as does the phrase “gives me the Ick”). “Agent-assisted” is more descriptive, accurate and less buzz-wordy. But the debate can’t be reduced to simply CMS vs agent-assisted coding, because nearly everything is built with agent assistance right now, while token costs are heavily subsidised, and we collectively realise that almost everything is quicker and easier if you don’t have to physically type out lines of code.
Agent-assistance can make light and speedy work of just about any web-development task. It can be used for building a static website, building something using a framework that uses static markdown files as a data store, building a theme or plugin for WordPress, or designing or building an entire CMS-driven site (trying not to mention WordPress twice in the same sentence, here, but you know I’m talking about WordPress).
It’s more a debate about using a CMS vs not using a CMS
So it comes back to the debate about whether you need a CMS, or would a static website suffice. This isn’t a new debate by any means. I built and published my first static website in 1998 and even then was trying to work out how to use a CGI script and a form to enable the site to be updated by a non-technical user. In the end I left that one static, as the hosting got complicated and expensive if it did anything more than serve static HTML files. The site also only had a handful of pages, so suited a static site (I’ll come back to that).
In my early freelance days I had a customer ask me to teach them how to use Dreamweaver, so they could update their own content, WYSIWYG-style but also to redesign their own site, or at least make layout changes and add new templates. In the early 00’s Macromedia launched different variations of Dreamweaver that allowed remote collaboration. The need for website content management was there, but there was no clear path for what form that would take.
At my first agency job, we had clients wanting to update their site content themselves, we would take an existing static website, convert the HTML files to classic asp files then add asp tags to render text content pulled from a Microsoft Access database (I know! It was last millennium). Then we added some password-protected forms to update the database, and we called it a “Content Admin System”.
So now we had taken a perfectly scalable, secure and fast static HTML site and made it slower, less secure and less capable of handling heavy traffic. We solved some of the issues caused by our terrible architecture decisions by having the “CAS” output a static HTML site which could then be hosted separately, decoupling the admin from the Front-end.
But the customers were happy, even if they literally never used it and just asked us via phone or email to make the content changes for them.
Later versions of that architecture were used for some fairly “large” sites – multilingual corporate websites, with multiple editors writing and maintaining site content from different locations around the world, a built-in search on the site content, job listings, job application forms, and at that point, this couldn’t have been a static website, even if the front-end of the site was served as mostly static content.
The debate wasn’t whether should we use a CMS, but should we really be using our own CMS
As most agencies were now building their own Content Management Systems – sometimes more than one codebase existing within the same agency – proprietary and open source systems started to emerge. I’ve forgotten the names of the proprietary systems, because the licence fees were usually way too high and unsustainable for the kind of projects we were doing.
Open source contenders started to appear, WordPress of course, which was very much intended as a blogging tool at that point, though could be used to build any kind of website. I also spent several years working exclusively with Plone – something that open-source, with a fantastic community behind it, and very much a CMS rather than a blogging tool.
In later years, coming into an agency as a freelancer to find that they were running five different systems, plus maintaining some of their self-built creations with zero documentation from two years previously, where the developers who built them had long-ago moved on.
For my own journey, standardising on WordPress was partly about consistency – I had used it over the years for several projects, but it was when I joined an agency as lead developer and they were only running two different systems, one of them being WordPress with ACF, which ticked all of the boxes for what I needed out of a CMS:
- Generally – an open-source Content Management System, that lives on a server, with all the usual features you’d expect – user management, roles and capabilities, publishing states, search, a theming system, a plugin system, an active community improving it.
- Content Schema for pages, that persists to the filesystem so it can be version controlled (provided by ACF, not natively in WordPress – there’s a future post in my head about that)
By standardising on WordPress, I was also able to focus on building expertise in running it optimally, rather then jumping from one system to another in search of shiny things, but only scratching the surface.
OK thanks for the history lesson, but why shouldn’t I use an agent to build and maintain a static website?
There’s some cases where a static website makes perfect sense – but I’d ask two main questions before deciding to go that route:
- Who is going to maintain and update it (read as “who is going to be prompting an agent to maintain it”) – are they happy with the secrets config needed for the hosting, so they don’t leak them? Are they happy with where the static files are stored on their computer? Do they know how to preview markdown files so they can see what the formatting looks like before publishing? Are they happy to run a local server on their machine to preview changes before publishing? Will they need to share editing duties with other people?
- How big is the site? A few pages? Hundreds of pages? Hundreds of Thousands of pages? Millions maybe? And does the site need to be multilingual so many different versions of each of those pages also need to exist?
- Does the website need dynamic features like a shopping cart, Job application handling, a liveblog? Static pages can live alongside dynamic features of course.
If none of the points above in (1) seem like an issue, it may be that you are a developer, or at least developer-minded. It doesn’t matter whether you have an agent loaded with free Tokens to handle all of those for you – you still need to know what to ask. I’m not going to put a number on (2), but there would be a point where building out a large number of pages each time you change a template, or sharing a GitHub repo full of markdown files to someone who has never used GitHub before and asking them to edit something, where you might think “am I doing this right”?
For the record I love static sites – the security, speed, efficiency and lack of complications. I’ve experimented over the years with different approaches, including the dynamic website with static content source” approach, but if I decided I wanted a static site right now, I’d probably have an agent run up a local WordPress site, and then use one of the many WordPress to static generators out there (after asking Claude: “Which one I should use, or should I bake my own?”).