The pros and cons of AI assisted development

The last couple of years has seen a massive increase in the use of AI to develop software. Developers tend to either love or hate it; I have to admit to being more on the love side, but, realistically, loving or hating AI as a development tool seems to me to be as logical as loving or hating your favourite hammer for it’s ability to drive in a screw rather than a nail…

AI is simply that – a tool. It’s a tool with a range of capabilties that allow it to be used for simple support through to full system development. There are a number of ways in which AI can be used, as follows:

• Advanced Intellisense – the AI is used in your development IDE to help you with development, by providing code blocks, hinting at ways forward and generally helping to code faster.
• As a junior developer – the AI can be used, with suitable prompts, to provide distinct functions that you then use in your code. It’s very good for fiddly regex expressions…
• Lint checking – when confronted with a piece of code that just throws a 500 error, or a block of HTML that just won’t render, giving the file to an AI with a suitable prompt will often find the issues – or at least suggest starting points for investigation – within a couple of minutes
• Vibe Coding – this is a ‘no code’ technique where the AI is given a prompt to create something – along the lines of ‘Write me a plugin that displays the date in Jakarta’. A few minutes later the AI will either spit out the relevant PHP code and supporting files, or even a zipped up plugin for installation. Very handy for quick prototyping. You can then tweak your prompt and regenerate the product.
• Outlining – somewhat like Vibe Coding but with added humanity! The AI is prompted to generate a plugin that is more of a scaffold / framework on to which you can hang your own code. You might use the AI to then generate the guts of the project separately, but you have more control.
• The ‘Ralph Wiggum’ technique where the AI is given a description of requirements and uses a plugin for the Claude AI to loop back on itself to fix its mistakes until all the requirements are met. Watch this blog for a post about my own experience with Ralph…

All of these techniques are very dependent upon the quality of the prompts used in, the LLM doing the work, etc. I use variations on all of these models of working to help me in my development work. The more a developer uses AI in that development process, the more issues they will encounter.

Used well, AI can make the development process faster and more consistent. Used carelessly, it can introduce security holes, technical debt, and “it works on my machine” code that falls apart in production.

WordPress plugin work contains a lot of repeating patterns: admin pages, settings forms, nonce checks, AJAX handlers, CPT registration, shortcodes, blocks, REST routes, WP-CLI commands, and so on. AI is genuinely good at producing a “first pass” version of this boilerplate. That first pass is rarely perfect, but it can developer time, especially when you already know what “good” looks like and can correct the generated code quickly.

Most plugin projects stall in the same places: data modelling, edge cases, UI states, and integrations with other plugins or APIs. These are what I regard as ‘the boring bits’ – I’m much more interested in my core functionality – the fun stuff. AI tools are useful as a sounding board that talks back. They can suggest approaches, identify likely failure points, and give you a starting list of things to check (capabilities, nonces, sanitisation, caching, transients, object caching behaviour, etc.). Even when the suggestion is not right, it can help you move again.

AI can help you spot issues you might otherwise miss: missing capability checks, unsanitised input, escaping in admin output, inconsistent naming, unclear responsibilities, or repeated logic that wants refactoring. It can also generate checklists, for example: “What should I verify before shipping an AJAX endpoint?” That is a practical way to reduce avoidable mistakes.

Many developers (me included) would rather build features than write documentation. AI can turn my rough notes into readable settings descriptions, tooltips, and “how to use this plugin” sections. It can also generate the .md file. This matters, because plugin success is often determined by how quickly a user understands it.

Even if you do not run a full PHPUnit suite, AI can help draft unit tests, integration test ideas, and edge-case scenarios. It can also help generate realistic dummy data for imports and exports, and propose quick regression test plans (especially useful when you are iterating fast).

There’s a science fiction film from the 1970s called ‘Dark Star’ – the strapline was ‘Bombed out in space with a spaced-out bomb’ Suffice to say it dealt with a rather hippy crew of a spacecraft whose AI also suffered from issues… Sometimes, you might feel that whatever AI you’re dealing with has lost touch with reality. AI can produce code that looks right but is subtly wrong. It may invent hooks, misname filters, or recommend patterns that are outdated or discouraged. These ‘hallucinations’ are partially caused by inadequate prompting, but also are part and parcel of the underlying way in which LLMs work. WordPress and the PHP language change over time, and plugin ecosystems evolve. Unless you verify everything against official documentation, you can end up with code that fails in real sites, or worse, fails only under certain hosting setups.

This is probably the biggest ignored issue. You might have a working Plugin but it may be stuffed full of potential holes. WordPress plugins live in hostile environments. If AI outputs code that misses ‘good practice’ security checks – a nonce check, capability check, sanitisation, or correct escaping – you can ship a vulnerability without realising it. Another reason why you need to be in a position to know what you’re doing, rather than blindly rely on what’s produced.

As Bruce Springsteen said back in 1985:

Blind faith in your leaders, or in anything, will get you killed.

Common “AI-shaped” security mistakes include:

• Trusting $_POST or $_GET too easily. Anything coming in via these routes should be sanitised and validated.
• Missing current_user_can() checks. If the Plugin code in question is supposed to be only available to certain user roles, make sure that only that role can execute the code.
• Missing check_admin_referer() or nonce validation for AJAX calls. Make sure that all the AJAX handlers only accept code from a known source – yours.
• Outputting user input without proper escaping (esc_html, esc_attr, etc.)
• Building SQL with interpolated strings instead of $wpdb->prepare(). SQL Injection is still a threat!

I’ve found that the code generated by different LLMs varies considerably in how these rules are adhered to. A year or so back, things were shakey. The most recent LLM models seem to be much better at the job.

AI can help with security, but only if you already have a strong security checklist and you enforce it. Of course, you can use the AI to help with this!

AI often prefers adding more abstraction than you need, or it creates classes and layers that are neat in theory but awkward in a real plugin. You can end up with a plugin that is harder to maintain than it should be. WordPress development tends to reward clarity over cleverness.

This awkwardness often seems to be an example of ‘Best Practice’ architecture being preferred to ‘Good Practice’ or even ‘Pragmatic’ architecture. Review the code produced and modify the prompts used where necessary, and be prepared to manually modify AI generated code where appropriate.

WordPress is GPL, and most plugins in the ecosystem are GPL-compatible, but the provenance of AI-generated code can be unclear. If you are building a commercial plugin, you should treat AI output as a draft you own responsibility for, not as a guaranteed-clean source. Be especially careful with “copy this from X plugin” style prompts. The safest habit is: generate a prototype, then rewrite and adapt it in your own style.

If you paste client code, credentials, logs, or proprietary business logic into an AI tool, you may be leaking sensitive information. Even if the tool claims not to train on inputs, you still need to consider policy, compliance, and client trust. A good default: never paste secrets, and sanitise logs before sharing. Check any code you submit to an AI too carefully for API keys, username / password combinations, etc.

The code produced by an AI may be very different in style to what you are used to reading and writing. Whilst this can be quite educational, it can also increase the time spent maintaining and understanding the code. It is possible to put prompts in to the AI chat to tell it to use example code as a ‘style guide’

Run the same prompt on two separate occasions on the same LLM, and it is quite possible that you will get two different scripts. Do it on different LLMs and you will almost certainly get different answers. Be prepared for this. This can be a particular issue when you return to an AI generated script and use a different model to continue development.

Here’s a brief list of how I use AI tools in my development process. I’ll br detailing some of these steps in separate blog posts in the future.

1. I use AI like a Junior Developer. I will develop a prompt that details the outline of what I am after, with as much detail in as I can manage. Then examine and test the code that is produced, and be prepared to iterate the prompt / test process. There may well come a point where the AI gets into a loop and keeps making a mess of things.
2. Keep versions of code created by the AI as checkpoints. Perform manual modifications on the AI generated code, then test and debug using AI to help. This will give you a version of the code that is potentially significantly different to the original AI generated version. I then start a new chat, upload a zipped version of the codebase, and tell the AI to use the review and analyse the uploaded version of the code and use it as the start point for all future changes. You can then prompt the AI to create new changes within the code base. This approach does need a little care, but I find it allows me to combine the best of AI and human coding.
3. Whatever is generated, check the code against WordPress documentation. Hooks, REST patterns, block APIs, and coding standards should be checked quickly. This catches the “looks right” mistakes.
4. Write tests or at least repeatable manual checks. Even a small set of regression steps (activate, settings save, AJAX endpoint, edge cases, multisite if relevant) is will catch a lot of introduced errors. This creation of test cases is a central part of ‘Ralph Wiggum’ AI coding.
5. Get the AI to carry out modifications in small, testable chunks.
6. Check the code produced for general readability and remove code that isn’t needed. This refactoring can be done alongside (2) If you would prefer a coding approach (i.e. don’t use jQuery, etc. then specify in some ‘coding rules’ (7)
7. Supplement your prompts with ‘Coding Rules’ that might feature guidance on the structure of comments in function headers, variable naming conventions, whether to us jQuery or other libraries, etc.
8. Write separate prompts to review your code. For example, have a Prompt that is effectively a checklist of things to pay special attention to – capabilities, nonces, sanitisation, escaping, prepared SQL, and error handling. Then upload your codebase and tell the AI to analyse the code against the prompt.