Why VS Code and AI Replaced WordPress in My Workflow

Five months ago, I opened VS Code to change one line of CSS on my site. Today, WordPress is gone from my workflow. I did not quit it on principle, or because I suddenly became a framework evangelist. I stopped using it because the shortest path from an idea to a working page has changed.

For years, the web publishing deal was simple. If you wanted speed without writing everything yourself, you accepted a dashboard, a theme system, a plugin marketplace, and a certain amount of quiet suffering. That bargain made sense. WordPress turned publishing into something millions of people could actually do, and it earned its dominance. It also trained us to think that websites needed a control panel sitting between the creator and the code.

That assumption is starting to break.

The editor is becoming the place where the site actually lives

The moment that made this obvious was embarrassingly small. I needed to add a testimonials section to my site, with a responsive carousel that matched the existing design. The old reflex was automatic: open WordPress, search for the right plugin, compare screenshots, install something that almost fits, then wrestle with settings and CSS until the seams become less visible.

Anyone who has done this knows the calendar lie involved. It sounds like a two-hour task. It becomes an afternoon. You spend half the time adapting yourself to the plugin author's assumptions, and the other half undoing them.

Out of curiosity, I tried the same job inside VS Code. I asked the built-in AI assistant to add a testimonials carousel, make it responsive, and integrate it with the current visual language. It scanned the project, saw how the site was structured, and generated a component that fit the actual codebase sitting in front of it. Three minutes later, I had something I could ship.

The speed mattered, but that was not the real shock. The real shock was that I did not have to translate my intent into the grammar of a CMS. I described the outcome I wanted, and the editor handled the implementation details inside my own project. That feels very different from faster development. It feels like the interface itself has moved.

A CMS made of files, prompts, and version history

A week later, I pushed it further. I wanted a blog workflow with drafts, previews, and an easy publishing path. WordPress has all of that, of course, but it comes with its own model of content, its own admin layer, its own database, and its own way of storing everything. You gain convenience, and you also inherit a worldview.

Inside VS Code with AI, I asked for something much narrower and more specific: draft posts in separate Markdown files, local preview, version tracking through Git, and deployment to Vercel. The assistant scaffolded the content structure, wired the draft logic, and set up the preview behavior without insisting that I adopt a giant general-purpose system.

That stack behaves like a CMS even though it does not look like one. Content lives in files. Drafts are just drafts. Version history is already there because Git exists. Preview is local and instant. Publishing is a commit and a push. I do not need a database for a site that mostly serves pages, and I do not need an admin panel just to change text on a page.

The important part is not that everyone should now worship Markdown and static deployment. The important part is that the publishing layer can now be assembled on demand, from the actual needs of a project, in the moment those needs appear. That is new. Traditional CMS products were built around predefined boxes. AI-assisted editors let you cut the box after you know what shape the object has.

For small sites, personal publications, product pages, landing pages, portfolios, and a surprising number of business sites, that is more than enough. In many cases, it is cleaner, cheaper, and easier to reason about than the old stack. If something breaks, I can inspect the code directly instead of spelunking through plugins like I am debugging a haunted house.

SaaS builders are about to lose their easiest argument

This is where the pressure spreads beyond WordPress. Framer, Squarespace, Wix, Webflow, Shopify apps, all of them sell some version of the same promise: you do not need to build this yourself because our interface makes the hard parts manageable. That promise still has value. Plenty of people want support, hosting, templates, analytics, forms, and billing all in one place.

But the usability comparison is changing fast. When I can write “move this section below the hero, make the cards tighter, add search with autocomplete, keep the mobile layout intact” and get a usable result in my own codebase, the old GUI advantage starts to look thinner than it did a year ago.

The real weakness shows up when you want to leave the happy path. A custom search experience on a site builder often leads to paid integrations, external APIs, or a wall you cannot walk through. A specialized booking flow in an ecommerce platform quickly becomes another monthly plugin subscription with its own quirks, limits, and support tickets. AI-assisted code generation changes that equation because the custom feature is no longer an exceptional event requiring a mini procurement process. It becomes another request inside the editor.

That does not mean these companies vanish overnight. Many customers are buying risk transfer as much as convenience. They want someone else responsible for uptime, security patches, and compliance. Teams with nontechnical editors may still prefer structured interfaces over repositories and pull requests. Enterprises love accountable vendors. None of that disappears because a model can write React.

What changes is pricing power. The moment a large share of websites can be built and maintained through AI over commodity hosting, the premium charged for boxed simplicity becomes harder to defend. If the cheaper route is also more flexible, then ease of use stops being a moat and starts becoming marketing nostalgia.

Design is still the weak spot, and it matters more than people admit

The current catch is obvious the minute you look at many AI-generated sites. The code can be solid. The visuals often feel like they were approved by a committee of polite engineers. You ask for something modern and minimal, and you get a lot of white space, rounded rectangles, gray borders, and the vague energy of a startup that definitely says “seamless” on its homepage.

This gap matters because web design is not decoration sitting on top of functionality. It is how information gains hierarchy, trust, mood, and momentum. A good designer is making hundreds of small decisions about spacing, rhythm, contrast, motion, density, and the way a brand should feel when someone lands on a page for six seconds. Current coding assistants can imitate patterns. They still struggle with taste.

I do not think that gap stays open for long. The path is pretty visible. Models are becoming more multimodal, more specialized, and better at evaluating their own output. Mixture-of-experts approaches are part of that story. Instead of one giant model doing everything equally well, you route parts of the task to specialized systems: layout judgment, accessibility, responsive behavior, component logic, brand consistency, code quality. In plain English, the machine stops being a general intern and starts behaving more like a small team.

The timeline is hard to call precisely, and the web is littered with people who were six months away for several years. Still, it is easy to imagine a near future where the AI does not merely generate code from a text description. It forms an internal visual representation, compares options, notices alignment problems, understands why a certain spacing feels off, and ships something far closer to professional output. When that happens, a huge part of templated web design gets squeezed from both sides.

The skill that grows in value is judgment

This shift does not eliminate developers, designers, or agencies. It changes where their leverage sits. Developers spend less time grinding through repetitive implementation and more time shaping systems, reviewing generated code, and defining constraints that keep a project coherent. Designers spend less time moving pixels by hand and more time setting taste, creating reusable visual logic, and protecting brand quality from plausible mediocrity. Agencies have to sell judgment, strategy, and domain understanding, because “we can customize a template” is turning into a weak pitch.

For nontechnical creators, the barrier is not disappearing so much as moving. You can get much further without knowing syntax, but you still need to know what you are asking for. Precision becomes a creative skill. So does editing. If the machine can generate ten versions instantly, the scarce resource is your ability to recognize which version deserves to survive.

That is a deeper change than AI writes code now. It shifts creation away from manipulating tools and toward specifying intent. The people who do well in that world are not necessarily the ones with the most commands memorized. They are the ones who can describe a system clearly, spot weak output quickly, and keep the whole thing pointed at a coherent goal.

Why WordPress suddenly feels heavier than it used to

Seen from that angle, WordPress starts to feel like a product from a different era of the web. It assumes a persistent admin layer, a database-backed content model, theme conventions, plugin discovery, and a long tail of compatibility concerns. For big editorial organizations and certain client scenarios, that machinery still solves real problems. It gives structure, permissions, workflows, and a familiar environment to people who do not want to touch code.

For my site, and for many sites like it, that machinery now feels oversized. I do not want an admin panel between me and my content. I do not want to negotiate with a plugin ecosystem every time I add a feature. I do not want the default answer to every custom need to be “install something and hope the updates behave.”

What I want is much simpler. I want to describe a change in natural language, let the editor modify the project with full awareness of the existing code, review the result, and ship it. If a draft needs to stay unpublished, the site should understand that. If I want a new page layout or a custom widget, I should not have to wait for a vendor's roadmap or squeeze my needs through a settings page designed for everyone else.

That is why I left WordPress. I did not replace it with another giant platform. I replaced it with a workflow that keeps getting more personalized every week.

Software is learning the shape of the work

The deepest part of this shift is not about web tooling at all. It is about the direction of software. For a long time, using software meant adapting yourself to its categories. You learned the menu structure, the field names, the plugin conventions, the weird place where the one important option was hidden. Competence meant internalizing the machine's map.

AI-assisted creation flips some of that. The software increasingly meets you at the level of intention. You start with the thing you want to happen, and the machinery figures out more of the route. Sometimes it guesses wrong. Sometimes the output is clumsy. Sometimes it produces a confident mess and you still need to know enough to catch it. Even with those limits, the direction is clear.

That is why this feels bigger than a productivity boost. When the distance between “I want this on my site” and “it is live” collapses, older categories start to look less solid. The dashboard matters less. The plugin market matters less. The distinction between content management and feature development starts to blur, because the same conversational layer can handle both.

Five months ago, I opened VS Code to change one CSS rule. Now it is the place where I plan, write, shape, and publish the site itself. That is not a small upgrade. It is a different relationship between the creator and the medium.