A working demo is persuasive. Give an AI coding tool a reasonably clear brief and it can produce a WordPress feature that looks convincing remarkably quickly. The temptation is to treat the time between the brief and the demo as the time the feature took to build.
I think that leaves out the part clients are actually paying us to get right: whether it belongs in their website, works for the people using it and will still make sense when somebody has to change it.
As these tools become more capable, I want the conversation about AI-assisted development to include a review budget. Producing more code creates more work to understand. That work needs a place in the project.
Start with a task someone can finish
“Build a resource filter” sounds like a useful instruction. It leaves quite a lot undecided.
Which resources should it show? Can a visitor share a filtered view? What happens when there are no matches? Does it work with a keyboard? If an editor changes a resource’s category, when should the results update?
Those decisions are part of the feature. An AI tool will often fill gaps with something plausible, but plausible is a poor substitute for an agreed requirement.
I would rather start with a short description of the person, the task and the expected result. For example: a visitor can select a topic, see matching reports and send a colleague a link to the same results. Then I can judge the implementation against something more useful than whether the controls look finished.
Review what the demo does not show
For WordPress, I want to understand which existing features the change uses and what new responsibility it introduces. A small addition should not quietly create a second permissions system or a separate cache that nobody knows how to clear.
Permissions are a good example. Hiding an editing button does not establish who is allowed to change the underlying data. WordPress provides capability checks for that decision. A review should follow the request through to where the action happens, including requests that bypass the visible interface.
I also want to see the feature with inconvenient content: a long title, a missing image, an empty collection and a user who has fewer permissions than an administrator. Real sites supply those conditions without asking permission first.
Automated tests can protect important behaviour, but a test that repeats the implementation’s assumptions proves very little. Start with the outcome that must remain true, then check that the test would fail if the outcome broke.
Keep the change small enough to explain
A second AI review can be useful, especially for finding things the first pass missed. It still needs judgement. GitHub’s own responsible-use guidance says Copilot code review can miss problems and should be supplemented with careful human review.
For me, that is a reason to keep changes bounded. A focused change is easier to read, test and reverse than a sprawling rewrite that happens to produce the requested screen. If I cannot explain why a new dependency or abstraction is necessary, it probably needs another look.
The handover matters too. Someone should be able to find the relevant code, understand the important decisions and identify how to undo the change. An impressive chat transcript is not a maintenance plan.
I am interested in AI because it can give us more room to solve useful problems. I want some of the time it saves to go into checking the result, including the unglamorous parts that never appear in a demo. That is how a quickly written feature earns its place on a live website.
