AI can build your app in an afternoon. Your users will figure that out just as fast.

I've been trying other people's AI-coded apps. Apps built by indie hackers I follow and respect, people who ship fast and talk about it publicly.

The experience has been, almost universally, terrible.

Buttons that don't do what they say. Flows that dead-end without explanation. States the developer clearly never encountered because they never used the thing past the demo.

You've been on one side of this, probably both. You're an indie hacker who believes AI changed the game for builders. And it did. The question is whether it changed the game for your users too, or just for you.

I wanted to support these builders. I know how much it means when someone actually tries your product. But the gap between "shipped" and "usable" was so wide that giving useful feedback would have been a second job. The developer had, without realizing it, dumped an enormous amount of work on me.

The Demo That Eats Itself

There's a seductive video format everywhere right now: "I built this app in 2 hours with AI." The demo looks incredible. Clean UI. Working features. A complete product, conjured from a conversation with a chatbot.

What you're watching is the happy path. And the happy path is a fraction of what a real user encounters.

AI is genuinely good at generating plausible software. It can scaffold an app, wire up a database, build a UI that looks like it works. For a single-script tool, that might be enough. The scope is small enough that "plausible" and "functional" overlap.

The moment an app has real users with different needs, edge cases, states that persist across sessions, plausible and functional start to diverge. A December 2025 analysis of 470 open-source pull requests found that AI co-authored code contained 1.7 times more major issues than human-written code, with security vulnerabilities running more than twice as high.¹ None of that is the AI's fault. The AI did what it was asked. The developer shipped what the AI gave them without doing their part. That's the distance between "looks like it works" and "actually works."

What the Uber-Engineer Actually Does

The builders who use AI coding well bring something specific. They operate as architect, product manager, QA team, and senior engineer simultaneously. They prompt, evaluate, correct, re-architect, test as a user, and iterate. The AI handles the "typing". They handle everything else.

That's a staggering amount of judgment for one person to hold. And it's the minimum bar for shipping software that doesn't waste a stranger's time.

Here's where it gets interesting. The METR research group ran a controlled trial in mid-2025 with 16 experienced open-source developers working on their own repositories, codebases they'd contributed to for years.² These developers felt 20% faster when using AI coding tools. Measured results showed they were actually 19% slower.

The important context: these were experts on familiar ground, already fast without AI. The speed advantage of AI coding is more pronounced when you're building something new or working outside deep expertise. But even then, the perception gap matters. The feeling of speed arrives instantly. The judgment calls pile up silently. Everything about the experience whispers you're done. Often, you're just getting started on the part that actually matters.

The Quality Tax Gets Paid Somewhere

In traditional development, quality work happens before the user sees the product. Testing, edge case handling, user research. It's expensive and slow, which is exactly why AI-assisted building feels so liberating. You skip all that friction.

But the friction wasn't waste. It was the work of making software actually usable. When you skip it, you don't eliminate the cost. You transfer it. Instead of the developer spending hours testing edge cases, the user spends minutes hitting them. Instead of a QA team catching the broken flow, a customer discovers it mid-task with real data.

The developer saved time. The user lost time. The user didn't agree to that trade.

The Tab You'll Never Reopen

Those transferred costs are starting to accumulate in a specific way: eroding trust.

I've noticed it in myself. When someone mentions their app was "vibe-coded" or "built in a weekend with AI," my expectations now drop. That framing, which the builder thinks is impressive, has started to work against them. It's becoming a signal that says: probably wasn't tested. Probably breaks on the second click.

The builders are sensing it too. Positive developer sentiment toward AI coding tools dropped to 60% in 2025, down from over 70% the year before. Two-thirds of developers report spending more time fixing "almost-right" AI code than they save generating it.³

If the people building with these tools are losing confidence, imagine what the people using the output feel.

This isn't an organized backlash. No hashtag, no boycott. Just millions of individual decisions to close the tab, delete the app, and never come back. The quiet kind of judgment that doesn't announce itself until it's already shaped behavior.

The Trust Window

We're in a brief window where users are still willing to try AI-built products. Curiosity is high. Expectations are adjustable.

That window has a shelf life. Every low-quality app that ships burns a small piece of collective goodwill. Every "built in a weekend" product that wastes someone's time makes the next builder's launch harder.

Yes, the tools are improving fast. AI-generated code will get better. But trust, once lost, recovers slowly. Users don't track which model version built the app that wasted their afternoon. They just remember the waste. And they remember who made it. Ship one broken app and the damage extends beyond that product. People might not even try your next one.

Before AI, most serious software went through some form of quality assurance. Slow, expensive, sometimes excessive, but it existed. AI coding introduced a seductive new mode: skip all of it. Ship what the model gives you. Move on to the next thing.

Both extremes are wrong. Exhaustive QA kills the speed advantage that makes AI coding worth doing. Zero QA kills the product. There's a third mode: lightweight quality rituals that fit into a fast-shipping workflow without gutting it.

A few that work for solo builders:

  1. The stranger session. Before you ship, use the app the way someone who didn't build it would. Real multiple iterative sessions where you try to accomplish what the app promises, without unconsciously avoiding the paths you know are broken. Give it to one person who owes you nothing and watch what they do.
  2. The error walkthrough. Spend thirty minutes deliberately triggering every failure state you can think of. Bad input, empty fields, double-clicks, back button, dropped connection. AI almost never handles these on the first pass, and each one is a moment where a user decides you don't respect their time.
  3. The day-two test. Come back to your own app tomorrow, after the build excitement has faded. The test of real software is whether it holds up on the third visit, when the novelty is gone and only the utility remains. If you don't want to use it yourself the next day, your users won't either.
  4. Ship the core, not the surface. AI is great at generating impressive-looking breadth. Resist it. One flow that works flawlessly beats five that mostly work. Cut features until what remains is solid.
  5. Make AI your QA partner, not just your builder. The same AI that wrote the code can help stress-test it. Ask it to list every edge case for a given flow. Have it generate test scenarios you wouldn't think of. Use it to review its own output with fresh context. This works, but only with your direction. Left unsupervised, AI will rubber-stamp its own work. You need to prompt it adversarially: "What will break? What did I miss? What happens when a user does something unexpected here?" The AI won't care about quality on its own. You have to make it care by asking the right questions.

None of this takes weeks. A few hours, spread across a day or two, catches the problems that make users leave. The goal isn't perfection. It's clearing the bar where someone can actually use the thing you made without doing your job for you. When an app clears that bar, users can become generous. They'll report bugs, flag edge cases, suggest improvements, stick around through rough spots. But only if they can tell you've done your part first. The apps I abandoned weren't the ones with bugs. They were the ones where it felt like nobody had used them before I did.

AI didn't change what makes software good. It just made it faster to ship software that isn't. The builders who add even a thin layer of genuine quality work will stand out, because right now, almost nobody does.

Rabbit Hole

If this resonated, you might also dig into:

  1. CodeRabbit, "State of AI vs Human Code Generation Report" (December 2025). Analysis of 470 open-source GitHub pull requests (320 AI-coauthored, 150 human-only) found AI co-authored code contained 1.7x more major issues than human-written code, with security vulnerabilities running significantly higher across multiple categories.
  2. METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (July 2025). A randomized controlled trial with 16 experienced developers working on 246 real issues in their own repositories (averaging 22k+ stars, 5+ years of contributions). Despite believing they were faster, measured results showed a 19% slowdown. Developers reported spending significant time cleaning up AI-generated code.
  3. CodeRabbit, "2025 Was the Year of AI Speed. 2026 Will Be the Year of AI Quality" (2026). Reports declining developer sentiment toward AI coding tools and the growing time cost of fixing near-correct AI output.