AI didn't make developers faster. It made bad decisions faster. Here's how to tell the difference.

It Started With a PR Review

Pull request comes in. 800 lines changed.

I open it expecting the usual — some new feature, maybe a refactor. Instead I find a completely custom implementation of something Flutter has shipped natively for two years.

The code? Honestly impressive. Clean separation. Well-named abstractions. Proper error handling. The kind of PR that would've taken a mid-level dev a week to write.

It took this developer an afternoon. With Claude.

And it was entirely the wrong approach.

What "Vibe Coding" Actually Costs You

Everyone's talking about how fast you can ship with AI. Fair — the velocity is real.

But there's a tax nobody mentions upfront.

When you prompt your way to a solution without deeply understanding the problem space, you accumulate a different kind of debt. Not just technical debt. Comprehension debt.

You own code you can't fully explain. Features that work until they don't. Abstractions that made sense in the AI's output but have no business being in your codebase.

And the worst part? It looks fine. It passes review. It ships.

Until it doesn't.

The Real Story

A developer on my team was building a file upload feature for a mobile app. Requirements were clear:

• Pick files from local storage

• Upload to S3

• Show progress

• Handle failures gracefully

She came back a day later with this:

class UploadOrchestrator {
  final UploadQueue _queue;
  final ChunkManager _chunkManager;
  final RetryCoordinator _retryCoordinator;
  final ProgressAggregator _progressAggregator;
  final NetworkStateMonitor _networkMonitor;

  // ... 400 more lines
}

Five custom classes. A chunk manager that split files into 512KB pieces. A retry coordinator with three backoff strategies. A progress aggregator that calculated weighted averages across concurrent uploads.

I asked her one question:

"What's the actual upload size limit we're dealing with?"

She checked.

4MB max. Single file. One at a time.

// What we actually needed
final response = await dio.post(
  '/upload',
  data: FormData.fromMap({'file': await MultipartFile.fromFile(path)}),
  onSendProgress: (sent, total) => onProgress(sent / total),
);

12 lines. Zero custom classes. Ships the same day.

The 400-line version? Built to solve a problem that didn't exist, generated by an AI that had no way of knowing that.

Why This Keeps Happening

Here's the mechanics of what goes wrong:

1. AI Has No Context Floor

When you prompt "build a file upload feature with progress and retry logic," the AI doesn't know:

• Your actual file size constraints

• What packages you already have installed

• What the platform already handles for you

• What "good enough" looks like for your use case

It builds a complete, robust solution to the general version of your problem. Not your specific one.

2. Complete Solutions Look More Correct Than Simple Ones

This is the psychological trap.

A 400-line solution with proper abstractions feels more professional than 12 lines that do the same thing. It looks like you thought it through. It looks like you anticipated edge cases.

It isn't, and you didn't — the AI did. And the AI anticipated every edge case, including the ones that will never happen in your app.

3. We've Lost the Friction That Protected Us

Before AI, writing 400 lines took time. That time created natural pressure to ask: is this really necessary?

That friction is gone. You can generate production-looking code faster than you can properly think through the problem. The guardrail was never technical skill — it was the cost of the wrong choice.

Remove the cost, remove the guardrail.

The Questions to Ask Before You Prompt

I've started treating these as a mandatory pre-flight before writing any non-trivial prompt:

→ Does the platform already solve this?

Before building anything for Flutter, check:

• pub.dev for maintained packages

• Flutter's own widget/API docs

• The framework's cookbook

For a backend feature, check if your framework has it built in. For a mobile feature, check what the OS provides natively.

AI will never tell you to go check pub.dev. That's your job.

→ What's the simplest version of this problem?

Strip out every assumption. What's the actual core requirement?

"Build a robust background sync system" → probably wrong framing. "Retry a failed API call when connectivity returns" → closer. "Use WorkManager to trigger a sync job on connectivity change" → now you can Google, find a package, and be done in an hour.

→ Are you solving for now or for an imaginary future?

AI loves to future-proof. It'll add extension points for features you haven't built yet. It'll parameterize things that don't need to be configurable. It'll build for scale you don't have.

Your app with 200 users does not need the same upload architecture as Dropbox. Resist it.

The Skill Stack Is Inverting

Here's what the AI era has actually changed about what makes a developer valuable:

The bottom of this stack got commoditized. The top got more valuable.

Platform knowledge, system design instincts, the ability to say "we don't need this" — these compound. AI doesn't replace them. It amplifies whoever has them.

A Framework That's Actually Helped

Before any feature implementation, I now run through this mental checklist:

1. Can I state the real problem in one sentence?
   └── No → keep breaking it down

2. Does the platform have a native answer?
   └── Check docs before prompting

3. What's the minimum surface area that solves it?
   └── Start there. Expand only if needed.

4. What does this look like in 6 months if it breaks?
   └── If you can't answer this, your abstraction is too deep

5. Would I be able to explain this to a teammate without AI assistance?
   └── If no → you don't own this code yet

That last one is the harsh one. But it's the important one.

If you can't explain what your code does without pulling up the AI chat to remind yourself — you're not the author. You're the approver. And approvers are not accountable in the same way.

Vibe Coding Isn't the Problem. Vibe Shipping Is.

I want to be clear: use AI. Use it constantly. It's genuinely one of the best tools we've had in decades.

But there's a difference between:

• Vibe Coding — using AI to help implement something you understand

• Vibe Shipping — pushing AI-generated code you haven't interrogated

The first makes you faster. The second makes your codebase unpredictable.

The line between them isn't the tool. It's whether you asked the right questions before you opened the prompt box.

Bottom Line

AI has made writing code nearly free.

It has made understanding your problem worth more than ever.

The developer who wins right now isn't the one who prompts the most. It's the one who can look at 400 clean, well-structured lines and say — "delete it, we don't need this."

That judgment doesn't come from AI. It comes from platform depth, from reading codebases, from shipping things and maintaining them long enough to feel the weight of every unnecessary class.

Build that. Everything else is just syntax.

What's the most unnecessary thing AI helped someone build on your team? Drop it in the comments — genuinely curious.