5. Your First "Hello, Vibe" Session
Overview and links for this section of the guide.
On this page
What you’re building in this chapter
You’re going to do a complete “Hello, Vibe” run: a tiny project that goes from prompt → code → runnable project → refactor → small feature—without losing control of the architecture.
The concrete deliverable is a small CLI calculator you can run locally. The deeper deliverable is a repeatable process you’ll reuse for every future project.
This is not about building the world’s best calculator. It’s a safe sandbox for practicing the vibe loop with real code you can run, test, and improve.
Why this is the right “first” project
A CLI calculator is ideal for early vibe coding because it has:
- Clear inputs/outputs: you can tell if it works immediately.
- Small surface area: the model can hold the whole project in context.
- Natural refactors: parsing, evaluation, error handling, and CLI UX.
- Easy tests: you can lock behavior with simple example cases.
- Real safety lessons: “don’t use
eval” is an early security win. - Fast iteration: most loops are under a minute once set up.
Prerequisites (keep it minimal)
You only need:
- AI Studio (or any chat interface you’re using for generation),
- a code editor,
- a runtime (we’ll use Python in examples),
- a terminal to run and test.
If you haven’t read the setup pages yet, start here:
The workflow you’re practicing
This chapter is a miniature version of the full vibe loop:
- Ask for a tiny project with clear constraints and acceptance criteria.
- Turn output into files you can run immediately.
- Run it before you “improve” it (feedback beats vibes).
- Refactor for clarity once it’s runnable.
- Add one feature with tests so you don’t regress.
- Capture a reusable template so the next project starts faster.
If your iterations take more than a few minutes, reduce scope. Fast loops are the core advantage of vibe coding.
Ship points (where you stop and lock in)
A ship point is where you pause, verify, and “lock in” progress. In this chapter, ship points look like:
- SP1: the calculator runs for basic inputs.
- SP2: you have a real project structure (files, run command, tests).
- SP3: refactor completed with no behavior change (tests still pass).
- SP4: one new feature added with regression protection.
- SP5: you saved a starter prompt/template for the next project.
Pages in this chapter
- 5.1 A one-prompt micro app: “build me a CLI calculator”
- 5.2 Turn the output into a runnable project
- 5.3 The first refactor prompt (make it clean, not clever)
- 5.4 Add one feature without regressions
- 5.5 Capture a reusable template
Where to go next
Explore next