Share on X

Writing / AI Agent

N° 06

What Is Vibe Coding? A Beginner’s Guide to Building Apps with AI—Tools, Steps, and Risks

Learn what vibe coding originally meant, how it differs from responsible AI-assisted development, and how to build a study timer by talking to an AI. This beginner-friendly guide covers tool selection, reusable prompts, hands-on testing, and the risks of handling personal data, credentials, and production systems.

You Can Build an App Without Knowing How to Program

Vibe coding is a development style in which you describe what you want in everyday language, then work with an AI to generate, run, and revise it through conversation. Instead of writing every line yourself, you might say, “Build a 25-minute timer” or “Make the timer easier to read.”

Being able to build something quickly, however, is not the same as being able to operate it safely. This guide walks you through a low-risk first project—a study timer with no login or payments—and shows you how to build it, test it, and decide whether it is safe to publish.

What Is Vibe Coding?

Asking AI to Build an App in Natural Language

A conventional development loop usually looks like this:

Design → write code → run it → investigate errors → make changes

With vibe coding, the central activity becomes a conversation with an AI:

Describe the product → let the AI generate it → run it → describe what feels wrong → let the AI revise it

The difference from an ordinary ChatGPT conversation is that you are not merely receiving an explanation or isolated code sample. An AI agent can create and edit files inside a project, run the application, and respond to the results. Your role shifts from typing code to specifying needs and judging behavior.

The boundary between vibe coding and no-code tools is not absolute, but their interaction models differ. No-code products generally ask you to assemble predefined components through visual settings. Vibe-coding tools generate code from natural language, offering more flexibility but also creating more room for hidden bugs or unsafe implementation choices.

Where the Term Came From

Andrej Karpathy coined “vibe coding” on February 6, 2025. His original description involved accepting AI-generated changes without reading the diffs, pasting errors back into the model, and continuing based more on visible behavior than on an understanding of the code.

Simon Willison has argued that the term should not be stretched to cover every use of AI in programming. If a person reads the generated code, tests it thoroughly, and can explain it, he classifies that as AI-assisted software development—not vibe coding.Simon Willison’s Weblog

How It Differs from AI-Assisted Development

For this article, we will use the following distinctions:

  • Vibe coding, broadly defined: using natural language to have AI generate code or an application
  • Vibe coding, narrowly defined: iterating from visible results without fully understanding the generated code
  • AI-assisted development: reviewing, testing, and understanding AI-generated work before accepting it

We will use the broader definition because it is more accessible to beginners. That does not mean publishing unreviewed output is a good idea. Vibe coding can be an excellent way to explore a prototype; software used by other people requires a much higher standard of review and testing.

What Can You Build with Vibe Coding?

A good first project should have limited consequences if it fails.

  • A habit tracker
  • A study timer
  • A quiz or personality test
  • A portfolio
  • A store or event information page
  • A simple calculator or aggregation tool

Avoid starting with services that process credit card details, store customer data, require complex authentication or permissions, or make consequential medical, investment, or legal decisions.

The right question is not simply, “Can the AI build it?” Ask, “If it fails, can I understand the impact and manage it safely?” A store page listing opening hours is very different from a booking system that stores customer records, even if both look simple on screen.

Beginner-Friendly Vibe-Coding Tools

Replit Agent

Replit Agent is a strong option if you want to create, run, revise, and publish an app from a browser. Replit says its Agent can plan changes, write code, debug problems, and explain behavior. Its official guidance also recommends being specific, planning first, and reviewing and testing the result.Replit Docs

Lovable

Lovable is a candidate for people who want to build a polished web interface visually. Its documentation recommends a “frontend-first” approach for beginners: create layouts, flows, and logic with mock data before connecting a database.Lovable Documentation

Bolt

Bolt is an AI builder for websites, web apps, and mobile apps. Its official quickstart covers building, editing, and publishing without writing code. The guide also notes that applications without database features generally build faster.Bolt QuickStart

v0

v0 is particularly useful when interface design matters. Its official documentation now covers full-stack apps with APIs, persistence, and backend logic—not just UI generation. It recommends an incremental workflow that begins with the interface and adds the data layer and authentication later.v0 Docs

The walkthrough below assumes Replit Agent because it keeps building, previewing, and publishing in one browser-based environment. The same prompts and checks can be adapted to other tools. Pricing, free allowances, and available features change, so consult each product’s official pages before starting.

Decide What You Are Building Before You Begin

Keep the first version deliberately small:

  • Purpose: track your own study time
  • User: only you
  • Screens: one
  • Required features: start, pause, reset, and today’s total
  • Storage: the current browser
  • Excluded features: login, sharing, leaderboards, payments, and a cloud database

The generated app may use a browser feature such as localStorage. You do not need to memorize that term, but you should understand the tradeoff: the record remains only in the same browser on the same device and can disappear if its browser data is cleared.

A useful initial prompt identifies the user, purpose, required features, excluded features, storage method, visual direction, and mobile requirements. Fewer features create a clearer definition of “done” and keep the app within a range you can personally test.

Hands-On: Build a Study Timer with AI

Step 1: Enter the Initial Prompt

Start a new project in Replit Agent and enter this prompt:

Build a simple study timer.

It should count down from 25 minutes and provide Start, Pause, and Reset controls. It should also display the total time studied today.

Store records only in this browser. Do not use login, external APIs, or a cloud database. Reset “Today’s total” when the date changes.

Use a single-screen, black-and-white design that is easy to operate on a phone.

Before implementing it, show me a short plan. When it is finished, list the behaviors I should verify.

You do not need to choose a programming language or framework. You should specify storage and exclusions, however; otherwise, the AI may introduce accounts or a database unnecessarily. Constraints are part of the requirements.

Step 2: Inspect the Generated Screen

You do not have to begin by reading the code. Test the product as a user:

  • Does Start decrease the time once per second?
  • Does Pause stop it?
  • Does Start resume from the paused value?
  • Does Reset return it to 25 minutes?
  • Does it stop at zero and add the completed time to today’s total?
  • Does today’s total remain after a reload?
  • Are all controls usable at a phone-sized width?

Any difference between the expected and observed result becomes useful input for the next prompt.

Step 3: Make One Change at a Time

Try focused requests such as:

Make the timer digits much larger. Do not change any other behavior.

Add a clear visual label when the timer is paused.

Show a confirmation dialog when Reset is selected. If the user cancels, do not change the timer or study record.

Bundling many revisions together makes it harder to identify which change caused a regression. Apply one change, then retest the main controls before continuing.

Step 4: Try Adversarial Interactions

Testing means checking not only the intended path but also common mistakes and awkward interactions.

  • Select Start several times in quick succession
  • Reload while the timer is running
  • Alternate between Pause and Start repeatedly
  • Try to start again after the timer reaches zero
  • Repeatedly select Reset and its confirmation controls
  • Check that completed time is not counted twice
  • Simulate a date change and verify the daily reset

When something breaks, report the observation and expected behavior instead of guessing at the cause:

Selecting Start twice makes the countdown run at double speed. Fix it so only one countdown process can run, and add a test that reproduces this problem.

If an error appears, paste it without shortening it—but first make sure it contains no API keys, passwords, or personal data.

Step 5: Request a Final Review

Once the interface looks finished, ask the AI for another pass:

Review the current implementation for interactions that could break the timer. Check duplicate start processes, stopping at zero, double-counting completed time, reload behavior, date changes, and mobile layout. Explain any problem and fix in beginner-friendly language, and add automated tests where practical.

Do not treat “No problems found” as proof that the app is correct. Repeat the same interactions yourself after every fix. AI review can support human testing; it does not replace it.

Step 6: Decide Whether to Publish

If the app is for you alone, leaving it in a private preview may be enough. Before publishing, verify that:

  • No name, email address, study record, or other personal information is embedded
  • No API key, password, or connection string appears in the code or interface
  • No test copy or unnecessary admin screen remains
  • The visibility setting matches your intention
  • Public viewing or misuse would not cause serious harm

A Publish button is not a safety or quality certification. Once an application is public, strangers and automated traffic may be able to reach it.

Risks and Safety Considerations

Working Does Not Necessarily Mean Correct

An app may render correctly and pass its main interactions while still failing on unusual input, rapid clicks, incorrect calculations, or permission checks.

A December 2025 preprint evaluated 200 tasks based on feature requests from real open-source projects that had resulted in vulnerable implementations. For one tested agent-and-model configuration, 61% of solutions were functionally correct, while only 10.5% were rated secure. This is not a universal defect rate for AI tools, but it illustrates why “functional” and “safe” are separate judgments.arXiv

Personal Information Can Be Exposed

Adding login and a database introduces authentication and authorization: the app must reliably decide who can read or change each record. Hiding a button in the interface is not sufficient to prevent access to underlying data.

For a first project, do not store names, addresses, phone numbers, health details, financial details, or customer information. For an internal business tool, begin with fictional data and check your employer’s policies or consult its IT team before using real company information.

Never Paste API Keys into Prompts or Client Code

An API key or access token is effectively a password granting access to another service. Do not place one directly in a chat, public source code, or browser-delivered code. Use the platform’s Secrets feature or server-side environment variables.

Replit’s shared-responsibility documentation similarly advises users to keep credentials out of prompts and use Secrets or Connectors instead.Replit shared responsibility model

Repeated AI Fixes Can Make the Project Harder to Manage

Layers of follow-up instructions can produce duplicate logic and unnecessary code, while one fix may break another feature. Stop adding features and request an explanation or experienced review if:

  • Every fix breaks something else
  • The AI repeats the same change
  • You cannot identify why a file or external service exists
  • Unexpected paid services or databases appear
  • The AI cannot explain the error or its own change

If the tool provides checkpoints or version history, save a recoverable state after each small, working change.

You Still Have Responsibilities After Publishing

A platform may secure its infrastructure and provide scanning tools, but it does not automatically guarantee your application’s permissions, data handling, visibility, or legal compliance. Replit’s responsibility model assigns application access control, data, security testing, and the choice of publishing visibility to the application owner.Replit shared responsibility model

Before moving to an app used by others, involving money, or supporting important business operations, have an experienced developer or security professional review it.

Five Ways Beginners Can Avoid Common Failures

  1. Start with one screen and roughly three core features.
  2. Ask for a short plan before implementation begins.
  3. Request one change at a time.
  4. Test repeated clicks, reloads, and empty input—not only the happy path.
  5. Before publishing, review security, personal data, secrets, and visibility.

A clever prompt matters less than building something small, operating it yourself, and reporting exactly how reality differs from your expectations.

Frequently Asked Questions

Can I Vibe Code for Free?

Some tools offer free usage, but may limit generations, consumption, or publishing. Prices and plan conditions change, so check the official pricing page before registering.

Can I Do It Only on a Smartphone?

Some browser-based services work on phones, but moving between the builder and preview and checking multiple screen sizes is generally easier on a computer. You should still test the finished app on a real phone.

Will Vibe Coding Teach Me Programming?

It can teach you the cycle of defining, building, testing, and improving a product. Simply approving generated output is less likely to develop code-reading skills. Ask questions such as, “Explain this change for a beginner” and “Which files did you modify?” to turn the project into a learning exercise.

Can I Sell an App I Built This Way?

It may be technically possible, but selling software introduces security, privacy, payments, terms of service, copyright, support, and legal obligations. Do not move directly from a working prototype to a commercial release without an experienced review.

Conclusion: Start with a Small Tool for Yourself

Vibe coding has dramatically lowered the barrier between an idea and a working application. That does not mean AI-generated software should be trusted without checking it. Build small, operate the result yourself, and investigate anything unexpected. Your best first project is a personal tool with no personal data, login, or payments.