What Vibe Coding Cannot Do (As of 2026)

I'm bullish on vibe coding. I ship with it every week. But there's a category of work where prompting an AI is slower than just writing it yourself, and knowing the difference has saved me days. Here's my personal list as of April 2026.

Cross-File Architectural Refactors

Moving a feature across 8 files while renaming types, updating imports, and preserving behavior — AI is shockingly bad at this. It gets 6 of the 8 files right and forgets the other 2. Or it renames the type in 6 files and leaves the old name in 2 as a "compatibility shim" that you didn't ask for.

For this kind of refactor, use a real refactoring tool (your IDE, ts-morph, jscodeshift) or do it by hand with grep. The AI can generate the jscodeshift script for you, which is fine — but don't ask it to just "do the refactor" across a large codebase.

Debugging Race Conditions

The AI has never seen your race condition happen. It will guess, confidently, at causes that sound plausible. Since race conditions rarely reproduce deterministically, you can't even easily prove the AI wrong. You'll spin for hours.

Race conditions need logs, event ordering, and careful reading. A human who stares at the code for 15 minutes is much better at this than 15 prompts.

Performance Debugging Without Profiler Data

"Why is my page slow?" will get you 20 plausible-sounding suggestions from the AI, 19 of which don't apply to your actual bottleneck. Use a profiler first. Lighthouse, Chrome DevTools Performance tab, React DevTools Profiler — get actual data, then paste the data into the AI. "Here's my Performance trace, the bottleneck is Recoil state updates" is 10x better than "my app is slow."

Anything That Requires Reading an Actual Spec

OAuth flows. Payment webhooks. OIDC. SAML. Anything where the correct behavior is defined by a 60-page document, and "kinda working" is worse than "not working" because you'll discover the gap in production. The AI will confidently write half the spec. You need to read the actual spec, at least the parts you're using.

CSS Bugs Caused by Specificity

"Why isn't my text red?" The AI will try 5 things: !important, changing the selector, adding inline styles, moving the CSS to a different file, switching to Tailwind. None of them address the actual specificity issue. You have to open DevTools, inspect the element, look at the cascade, and figure out which rule is winning. The AI can't do that.

First-Time Setup of Something You Don't Understand

Setting up Kubernetes, a monorepo with shared TypeScript types, or a complex CI/CD pipeline when you've never done it before — the AI will generate a config that looks right. It will be missing 3-4 critical details that you won't notice until production. Read the getting-started docs for the thing once before prompting, so you can at least recognize a broken config.

"Make It Look Better"

Design work is hit or miss. The AI can rearrange elements, pick colors, and add padding. It cannot tell you that the hierarchy is broken, the body copy is too long, or the CTA is in the wrong place. For real design work, read a Refactoring UI style book once, or ask a designer. Don't iterate with AI — you'll get 20 versions of the same mediocrity.

Naming Things Well

AI naming is competent but generic. UserDataHelper, ItemProcessorService, handleSubmit. Good names require understanding the domain and the reader. The AI optimizes for sounding plausible, not for communicating intent. Names matter more than you think — spend your own time on them.

What This Means for the Checklist

The Vibe Code Fix checklist is for AI-generated code that needs review. The items I listed here are cases where you shouldn't use AI in the first place. Knowing the second list makes the first list shorter. If you stop using AI for race-condition debugging and specificity CSS bugs, you won't have to review AI attempts at those things.