Vibe-Coding Isn't the Problem. The Person Holding It Is.

Earlier this month I wrote about why business owners should not ship vibe-coded production code they cannot read. That argument still stands. What I did not write, and what kept nagging at me after I hit publish, is the other half of the story.

Vibe-coding in the hands of an experienced developer is not sloppy. It is a force multiplier. And most of the people loudly arguing about it on the internet are arguing about beginners.

The conflation problem

There are two completely different things happening under the label "vibe-coding," and the public discourse refuses to separate them.

The first version is a person who cannot read code asking an AI to generate a production application and then shipping the result on faith. That is the version that scans 5,600 deployed apps and finds 2,000 critical vulnerabilities. That is the version where a Supabase database gets breached three days after launch because nobody enabled row-level security. That is the version I wrote about and I will keep writing about: do not do this.

The second version is a developer who has spent twenty-plus years thinking about systems, security, performance, and maintainability using an AI to generate code they are entirely capable of reviewing, rejecting, refactoring, and shipping under their own name. That version is not the same thing.

Conflating the two is intellectually lazy, and it is the reason most defenses of vibe-coding land awkwardly. Defenders are usually trying to defend the second thing. Critics are usually attacking the first. Both sides leave the room convinced they won the argument they were each having privately.

What AI-assisted development actually looks like on a Tuesday

Let me describe what this looks like at my desk, on a normal day, building a normal feature for a normal client.

I have a spec. I know what the data model needs to look like. I know what the controller surface is, what the Livewire component needs to render, what the edge cases are around concurrent edits, what tests I will write to verify the behavior, and which Eloquent scopes already exist that the new feature should reuse. I prompt Claude with that context, plus the relevant slices of the codebase, and it produces a first pass: the migration, the model, the controller, the Livewire component, the tests.

Some of it is correct. Some of it is wrong in interesting ways. Some of it is the kind of subtly wrong you only notice if you have been bitten by the same class of bug before.

Then I read it.

I delete the parts I would never write. I rewrite the parts that are technically correct but architecturally sloppy. I swap the raw SQL Claude reached for with the Eloquent it should have used. I tighten the validation. I notice the N+1 buried inside a Blade @foreach and fix it before it ships. I run the tests, fix the four that fail because the AI guessed at our app's conventions, and merge.

That entire loop is faster than typing it from scratch. Not because the AI did the thinking. Because it did the typing while I did the thinking.

Judgment becomes the bottleneck. It has always been the bottleneck.

Here is the thing critics keep missing. Speed of code production was never the constraint on software quality. Judgment was.

Knowing what to build. Knowing what to test. Knowing what to throw away. Knowing which trade-off you are making when you reach for a library, when a function is doing three things at once, when a query is going to fall over at scale, when an integration is silently swallowing errors and pretending everything is fine. That stuff has always been the work. The keystrokes were never the hard part.

AI does not replace any of it. It makes the typing faster and frees up cycles for the part that actually matters. If a developer's judgment is good, AI makes them faster without making the output worse. If a developer's judgment is bad, AI makes them faster at shipping bad code. Both directions amplify. The tool does not care which direction.

The honest reading of every "AI is ruining software" essay is that the author has watched bad judgment get amplified and is generalizing from it. Fair enough. It is also not an argument against AI. It is an argument against shipping code without judgment, which has been the actual problem in this industry since long before the first transformer was trained.

The wrong question, and the right one

The question I keep seeing in the litigation of this debate is: did AI write this code?

It is the wrong question. The right question is: does the person shipping this understand what it does, why it works, where it will fail, and what they would change if requirements shifted next month?

If the answer is yes, the provenance of the first draft is mostly irrelevant. A senior developer pasting in an AI-generated migration after reviewing it is making the same kind of decision a senior developer made a decade ago when they pasted in a Stack Overflow snippet, or before that when they copied a routine out of an O'Reilly book. The skill is in the evaluation, not the keystroke count.

If the answer is no, you have a problem whether the code was AI-generated or hand-typed by an enthusiastic junior who learned PHP last month. The problem is not the AI. The problem is shipping things you do not understand. We had that problem before LLMs existed. We will have it after them.

How this actually looks at Pixelworx

Most of the code that ships from Pixelworx these days passes through an AI tool at some point in its lifecycle. The first cut of a migration. A test stub before I write the real tests. A regex I cannot be bothered to derive from scratch. A boilerplate Livewire component that becomes 60% of its final form after I am done with it. The docblocks on a service class I just hand-wrote.

Here is what does not pass through an AI tool: the decisions.

Which architecture is right for the problem. What the data model should be. Where the bounded contexts live. What the failure modes are. Which trade-offs I am willing to accept and which I am not. Whether to ship a feature behind a Pennant flag so we can roll it back if telemetry looks wrong. Whether the TALL stack is even the right answer for this particular thing.

Those still live entirely in my head, and in the heads of the people I work with, and they are the only reason any of the AI output ships in a state I am willing to put my name on.

This is what the discourse keeps missing on both sides. The defenders of vibe-coding overpromise: "AI can build your whole app." It can produce code that looks like your whole app. Those are different sentences. The critics overcorrect: "AI can't be trusted." It can be trusted exactly as much as the person reading its output. Which is to say, it can be trusted in some hands and not in others, and that has been true of every tool a developer has ever picked up.

What this means if you are hiring (or being hired)

If you are hiring a developer in 2026 and you are worried about whether they use AI tools, you are filtering on the wrong thing.

Filter on whether they understand what they ship. Filter on whether they can defend a design decision without invoking "the model wrote it." Filter on whether they can sit down in front of a stack trace at 2 a.m., when production is on fire, and reason their way out without a copilot to lean on. The developers who can do that with AI in their workflow are faster than they used to be. The developers who could never do it are now faster at shipping things they cannot fix.

That gap is going to keep widening. Hire the side of it you can sleep at night having hired.

If you have software that needs building and you want someone whose judgment you trust holding the keyboard, regardless of whether the first draft came out of their fingers or a model, we should talk.