From idea to prototype
Vibe coding: how to turn an idea into a working prototype
Here, vibe coding means development with AI assistance through requests, code review, and repeated checks. Our reading-list exercise uses an assistant-authored browser fixture, not a benchmark of an external AI service. The sample request is proposed wording, not an executed model conversation.
Start with one user and one useful action. Describe successful behaviour, request a small change, inspect it, and test it against that description. A useful prototype lets you demonstrate boundaries and explain unresolved questions. A finished-looking first screen does not establish that.
Choose one user and one job
“A useful learning app” leaves almost every decision open. Choose a person, situation, and action: a learner wants a short reading list while choosing the next text. The first task is to add a title and see it in the list. Explain that before discussing colours or extra screens.
Write down the start and completion of the action. Here, the learner starts with a labelled title field and finishes with a visible item. Removal supports the same task. Accounts, recommendations, sharing, and a catalogue answer different questions and are outside this exercise.
If choosing is difficult, list alternatives and select one with an observable result. Make the decision testable. Small scope still needs care; it gives you fewer moving parts to understand.
Write the brief before requesting code
Describe accepted and rejected behaviour in plain language. For our list: a non-empty title can be added with Enter; empty or whitespace-only input creates no item; removing the last item brings back an empty-list hint. Text containing angle brackets must remain text. State that a fresh page starts empty, because this exercise does not include saved storage.
Record unknowns and exclusions beside requirements. You may not know whether readers need lists across devices or whether duplicate titles are allowed. Avoid invisible assumptions: clarify questions affecting the next change and leave the others open.
Keep the brief beside the implementation and use it to review changes. The useful-prompts guide can help organise context and expected output. For this exercise, give invented book titles only; personal information adds nothing to the learning task.
Request one small, reviewable change
A proposed request is: “Create a reading-list interaction with a labelled title field, an add action, and an empty-list hint. Add trimmed, non-empty titles with Enter. Show each title as plain text with a remove action. Restore the hint when the list is empty. Keep data only in this page session. Explain the changed parts and list anything you have not checked.”
This is a starting brief, not evidence of correct AI implementation. After reviewing it, request a specific improvement separately, such as a clearer rejection message. Retain earlier requirements so the next change does not quietly remove keyboard support or introduce storage.
Compare additions with the brief. If accounts or an external connection appear, pause that addition and question its necessity. Save a working version through the project’s existing process to compare changes and recover from regressions.
Inspect behaviour, not only appearance
GitHub warns that code suggestions can appear correct while being inaccurate or insecure; human review and testing must consider context and architecture. See its responsible-use guidance.
Read changed parts and trace input to the displayed result. Try empty input, spaces, an ordinary title, and removal, then repeat. Check whether focus and labels support keyboard use. A visible button does not establish that its action works.
MDN explains that browser validation helps user feedback but cannot replace server-side validation when a server receives the data. See its form-validation guide.
Our page-only exercise has no receiving server. Adding one later would require a fresh review of how data is accepted and handled. Do not infer those protections from the current input message.
Read the bounded teaching example
We checked the isolated teaching fixture in a browser. Empty input and spaces created no item. Enter added an Armenian title. The string “<b>Sample</b>” appeared literally rather than becoming a bold-text element. Removing the items restored the empty-list hint; loading the fixture in a fresh document started the list empty again.
The checked layouts, 390 and 1280 pixels wide, had no horizontal overflow; no page errors were observed. These are observations about this assistant-authored fixture, not results from an external AI coding service. The fixture used no server, saved storage, or external network connection.
Record input, expectation, observation, and outcome. Angle brackets check literal display, not every security property. Two widths describe only those layouts. A fresh-page reset confirms no persistence, not behaviour after connection failure: the exercise has no connection.
Describe a failure, change one thing, and retest
For a proposed failure-reporting exercise, imagine: “On an empty list, I entered three spaces and pressed Enter. I expected no item and a clear message. Instead, a blank row appeared.” This is a hypothetical defect, not an observed failure in our checked fixture. Include the starting state and exact action so another person can reproduce a real problem.
Ask for a correction to that behaviour while preserving ordinary title entry and removal. Review the change, run the failing case again, and repeat the neighbouring cases. Fixing blank input could accidentally block a real title; changing removal could leave the empty-list hint hidden.
Record uncertainty rather than requesting a broad rewrite. If you cannot explain changed logic or assess its consequences, give the brief and reproducible case to a reviewer. The beginner ChatGPT guide offers related preparation for clearer follow-up requests.
Hand over evidence and open decisions
A working prototype answers a bounded question. Its handoff should include the brief, current files, steps to demonstrate the action, checks performed, and known limits. Separate observed results from intended behaviour. Name missing persistence explicitly so a reviewer does not mistake a reset for lost production data.
A real service introduces decisions about users, access, data, maintenance, and failures. These need separate requirements and review. A successful local interaction does not settle them. This guide stops at the prototype, without a first-website publication walkthrough.
Choose the next step from evidence: clarify a need, fix a reproduced defect, or request review of an extension. The professions overview provides wider learning context. Compare the Vibe Coding programme with your goals without treating this exercise as a promised course outcome.
Key takeaways
- Define one observable action and its boundaries.
- Review each small change and retest the relevant cases.
- Hand over observed results, open decisions, and known limits.
Frequently asked questions
Do I need to understand the code?
You need enough understanding to explain and review the changed behaviour, or help from someone who can. A successful demonstration does not replace code review, and AI assistance does not remove responsibility for what you use.
Should I request the entire app at once?
Start with the smallest useful action and explicit acceptance checks. Add another step only when you can review the current one. This makes it easier to identify which change introduced a problem.
Does a working prototype save user data?
Only if storage was deliberately included and checked. Our teaching fixture starts empty on a fresh page. Saving across visits or devices is a separate requirement with additional design decisions.
What should I do after the first successful check?
Repeat the important rejection and recovery cases, record limitations, and review the next need. You can compare the Vibe Coding programme with your goals; this article promises no particular course result.
Sources
Checked: