AI Coding Tools Are Incredible (Until You Skip the Planning) - Part 1

AI coding tools are genuinely amazing

I need to say this up front because the rest of this post is going to sound critical. AI coding agents, tools like Cursor, Copilot, Claude Code, Windsurf, and the rest of them, are some of the most impressive technology I’ve ever used. I watch them scaffold entire features, write tests, refactor code, and solve problems I would have spent hours debugging.

They are not the problem.

The problem is us. Specifically, the problem is what happens when you hand a powerful tool to someone who hasn’t decided what they’re building yet.

The rise of vibe coding

There’s a term floating around now: vibe coding. It means sitting down with an AI agent and just… going. No spec. No plan. No acceptance criteria. You describe what you want in plain English, the AI writes the code, you look at the output, you adjust, you keep going.

It feels incredible. You’re shipping features in an afternoon that would have taken a week. You feel productive. You feel like the future arrived early.

Then you show it to users. Or your cofounder. Or your team. And you realise you built something that technically works but doesn’t actually solve the problem.

The AI doesn’t know what you know

Here’s the thing about AI coding tools that people forget: they are extraordinary at the “how” and completely blind to the “what” and “why.”

When you tell an AI agent “build me a user authentication system,” it will build one. It’ll probably be pretty good. It’ll have login, registration, password hashing, maybe even JWT tokens.

But it won’t ask you:

• Do users need to log in with Google? Microsoft? SSO?
• What happens when someone forgets their password while they’re on a plane with no email access?
• Is there a free tier? What can free users access?
• Do you need to support multiple users per organisation?
• What about GDPR? Do you need a data deletion flow?
• Can users have multiple sessions? Should logging in on one device log them out elsewhere?
• What happens when a user’s trial expires mid-session?

An experienced PM or engineer would ask these questions within the first ten minutes. The AI just builds what you described and moves on.

Edge cases are where products live or die

This is the part that really gets me. AI coding tools are almost comically bad at thinking about edge cases unprompted. And edge cases aren’t rare situations. They’re the situations your users will absolutely hit.

Here’s a partial list of edge cases I’ve seen AI-generated code completely miss:

Empty states. What does the dashboard look like when a new user has no data? The AI builds a beautiful dashboard that shows charts and tables, but with zero data it renders a broken mess. Nobody thought about the first-time user experience because nobody wrote it down.

Error handling. The AI builds the happy path perfectly. But what happens when the API returns a 500? When the database connection drops? When the user submits a form twice? When their session expires between loading the page and clicking submit? The AI doesn’t think about these scenarios unless you explicitly describe them.

Permissions. The AI builds an admin panel. Great. Can regular users see it? Can they access admin API endpoints directly? What about users whose role changes while they’re logged in? The AI built what you asked for. You didn’t ask for permission boundaries.

Data migration. You asked for a new feature that changes the data model. The AI wrote the new code. It did not write a migration for your existing 10,000 users who have data in the old format. Their accounts are now broken.

Concurrency. Two users edit the same document at the same time. The AI built a document editor. It didn’t build conflict resolution. Last write wins, and someone just lost 30 minutes of work.

Accessibility. The AI built a custom dropdown component. It looks great. A screen reader user can’t interact with it at all. No ARIA labels, no keyboard navigation, no focus management.

Rate limiting. The AI built an API endpoint that calls an external service. Under normal load it works fine. Under heavy load it burns through your API quota in 20 minutes because nobody specified rate limits.

I could keep going. I could fill an entire article with just edge cases. And that’s exactly the point. The list is endless, and AI tools will miss almost all of them unless you tell them what to look for.

The AI is a mirror of your preparation

The quality of AI-generated code is directly proportional to the quality of the instructions it receives. Give it a vague prompt, get vague code. Give it detailed acceptance criteria with edge cases specified, get something genuinely useful.

I’ve seen the exact same AI tool produce terrible output and brilliant output in the same afternoon. The difference wasn’t the model. It was the prompt. And prompts are just requirements by another name.

Vibe coding isn’t building. It’s prototyping.

There’s nothing wrong with vibe coding as an exploration tool. Sitting down with an AI agent and riffing on ideas is a fantastic way to prototype. You can validate a concept in an hour. You can see if an approach feels right before investing real time.

The problem is when people treat the prototype as the product. When “it works on my machine with test data and a single user” becomes “ship it.”

Prototyping without a plan is creative exploration. Building without a plan is expensive chaos.

What’s actually missing

Every vibe coding disaster I’ve seen traces back to the same root cause: nobody wrote down what they were building before they started.

Not a 50-page requirements document. Not a formal PRD. Just the basics:

• What problem are we solving?
• Who is the user?
• What does “done” look like?
• What are the known edge cases?
• What is explicitly out of scope?

Five questions. Takes 20 minutes to answer properly. Saves days, sometimes weeks, of building the wrong thing.

In part 2, I’ll cover exactly how to set up AI coding tools for success. Because the answer isn’t to stop using them. The answer is to stop using them blind.