I’ve been writing PHP for the best part of twenty years. So when people started throwing the phrase “vibe coding” around, I’ll admit my first reaction wasn’t excitement. It was suspicion.
If you haven’t come across the term, vibe coding is what happens when you describe what you want to an AI in plain English and let it write the code, often without checking the output line by line. It was coined back in February 2025, and depending on who you ask, it’s either the biggest productivity shift software development has seen since version control, or it’s a slow-motion car crash for anyone who doesn’t already know what good code looks like.
Here’s where it gets interesting: both of those things are true, depending entirely on who’s doing the vibe coding.
I should point out at this stage that I’m not writing this as someone who’s scared AI is coming for my job, and I’m not writing it as a cheerleader either. I’m writing it as a developer who’s spent years building things in PHP and WordPress (you can read more about that background on my about page), and who’s spent the last while working out how to use AI properly rather than just using it.
That distinction matters more than anything else in this post. Let me explain why.
Why My Opinion on This Is Worth Anything
Here’s the thing nobody talks about when they’re hyping up vibe coding: the AI doesn’t know if the code it just wrote actually works. Not properly. It knows if the syntax is valid. It knows if the code resembles the millions of examples it learned from. What it doesn’t know is whether that WP_Query call is going to behave itself in your specific theme, whether that database call is sanitised properly, or whether the “working” demo it just produced is one edge case away from falling over in production.
I know those things because I’ve been doing this for years. I’ve made the mistakes already, the hard way, before AI was around to make them for me. That’s the entire reason I can sit down with an AI assistant and get something useful out of it: I can tell the difference between code that works and code that merely looks like it works.
That’s not a dig at anyone learning to code with AI for the first time. It’s just an honest statement of where the value is. If you can’t read the output, you’re not vibe coding. You’re gambling, and you won’t know you’ve lost until the site’s down or the database is full of garbage.
What Vibe Coding Is Actually Good For
Let’s start with the positive, because there’s plenty of it.
Boilerplate and scaffolding. If I need a new WordPress plugin skeleton, a custom post type registered, or a settings page wired up, AI does this faster than I can type it myself. This is the stuff that’s mechanical, repetitive, and well documented. The AI has seen ten thousand examples of exactly this pattern, and it reproduces it reliably.
A second pair of eyes on logic. Sometimes I’ll have a function that’s nearly right but something’s nagging at me. Describing the problem to an AI and asking it to spot the issue is often faster than staring at my own code for twenty minutes. It’s not always right, but it’s right often enough to be worth the thirty seconds it takes to ask.
Translating between languages and frameworks. I know PHP inside out. I don’t know every JavaScript framework that’s come along in the last five years. When I need a bit of vanilla JS to handle something on the front end, AI gets me a working first draft far quicker than me hunting through documentation for syntax I use twice a year.
Explaining other people’s code. Picking up someone else’s undocumented PHP from three years ago used to mean a slow read-through with a coffee. Now I can paste the function in and get a plain-English explanation of what it’s doing, which I then verify myself rather than take on faith.
Writing the dull stuff. Comments, docblocks, README files, basic error handling boilerplate. None of this requires creative thought. All of it benefits from being done well rather than skipped, which is exactly the kind of task AI doesn’t get bored of.
Generating test data and edge cases I wouldn’t think to write myself. Ask for fifty rows of realistic-looking dummy content, or a list of every weird string that might break a form field (empty, massive, full of emoji, full of SQL-looking nonsense), and you get a genuinely useful list in seconds. I’d normally write three or four examples and call it done. AI gives me twenty, and a couple of them are always things I hadn’t considered.
Refactoring with a clear before-and-after. When I know exactly what I want the code to look like after the change, AI is a huge time saver at getting there. “Take this function and split it into three smaller ones, each with a single responsibility” is a task it handles well, because the judgement call (deciding it should be split, and how) was already made by me. It’s just doing the typing.
Notice the theme. Every one of these is a task where I can verify the result quickly, and where being wrong is cheap. That’s not an accident. The moment a task requires judgement I can’t verify in thirty seconds, my approach to vibe coding changes completely, which brings us to the next bit.
Where Vibe Coding Falls Down
Now the bit that doesn’t get said enough, because nobody selling AI tools wants to say it.
It doesn’t know your system. It knows what WordPress code generally looks like. It has no idea about that one quirky function in your theme from 2019, the database structure you inherited from a previous developer, or the three other plugins running on the site that’ll happily clash with whatever it’s just suggested. Every piece of AI-generated code needs to be read with your actual environment in mind, not just trusted because it compiles.
It’s confidently wrong, often. This is the one that catches people out. AI doesn’t hedge the way an inexperienced human developer would. It doesn’t say “I’m not sure this is right.” It writes the wrong code with exactly the same confidence as the right code. If you don’t already know enough to spot the difference, you’ve got no way of telling which one you’re looking at.
Security is an afterthought unless you ask. I’ve seen AI happily generate a form handler with no input sanitisation, no nonce verification, nothing. Ask it to fix that and it will, instantly, which tells you the knowledge is in there. But it doesn’t volunteer it. You have to know to ask, which means you have to already know it matters.
It struggles with anything that needs real architectural judgement. Should this be a custom post type or a custom table? Should this logic live in a plugin or the theme? Is this the right moment to refactor or should we live with the mess for now? These aren’t syntax questions. They’re judgement calls based on years of seeing what goes wrong six months down the line, and AI has no skin in that game. It’ll answer confidently either way.
Long-running, complex builds drift. For a quick function, fine. For something that spans multiple files and grows over several sessions, I’ve watched AI lose track of decisions made twenty minutes earlier in the same conversation, quietly contradicting itself. You have to be the one holding the whole shape of the project in your head, because it isn’t.
Here’s a real example, not a hypothetical. I built a JSON import plugin for WordPress, asked AI to review and rewrite parts of it, and the result ran without a single error, looked complete, and still quietly failed the first time I used it on a real file. The rewritten code was checking for the wrong field names, ones I’d never actually specified. Nothing crashed. Nothing logged an error. It just didn’t do what I needed, and only testing against real data caught it. I’ve written up the full story, mistakes and all, in a dedicated case study, because it’s worth more as a complete example than a paragraph here.
That’s the danger in one sentence: AI-generated code fails silently far more often than it fails loudly, because it’s optimising for “looks right” rather than “is right,” and those two things only reliably overlap when someone who knows the difference is checking.
The pattern across all of these: vibe coding is excellent within a narrow, well-bounded task, and it gets progressively less reliable the more judgement, context, or architectural thinking the task demands. Which is exactly the part of the job that took me years to get good at.
My Actual Workflow
Right, enough theory. Here’s what vibe coding actually looks like in practice when I sit down to build something.
1. I describe the task precisely, including constraints. Not “build me a contact form,” but the specific plugin or theme it needs to sit in, the fields required, what should happen on submission, and any existing functions or hooks it needs to play nicely with. The vaguer the prompt, the more generic and wrong the output. This is the single biggest factor in getting usable code back.
2. I ask for the boring stuff up front. Sanitisation, validation, error handling, nonces if it’s WordPress. I don’t wait to be shown an insecure version and then fix it. I ask for it properly the first time, because I know to ask.
3. I read every line before it goes anywhere near a live site. Not skim. Read. If there’s a function I don’t immediately understand, I ask the AI to explain its own reasoning, and I check that explanation against what I know rather than just accepting it.
4. I test the edge cases myself. What happens with an empty field? A massive input? A user without the expected permissions? AI tests the happy path by default unless you push it. Pushing it is my job.
5. I keep sessions focused. One function, one feature, one fix at a time, rather than one sprawling conversation trying to build an entire plugin from scratch. Shorter sessions mean less drift and less chance the AI’s quietly forgotten a decision from ten messages back.
6. I treat it like a fast junior developer, not an oracle. A genuinely good junior developer who can type at the speed of light, has read every PHP tutorial ever written, and has zero experience of what happens when code meets the real world. I wouldn’t deploy a junior’s first draft unsupervised. I don’t deploy AI’s either.
That last point is the one I’d want anyone reading this to take away above all the others.
A Few Vibe Coding Habits That Make a Real Difference
Beyond the broad workflow, there are some smaller habits that consistently improve what comes back. None of this is complicated, but all of it gets skipped by people who are new to working this way.
Give it the existing code, not just a description. If I’m adding a feature to an existing function, I paste the function in rather than describing what it does from memory. AI matches the style, naming conventions, and structure already in use far better when it can see them, rather than guessing and producing something that clashes with the rest of the file.
State what shouldn’t change. “Add validation to this form handler, but don’t change how the data gets saved to the database” heads off a whole class of unwanted rewrites. Left unconstrained, AI will sometimes “improve” things you didn’t ask it to touch, and you won’t always notice until something downstream breaks.
Ask it to flag its own assumptions. “Tell me anywhere you’ve guessed at something rather than knowing it” is a simple line that surfaces a surprising amount. AI will often quietly assume a database table structure, a function that exists elsewhere, or a value that gets passed in from somewhere else. Most of the time those assumptions are wrong, and most of the time it’ll tell you, if you ask.
Use it to review your own code, not just generate new code. Pasting in something I’ve written myself and asking “what would you flag in a code review here” catches things I’ve gone blind to after staring at the same function for an hour. It’s not infallible, but it’s a genuinely useful extra pair of eyes, going both directions.
What I Use
For the record, I’m not precious about which AI assistant does the work, since the underlying skill (reading the output properly) matters far more than the brand on the tin. What matters more is having an editor or terminal setup where I can move quickly between writing the prompt, reviewing the output, and testing it in a real environment without a lot of friction. The faster that loop runs, the more I get out of the process, and the less tempting it is to skip the reviewing step out of impatience. That temptation, by the way, is the actual risk in vibe coding. Not the AI being wrong. Us being in a hurry.
If You Want to Try This Properly
If you’re a PHP or WordPress developer wanting to try vibe coding properly, without diving straight into something critical, here’s where I’d point you.
Pick a task you could write yourself in fifteen minutes but would rather not. A custom shortcode, a small admin notice, a one-off data export function. Something low stakes enough that if the AI gets it wrong, nothing breaks and nobody notices but you.
Write the prompt with real constraints, not a vague request. Ask for the security basics up front rather than as an afterthought. Read every line it gives you back, properly, the way you’d read a pull request from someone you’d never worked with before. Then test the edge cases yourself, deliberately trying to break it.
Do that ten times on low-stakes tasks before you trust it anywhere near something that matters. By the tenth time, you’ll have a much sharper sense of where it’s reliable for your particular stack and where it isn’t, which is worth far more than any general rule I could give you here.
Where This Goes From Here
I’ll be writing more in this section as I keep working this way; specific prompt patterns that get good PHP out of an AI assistant, debugging sessions where AI got it wrong and what that taught me, and WordPress-specific workflows worth stealing. This post is the starting point, not the whole story.
If you’re a developer who already knows your craft, vibe coding is a genuinely useful way of working that’ll save you hours every week once you know how to point it. If you’re hoping it’ll let you skip learning the craft altogether, you’re going to have a much rougher time than the marketing suggests, and you’ll find out exactly when it matters most: in production, with users watching.
I learned PHP the slow way, by getting it wrong a lot. That turned out to be the best possible preparation for vibe coding now. Not bad for an “outdated” skill, all things considered.