From One Sentence to a Working App: What Vibe Coding Gets Right — and Where It Still Needs You

This week my feed has been full of the same demo: type one sentence — "Design a modern habit tracker app" — and watch a complete app appear. Screens, charts, forms, then production code, then a live backend. No editor open, no dependencies installed, no bill at the end.

It is a good demo. It is also, like most good demos, only half the story. I spent the weekend taking the prompt-to-app workflow seriously — building a small real app end to end — and the interesting part is not how much the tools can do. It is where they quietly stop, and what you still have to bring.

The pipeline that actually works

The modern vibe-coding stack is really four tools chained together, and each one solves a different problem:

1. Design from a sentence. A prompt-to-UI tool turns plain English into screens: dashboard, progress charts, forms. You get something clickable in seconds, which is genuinely useful for killing bad ideas fast.
2. UI to code. Export the design into a real codebase — typically React — instead of leaving it as a mockup. This is the step that separates a toy from a starting point.
3. Backend as a service. Auth, database, and hosting from one provider, so the app can store real data without you provisioning anything.
4. A coding agent. An agent that reads the generated code, wires the pieces together, and iterates when something breaks.

When the chain holds, the experience is remarkable: idea on Monday morning, working app with real users by Monday night. The tools are free to start with, which is why the demos spread so fast.

A worked example: the habit tracker

Here is the prompt I started with — specific enough to be useful, vague enough to test the tools:

Design a modern habit tracker app. Home screen with today's habits, a weekly progress chart, streak counters, and an add-habit form. Dark theme, mobile-first, calm colors. 

The design tool returned five screens in under a minute. The export produced a React app with components, routing, and state already wired. So far, so magical.

Then I asked the coding agent to connect it to a real backend, and that is where the demo ended. The generated code had no auth, no data model, and placeholder data hard-coded into the components. Getting it to production meant writing the boring parts myself — starting with security rules, because a database with no rules is a public database:

rules_version = '2'; service cloud.firestore { match /databases/{database}/documents {  // Users can only read and write their own habits match /habits/{habitId} { allow read, write: if request.auth != null && request.auth.uid == resource.data.ownerId; } } } 

That is ten lines, and no demo shows them — but they are the difference between an app and a liability.

Where the demo breaks

After a weekend of this, four failure modes kept repeating:

1. The code looks finished before it is. Generated components are clean and convincing, and they hide missing error handling, unvalidated inputs, and hard-coded values. Read every file before you trust it.

2. The data model is an afterthought. A habit tracker is easy until you ask: what happens when a user deletes a habit mid-streak? What does "weekly progress" mean across time zones? The tool will not ask these questions. You have to.

3. The agent invents APIs. Ask for a feature the backend does not support and the agent may confidently call a function that does not exist. Type-checking and a test run catch this in minutes; skipping them costs hours later.

4. There are no tests. Generated apps ship with zero tests. One small test file for the core logic — streak calculation, in my case — catches the regressions the agent introduces while "fixing" things.

None of this is a reason to dismiss the tools. It is the reason to use them like a senior developer uses a junior developer: fast, tireless, and in need of review.

A checklist that makes vibe coding production-safe

Before I ship anything built this way, it has to pass five checks:

• I can explain the data model in one paragraph. If I cannot, the app is not ready.
• Auth and database rules are written by hand, not generated.
• Every generated file has been read, not just run.
• Core logic has at least one test. Streaks, totals, billing math — whatever the app cannot afford to get wrong.
• Secrets live in environment variables, never in generated code or committed files.

That list takes about an hour on a small app. It is the hour that turns a demo into software.

The verdict

Vibe coding is real, and it is not going away. The right mental model is not "AI replaces developers" — it is "the cost of a first draft just fell to near zero." First drafts were never the hard part of software. Decisions were: what to build, what the data means, what can go wrong, and who is responsible when it does.

Those decisions are still yours. The tools just give you more time to make them well — if you spend the time you saved on review instead of on shipping faster.

Build the demo. Then do the hour of real engineering. That is the whole workflow.

— Davis George · zhuan.xyz