This is the single most durable skill in the entire course, so we teach it first. In traditional software, an engineer writes code. In your world, you write the brief, and the brief is the thing you author. Get good at this and every tool in every week gets easier. Stay sloppy at it and you will fight every tool you touch.

Start by understanding why briefs fail, because almost all of them fail the same way: they are too vague, and the AI fills the vagueness with guesses. "Build me a signup section" leaves a hundred decisions unmade, so the tool makes them for you, and you spend the next twenty minutes undoing choices you never wanted. The fix is not to write more, it is to write more specifically. Lovable's own guidance puts it well: the smaller and more concrete the part you describe, the smarter the result. "Add a form with an email input and a rounded submit button that shows a success message" builds what you pictured. "Add a signup" builds a coin toss.

A brief that builds has four things in it, and you can hold them in your head. What it does, in one plain sentence. Who it is for, named specifically, because "a budgeting app for Gen Z freelancers" produces different, better output than "a budgeting app." The one key action the user should be able to take, because naming the single most important thing focuses the whole build. And the look and feel, described in concrete words: not "make it nice" but "calm and wellness-inspired, soft earth tones, generous spacing, rounded corners." Those descriptive words are not decoration; they measurably change what the tool produces.

Two techniques make you noticeably better immediately. First, build in components, not whole pages. Asking for an entire app in one prompt is like throwing a full recipe in a blender; you get something, but not something usable. Instead, build one piece (the hero, then the form, then the list of results), review each, and move on. You get control, and when something is wrong you fix that one block instead of re-rolling everything. Second, let the tool interview you. Add a line to the end of your prompt like "ask me any questions you need to fully understand this feature before you build it," and use Plan mode. The AI will surface the decisions you forgot to make, which is exactly where vagueness hides.

In the live session you will do this on your own capstone: take the one core action from your seed and write a brief for it, out loud, together, and watch the difference between a vague version and a sharp one in real time. You will leave with a brief that is ready to build, which is exactly what the next lesson picks up.