Somewhere along the way the industry decided the answer to a quick fix was “just ask ChatGPT”, and site stability has been paying for it since. Fourteen years of wrestling with WordPress internals has given me a decent nose for trouble, and the volume of slot machine development I see now points at a technical debt problem that is going to get expensive. So we should talk about LLM generated code.
The slot machine effect
Prompting an LLM for a WooCommerce snippet is a lever pull. Sometimes you hit the jackpot and get a working function that saves two hours. More often you get something that looks right and is broken underneath. The process is nondeterministic, so the clean solution you got today has no bearing on the pile of invented WordPress hooks you get tomorrow.
I saw a checkout fix recently where the LLM generated code hooked a filter that has not existed since the WP 4.x era. No crash, no error, just logic that never ran. The client lost three days of tracking data to a quick fix that was a ghost. What worries me is the selective memory around this: developers remember the wins and quietly write off the hours spent debugging silent failures.
Technical debt in a box
Breakage is the smaller problem. The bigger one is that the output routinely ignores the WordPress Coding Standards. These models trained on enormous piles of code, plenty of it bad: stale StackOverflow answers, insecure quick hacks, legacy snippets nobody should copy. Paste that into a modern install and you have skipped years of security work.
<?php
/**
* THE LLM APPROACH (NAIVE & INSECURE)
* This looks functional but misses critical WordPress security protocols.
*/
add_action('init', function() {
if (isset($_POST['update_option'])) {
update_option('my_custom_option', $_POST['value']); // Hallucinates security!
}
});
/**
* THE SENIOR APPROACH (ROBUST)
* Using proper sanitization, capability checks, and nonces.
*/
add_action('admin_post_bbioon_update_option', 'bbioon_safe_option_update');
function bbioon_safe_option_update() {
if (!current_user_can('manage_options')) {
wp_die('Unauthorized');
}
check_admin_referer('bbioon_option_action', 'bbioon_nonce');
if (isset($_POST['value'])) {
$sanitized_value = sanitize_text_field($_POST['value']);
update_option('bbioon_custom_option', $sanitized_value);
}
wp_redirect(admin_url('options-general.php?page=bbioon-settings&success=true'));
exit;
}
The token gambit
The business model on the provider side is also shifting. You pay for tokens, which are units of work, whether the output ships or turns out to be a hallucinated mess. That gets uncomfortable in production, where inference is not cheap. Anthropic and OpenAI are both still working out how per-token pricing squares with the quality of what comes back.
Put LLM generated code at the center of your business logic and you are paying for a gamble. The response that introduces a race condition or a transient bug costs you the same tokens as a good one. Then the site starts bottlenecking under load and you pay a senior developer roughly five times the original savings to unpick it.
If this kind of cleanup is eating your dev hours, hand it over. I have been wrestling with WordPress since the 4.x days.
Audit before you ship
Use AI to scaffold an idea, then hand the result to somebody who knows the difference between a transient and a global and let them read it line by line. Architectural oversight is still a human job. The snippet that appears to work gives you a nice five minutes; the debt from bad LLM generated code sits in the repo for years.
