Applied AI Academy

You can ship software by describing it — if you test like a sceptic

Vibe coding: from plain language to working apps

The question: How far can a non-programmer get by iterating with an AI builder — and where does it break?

Claude artifacts, Google AI Studio build mode, Lovable, v0 and Bolt turn descriptions into running software. That collapses the cost of prototypes — and creates a new skill: specifying, testing and iterating like a product owner, not a coder.

What the lesson covers

Vibe coding is a loop: describe → run → notice what is wrong → describe the fix. The model writes the code; you own the intent, the taste and the acceptance test. The people who get magical results are not better prompters — they are better testers: they click every button, try weird inputs, and report symptoms precisely ("the score resets when I pause" beats "it's buggy").

Start where the tools are strongest: single-page apps, games, calculators, dashboards, landing pages. Structure your first description like a brief: who it is for, the 3 core actions, what data it shows, and what "done" looks like. Then iterate in SMALL steps — one change per message — because large vague asks produce large vague rewrites.

Know the breaking points: state that must persist (needs a backend), secrets (never paste API keys into generated client code), auth, payments, and anything with real user data. That is the moment to graduate from a toy to an architecture — or to hand off to engineering with your working prototype as the spec.

The professional habit that transfers from Lesson 5: keep a change log of what you asked and what broke. A prototype whose history you can explain is a communication asset; one that "just emerged" is a liability the moment someone else must maintain it.

The economics are the reason this matters beyond hobby projects. A prototype that used to cost three weeks of an engineer's time now costs an afternoon of yours, which changes what is worth trying rather than what is worth shipping — and those are different decisions. The right use is exploration: five rough versions of an idea, tested on real users, before anyone commits engineering time. The wrong use is treating the fifth rough version as production because it works on your machine. The signal that you have crossed from one to the other is boring and reliable: the moment somebody who is not you depends on it, it needs an owner, a test and a place to live.

Key points

Framework — Describe → Run → Diagnose → Refine

One intent per iteration. Describe the change, run it immediately, diagnose the symptom precisely, refine. Ten small loops beat one grand specification.

The lab

Ship something real today, then find its edges.

Deliverable: A working shared link + your change log (5+ iterations) — submit it in the Team Battle "Game" or "Application" round.

Open this lesson, its lab and its quiz

Sources and further reading