This post is based on a talk I gave at the WP Meetup Vienna in January 2026
When I give talks about WordPress workflows, I usually start with a simple question: Who here still sets up WordPress sites manually? And almost every time, quite a few people raise their hands. That’s not surprising. It’s how most of us learned it, and for a long time, I worked exactly the same way.
The way I used to work
Until around 2019, my workflow looked pretty standard.
I installed WordPress, opened wp-config.php, adjusted a few settings, configured permalinks, created users, installed plugins, and set everything up manually. It worked, and there was nothing obviously wrong with it.
But over time, I started noticing a pattern.
Even though the steps were always similar, I never did them exactly the same way twice. Sometimes I skipped something. Sometimes I configured something slightly differently. Nothing dramatic, but enough to introduce inconsistencies.
And when you do this across many projects, those small differences start to add up.
The moment things changed
I was introduced to WP-CLI during a webinar by Alain Schlesser. He demonstrated how to install and configure WordPress entirely from the command line. No clicking through the admin, no UI at all, just commands. What stuck with me wasn’t that it looked clever, but that it made the whole process predictable.
Once you describe a process as a set of commands, you can repeat it exactly. That was the real shift for me.
Why many people still avoid it
When I started sharing WP-CLI with others, I noticed something that hasn’t really changed since.
There are people who don’t know it, and there are people who know it but avoid it.
The second group is much larger than you might expect. In most cases, it comes down to the terminal. It feels unfamiliar, and people assume it’s more complex than it actually is.
I saw this very clearly in workshops and at WordCamps. Even experienced developers often preferred to stay in the UI, even for tasks that could be automated in seconds.
What I learned from that is simple: Automation in WordPress does not have to be complicated. You don’t need to change everything at once. You can start with a single command and build from there.
The actual problem is not complexity
Setting up a WordPress site is not difficult. The individual steps are straightforward. The problem is repetition. You install WordPress, configure it, install your usual plugins, adjust some settings, and then you do the same thing again for the next project.
Over time, this leads to three things:
- inconsistent setups
- small configuration mistakes
- unnecessary time spent on repetitive work
None of this feels critical in the moment, but it becomes very noticeable when you look at your workflow as a whole.
A simple way to think about it
On my Mac, I can install an application like Slack by downloading it manually and clicking through the installer. Or I can open the terminal and run a single command with Homebrew. Both approaches lead to the same result. The difference is that one of them is faster, repeatable, and easy to reuse on another machine.
We already trust this approach when it comes to our local environment. We just tend to stop using it once we get to WordPress.
What WP-CLI actually enables
For me, it started with simple things.
Installing WordPress from the command line. Installing plugins without opening the admin. Setting options directly. At some point, I started combining these commands into small scripts. That’s when it became really useful.
Instead of running individual commands, I could run one script and get a complete project setup. The structure was always the same, the defaults were always the same, and the result was predictable.
That consistency is the real value.
Why this matters in a team
This becomes even more important when you work with other people. If you tell someone to “install a form plugin”, you will likely get different results depending on who does it. Different plugins, different configurations, different assumptions. A script removes that ambiguity. It defines exactly how things should be set up.
In that sense, automation is also a form of documentation.
It’s not just about new projects
The benefits are even more obvious when you look at maintenance and support work. With WP-CLI, you can update plugins, themes, and core without logging into the site. You can check for available updates, flush rewrite rules, repair the database, or run search and replace operations safely.
More importantly, you can do this across multiple sites. Using aliases, you can target a specific environment or even run the same command across a group of sites. That makes repetitive maintenance tasks much more manageable.
Where it really changed my work: support
Most of my day-to-day work is in technical support, and this is where WP-CLI has the biggest impact. A lot of common issues involve things like broken URLs after migrations, leftover staging domains, incorrect option values, or missing users.
Instead of navigating through the admin interface, I can inspect and modify these things directly. I can enable debugging constants without editing files manually. I can fix URLs properly, including serialized data. I can create users on a local copy without relying on the client.
And in some cases, I can run small pieces of PHP directly to inspect the system in ways the UI simply doesn’t allow. This turns debugging into a much more structured process.
Sandboxes instead of assumptions
One of the biggest improvements in my workflow is how I handle debugging environments. Instead of working directly on a client site, I spin up a local or sandbox environment and reproduce the issue there.
With a bit of automation, this takes seconds instead of minutes. The difference in outcome is significant. Instead of guessing what might be wrong, I can isolate the problem and describe it precisely. That makes it easier to fix, and much easier to communicate to other developers.
Testing things that are otherwise painful
Some issues only appear under very specific conditions. For example, certain WooCommerce features only trigger after a specific number of orders. You could try to reproduce that manually, or you can generate the required data using the CLI and test it properly. That kind of workflow is where automation really pays off.
What changed recently: AI
Over the past year, another layer has been added to this.
We are moving from writing scripts manually to generating them more efficiently with AI tools.
Tools like Cursor, Claude, or Replit don’t replace WP-CLI, but they make it easier to build on top of it. You can go from an idea to a working script or prototype much faster than before.
AI is not a replacement for understanding
It’s important to keep expectations realistic. AI does not replace experience or understanding. You still need to know what you are trying to achieve and how WordPress behaves in different situations.
What AI does is help you get there faster. It can assist with debugging, suggest approaches, or help you write code more efficiently. But the responsibility for the outcome still lies with you.
From scripts to small tools
One interesting development is how easy it has become to build small internal tools. During my talk, I showed a simple interface that generates WP-CLI scripts based on user input. The entire prototype was created through prompting.
It’s not perfect, but it’s useful. And that’s often enough. These tools don’t need to be polished products. They just need to solve a real problem in your workflow.
What’s happening in WordPress
There are also some interesting developments within the WordPress ecosystem itself. The formation of the WordPress AI Team and projects like the Abilities API or the Model Context Protocol show that there is a clear focus on building proper foundations.
The goal is not to add AI features everywhere, but to define how AI can interact with WordPress in a structured and secure way. That is a much more sustainable approach.
Where this is going
We are still early in this transition, but the direction is clear. WP-CLI gave us a solid foundation for automation. Scripts made workflows repeatable. AI is starting to bridge the gap between intention and execution. The combination of these elements will shape how we work with WordPress in the coming years.
Final thought
Automation is often misunderstood as a way to avoid work. In reality, it’s about removing the parts of your work that don’t require thinking. Setting up the same system over and over again is not where your value is. Understanding problems, debugging complex issues, and making good decisions is.
WP-CLI is not the end goal. It’s the starting point. What you build on top of it is up to you.
Update: May 2026
Since this talk in January, things have moved quite a bit. Especially around how we actually use AI in day-to-day development.
What I briefly showed at WordCamp Europe as “describe what you need” is no longer a preview. The starting point for a new project or an automation is often just a chat window.
We give AI tools direct access to parts of our environment. Filesystem access, repositories, and even the ability to run commands. Tools like Claude Code, Cursor, or OpenClaw are typically used as coding agents. They don’t just suggest code, they write, modify, and iterate on it directly inside your project.
At the same time, this doesn’t mean giving up control. When it comes to running commands, especially CLI commands, you usually review and confirm them before they are executed, depending on your setup. That step is important. It keeps you in control while still benefiting from the speed these tools provide.
On the WordPress side, we’re starting to see early efforts toward a more structured approach. Instead of ad-hoc integrations, the focus is shifting toward defining clear capabilities and making them accessible to AI tools in a controlled way.
You can already see this thinking in projects like the official Agent Skills repository:
https://github.com/WordPress/agent-skills
These “skills” are structured instructions and workflows that guide AI tools toward correct patterns when working with WordPress. In parallel, MCP (Model Context Protocol) is gaining traction as a way to standardize how AI systems interact with platforms like WordPress.
Because right now, a lot of AI workflows feel powerful, but also a bit uncontrolled. Once you give an agent access to your filesystem or your codebase, you quickly realize how much trust is involved.
WP-CLI gave us automation. Scripts made it repeatable. Now we’re entering a phase where AI can operate on top of that, but the real challenge becomes defining boundaries.
It’s still early, but the direction is clear. Not more AI features, but better structure around how AI interacts with our systems.