Two questions keep turning up in enquiries. One is some version of “do you use AI?”, asked warily, as though the answer might disqualify me. The other is “shouldn’t this be cheaper now?”, asked hopefully.
Both deserve a straight answer rather than a marketing one, and the industry has settled into two unhelpful camps: people selling AI as a transformation, and people insisting it is rubbish and will pass.
My position sits in neither. I do not believe for a second that these tools are going to take over the jobs of developers and designers. I do believe they are extremely useful, and that the amount of use you get out of them scales almost exactly with how much you already knew before you opened them.
They are professional tools, not a shortcut past the profession
Anyone can use Claude or ChatGPT. That is the point of them, and it is genuinely good. But using one to its full advantage on a real project is a different thing, and it still needs somebody who understands what they are doing.
You can tell an AI tool to build you a website and it will build you a website. What you cannot do, without the fundamentals, is tell whether the thing it built is any good. It may have security holes in it. It may be put together in a way that works today and becomes unmaintainable in a year. It may have picked an approach that is popular rather than correct. And it will tell you, confidently, that this was the best way to do it, because that is what it does.
If you know the fundamentals you catch that. You read the output the way you would read a junior developer’s pull request: mostly fine, occasionally wrong in a way that matters, and you know which is which because you have debugged the consequences before. If you do not know the fundamentals, you have no way of telling the difference, and neither does the tool.
That is the whole of my position. These are tools for professionals rather than tools that let anybody do anything. The floor has not moved much. What has moved is the ceiling, for the people who already knew what they were doing.
So the job now, for developers and designers both, is to know these tools better than everyone else and use them to make the work faster and better: less time on boilerplate, more testing, quicker answers to unfamiliar problems. The mistake is not using them. The mistake is also using them instead of knowing your trade, and clinging to the old way of working out of principle is its own kind of mistake.
Where it genuinely saves time
The wins are real but unglamorous. They cluster around work that is necessary, well understood and boring.
Boilerplate. A plugin header, a settings page skeleton, a custom post type registration, the fortieth Elementor widget class shaped like the previous thirty-nine. I know exactly what this code should look like. Typing it is not skilled work, it is transcription, and having a first version appear so I can shape it is a straightforward saving.
Test data. Two hundred realistic products with varied prices, categories and descriptions, generated in a minute rather than assembled by hand. I used to test layouts against three items and discover the fourteenth broke it in production. That is better practice, not just faster.
First drafts of documentation. Every project should hand over with a document explaining how the custom bits work, and every developer, me included, writes those last and reluctantly. Drafting from the code and then correcting it means clients get documentation that actually exists. The correction is not optional, because the draft will confidently describe what the code appears to do rather than what it does.
Explaining an unfamiliar error. A stack trace from a library I have not touched, a cryptic fatal from a plugin whose source I did not write. A plain-language read on what is likely happening is a decent starting hypothesis. Not the answer. A shortcut past the twenty minutes of orientation that used to come first.
Reading someone else’s undocumented code. The biggest one, and the one I did not expect. A lot of my work is fixing sites other people built, where the previous developer has gone and the theme has a functions file of nine hundred lines with no comments. A summary of what a block of code is trying to achieve gets me oriented faster. I still read it myself before touching anything. But the map arrives sooner.
Notice what those have in common. Every one produces something I can verify quickly, in an area where I already know what right looks like.
Where it actively costs time
The failures are less obvious, which is precisely what makes them expensive.
Code that is subtly wrong but looks right. The main hazard, and worse than code that is obviously broken. Obviously broken code fails immediately and costs you nothing. Subtly wrong code passes a casual read, does the right thing in the case you tested, and fails on the edge case you did not. A capability check that is present but checks the wrong capability. A query that is fine until the table has fifty thousand rows. Escaping applied in the wrong place, so it looks handled and is not. Finding those takes longer than writing the thing myself would have.
Confident answers about APIs that changed. These tools are trained on a snapshot of the world, and WordPress moves. Deprecated functions get recommended with total assurance. Arguments a hook accepted three versions ago are still offered. The confidence of the wrong answer is the problem. When I wrote about the AI features in WordPress core, I checked everything against the dev notes for exactly this reason, and much of what I first had to hand was out of date.
Anything needing knowledge of a specific client’s site. The hard boundary. Why this checkout breaks only on Safari, why this plugin conflicts with that one on this host, why a header change broke a page nobody looks at. All of it depends on the particulars of one installation. That knowledge does not exist in a model. It exists in the person who has worked on the site, and the bulk of what clients pay me for is this category.
Overconfidence on my own part. The sneakiest cost, and worth admitting. Accepting a suggestion because it looks plausible while I am tired is a mistake I have made and now guard against deliberately.
The line that does not move
Whatever helped produce a piece of work, the person who ships it is accountable for it. That is not a slogan, it is the professional standard, and it is the only part of this conversation that genuinely matters.
If I hand you a plugin and it breaks your checkout, “the tool wrote that bit” is not a defence I would accept from anyone else and it is not one I will offer you. It is the same standard I have always applied to code copied from Stack Overflow, a snippet from a colleague, or something I wrote at eleven at night. The source changes. The standard does not.
The practical version: I do not ship code I cannot explain. If I cannot follow why something works, it gets rewritten until I can, because the day it breaks I am the one on the phone.
Does it mean cheaper or faster work?
A bit faster on some things and no cheaper on the things that matter. I would rather say that than pretend otherwise.
What genuinely compresses is the middle of a build. Scaffolding, repetitive components, the fifth variation of a form. On custom plugin work I can get to a working prototype sooner, which means you see something real earlier and can change your mind before the expensive part.
What does not compress is everything else, and everything else is most of it. Working out what you actually need, which is a conversation. Design decisions and the revisions that follow. Testing on real devices with real content. Diagnosing the fault that only appears on your site. Migration and launch. The judgement about whether a requirement is a good idea at all, which is often the most valuable thing I contribute and which nothing here touches.
There is a quieter effect too. Because the boring parts cost less of my attention, more of it goes to the parts that need thought. That is better work rather than cheaper work, and if you are choosing on price alone, the distinction will not persuade you and probably should not.
What I will not use it for
I will not put client data into a general-purpose tool. Not a database export, not a customer list, not the contents of a support inbox. If a debugging task needs real data, it stays on my machine.
I will not let anything change a live site without me driving. Automation that fixes things unattended is a risk I want no part of on a site that takes orders.
I will not use generated imagery to represent something real. Not a fake photo of premises, not an invented person on a team page, not a product shot of a thing that does not look like that.
And I will not present work as something it is not. Which brings me to this blog.
Since you are reading one: how these articles are made
This blog is written with AI assistance. I would rather say so plainly.
The process: I decide the subject and the position, because the opinions here are mine and the judgements come from the work. Drafting is assisted. Then every factual claim gets checked against primary sources, and I edit until it sounds like me and says what I think.
That stage is not cosmetic. The first draft of any technical article contains confident specifics that are wrong, in the same way the code does, and the checking is the work. If an article here tells you a feature shipped in a particular version, I looked it up. If it hedges, that is because I could not confirm it and would rather hedge than fabricate.
Some will read that as a reason to trust the writing less. I would argue the opposite: the standard that matters is whether it is accurate and useful, and I check these pieces harder than anything I wrote before.
Common questions
Do you use AI to build client websites?
For parts of the process, yes: boilerplate, scaffolding, test data, first drafts of documentation. The architecture, the decisions and every line that ships are mine, and nothing goes out that I have not read and understood.
Does that mean my project costs less?
Not meaningfully. The parts that compress are a small share of a project. The parts that do not, discovery, design, testing, launch and the diagnosis of your specific problems, are most of the cost, and they take the time they take.
Could I not just do this myself with an AI tool?
For something small and self-contained, genuinely yes, and I would not talk anyone out of it. The catch is that you will get an answer either way, and without the background you cannot tell a good one from a plausible one. That is fine on a personal project and expensive on a site taking payments. It also struggles with the accumulated context of a real site: what breaks what, why the previous developer did that, and which suggested fix will not cause a different problem in three months.
Is my data going into these tools?
No. Client data does not go into general-purpose AI tools. If a job needs real data to diagnose, it stays local.
Where I have landed
AI is a good tool and a bad colleague. It is fast at the things I can check quickly and unreliable at the things I cannot, so the discipline is knowing which is which, and that comes from experience rather than from the tool.
The developers who will struggle are the ones using it to produce work beyond what they can evaluate. The ones who will do well use it to go faster through work they could have done anyway, which sounds like a smaller claim and is a more honest one.
The other group who will struggle are the ones refusing to touch it. Knowing these tools properly is part of the job now, in the same way knowing your way around a browser’s dev tools is, and someone spending three hours on what a good prompt and twenty minutes of review would have finished is not being principled. They are just being slow.
What I would want you to take from this: ask whoever builds your website whether they can explain every part of it. That has always been the right question. It matters more now, but it was never a new one.
If you have a project and want a straight answer about what it will actually take, get in touch and tell me what you are trying to do.
