Don’t Blame the Car for the Accident: AI Code Quality Is a Driver Problem

Last week, I was reviewing a pull request from one of my developers. The code was clean. The naming conventions were solid. The structure was logical. It looked like good code.

But it wasn’t.

It was missing three critical edge cases. It had no error handling for when the WordPress database connection times out. It didn’t account for multisite installations. And the caching strategy would have caused stale data for any site with more than a hundred concurrent users.

When I pointed this out, my developer looked confused. “But I used Claude to write this. And it looked great.”

I nodded. “It does look great. That’s the problem.”

This moment crystallized something I’ve been thinking about for months. Something I’ve been telling my team, my clients, and anyone who’ll listen. And it’s going to be the core message of this entire post:

Don’t blame AI for bad code. Blame incomplete planning. Blame missing edge cases. Blame lazy prompting. Blame the developer who accepted “looks good” without asking “IS it good?”

But also – don’t panic. Because we’re learning. We’re evolving. And the code is getting better as WE get better at driving the car.

Let me explain.

The Thread That Started This Whole Train of Thought

A few weeks ago, a post on r/node caught my attention. It had over 500 upvotes and a hundred comments. The title was:

“I spent a week reading through AI-generated code that’s been in production for 8 months. It was fine. That was the problem.”

Read that title again. Let it sink in.

“It was fine. That was the problem.”

The developer’s point was devastating in its subtlety. The AI-generated code wasn’t broken. It didn’t crash. It didn’t have obvious bugs. It worked. For eight months, it just… worked.

But when they dug deeper, they found:

• Memory leaks that were slowly growing but hadn’t hit critical mass yet
• Database queries that were inefficient but fast enough on the current dataset size
• Security patterns that were technically correct but didn’t follow best practices for their specific deployment environment
• Error handling that caught the happy path but silently swallowed edge cases
• Architecture decisions that would become painful to modify as requirements evolved

The code was “fine.” It was functional. It passed code review (barely). It didn’t set off any alarms.

But “fine” is not the standard for production code. “Fine” is a ticking time bomb. “Fine” is technical debt accumulating silently. “Fine” is a system that works until it doesn’t – and when it doesn’t, nobody understands why because nobody truly understood how it worked in the first place.

And that’s the crux of the problem with how many people are using AI to write code.

We Are Learning. The Code Is Evolving. That’s Okay.

Before I go further, I want to say something important: I am not here to bash AI-generated code. I use AI to write code every single day. My entire workflow runs on AI assistance. I believe AI is one of the most transformative tools to hit software development in decades.

What I’m here to talk about is responsibility.

We are in the early stages of a massive shift in how software is built. And like any early stage, we’re making mistakes. We’re figuring things out. We’re learning what works and what doesn’t. That’s not just normal – it’s necessary.

Think about when you first started coding. Your early code was terrible. Mine certainly was. I wrote WordPress plugins in 2012 that would make me cringe today. No object-oriented structure. No sanitization. No nonce verification. Direct database queries everywhere. It “worked” – but it was amateur hour.

Over the years, I got better. I learned best practices. I understood security. I developed an eye for architecture. My code evolved because I evolved.

The same thing is happening right now with AI-assisted development. We’re in the early phase. The code that AI produces today is like the code we manually wrote ten years ago – technically functional but lacking the depth that comes from experience and careful thinking.

The difference is: with manual coding, the learning curve took years. With AI-assisted coding, the learning curve can be compressed – IF you approach it with the right mindset.

Half-Cooked or Ready to Eat: The Choice Is Yours

Here’s a phrase I use with my team constantly:

“AI code can be half-cooked or ready to eat. Which one it is depends entirely on you – not on the AI.”

Let me unpack this.

When I say “half-cooked,” I mean code that:

• Works for the happy path but breaks on edge cases
• Looks structured but doesn’t follow the patterns that matter for your specific codebase
• Has proper syntax but improper logic for your business requirements
• Passes basic tests but fails under real-world conditions
• Is correct today but unmaintainable tomorrow

When I say “ready to eat,” I mean code that:

• Handles all the cases you’ve thought through – and the ones AI helped you identify
• Follows your project’s specific conventions and architecture decisions
• Has been reviewed not just for correctness but for appropriateness
• Is documented, tested, and maintainable
• You understand well enough to debug it at 2 AM without AI’s help

The difference between these two outcomes isn’t the AI. The AI is the same. The prompts are similar. The model is identical. The difference is the person sitting in the driver’s seat.

What Actually Determines AI Code Quality

After using AI for coding across hundreds of projects – WordPress plugins, themes, custom integrations, REST APIs – I’ve identified four factors that determine whether AI-generated code is half-cooked or production-ready.

1. Your Logic

AI reflects your thinking. If your thinking is shallow, the code will be shallow. If your thinking is deep, the code will be deep.

When I ask AI to build a user registration system for a BuddyPress community, I don’t just say “build a registration system.” I think about:

• What happens if two users try to register with the same email at the exact same second?
• What if the email verification service is down?
• What if a user starts registration on mobile, gets interrupted, and comes back on desktop?
• What about spam registrations? What about disposable email addresses?
• What if the database insert succeeds but the welcome email fails?
• What about GDPR compliance for users in the EU?
• What about accessibility for users with screen readers?

These questions come from years of building registration systems and watching them fail in creative ways. AI can’t ask these questions for you. AI doesn’t know your user base. AI doesn’t know your hosting environment. AI doesn’t know that your client’s users are primarily in India where email delivery is unreliable.

Your logic – your thinking about the problem – is the foundation. AI builds on top of whatever foundation you provide. Weak foundation, weak building.

2. Your Cases

Edge cases are where amateur code and professional code diverge. And edge cases are almost entirely a human responsibility.

AI will give you the happy path every time. User enters valid data. API responds correctly. Database is available. Network is stable. Everything works.

But production is NOT the happy path. Production is:

• Users entering Unicode characters in fields that expect ASCII
• API timeouts during peak traffic
• Database deadlocks during concurrent writes
• Network failures in the middle of multi-step transactions
• Malicious input designed to exploit your system
• Race conditions that only manifest under specific load patterns

That 75% number from CodeRabbit’s research isn’t because AI is bad at logic. It’s because developers aren’t defining enough cases. They’re accepting the first output without thinking: “What did I forget to ask for?”

3. Your Scoping

Scoping is the invisible skill that separates senior developers from juniors. It’s the ability to define boundaries – what’s in scope, what’s out, what’s a concern for now versus later, what needs to be perfect versus what needs to be good enough.

When I scope a feature for one of our plugins, I’m making dozens of decisions before a single line of code is written:

• Which WordPress versions do we need to support?
• Which PHP versions?
• Does this interact with WooCommerce? BuddyPress? Both?
• What’s the performance envelope? How many users, how many requests per second?
• What’s the data model? Do we use custom tables or post meta?
• What are the permission boundaries? Who can do what?
• What’s the backward compatibility story? Will this break existing users’ data?

AI doesn’t know any of this unless you tell it. And if you don’t tell it, it makes assumptions. Those assumptions might be wrong. They might be correct for a generic case but wrong for YOUR case.

Good scoping = good AI code. Bad scoping = code that looks good but doesn’t fit your actual requirements.

4. Your Boundaries

This is the one most people miss entirely. Boundaries means knowing where AI’s output ends and your judgment begins.

I never accept AI-generated code without:

• Reading every line (not skimming – reading)
• Understanding WHY it made each architectural choice
• Checking if its assumptions match my requirements
• Running it through our PHPCS and PHPStan checks
• Mentally walking through the user journey
• Asking: “What would break if 1,000 users hit this endpoint simultaneously?”

The developers who ship bad AI code are the ones who’ve removed these boundaries. They’ve turned AI from a tool into an oracle. They’ve stopped thinking and started accepting.

The Story of the Three Brothers

My father used to tell me a story when I was young, and I find myself thinking about it every day now in the context of AI. Let me share it with you.

A father had three sons. One day, he called them together and said: “I need you to go to the next town and find out everything about the merchant who wants to do business with us. What he sells, his reputation, his prices, his terms, his history. Come back when you have everything I need.”

The first brother left immediately. He was eager and fast. He reached the town, found the merchant’s shop, asked a few quick questions, and headed back the same day. He reported to his father:

“The merchant sells spices. His shop is in the market square. He seemed friendly.”

The father frowned. “What about his prices? His terms? His reputation among other merchants?”

The first brother shrugged. “I didn’t ask about that.”

So the father sent him back. Another trip. Another day wasted.

The second brother was a bit more thorough. He spent two days in the town. He asked about prices and terms. He came back with more information. But when the father asked about the merchant’s history – had he ever cheated anyone? Had any disputes? Was he reliable during monsoon season when supplies were scarce? – the second brother had no answers.

Back he went. A third trip.

The third brother didn’t leave until the next morning. He sat with his father that evening and asked: “What exactly are you trying to decide? What would make you say yes to this partnership, and what would make you say no?”

The father told him everything. The third brother listened. He made a list. He thought about what else his father might need to know, even if he hadn’t explicitly asked. Then he went to the town.

He came back three days later. But he came back ONCE. With EVERYTHING. Not just what was asked, but what was needed. He’d talked to other merchants. He’d checked the supply chain. He’d even negotiated preliminary terms.

One trip. Complete information. Decision made.

This parable IS the story of AI-assisted development.

AI is the town. It has all the information. It can give you everything you need. But it will only give you what you ASK for.

The first brother is the developer who prompts AI once, takes the first output, and ships it. Quick. Easy. And missing critical details.

The second brother is the developer who iterates – a bit better, but still reactive. They fix what they notice is missing but don’t proactively think about what else might be needed.

The third brother is the developer who thinks deeply before engaging AI. Who defines the complete scope. Who asks not just “what do I need?” but “what might I be missing?” Who approaches AI with a complete mental model and uses AI to implement it, not to create it.

The third brother doesn’t need three trips. They get it right the first time. Not because AI is smarter for them – but because THEY are smarter about what they ask for.

And when the first two brothers come back with incomplete information and have to start over? AI just shrugs and says:

“Sorry 🙂 – You didn’t ask about that.”

And it’s right. It IS sorry. But your time is still wasted. Your code is still incomplete. And your client is still waiting for something that works properly.

The Numbers Don’t Lie (But They Need Context)

Let’s look at the data. Because while my experience is one data point, the industry research tells a consistent story.

CodeRabbit analyzed thousands of pull requests comparing AI-generated code to human-written code. The result: AI code creates 1.7 times more issues. Not twice as many. Not ten times. Just 1.7 times.

That number is important because of what it DOESN’T say. It doesn’t say AI code is terrible. It doesn’t say AI is useless. It says AI code, ON AVERAGE, has more issues. And the key word is “on average.”

Because averages include the first brothers AND the third brothers. The developers who prompt once and ship, AND the developers who think deeply, scope carefully, and review thoroughly. If you separate those groups, I guarantee the third brothers’ AI code has FEWER issues than the average human code.

The problem isn’t AI. The problem is that many developers are being first brothers when they need to be third brothers.

This one is fascinating. Developers FEEL 39-44% more productive when using AI. But when you measure actual output – features shipped, bugs introduced, code that survives in production – the productivity gain is much smaller, and sometimes negative when you factor in the bug-fixing overhead.

Why? Because AI makes you FEEL productive. You’re writing code faster. The code looks good. You’re shipping features quickly. It FEELS like you’re crushing it.

But if that code has 75% more logic errors, and each logic error takes 2-3 hours to debug and fix in production, the net productivity might actually be lower than writing the code manually and getting it right the first time.

This is the driver problem in its purest form. The car (AI) is fast. The speedometer says you’re going 200 km/h. But if you’re headed in the wrong direction, speed doesn’t help. It actually makes things worse because you’re getting further from your destination faster.

The Security Dimension

This is the stat that should keep every developer up at night. Nearly half of AI-generated code contains security vulnerabilities. Not bugs – vulnerabilities. The kind of issues that can lead to data breaches, unauthorized access, and real-world harm to users.

But again – is this AI’s fault? Or is it the developer’s fault for not specifying security requirements? For not asking AI to follow OWASP guidelines? For not reviewing the code through a security lens? For not running it through static analysis tools?

In our WordPress work, we have automated PHPCS checks that catch common security issues – missing nonce verification, unsanitized input, unescaped output. Every piece of code, whether written by a human or AI, goes through these checks before it’s merged.

The 48% vulnerability rate is a measurement of AI’s default output. It’s NOT a measurement of what AI produces when paired with a competent developer who has proper security practices in their workflow.

The car has no brakes by default. But a good driver installs brakes before driving. A bad driver complains about the crash.

The IEEE Spectrum Warning

IEEE Spectrum published an article titled “AI Coding Degrades” that made waves in the developer community. Their analysis showed concerning trends: as more AI-generated code enters codebases, the overall quality metrics are declining.

This sounds alarming. And in some ways, it is. But let me add nuance.

We’re in a transition period. The people who are flooding codebases with AI-generated code right now are, by and large, the early majority – not the experts. They’re excited about the productivity gains but haven’t yet developed the practices to ensure quality.

This happened before. Remember when PHP became popular in the early 2000s? The language was accessible, the barrier to entry was low, and suddenly the internet was flooded with terrible PHP code. SQL injection everywhere. No input validation. Spaghetti code that made even hardened developers weep.

Was that PHP’s fault? No. PHP is a perfectly capable language. It was a people problem. Too many developers with too little experience writing too much code too fast.

The same thing is happening with AI-generated code. The tool isn’t the problem. The gap between the tool’s capability and the user’s expertise is the problem.

And just like PHP eventually matured – with frameworks like Laravel enforcing best practices, with tools like PHPCS enforcing standards, with the community developing conventions – AI-assisted development will mature too. We’ll develop better practices. Better review processes. Better tooling. Better education.

We’re in the messy middle. And that’s okay. As long as we acknowledge it and work to improve.

The “11 Years Coding” Cautionary Tale

Another Reddit thread that caught my eye was from a developer with 11 years of experience who admitted they can no longer debug without AI assistance. They’d become so dependent on AI for problem-solving that their own debugging skills had atrophied.

This is the other side of the driver problem. It’s not just about how you use AI to write code. It’s about what happens to YOUR skills when AI becomes a crutch rather than a tool.

A racing driver who uses cruise control for everything eventually loses the feel for the car. They can’t sense when the tires are losing grip. They can’t hear the engine telling them to shift. They can’t feel the road through the steering wheel. They become a passenger in their own car.

The same thing happens with developers who outsource their thinking to AI. They stop building mental models. They stop understanding the codebase architecture. They stop developing the intuition that comes from manually tracing code paths and debugging line by line.

And when AI fails – when it gives wrong advice, when it can’t figure out the bug, when the problem is too novel or too specific for AI to handle – they’re stuck. They’ve lost the muscle they used to have.

AI should make you a better driver, not a passenger. The moment you can’t drive without AI, you’ve become dependent on a tool that’s still learning to drive itself.

In my team, I have a rule: every developer must be able to explain every line of AI-generated code they submit. Not just what it does, but WHY it does it that way. If they can’t explain it, they can’t ship it. Because if you can’t explain it, you can’t debug it. And if you can’t debug it, you can’t maintain it.

Planning and Scoping: The Skill AI Made MORE Important, Not Less

Here’s the paradox that most people miss: AI didn’t make planning and scoping less important. It made them MORE important.

When you wrote code manually, bad planning led to bad code – but at least you were forced to confront the gaps as you wrote each line. You’d hit a point where you realized “wait, I didn’t think about this case” and you’d handle it on the fly. The manual process of writing code created natural checkpoints for your thinking.

With AI, those checkpoints disappear. AI doesn’t say “wait, did you consider this case?” AI just writes the code based on what you told it. If you didn’t mention error handling, there’s no error handling. If you didn’t specify concurrent access patterns, there’s no concurrency protection. If you didn’t ask about security, there’s no security hardening.

The manual checkpoints are gone. Which means you need to front-load all that thinking into the planning and scoping phase. You need to think about edge cases BEFORE you start coding, not during.

This is why I spend more time planning now than I did before AI. Not less. More. Because I know that the quality of my planning directly determines the quality of the output.

Before AI, I’d spend maybe 30% of my time planning and 70% coding. Now, I spend 60% planning and 40% with AI. The total time is less – AI makes the coding phase dramatically faster – but the proportion of planning is much higher.

And the developers who are producing the best AI-assisted code? They’re the ones who were already great planners. The ones who wrote detailed specs before writing code. The ones who thought about edge cases before they encountered them. The ones who scoped carefully and defined boundaries clearly.

AI amplified their existing skill. It didn’t replace the need for it.

My Framework: The Driver’s Checklist

After a year of integrating AI deeply into our development workflow, I’ve developed a checklist that every developer on my team follows. I’m sharing it here because I think it can help anyone who’s using AI for coding.

Before You Prompt

1. Define the complete scope – What exactly are you building? What are the inputs, outputs, and transformations?
2. List your edge cases – What happens when things go wrong? Empty inputs? Huge inputs? Invalid data? Network failures? Permission denials?
3. Specify your constraints – WordPress version, PHP version, browser support, performance requirements, security requirements
4. Identify your dependencies – What other systems does this interact with? What are their failure modes?
5. Define your testing criteria – How will you know this code is correct? What tests will you write?

During AI Interaction

1. Provide context, not just instructions – Don’t say “build a form.” Say “build a registration form for a BuddyPress community with 50,000 members, primarily mobile users in South Asia, that needs to handle rate limiting, spam prevention, email verification with fallback for unreliable email providers, and GDPR-compliant data handling.”
2. Challenge the first output – Never accept the first version. Ask: “What edge cases did you miss? What could go wrong in production? What security considerations should I add?”
3. Iterate with specificity – When you refine, be specific about WHY you’re changing things. This helps AI understand your actual requirements better.
4. Ask for alternatives – “Show me three different approaches to this and explain the tradeoffs.” This reveals assumptions you might not have considered.

After AI Generates Code

1. Read every line – Not skim. Read. Understand each function, each condition, each variable.
2. Check against your edge case list – Does the code handle every case you identified? If not, why not?
3. Run your automated checks – PHPCS, PHPStan, ESLint, whatever your project uses. Automated tools catch what eyes miss.
4. Manual testing – Test the happy path AND the unhappy paths. Test with bad data. Test with no data. Test concurrently.
5. The 2 AM test – Could you debug this code at 2 AM without AI’s help? If not, you don’t understand it well enough to ship it.

This checklist adds time to the process. But it removes issues from production. And production issues are 10x more expensive than development-phase issues. Every time.

Stack Overflow’s Warning

Stack Overflow published a piece asking whether bugs and incidents are inevitable with AI coding agents. Their answer was nuanced: not inevitable, but significantly more likely when developers treat AI as a replacement for thinking rather than an augmentation of it.

The key insight from their analysis: the developers who reported the best outcomes with AI coding tools were the ones who had the strongest fundamental skills. They used AI to go faster, not to skip steps. They used AI to implement their thinking, not to do their thinking.

This matches everything I’ve observed in my own team. My senior developers produce excellent code with AI because they know what excellent code looks like. They can evaluate AI’s output against their internal model of quality. They catch the subtle issues that juniors miss.

My junior developers, by contrast, need more oversight when using AI. Not because they’re bad developers, but because they haven’t yet built the mental models needed to evaluate AI’s output. They’re still learning what “good” looks like. And when AI gives them something that looks good but isn’t, they can’t always tell the difference.

The best AI code comes from the best human developers. The tool amplifies what’s already there. There’s no shortcut past building real skill first.

This is why I’m such a strong advocate for foundational skills even in the AI era. ESPECIALLY in the AI era. Because AI makes the gap between skilled and unskilled developers wider, not narrower. A skilled developer with AI is extraordinarily productive. An unskilled developer with AI produces extraordinarily convincing garbage.

The Real Question: Are You Driving, or Is the Car Driving You?

I want you to honestly answer this question about your own development workflow:

When you use AI to write code, who is in control?

Are you giving AI specific instructions based on your deep understanding of the problem, reviewing the output critically, and making informed decisions about what to keep, modify, or reject?

Or are you giving AI vague instructions, accepting the first output that compiles, and hoping it works in production?

The first is driving. The second is being driven. And the difference in outcomes is dramatic.

A driver decides where to go, how fast to go, when to brake, when to accelerate, when to take a detour. The car is a tool that executes the driver’s decisions.

If you’re letting AI make the decisions – architecture decisions, library choices, error handling strategies, security patterns – you’re not driving. You’re a passenger in a self-driving car that’s still in beta.

And passengers don’t get to complain about accidents. Because they chose to let go of the wheel.

How I Use AI in My WordPress Development

Let me give you a concrete example of what “driving” looks like in practice.

Last month, we built a new feature for one of our BuddyPress plugins – a group activity digest system. Here’s how I approached it:

Step 1: I planned the complete feature. Before touching AI, I wrote a spec. User stories. Data model. API endpoints. Email template requirements. Cron schedule. Error handling strategy. Edge cases (What if a group has 10,000 members? What if a user is in 50 groups? What if the email server throttles us? What if a user unsubscribes mid-digest?).

Step 2: I broke it into components. Database schema. Cron handler. Data aggregation service. Email renderer. REST API endpoints. Admin settings. Each component had its own spec.

Step 3: I used AI for implementation. For each component, I gave AI the detailed spec plus our coding standards plus WordPress-specific requirements. The output was usually 70-80% of what I needed.

Step 4: I reviewed and refined. For each component, I read every line. I found missing edge cases (AI didn’t handle the case where a group admin deletes a group while a digest is being compiled). I found performance issues (AI used WP_Query where a direct database query was more appropriate for this specific aggregation). I found security gaps (one endpoint was missing capability checks).

Step 5: I tested comprehensively. Happy paths. Edge cases. Performance under load. Security scanning. Cross-browser email rendering. Mobile responsive testing.

The result? A solid feature that shipped with zero critical bugs. The whole process took about 40% less time than it would have without AI. But NOT because AI did 40% of the thinking. Because AI did 40% of the typing. The thinking was 100% mine.

The Evolution Mindset

I want to end with something positive, because this post might sound like I’m down on AI-generated code. I’m not. I’m optimistic.

We are in an evolution. Both AI and the developers using AI are getting better every month.

Six months ago, the AI code I was getting required more revision. Today, with better prompting practices, better tools, and better AI models, the code is noticeably better. Six months from now, it’ll be better still.

But here’s the thing about evolution: it requires pressure. It requires us to maintain high standards. It requires us to reject “fine” and demand “excellent.” It requires us to keep driving rather than becoming passengers.

If we accept mediocre AI code because it’s fast, we’re not just building bad software. We’re training ourselves to have lower standards. We’re weakening our own skills. We’re creating an industry where “it compiles and doesn’t crash” is the bar for quality.

That’s not the industry I want to work in. And it’s not the standard my clients deserve.

So here’s my challenge to you: the next time you get AI-generated code, don’t just check if it works. Check if it’s excellent. Check if it handles the cases you forgot to ask about. Check if you can explain every line. Check if it’ll survive Day 100, not just Day 1.

Be the third brother. Be the driver, not the passenger. And for the love of clean code, stop blaming the car for accidents caused by bad driving.

The Bottom Line

AI-generated code is not inherently good or bad. It’s a reflection. A mirror of the developer who prompted it, scoped it, reviewed it, and shipped it.

If you go in with clear thinking, thorough planning, comprehensive edge cases, and rigorous review – you’ll get code that’s better than what most developers write manually. Because AI brings consistency, pattern awareness, and tireless attention to syntax that humans can’t match.

If you go in blind, accept the first output, skip the review, and ship without testing – you’ll get code that looks good and works fine until it catastrophically doesn’t. And by then, the damage to your reputation, your client’s business, and your sanity will be done.

The choice is yours. It always was. AI just made the consequences of that choice more visible.

I choose to drive. I hope you will too.

We’re all learning. The AI is learning. We’re learning to drive it. The code is getting better because WE are getting better. That’s not a crisis – that’s evolution. And evolution rewards the ones who keep raising their standards.

---

I’d love to hear about your experience with AI-generated code. Are you a first brother or a third brother? Have you found the balance between speed and quality? What practices have you developed for reviewing AI output? Let’s learn from each other – drop a comment or reach out. This conversation is too important to have alone.

Related Reading

• Claude Code for WordPress: How I Cut My Token Usage by 37%
• Claude’s 1M Context Window and WordPress: What Actually Changes for Developers
• How I Use AI to Run Product, Strategy, and Execution While My Team Handles Development