DDiscoveryVIP
YOUR HOME FOR LEARNING VIBE CODING

Build with AI.
Understand what
you’re building.

Turn an idea into a working project—with clearer prompts, smaller steps and evidence that it works.

Find my starting point ↗Plan a project
12 quick lessons6 starter projects25 connected resources
your-next-project / workflow
01
A useful ideaOne person. One problem.
↓
02
A testable briefDefine what done looks like.
↓
03
A working sliceBuild small. Read the change.
↓
04
Evidence, not guessworkRun it. Check it. Improve it.
✓
Choose a path and begin learning.Progress stays in this browser.
NEW · YOUR GUIDED LEARNING JOURNEY

From first idea to independent builder.

50 guided lessons. Five learning routes. Ten project milestones. Build a personal workbook as you practice planning, coding with AI, debugging and reviewing your work.

10 LESSONS

Start from zero

Learn the vocabulary, choose a small problem and produce a testable brief.

Start this route →
25 LESSONS

Build your first app

Move from a brief through small changes to a working slice.

Start this route →
15 LESSONS

Debug and improve

Understand the code, investigate failures and review usability.

Start this route →
20 LESSONS

Prepare to share

Review boundaries, connected systems, deployment and maintenance.

Start this route →
50 LESSONS

The complete journey

All 50 lessons, ten milestones and an independent capstone.

Start this route →

Includes worked examples, knowledge checks, saved practice notes and a hands-on bug repair lab. Progress stays in your browser; export a backup to keep it. Practice completion is self-reviewed, not certification of an external app.

A CLEAR NEXT STEP

Where are you starting?

You don’t need to learn everything at once. Pick the route that matches what you want to do today.

01

I’m new to this

Understand the workflow and plan a small first project.

Start learning →
02

I want to build something

Move from a brief to reviewable changes and real evidence.

Start learning →
03

I want to improve or publish

Test the edges, protect data and verify the deployed flow.

Start learning →
LEARN THE LOOP

From a rough idea to a reliable habit.

Each lesson has a plain-language explanation, an example and a small task to try. Knowledge checks record your understanding, not your application’s quality.

01FoundationsStart with the right mental model

Vibe coding is often used to describe building software through natural-language instructions to an AI coding tool. People use the term differently. This hub teaches an accountable version: you explain the intent, inspect the result and verify that it works. Fluency in a generated explanation is not evidence that the code is correct.

In practice

“Build a study timer” is the start of a conversation, not proof that the timer keeps accurate time.

Try this

Name one result you can observe in the browser.

02FoundationsChoose one complete user journey

A small complete feature is easier to understand than a large unfinished application. Describe what a person enters, what they do and what useful result they receive. Leave optional dashboards, accounts and integrations for later unless the first outcome depends on them.

In practice

For a reading list: type a title, add it, mark it finished. Payments and social sharing can wait.

Try this

Write your smallest version in one sentence using “A user can…”.

03FoundationsWrite a brief you can test

Include a goal, audience, starting point, stack and observable acceptance checks. Replace adjectives such as “amazing” or “smart” with behaviors you can inspect. State what is outside the first version. Unknown facts should be questions or explicit assumptions.

In practice

Instead of “make it user friendly”, ask for visible labels, keyboard-operable controls and a clear empty state.

Try this

Use the planner to write three “when…then…” checks.

04PromptingGive relevant context

Share the files, errors, constraints and project conventions that affect the change. Keep secrets out of prompts. Ask the assistant to inspect existing code before assuming a framework or directory structure. A concise relevant reproduction is often more useful than a large unrelated file dump.

In practice

A bug report includes the affected function and the exact error, not only a screenshot of the homepage.

Try this

List what a helper would need to reproduce your next task.

05BuildingAsk for one reviewable change

Keep each change focused enough to explain and test. Ask what files will change, why the change is necessary and how to verify it. If the assistant proposes a broad rewrite for a small issue, first establish whether the current implementation can be repaired more narrowly.

In practice

A broken filter should be diagnosed before replacing the entire application.

Try this

Write a request that changes one behavior while preserving the others.

06BuildingRead the change, not just the summary

A diff shows what was added and removed. Trace the user input through validation, state updates and output. Ask about unfamiliar lines and check whether dependencies or network requests were introduced. The assistant’s summary is a guide to the change; the files are the actual change.

In practice

If a local notes app suddenly sends notes to an endpoint, that data flow deserves investigation before release.

Try this

Identify where input enters and where it is stored or displayed.

07DebuggingDebug with evidence

Describe the expected behavior, actual behavior, exact input and reproduction steps. Record the first relevant error. Change one plausible cause at a time and repeat the reproduction. A fix should explain the failure and include a check that would catch its return.

In practice

“The counter shows 01 after one click” is more diagnostic than “the counter is weird”.

Try this

Use the Debug prompt mode to create a reproducible report.

08TestingTest more than the happy path

Start with the primary user journey, then try empty, invalid and boundary inputs. Check reload behavior, keyboard use, small screens and failures of external services when relevant. Choose tests that could reveal a meaningful mistake rather than only repeating the implementation.

In practice

A budget tool should handle no entries, a zero amount and an invalid amount—not only three valid numbers.

Try this

Record one normal case, one edge case and one failure case.

09TestingKnow where data and secrets go

Browser code is visible to people using the page. Private credentials do not belong in shipped frontend files. Decide which data is needed, where it is stored and who can access it. If the project needs authentication or a privileged service, plan the server-side boundary and review it carefully.

In practice

A weather widget can show a placeholder while you decide how a protected API will be called; it should not publish a private credential.

Try this

Draw a short input → processing → storage/output map.

10TestingMake the flow usable for more people

Use semantic controls, labels, meaningful feedback and visible focus. Try the main journey with a keyboard and at a narrow viewport. Respect reduced-motion preferences where motion is optional. Automated checks help, but they do not replace contextual evaluation and user testing.

In practice

A clickable div may work with a mouse while being unreachable with a keyboard.

Try this

Complete your primary flow without using a pointer.

11ShippingKeep a working checkpoint

Save a known working state before a risky change. Use version control to inspect differences and recover earlier work. Keep changes small enough to explain. A backup is only useful when you know what it contains and how to restore it.

In practice

Before changing how notes are stored, preserve the working version and test the migration on disposable data.

Try this

Write down how you would undo your next change.

12ShippingRelease, observe and improve

Use a release review proportionate to the feature and its risks. Test the deployed environment, not just your local preview. Check required files, configuration and the primary user journey. Record what you verified and what remains uncertain, then improve with real feedback.

In practice

A form can look complete locally while failing on hosting because its endpoint or configuration is missing.

Try this

Use the release journal to record evidence for one deployed user journey.

AN IDEA YOU CAN ACT ON

Build your project brief.

Choose a small project, shape its scope and generate prompts for each stage. This organizer works locally; it does not call an AI or build the application for you.

A useful first brief includes: your goal, audience, stack, starting point, essential behaviors, data handling, constraints and observable tests. Ask for the smallest complete flow first.
PRACTICE YOUR JUDGMENT

What would you do next?

Real projects rarely follow a perfect script. Try these short decisions and learn why a response helps—or makes the problem harder.

The first version keeps growing

Your study timer now includes accounts, subscriptions, chat and a dashboard—but the countdown still does not work. What should you ask next?

A complete small flow gives you something testable. Defer features that do not support it.

A mysterious result

A counter displays 01 after its first click. Which follow-up is most useful?

The initial value and operation can reveal a string/number mismatch. Reproduce before changing unrelated code.

A shortcut with a hidden cost

The proposed frontend includes a private service key in a JavaScript constant. What should happen?

Keep private credentials out of frontend code and review access controls before integration.

It works once

The generated form submitted successfully with one perfect input. What is a useful next check?

Failures and alternate interaction paths reveal issues that one successful test can miss.

A tiny bug, a huge diff

A label issue produced changes across most of the project. How should you respond?

A focused explanation and test plan help identify unnecessary or risky changes.

The preview is not the deployment

The tool works locally but the deployed page returns an error. What comes next?

Evidence from the deployed environment helps distinguish hosting differences from application logic.

YOUR EXPANDING RESOURCE SHELF

The right resource for the next step.

Explore connected guides and tools across prompting, building, debugging and release. Save favorites to make your own return-to list.

25 resources

FINISH WITH EVIDENCE

A release journal, not a green-light button.

Record what you actually checked. These are your self-reported notes; the page does not run tests, audit security or certify readiness.

  • Primary journey: Record the inputs, actions and observed result for the main flow.
  • Invalid and empty inputs: Record one rejected or empty input and how the page helps the user recover.
  • Keyboard and mobile: Record the keyboard flow and the narrow viewport you inspected.
  • Data and secrets: Record where data is stored/sent and how private credentials are kept out of client code.
  • Failure behavior: Record a relevant failure case, such as unavailable storage or an unsuccessful request.
  • Change review: Record which files changed and any new dependencies or external requests.
  • Recovery plan: Record the checkpoint or backup and how you would restore it.
  • Deployed verification: Record the deployed URL, date and observed main-flow result; leave blank until tested.
CLEAR UP THE JARGON

Common questions, useful definitions.

Do I need to know how to code?

You can begin with small projects while learning the basics. Understanding HTML, CSS, JavaScript and data flow helps you judge changes and diagnose failures. This hub links to those foundations alongside AI-assisted workflows.

Which AI coding tool should I use?

Start with a tool you can access and understand. Consider where code runs, what permissions it receives, how changes are reviewed and how you can export or recover your work. This hub is provider-neutral and does not maintain a live pricing or rankings list.

Does this planner build my application?

No. It creates a structured brief and stage-specific prompts from your inputs. Copy them into your chosen coding assistant, then review and test the actual implementation.

What if generated code does not work?

Save the current state, reproduce the failure and capture the first relevant error. Share expected versus actual behavior and ask for a small diagnostic step before a broad rewrite.

Can I publish a project immediately?

Publish only after checks appropriate to its use and risk. Verify the deployed flow, data handling and recovery path. A personal practice tool and an application handling private records need different levels of review.

How do I continue learning here?

Choose a path, complete the short lessons, use a starter project and save useful resources. Your progress stays in this browser; export it before clearing storage.

A small vocabulary that helps

Thin slice
The smallest end-to-end feature that delivers a useful result.
Acceptance check
An observable condition you use to decide whether a behavior works.
Context
Relevant code, requirements, errors and background supplied for a task.
Diff
A view of additions and removals between versions of files.
Regression
A previously working behavior that breaks after a change.
Environment
The runtime, configuration and services in which the code executes.
Checkpoint
A known working state you can return to.
Deployment
Putting the application into the environment where people will use it.
KEEP BUILDING YOUR UNDERSTANDING

A hub you can keep returning to.

Continue with the field guide, explore a deeper lab, or bring your next project back to the planner.

Open Field Guide V2 ↗Read the beginner guideVibe Learning ↗
Created by Laurence Svekis

Web Developer, Educator, Author, and Google Developer Expert.

Learn AI one practical skill at a time ↗

Content review: 2026-10-27. Provider-neutral guidance; no live model rankings or pricing claims.

Further reading: MDN testing strategies · W3C accessibility evaluation. Original lessons and practice scenarios by DiscoveryVIP.