Vibe Coding an App: Why the Last 20% Decides It

Vibe coding is building software by describing what you want to an AI and accepting the code it writes, often without reading every line. The phrase is Andrej Karpathy's, from early 2025, and it stuck because it named something a lot of people were suddenly doing. I build shoutouts, a group card site, mostly this way. This post is about what that gets you, and what it doesn't.

What I learned at Codesmith about the first 80%

Before shoutouts, I went through Codesmith, a software engineering bootcamp. One idea from it has stuck with me more than any framework: anyone can build 80% of an app in a week. The last 20% is what makes or breaks it.

The 80% is the part you can see. The screens, the buttons, the happy path where everything goes right. It's the demo. The last 20% is everything that has to be true for a stranger to use it on a bad day: on an old phone, with a slow connection, a typo in their email, and a card that declines on the first try.

Programmers have joked about this for decades. There's an old line from Bell Labs that the first 90% of the code takes the first 90% of the time, and the remaining 10% takes the other 90%. The numbers are a joke. The shape is real.

What AI changed, and what it didn't

AI tools collapsed the first 80%. What took my bootcamp cohort a week now takes an afternoon. I described a group card where people sign with no account and the recipient opens it like a present, and I had a working version in days: create a card, share a link, sign it, open it.

What didn't change is the last 20%. If anything it got bigger, for a simple reason: when everyone can reach 80% in an afternoon, the 80% stops being worth much. The demo is no longer the hard part, so it's no longer the part that sets one product apart from another.

What the last 20% looked like for shoutouts

Here is some of what came after the working version. None of it was in the demo. All of it would have cost me users.

The email went to spam. The first cards I delivered for real landed in Gmail's spam folder. The email said, more or less, "someone made you a card, click here." That's exactly what a phishing email says. The fix wasn't code: it was writing an email that couldn't be mistaken for one, with the names of the people who signed in the subject line and the card's own words in the body.

"Deliver at 9am" meant nobody's 9am. An organizer in New York schedules a card for a recipient in London. Whose morning is that? Then daylight saving time moves the clocks twice a year. Getting a card to arrive when the organizer meant it to is a small feature that took real care.

A relative in Italy saw a blank page. Her iPhone was too old to update, and modern styling tools don't support it. To her, the signing link opened onto nothing. Nobody would ever have told me. I built a plain version of the signing page for older phones, which now catches anyone in the same spot.

Office email scanners clicked every link. Corporate mail filters open every link in an email to check it for malware. One of those links was "unsubscribe." Whole teams were being unsubscribed from their own weekly digest by a security robot. Now an unsubscribe link asks a person to press a button.

Third-party services don't behave like their docs. Payments, video, email and Slack each come from a different company, and each one answers in its own way. A second click on "Subscribe" could start a second subscription. A video service's message turned out not to include a detail I'd assumed it always would. Slack says "slow down" when you send too much and expects you to listen. Each of these is an afternoon to fix, and you find out about them one at a time, in production.

Who can change what. The code the AI first wrote for permissions answered "can this person edit this card?" correctly. It took a careful audit to ask the next question: edit which parts of it? A card's message, yes. Its price plan, no. That's the kind of question an AI answers well once it's asked, and almost never asks itself.

None of these are interesting. That's the point. They're the boring work that makes people trust a thing enough to use it twice.

How to use AI for the last 20% too

I don't think the lesson is "stop vibe coding." Most of the fixes above were written with the same AI tools that wrote the first version. The difference was that I knew to ask.

That's what a bootcamp taught me that a chatbot doesn't: what questions a working product has to answer. A few I now ask about every feature before I call it done:

• What happens on a phone from 2016? On a slow connection?
• What happens if they click twice? If they close the tab halfway?
• What happens if the other service is down, slow, or answers with something I didn't expect?
• Whose time zone is this in?
• Who is allowed to do this, and who is allowed to change each part of it?
• If this email went to a stranger, would it look like spam?
• What does someone see when it goes wrong?

AI is very good at answering these. It's still on you to ask them.

So, should you vibe code your app?

Yes, for the first 80%. It's the fastest way there is to find out whether an idea is worth the other 20%. Just don't mistake the demo for the product. The week you spend getting something working is the start. The months after it, spent on the boring parts, are what you're actually building.

That's what shoutouts is: a week of building a card people can sign, and everything since spent making sure the card arrives, opens, and works for the person on the other end.