Vibe Coding Got You 80%. Here's What the Last 20% Actually Takes.

You might remember Moltbook. It was the biggest thing in the world for about three days back in January. It does still exist, but with a lot less fanfare.

The idea was completely novel: a social network for AI agents. Humans could read the site, but only AI agents could interact with it. It was also built entirely by AI, with creator Matt Schlicht saying he didn't write a single line of code. It was vibe-coded.

Moltbook was a great idea, but the vibe-coding led to terrible execution, at least for the main component that matters in a social network: messaging. Within a week, security researchers found that the messages weren't private and identities weren't real. Anyone could read the direct messages between agents, and anyone could post as any agent.

There was also no moderation. Crypto scammers moved in almost immediately, running pump-and-dump schemes through agent accounts, and there was nothing to scan for them or take them down.

AI-assisted development is a huge boon to the software world. But expecting "Make me a chat app. Make no mistakes." to produce production-quality output is a misunderstanding of what these tools are good at.

Where Vibe-Coding Works, and Where It Hits Its Limits

The term "vibe-coding" has a very specific meaning:

"There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good...I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

Vibe coding is exactly that. Describing what you want and judging the output not by the code, but by the behavior. The code is there, but the whole point is that you don't have to look at it. It took off as developers began to realize AI's sheer capabilities when it came to code. AI could do all of the writing from a simple prompt. "Make me a chat app. Make no mistakes." is a meme, but AI is fully capable of doing the first part.

That is because most apps are fundamentally the same under the hood, and LLMs have been trained in billions of lines of code that look identical, so you'll get a "chat app" with:

• Solid scaffolding. Auth, user accounts, and a sensible schema for channels and message history follow patterns the models have seen ten thousand times, and it all stands up in an hour instead of a day.
• A polished UI. The channel list, message pane, and input box all behave as you'd expect because the feedback loop is immediate and anyone can see whether the result looks right.
• Basic real-time messaging that works. Messages pass between open tabs over WebSockets, since every framework has a chat tutorial and the models have absorbed them all.
• Any extras you ask for. Typing indicators, timestamps, avatars, and read receipts will all show up, since each is a well-documented feature with hundreds of reference implementations.

Chat has a well-documented happy path. A model can follow that and create something that works for two people, over a local connection, with a few cute extras. But what about a user whose connection drops every time their train goes through a tunnel? Or two thousand people posting in the same channel at once? Or a message that has to reach a phone that's been offline all day?

What about when you want to add audio or video? Or like Moltbook, need moderation or feeds? Then, you're off the happy path and into the long 20% of the app vibe-coding can't deal with.

Video & Audio: Where They Hit Limits

Ask a model for video calling, and you'll get a working call between two laptops on the same wifi. But having helped build Stream, I can tell you there is a whole stack of machinery that underpins large-scale AV.

A real video feature needs:

• A signaling service to exchange connection offers, renegotiate when someone shares a screen, and handle peers that drop and rejoin
• STUN servers so each machine can discover its own public address
• TURN servers to relay the call when a firewall or strict NAT blocks a direct connection
• An SFU to route group calls, because peer-to-peer runs out of upload bandwidth past a few participants
• Simulcast, so each client sends multiple resolutions and one weak connection doesn't degrade the call for everyone
• Codec negotiation across browsers that don't all support the same formats
• Device handling for echo, camera permissions, and calls that survive a phone locking its screen

Most of that list is not code in your app, so it's completely invisible to AI coding agents. Signaling, STUN, TURN, and the SFU are all services you have to deploy, scale, and monitor. They also have to run close to your users, because routing media through the wrong continent adds latency you can hear. And they're stateful, so a call pinned to one SFU node has to survive that node's deploys and failures.

With TURN and the SFU, you also have to think bandwidth. Every relayed or routed call pushes its media through your servers, and the SFU forwards a copy of each stream to every other participant, so egress grows with every person who joins. That stops being an infrastructure question and becomes a cost one. You have to think about per-minute serving costs, cloud egress pricing, and how your peak concurrency affects the bill.

Two laptops on the same wifi, connected without TURN, without an SFU, and without simulcast, work great. But it isn't real-time video that your user can actually join, from behind an office firewall or on a phone that jumps from wifi to LTE mid-call.

Chat: Where It Runs Into Trouble

Chat looks like the easier half, but chat is full of little hiccups that AI will struggle to build.

Read receipts are a good example because every user expects them, and nothing about them seems hard. When a user opens a channel, the client sends a read event, the server flips a flag on the message, and the sender sees the checkmark. Between two tabs, it works on the first try.

The first complication is that read state belongs to a person, not a device. If you read a message on your phone, the badge has to clear on your laptop, and on the tablet that comes back online next week. That makes it server-side state every device converges on, not a flag in the UI.

It also isn't one state. "Delivered to a device" and "read by the person" are separate events. Oh, and a push notification arriving on a locked phone counts as neither.

Then there's the write volume. Storing a receipt row per user per message means a 500-person channel writes 500 rows for every message sent, before a single "seen by" list updates. The production design is a per-user, per-channel pointer to the last message read. One small record per person, cheap to update, cheap to count against.

That single pointer is going to be a huge implementation:

• It only means something if every device agrees on the order of messages in the channel, so the checkbox feature now depends on the ordering guarantees of the whole system
• It can only move forward, and has to survive duplicate and out-of-order read events from reconnecting clients
• It drives the unread counts and the app-icon badge, which are the numbers users notice instantly when they're wrong
• Its updates are themselves real-time events, pushed live in a one-on-one chat where the sender is watching for "Read" and throttled in a channel where ten thousand people would otherwise generate ten thousand seen events per message
• It has to respect privacy settings, since users can turn receipts off and expect that to hide their read state everywhere at once

Can AI build all of this? Now, yes. But suddenly you have a huge extra feature set to implement for something as trivial as a read receipt. And with dozens of small sad paths to account for, you are either spending your time now testing vibe-coded receipts, or shipping faulty product.

Feeds: Where It Gets Hard

Ask a model to build a feed, and you'll get a query that pulls recent posts and renders them in order. That might work for a demo with ten posts and three users... but it's not what runs a social network with any real activity.

A real feed needs:

• A fanout strategy. Fanout-on-write pushes a new post into every follower's feed immediately, which is fast to read but expensive once an account has thousands of followers. Fanout-on-read computes the feed at request time, which is cheap to write but slow when someone has thousands of followers. Most production feeds use a mix of both, and if you choose the wrong one, you might end up rebuilding the system later.
• Ranking. Reverse-chronological is just the starting point. Once volume grows, some signal has to decide what surfaces first, and that signal has to update in real time as new activity comes in.
• Deduplication and aggregation. "12 people liked your post" is a single feed entry built from twelve separate events.
• Rate limiting on distribution. A bad actor who can post can also flood every follower's feed with that post. Moltbook's pump-and-dump accounts didn't need to break the platform's security to do damage; they just needed a feed with no brakes on how fast one account's content reaches everyone else.
• Delivery that survives reconnects. A feed has to reconcile a client that's been offline, the same problem this article already covers for chat, but now across posts, likes, and follows instead of messages.

None of this is visible in a local demo, because a demo has one account posting into its own feed. You'll see it when a platform has real accounts following real accounts at real volume, which is exactly the moment Moltbook had.

Moderation: Where It Cracks

Moderation is the part Moltbook skipped.

A model can easily ship a bad-words.txt, but within days it's being dodged with swapped characters, spaced-out letters, and images. The crypto spam that filled Moltbook wouldn't trip a profanity filter at all. Whatever you deploy, users probe it and route around it. Static rules immediately decay.

A full production moderation system needs:

• Scanning in the send path, across text, images, video frames, and audio, fast enough that a checked message doesn't feel slow
• Classifiers that read meaning instead of matching words, retrained as evasion tactics change
• Spam and circumvention detection for attacks that are commercial rather than toxic, since a scam reads as polite text
• A review queue and moderator tooling, because classifiers produce false positives and a human has to resolve them
• An appeals workflow, because users will contest removals and EU law requires you to hear them
• Audit logs of what was removed and why, for the transparency reports regulators now expect

The failure mode here can also be illegal. The EU's Digital Services Act requires a statement of reasons for every removal and an internal appeals process, with fines of up to 6% of global turnover. The UK's Online Safety Act applies a £18 million or 10% of worldwide revenue cap, whichever is greater. In the US, a provider that becomes aware of CSAM is required by federal law to report it to NCMEC. And you'll meet Apple before you meet any regulator, since App Review requires user-generated-content apps to ship with reporting and blocking.

AI definitely has a place in this system. Stream's AI moderation runs on classifiers and LLMs, because at any real message volume, automated scanning is the only thing that scales. But that's purpose-built AI sitting inside a system with policy and people around it. Someone still writes the rules on what your platform tolerates, someone reviews the flags, someone answers the appeals.

A coding agent can scaffold the tooling in an afternoon. It can't decide policy, and it can't take responsibility when a call is wrong.

Take the 80%, Plan for the 20%

None of this is an argument against AI-assisted development. The 80% is real, and you should take it all. Let the models build your UI, your application logic, your prototypes, and every feature where the behavior you can watch in development is the whole story.

The last 20% is where that test fails. Connection infrastructure, delivery guarantees, and moderation all behave differently on your laptop and in production.

You also shouldn't build them. TURN servers, SFUs, message ordering, read state, and scanning pipelines are the same problems for every app that has them, which is why they exist as infrastructure you can buy.

Stream builds exactly that, so I'm not a neutral party here. We've also built Agent Skills, so Claude Code, Cursor, or whatever you're using can wire up our APIs directly instead of guessing.

"Make me a chat app" turned out to be the easy instruction. "Make no mistakes" is the one that covers your users' messages, calls, and safety, and it's still engineering work, whether your team does it or you put proven infrastructure in place.