Vibe coding is programming by describing what you want in natural language and letting the AI write the code. The expression came out of a February 2025 post and, in November of the same year, became the Collins dictionary’s word of the year. Today you can create a site, an automation, or a simple app without typing a line of code.

The useful question is not whether it works, but how to use the tools without putting something online that you do not understand. This article shows the kinds of tools, a safe step-by-step, and the limits of the method.

Reported on October 12, 2026. The tools cited change features and prices often; check the official documentation before you choose.

Where vibe coding came from

On February 2, 2025, Andrej Karpathy, former AI director at Tesla and one of the founders of OpenAI, described on X “a new kind of programming” in which you “give in to the vibes” and “forget that the code exists”. He said he talked to the assistant by voice and accepted the changes without reading the diffs. Source: Karpathy’s post.

The term caught on. Collins chose “vibe coding” as the word of the year for 2025 and defined it as the use of AI, driven by natural language, to help write code. Source: Collins Dictionary.

It is worth separating two things. The developer Simon Willison proposes a narrow definition: vibe coding is generating code with AI without reviewing what was generated. Using AI and then reading, testing, and understanding the code is AI-assisted programming, not vibe coding. Source: Simon Willison. The difference matters because it defines how much you can trust the result.

The three kinds of tools

The tools divide by where the AI works and by how much control you keep.

TypeHow it worksExamplesWho it is for
Browser app generatorYou describe the app in a chat and get a working project, with a live previewLovablePeople who do not program and want a fast prototype
Editor assistantThe AI suggests and edits code inside the editor, file by fileGitHub Copilot, CursorPeople who already use a code editor
Terminal agentThe AI reads the whole project, runs commands, runs tests, and proposes changesClaude Code, Gemini CLI, CodexPeople who maintain larger projects

The farther left you go on the table (browser generator), the less of the code you see. The farther right (terminal agent), the more the tool acts on its own, and the more it matters to have tests to check what it did.

To start, choose by your starting point, not by the tool of the moment: no experience with code, a browser generator; you already use an editor, an assistant; a project with several files and tests, an agent.

A step-by-step for using it without regret

The flow below applies to any of the three categories.

  1. Write what the software should do before you open the tool. A paragraph with the goal, who uses it, which data goes in, and what comes out. The AI fills gaps with assumptions; the fewer gaps, the fewer surprises.
  2. Ask for one thing at a time. “Create the signup screen” works better than “create the whole system”. Smaller requests produce changes you can check.
  3. Run and test each change. Open the result, click, and fill in wrong fields on purpose. If the tool allows it, ask for automated tests and watch them pass.
  4. Save versions. Use the tool’s own history or a Git repository. When the AI breaks something that worked, and that happens, you go back in seconds.
  5. Ask for explanations. Ask “what does this snippet do?” and “what data does this code send outside?”. If the answer does not make sense, do not publish.
  6. Review security before you publish. Passwords and API keys never stay in the code; forms need to validate what they receive; user data requires care under the LGPD.

Step 6 is not excess caution. In 2025, Veracode tested more than 100 language models on 80 programming tasks and found security flaws in 45% of cases; against cross-site scripting attacks (script injection into pages), the models failed on 86% of the tasks. Newer or larger models did not do better on security. Source: Veracode.

In short: generated code usually works, but working is not the same as being secure.

Where vibe coding works and where it does not

It works well for:

  • prototypes to validate an idea before you invest;
  • internal and personal tools, used by a few people;
  • simple automations, such as organizing spreadsheets or renaming files;
  • learning: asking the AI to build and explain is a good way to understand new code.

It calls for extra care when:

  • the system handles payment, a password, or personal data;
  • many people will depend on it day to day;
  • someone will need to maintain the code a year from now.

In those cases, the path is assisted programming: the AI writes, but a person reads, tests, and answers for the result.

Assisted programming: the practices I use

Update note (October 29, 2026): this section incorporates the post “Programming with AI: the practices that separate help from harm”, published on July 31, 2026, which ceased to exist as its own page.

This blog, the training portal, and the bot that monitors official sites were born with an AI assistant at the keyboard. What that routine taught fits in one sentence: AI amplifies what is already in the process. Where there is discipline, it becomes speed; where there is haste, it becomes damage at scale. The practices below are in use, and each one was born from a real stumble.

  1. Code the AI delivers as “done” is only proposed. Nothing is done until a test actually runs. Here, every change goes through a battery of automatic checks before publishing, and what cannot be executed is declared “not tested”. A font swap that looked perfect on Windows failed the layout test on Linux, where the fallback font was a different one; no reading of the code would have caught that.
  2. An API the model cites may not exist. The model invents a method, a parameter, and a library with the same confidence it uses when it is right. The rule: either the AI shows the real documentation, or it states in writing that it is guessing. A declared guess can be checked in a minute.
  3. An executable contract in the middle of the path. Each post on this site goes through a content contract that fails the build when something breaks the rule. It has already blocked a tag outside the list and a description that exceeded the limit by one character. The contract does not distinguish whether the person or the AI made the mistake, and that is why it protects on both sides.
  4. A small change, read by a person. With AI you produce more code per hour, and a superficial review becomes automatic approval under another name. The change needs to fit in an honest review, and nothing reaches production without human approval.
  5. Check it in the published environment. A green test does not end the work. A generic style selector once misaligned a badge on the page without any test flagging it. Automation proves structure; finish only shows up for whoever looks at the published result.
  6. House rules in writing. The project’s conventions live in a file the AI reads before it starts, and what gets learned becomes project memory. What is recorded guides, but the instruction of the moment wins, and a conflict between the two is declared, never resolved in silence.

Before you accept what the AI wrote, answer: did a test run this code? Does every cited API exist in the documentation? Is what stops the error before production code, or good intentions? Does the change fit in an honest review? Did someone look at the published result? Is what was agreed written where the next session will find it? If any answer is “no”, that is the practice that is missing.

An example from the other side: using tools that already exist

Not every problem calls for new software. Merging PDFs, converting an image, or running a recurring calculation already has a ready-made tool, and building your own only makes sense when none of them fits.

Transparency: BRUP — Ferramentas Úteis is a project of this blog’s author. The site gathers online tools and step-by-step content that teaches how to use each one. We have already measured here whether BRUP’s tools send your files to a server, with the procedure open for you to repeat.

What to do now

Vibe coding lowered the barrier to creating software, but it did not remove responsibility for it. Choose the tool by your starting point, ask for one thing at a time, test each step, and review security before you publish.

If what you need already exists, start with the ready-made tools at BRUP — Ferramentas Úteis and follow the step-by-step for each one. If it does not exist, use the script in this article and build yours.

Sources