Vibe coding is creating software by asking an AI model in natural language and accepting the code it generates without reading or reviewing it. You describe what you want, test if it works, and when it errors, you paste the message back into the chat. It works well for a weekend prototype, but it can get expensive when the system stores data from other people or goes into production.
Next, you will see where the term came from, how the practice works in day-to-day life, when it makes sense, and what risks arise when no one looks at the code.
Where the term came from
The expression was coined by Andrej Karpathy, an experienced programmer, in a post on the X network in February 2025. He described a way of programming where you surrender to the "vibes" and forget that the code exists: you accept the changes suggested by the model without reading the code. Karpathy himself said he found this acceptable for disposable weekend projects.
Martin Fowler, a well-known author in the field of software engineering, provides a useful criterion for separating things. For him, those who use AI to write all the code but continue to review and take care of the structure are not doing vibe coding. That is another practice, which he calls agentic engineering.
How it works in practice
Imagine you want an app to track household expenses. In vibe coding, the script usually goes like this: you write "create a web app with a login where I can enter expenses and see a graph by month," the tool generates dozens of files, you run it, something breaks, you paste the error, the AI fixes it, and so on until the screen looks right. At no point do you open the code to understand what it does.
Tools used
In the original post, Karpathy mentioned Cursor, an AI code editor, using the Composer feature, and a voice dictation app to talk to it almost without touching the keyboard. Today, the same style appears in three types of tools:
- code editors with built-in AI assistants that suggest and apply changes across multiple files;
- programming agents that run in the terminal and execute commands, install packages, and alter the project on their own;
- platforms that generate an entire app from a text description.
What defines vibe coding is the way of use, not the tool. Any of them can be used with or without review. Features and product names change quickly, so it's worth checking the official documentation of each one before choosing.
When it makes sense
Fowler summarizes it well: vibe coding fits with disposable software, used only by the creator or a small group that understands the risks. Some examples:
- a prototype to show an idea to the team before investing development time;
- a personal script that renames photos or organizes spreadsheets on your computer;
- an experiment to learn how a library works;
- a simple internal tool, with no personal data and no internet access.
In these cases, if the code breaks or gets messy, the loss is small and you throw it away and start over.
When it gets risky
The risk increases when the system is complex, has many users, or holds information that is not yours. Fowler points out frequent maintenance, correction, and security issues, and considers security to be the most serious.
Security of the generated code
A study by Veracode published in July 2025 tested over 100 language models on 80 programming tasks related to known vulnerabilities. In 45% of the cases, the generated code had vulnerabilities. Against cross-site scripting (XSS), the models failed in 86% of the tests; against log injection, in 88%. In Java, the failure rate exceeded 70%. And larger models did not perform much better than the smaller ones.
In practice, this means that a form generated by the AI could accept a malicious script and display it to other users. If you don’t read the code, you won’t notice.
API keys and exposed data
When you ask "connect to the payment service" and paste your key in the chat, the AI may place it directly in the code, even on the client side, where any visitor can see it. The same goes for overly open database rules that allow anyone to read the user table. These are simple mistakes to catch in a review and easy to overlook when no one reviews.
Nonexistent dependencies (or that are traps)
OWASP, an open community of reference in application security, lists in its Top 10 risks for applications with LLM (2025 edition) the generation of insecure code and the suggestion of libraries that do not exist. The described scenario is real: attackers test programming assistants to discover package names that the AI tends to invent and publish malicious packages with those names in popular repositories. Those who install without checking take the malware along.
Quality, maintenance, and technical debt
Without paying attention to the code, vibe coding produces a lot of low-quality code in a short time, as Fowler observes. The app works today, but no one can explain why, and every correction requested from the AI may break another part. This is the technical debt: a cost you pay later, when you need to change something and discover it is easier to rewrite than to understand.
Privacy and LGPD
If your app collects name, email, CPF, or any data from individuals, the General Data Protection Law (Law 13.709/2018) applies. Article 46 requires technical and administrative security measures to protect that data from unauthorized access, and paragraph 2 states that they must be observed "from the product or service design phase to its execution." Article 48 requires the data controller to inform the national authority and the data subjects about incidents that could cause significant risk or harm. "The AI wrote it" does not change who is responsible for the system.
Best practices for usage without exposing yourself
You don’t need to give up AI. You need to replace "accept everything" with some habits:
- Read the code before publishing. If you don’t understand a piece, ask the AI to explain and check.
- Never paste API keys, passwords, or real customer data into the chat. Store secrets in environment variables and outside the repository.
- Check each suggested package in the official repository before installing: see if it exists, who maintains it, and if it has real use.
- Run security and dependency analysis tools on the project, as you would with code written by a person.
- Write tests for the parts that handle login, payment, and personal data.
- Separate prototype from product. What originated in improvisation should be reviewed or rewritten before receiving real users.
- If there is personal data, think about LGPD from the start: collect only what is necessary and protect access.
OWASP's recommendations go along the same lines: human supervision, cross-checking with reliable sources, and secure coding practices to avoid incorporating flaws from incorrect suggestions.
Frequently asked questions
Is vibe coding the same as programming with AI?
No. Vibe coding is accepting code without reviewing it. Using AI and reviewing the result is another practice, which Martin Fowler calls agentic engineering.
Can someone who has never programmed do vibe coding?
Yes, and many people do it for personal tools. The problem starts when the app stores data from other people or goes online without someone understanding the code.
Do newer AI models solve the security problem?
You can't count on that. In the Veracode 2025 study, larger models did not have significantly better security performance than the smaller ones.
If the AI made a mistake, whose responsibility is it?
The LGPD requires security measures from data processing agents, that is, those who collect and use the data. The tool used to write the code does not change that.
Next steps
Take a project you created with AI and do a quick review: look for keys in the code, list the dependencies, and confirm that each one exists in the official repository. To deepen your understanding of programming and security fundamentals, explore the Hcode course platform.
Sources
Vibe Coding, Martin Fowler (martinfowler.com), May 21, 2026.
AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals, Veracode, July 30, 2025.
LLM09:2025 Misinformation, OWASP Gen AI Security Project, updated April 17, 2025.
Law No. 13.709, of August 14, 2018 (General Data Protection Law), Presidency of the Republic, consulted on October 27, 2026.