Vibe coding for beginners

What vibe coding is—and what it is not

Vibe coding is a conversational approach to software creation. You describe the behaviour you want in ordinary language, an AI system proposes or edits code, you run the result, and the conversation continues. The Google Cloud concept explainer describes the broad idea and also distinguishes it from conventional AI-assisted development where a developer remains closely involved with the code.

The term does not name one product, model or formal engineering standard. People use it for everything from generating a disposable prototype to asking an agent to change several files. That range is why beginners need to state what kind of work they are doing and how much review it will receive.

Vibe coding is not evidence that code is correct, accessible, secure, private, maintainable or lawful. A clean interface can hide a broken edge case. A passing AI-generated test can repeat the same wrong assumption as the generated implementation. A confident explanation can still refer to an API that has changed.

It is also not a substitute for permission. Do not give a tool confidential client code, private repository content, credentials or personal records unless the responsible organisation has approved the tool and its data terms for that use.

The useful mindset is not “the AI built it.” It is “the AI proposed a change, and I can explain why I accepted it.”

The vibe coding roadmap gives you a sequence of topics to study. This guide focuses on the day-to-day control loop you can apply while building.

Prepare a safe place to experiment

Your first project should be easy to inspect, easy to delete and low-risk if it fails. A static page or local browser tool is safer than a system that sends messages, moves money, changes production data or makes decisions about real people.

• Choose one user and one task. “A learner saves a useful link” is clear. “Build a complete education platform” is not.
• Use synthetic information. Invent names and records. Do not paste phone numbers, national ID numbers, health details, school records or payment information into a prompt.
• Create a recoverable baseline. Put the project in Git and make a clean commit before the tool edits files. Read GitHub's explanation of Git and distributed version control if this is new.
• Keep the first version local. Do not publish until you have reviewed the repository for secrets, unsafe sample data and unexpected network calls.
• Write a stop condition. Decide what “done for now” means before the conversation expands into unrelated features.

A controlled beginner workflow

The safest workflow makes each change small enough to understand and reverse. It may feel slower than asking for the whole application in one prompt, but it gives you evidence about where a mistake entered the project.

1. Write the outcome in plain language

   Name the user, action and observable result. Add three to six acceptance checks. If you cannot describe how to verify the feature, the tool cannot infer a reliable finish line.

2. Show only relevant context

   Provide the current file structure, technology, error message and constraints needed for this change. Remove secrets and personal information. More context is not automatically better context.

3. Ask for a plan before an edit

   Request the files it expects to change, assumptions it is making, risks it sees and how it will test the result. Correct a bad plan before it becomes a large diff.

4. Generate one thin slice

   Ask for the smallest end-to-end behaviour: one form, one validation rule or one saved record. Explicitly keep authentication, payments, analytics and extra dependencies out of scope.

5. Read the diff before running it

   Use git status to see what changed and git diff to inspect the actual lines. Unexpected deleted files, configuration changes, packages or network calls are reasons to pause.

6. Run checks you chose independently

   Test the acceptance criteria, an empty value, an invalid value and a keyboard-only path. Do not limit testing to the examples the same AI generated.

7. Commit one understood improvement

   When the change is explainable and the checks pass, commit it with a message that describes the behaviour. If it fails, revert or repair that small change before adding another.

8. Record limits and stop

   Update the README with what works, what you tested and what remains unsafe or unfinished. Stop at the original definition of done; new ideas belong in a future list.

Prompt with a specification, not a mood

A productive prompt does not need special magic words. It needs enough information to make the result testable. Treat the prompt as a small work order that you will review.

This structure improves the conversation because you can point to the exact part that is wrong. If the tool proposes a database, you can refer to the no-backend constraint. If it produces no error message, you can refer to the acceptance check.

Useful follow-up prompts

• “Explain this diff in the order data moves through the feature.”
• “Which requirement is not covered by the current tests?”
• “Show me every new dependency, network request and browser-storage key.”
• “What happens with an empty value, a very long value and a non-HTTP URL?”
• “Change only the validation function and its tests; leave layout and dependencies unchanged.”
• “Give me the rollback steps before applying this migration.”

Avoid repeatedly saying “fix it” after a failure. Supply the exact error, the action that produced it, the expected result and the smallest relevant code. If the conversation has accumulated contradictory instructions, restate the current specification rather than relying on the tool to choose which old message still matters.

Review generated code in four passes

Code review is not only for teams. It is the moment you decide whether generated work enters your project. GitHub's primary documentation explains how reviews use comments and approvals to evaluate proposed changes; the same discipline applies to a local AI-generated diff. See About pull request reviews.

Pause when you see these warning signs

• A secret, token or password is placed in frontend code or committed configuration.
• User input is inserted as HTML without a clear sanitisation strategy.
• The tool disables a failing test, security check or type error instead of fixing the cause.
• A package is added even though the platform already provides the required feature.
• An authentication check exists only in the browser while protected data remains available from a server.
• The tool cannot explain a file it generated or refers to a function that is not present.
• A broad command deletes, overwrites or migrates data without a backup and rollback plan.

Asking the AI to review its own output can surface mistakes, but it is not independent assurance. Read important lines yourself, use another primary reference, and involve an experienced developer when the consequences exceed your ability to verify them.

Test behaviour, accessibility, security and privacy

“It opened in my browser” is a useful first observation, not a complete test result. Derive checks from the specification before looking at generated test suggestions.

Functional checks

• Complete the main task with ordinary valid input.
• Try empty, malformed, duplicate and unusually long values.
• Refresh, go back and repeat the action to expose state problems.
• Test a narrow viewport and a slower or interrupted request when the feature uses a network.
• Confirm the interface explains failure and preserves recoverable work.

Accessibility checks

Use the page without a mouse. Confirm that focus is visible, controls have programmatic labels, headings describe the structure, errors are connected to fields and content does not depend on colour alone. The W3C Web Accessibility Initiative's Easy Checks provides a primary starting point. Automated tools can help, but they do not replace keyboard and human review.

Security checks

Identify every untrusted input, privileged action, dependency and network destination. Validate on the trusted side of the system, keep secrets out of code sent to browsers, and grant an agent only the permissions it needs. Use the OWASP Top 10 to learn common web application risks and the OWASP Secrets Management Cheat Sheet for credential handling.

Privacy checks

List what the feature collects, where it travels, where it remains and how it can be deleted. Prefer synthetic records during development. Do not assume an AI vendor's chat, an editor extension and your deployed application share the same privacy settings; read each current policy separately.

Choose tools and control costs without hype

KODE Ń VIBE does not endorse a particular vibe coding product. Tools change models, limits, privacy options and prices, so copied comparisons become stale quickly. Check the vendor's current documentation and checkout terms on the day you decide.

Compare the parts that affect your work

• Review controls: can you see a plan and diff before files change, restrict commands, and undo a change cleanly?
• Permissions: does the tool need one file, a repository, a terminal, a browser session or cloud credentials? Can you reduce that access?
• Data handling: what content is sent, retained or used to improve services, and can an organisation configure those choices?
• Technology fit: does it support the language and project size you are learning without forcing an unnecessary framework?
• Portability: can you keep an ordinary Git repository and run the project without the tool?
• Usage and connectivity: how are requests measured, what happens at a limit, and how much network access does your normal workflow require?
• Price boundary: is billing fixed, usage-based or routed through another provider? Are taxes, model charges or deployment services separate?

Free tiers, student programmes and regional availability can change. Verify eligibility and renewal conditions with the provider rather than relying on a tutorial screenshot. Do not enter payment details until the seller, currency, recurring terms and cancellation process are clear.

Set a spending boundary before experimenting

• Use a disposable project to estimate how the tool counts normal requests.
• Enable a documented usage cap or billing alert where the provider offers one.
• Do not let an agent repeatedly retry a failing deployment or paid API call unattended.
• Record which external services a generated project uses and whether each can create a bill.
• Keep the code exportable so changing tools does not mean rebuilding the entire project.

Small exercise: build a learning-links board

This exercise is deliberately local and narrow. Build a static page where one learner can save a title, an HTTPS link and a topic, mark the link as read, and filter the list. Records remain in that browser. There is no login, sharing, analytics or backend.

If you would rather choose a different problem, use the beginner coding project ideas and keep the same small-scope rules.

Write this acceptance list before generating code

• The page explains that records stay in the current browser.
• A title, valid HTTPS URL and topic create one visible record.
• Empty or invalid values show a specific message and move focus to the problem.
• The list can be used and filtered with a keyboard at a narrow viewport.
• Read status and sample links remain after refresh.
• User text is inserted as text, not interpreted as HTML.
• Non-HTTP schemes are rejected and external links use safe link attributes.
• A clear-all action asks for confirmation and removes only this project's storage key.

Build it in four reviewed changes

1. Create the semantic shell

   Ask for the heading, explanation, labelled form, empty state and list container using plain HTML and the existing CSS file. Request no JavaScript yet. Check heading order, labels, focus order and mobile layout.

2. Add one in-memory record

   Ask for validation and an add action without persistence. Require safe DOM methods such as textContent for user values. Test empty fields, an invalid URL and a title containing HTML-like characters.

3. Add browser storage

   Specify one uniquely named local-storage key, defensive JSON parsing and a clear action that removes only that key. Explain that local storage is not encrypted or synchronised.

4. Add status and filtering

   Request a read/unread control with an accessible name and a topic filter that works from the keyboard. Re-run every earlier acceptance check so the new state does not break the core task.

Finish with evidence, not another feature

Review the final diff and dependency list. Confirm there are no requests to external servers. Add a README with the project purpose, storage key, setup steps, manual test results, known limits and the prompts or sources that materially shaped the work. Keep the commits so you can show how each slice changed.

Then change one requirement yourself—for example, make topic optional or add an edit action. That change reveals whether you understand the structure well enough to maintain it without restarting the conversation.

Primary sources and next steps

• Google Cloud: What is vibe coding? — a vendor's concept overview and terminology.
• GitHub: About pull request reviews — a primary reference for structured code review.
• GitHub: About dependency review — understanding dependency changes and risk.
• OWASP Top 10 — widely used awareness guidance for web application security risks.
• W3C WAI Easy Checks — preliminary accessibility checks from the standards body.
• Office of the Data Protection Commissioner, Kenya — current official data-protection information.

Continue with the vibe coding roadmap for an ordered topic list. If you are deciding whether this type of work fits your broader direction, use the tech career quiz as a reflection prompt, not an aptitude or hiring assessment. See the editorial policy for how KODE Ń VIBE handles sources, review dates and corrections.

Frequently asked questions