AI in operations is not a chatbot — this is what it is
When you mention "AI in operations" to a business owner, most of them think of a chatbot in the corner of the website or text written by a robot. That is also why the term has become so worn out: it has been used about everything and nothing.
But the real value of AI in operations and development doesn't lie in visible features on the site. It lies in all the invisible routine work behind it — scanning, patching, testing, verifying, documenting. That exact work used to be the reason ongoing operations were expensive. Here is what it means in practice in my working week, task by task.
The chatbot is the least interesting part of the story
Let's get the myth out of the way first. A chatbot on the website doesn't change your risk, your security or your speed when something breaks. What does change them are the processes running behind the site:
- When do you discover a vulnerability — the same day, or at the annual check?
- How long does it take from an error being spotted until the root cause is found and fixed?
- Do you even know whether the last release actually went live?
That is where the difference between old and new operations lies. And that is where AI has changed the numbers.
In practice 1: Vulnerabilities found the same day — not at the annual check
Most small businesses get their platform checked for vulnerabilities when there are problems, or when a supplier happens to drop by. Automated attacks don't wait for that. The bots scan constantly, and outdated plugins are a well-known way in: WordPress's own documentation warns that a plugin that hasn't been updated since the latest WordPress release may be incompatible, and that only the latest WordPress version is officially supported. See the sources at the bottom.
In my operations work, vulnerability scans run on every single change, not once a year. A concrete example from my own site: when I scanned this website's dependencies on 23 September 2026, the tool found three known vulnerabilities — one image library and two YAML parsers in the build tooling. They were patched the same day, and a new scan on 26 September 2026 found zero known vulnerabilities. It isn't a big number, but it is exactly the kind of finding that would otherwise have sat waiting for the next annual check.
And when major upgrades are due, the release notes are read first, so we know what will break — instead of finding out in production. That is the work that used to require a dedicated operations department. Now it requires one person who has set the system up.
In practice 2: From symptom to root cause in minutes, not weeks
I have written before about a contact form that lost enquiries for months without anyone noticing. The root cause is instructive: the sending library returned errors as a return value instead of throwing an error — and the code didn't check it. The result? The user got a friendly "Thank you for your message", while the enquiry silently disappeared.
Bugs like that aren't nasty because they are advanced. They are dangerous because nothing signals that anything is wrong. The form works, the site works, nobody complains — the leads just never arrive.
The difference in my model is the pace: the symptom is spotted (ideally automatically), the root cause is found by going through the code and the logs, the bug is fixed, and the fix is verified — typically the same day. In the classic model the route is: you might notice something yourself, send an email, the developer looks at it between other projects, an estimate arrives, and time gets booked for later. The expensive part is rarely the typing. It is the waiting.
In practice 3: Releases are verified in the content — not the status code
Here is a trap even professionals fall into: a page can respond with status code 200 and still show old code for days. The server answers politely, but the content is out of date — the cache or the deploy process has swallowed the change.
That is why, after every release, I don't just check that the site responds, but that the content really is the new version: the text, the feature, the fix. "It builds" and "it works" are two different things, and only the second one counts for your business.
It sounds like a small thing. It isn't, the next time it concerns a campaign page that was supposed to be live on Monday morning.
In practice 4: A quality gate on every single change
Every change — small ones too — passes the same gate: code analysis, a formatting check and a full build of the production version. If the gate is red, the change doesn't land. Full stop.
The consequence is that errors are caught before they reach your customers, and that every change can be rolled back precisely if something still trips up. Compare that with the classic situation: "We updated a bit here and a bit there, and now nobody knows what broke."
The gate takes time — that is the honest bill. It isn't free, and that isn't the point either. The point is that it is deterministic: the same check every time, instead of a judgement call that depends on how busy things are. And that recovering from a broken production site costs days and trust.
In practice 5: The boring work actually gets done
Internal links between pages. Metadata that matches the content. Speed checks. Documentation of how things fit together. These are all tasks that come with no visible reward — and which therefore never get done when the bill has to be justified hour by hour.
But that is exactly the work that, over time, separates a website that thrives from one that slowly rots from the inside. With AI in the process, the price of the boring work has fallen so much that it has become a natural part of everyday work instead of something you "get round to when there's time".
What AI can't do — and why that matters
For the sake of completeness: AI can't make decisions on your behalf, say no to bad ideas, know your business's history or carry the responsibility when something has to be deprioritised. The judgement — what matters for your particular business — still sits with a human.
The point is not that AI replaces a technical partner. The point is that AI makes the execution cheap enough for one person's judgement to cover the whole stack — instead of being spread thin across an agency with coordination, meetings and minimum task sizes in between. That is experience, not an average: I can't document a general number of hours, because the starting point varies too much with your setup.
The numbers
The classic model: a project manager coordinates between a frontend developer, a backend developer, DevOps and a security guru. Every hand-off has a minimum size, and the communication between them ends up on the invoice.
My model: one point of contact with the full overview, where AI handles the routine work — scans, tests, troubleshooting, verification — and the human spends their time on what requires judgement. It is the same coverage, and the difference is that there is no coordination line item between every single task.
Concrete prices from my own pricing structure — they are public, so you can do the maths yourself:
- Light (maintenance): DKK 5,000/month — the basics kept running: updates, backups, monitoring.
- Drift+: DKK 10,000/month — more scope, a quarterly report, ongoing improvements.
- Technical partner: DKK 15,000/month — including the CTO work: strategy, architecture, prioritisation, the whole stack.
The full structure, from Micro to the complete solution, is on the pricing and packages page.
One technical owner when the tasks are scattered everywhere
Technical partner from DKK 15,000/month: prioritisation, architecture and the whole stack with one person — so you don't coordinate between four suppliers.
Sources
The specific claims about WordPress security in this article are taken from WordPress's own documentation and were checked on 26 September 2026:
- Manage Plugins — compatibility when a plugin hasn't been updated since the latest WordPress release; back up before updating; delete unused plugins
- WordPress Security — only the latest WordPress version is officially supported; fixes for older versions are provided as a courtesy
The security figure in the article comes from my own dependency scan of this site on 23 and 26 September 2026 — not from a client case. The prices are Mahope's own public prices: Light DKK 5,000, Drift+ DKK 10,000 and Technical partner DKK 15,000/month, with the full structure on the pricing and packages page.
