The hardest part of vibe coding isn't building the app

Webappers — Wed, 19 Aug 2026 10:36:49 +0000

I've been thinking about this a lot lately.

With Claude, Codex, Cursor, etc., I can get an app from an idea to something working ridiculously quickly.

And honestly, that's great.

But then comes the part that isn't as fun.

You put it in front of actual users.

Someone does something you didn't think of.

An API returns something weird.

A background job fails.

A user creates an account and the account doesn't get added.

An AI-generated function technically works, but under one specific condition it does the completely wrong thing.

And suddenly you're spending more time figuring out what actually happened than fixing the problem.

That's the bit I think we're going to underestimate with vibe coding.

We're getting much better at creating software.

We're not necessarily getting better at knowing when the software is quietly going wrong.

That's why I've been building Shipsure.

The idea is to give AI-built apps another layer of visibility around the stuff that tends to go wrong once they're actually being used.

Not another AI coding agent.

Not another "paste your error into AI" tool.

More like:

Your app broke. Here's exactly what happened.

I'm still figuring out what the product should become, so I'm genuinely curious about this:

What's the most annoying bug you've had in an AI-built app that took way longer to find than it should have?

Not the biggest bug.
The stupid one.

The one where you eventually found it and thought "there is absolutely no reason this took me 3 hours."

Those are the problems I'm interested in.

I kept wondering why my AI-built apps kept breaking after they worked

Webappers — Wed, 19 Aug 2026 10:24:44 +0000

AI coding tools have made building an app ridiculously fast.

You can describe an idea to Claude, Cursor or Codex and have a working application in a matter of days or minutes depending on the project.

The part I'm finding more interesting now is what happens after you've shipped it.

Because most modern apps aren't really one application anymore.

You've got Stripe talking to your backend.

Shopify sending webhooks.

Supabase handling your database.

Resend sending emails.

Slack receiving notifications.

Some random API you needed for one feature.

And then you've got AI agents sitting somewhere in the middle doing things too.

Everything works great...
Right?

The webhook problem

One of the easiest examples is a webhook.

Say someone pays through Stripe.

Stripe sends your application an event.

Your backend processes it.

You update the database.

Then maybe you send a Slack notification.

Pretty simple.

Until your endpoint returns a 500.

Or the server times out.

Or your code throws an error because the payload wasn't what you expected.

Or the third-party API is temporarily down.

Now you've got an event that didn't get processed.

And unless you've built the monitoring yourself, you might not even know it happened.

I've ended up writing the same kind of stuff over and over:

receive webhook
↓
process it
↓
something fails
↓
log error
↓
try to figure out what happened
↓
manually reproduce it
↓
fix it
↓
try again

And that's before you even start thinking about retries.

This gets worse with AI-built applications

I think this is one of the less-discussed problems with vibe coding.

AI has made the building part dramatically easier.

But it also makes it incredibly easy to end up with an application that has 15 different integrations held together by code you generated three weeks ago.

You might know roughly what the system does.

But when something fails at 2am, you don't necessarily know:

Which event failed
What payload was received
Which endpoint processed it
What response came back
How long the request took
Whether it was retried
Whether the failure came from your app or the third-party service

That's the part that becomes painful.

So I built Eventfy

Eventfy is basically a place to see what's happening with your webhooks and integrations.

You can inspect events, see their delivery history, retry failed requests and replay events when you need to.

Instead of having:

Stripe → ??? → your application

you actually get somewhere to see what happened in between.

The goal isn't to add another giant infrastructure platform to your stack.

It's to make those annoying integration problems much easier to understand.

I think this becomes more important as AI coding gets better

There's an interesting irony here.

The better AI gets at writing software, the more software people are going to ship.

And the more software people ship, the more integrations they're going to have.

Which means the bottleneck might move from:

"Can I build this?"

to:

"Can I actually keep this thing running?"

AI can write the webhook handler.

It can write the API integration.

It can write the retry logic.

But when something inevitably goes wrong, you still need to know what happened.

That's the problem I'm interested in solving with Eventfy.