Taha
Öztürk
Frontend & AI Developer. I build user-focused web interfaces and speed up work with AI tools and automation.
Tip: Drag windows by their title bar, resize them from the edges and double-click the title to maximize.What is Vibe Coding? Where it works and where it fails in real projects
Short answer
Vibe coding is a development style where you describe software in plain language to an AI, let it write the code, and guide the process by testing the output without reading every line. It is incredibly fast for prototyping and personal tools, but real products with users and data require manual code reviews, testing, and security audits.
Frontend & AI Developer I build web interfaces and use AI to speed up how work gets done.
Short answer
Vibe coding is a development style where you describe software in plain language to an AI, let it write the code, and guide the process by testing the output without reading every line. It is incredibly fast for prototyping and personal tools, but real products with users and data require manual code reviews, testing, and security audits.
Vibe coding means explaining software to AI in plain language, having it write the code, and testing the result without reading the code itself. It reduces prototyping to a few hours, but in a product with real users, it returns as unread code, security vulnerabilities, and maintenance issues. Below, the questions of what is vibe coding, how the term changed, what the numbers say, and where it is useful in a real project find their answers.
Vibe coding is a development style where the developer describes the desired software to an AI in natural language and has the AI write the code. The developer runs the result and checks it; if they dislike a part, they state it again in a plain sentence, and the AI fixes it. The code itself is not read.
In Turkish, it is sometimes translated as "sezgisel kodlama" (intuitive coding). Since developers have adopted the English version, this article uses that term as well.
It would be wrong to call every task involving AI-written code "vibe coding." The distinguishing question is simple: Is there someone who reads, understands, and takes responsibility for the code written by the AI? If so, that work has other names that emerged by the end of 2025.
The term was coined by Andrej Karpathy in February 2025. Karpathy, who was part of the founding team at OpenAI and previously led the AI team at Tesla, was describing a new coding habit in a post on X. He described letting himself go into the flow, accepting changes suggested by the AI without reading them, and pasting error messages back into the model without adding any comments when an error occurred. He described this method as a not-so-bad way for projects that he would write over a weekend and then throw away.
The expression quickly spilled out of the software world. Collins Dictionary selected "vibe coding" as the 2025 word of the year.
As the term spread, its meaning expanded as well. When every piece of code written with AI began to be called "vibe coding," two new expressions emerged.
Developer Simon Willison proposed the term vibe engineering in October 2025. In this article, he defines vibe coding as the "fast, loose, and irresponsible" way of producing software with AI. On the opposite end, there is a way of working where experienced developers accelerate using AI agents while taking responsibility for the output. According to Willison, what makes this possible are automated tests, planning before starting, regular version control, and code reviews. The main idea of the article is this: AI tools augment existing expertise.
Karpathy held a similar position in his assessment written in February 2026 for the first year of the term. He explained that professionals no longer write most of the code, but instead manage and supervise the agents that write the code. He suggested the name agentic engineering for this way of working. The second half of the name emphasizes that the work is a real, learnable, and improvable expertise.
The difference between the three expressions lies in who reads the code:
| Approach | Who reads the code? | Suitable for |
|---|---|---|
| Vibe coding | No one | Prototype, one-off tool, experiment |
| Vibe engineering | Developer, along with tests | Product to be released |
| Agentic engineering | Developer, by managing multiple agents | Large and ongoing projects |
Regardless of the tool, the loop is the same:
How clear the initial request is directly determines the outcome. The difference between "Make a nice site" and "Create a three-section, light-colored landing page that collapses to a single column on mobile" is visible in the very first attempt. Adding an acceptance criterion to the request also helps: a sentence like "Show an error message if the form is submitted empty" defines what the AI considers "finished." Writing a good prompt is a subject for a separate article.
It is possible to divide vibe coding tools into roughly two groups.
Tools like Lovable, Bolt, v0, Base44, and Google AI Studio allow you to produce applications by chatting in the browser without installing anything. They show a preview instantly right next to the chat and deploy most applications with a single click. For someone who doesn't know how to code, these are the easiest starting points. Most of the security research mentioned below was conducted on applications built with these tools, because a user who never sees the code also fails to see a missing security configuration.
Claude Code, Cursor, OpenAI Codex, and Google Antigravity work within the project folder on your computer. They read and modify files, execute commands, and run tests. Since the developer retains the ability to see and change the code, this group is preferred more by software engineers. Vibe engineering and agentic engineering are also mostly performed with these tools.
Discussions about vibe coding are often based on impressions. There are a few measured data points available, and they do not always align.
You no longer need to spend days to see if an idea works. When presenting a new idea to a client or a team, a clickable prototype prepared in a single afternoon is more convincing than most presentations. If the idea doesn't stick, the loss is limited to a few hours.
A script that cleans a CSV file, a simple calculation sheet for the team to use, or a data transformation tool that will be run once and then deleted falls into this category. In these kinds of tasks, the only expectation is the correct result, and this is where vibe coding saves the most time. The common denominator is that they are not exposed to the internet and do not hold anyone's personal data.
When trying a new library or language, starting from a working example generated by AI is much faster than starting from a blank file. After running the example, the developer who opens and reads the code learns the new technology much faster. Those who move on without reading the code are left with nothing but a working output.
Problems begin the moment the resulting product has real users.
AI writes working code, but the code it writes is not always secure. Veracode tested over 100 language models in July 2025 with coding tasks where they had to choose between a secure and an insecure path. The models chose the insecure path in 45 percent of cases. In Java, this rate was over 70 percent.
The situation is no different in live applications:
The most common errors found in these studies are:
None of these become apparent while testing the application. The page loads, the form works, and everything seems fine. A developer who does not read the code will only notice the problem when someone exploits the vulnerability.
There are also attacks targeting the AI tools themselves. These attacks, which attempt to redirect the agent using instructions hidden in a web page or document that the agent reads, are called prompt injection. A separate article will cover this topic.
Language models sometimes suggest installing libraries that do not actually exist. A study published at USENIX Security 2025 examined 576,000 code samples generated by 16 models. At least 5.2% of the packages suggested by commercial models and at least 21.7% of those from open-source models did not exist, resulting in a total of over 205,000 hallucinated package names.
The risk is this: If an attacker publishes a malicious package with a name that models frequently hallucinate, a developer who tells them to "install" without reading the code will manually add that package to their project. Security researchers call this attack slopsquatting. Checking whether every new package suggested by AI truly exists, who published it, and how many people use it largely eliminates this risk.
In July 2025, SaaStr founder Jason Lemkin conducted a 12-day vibe coding experiment with Replit's AI agent. On the ninth day, despite instructions not to make changes, the agent deleted the production database. According to eWeek, the records of 1,206 administrators and more than 1,196 companies were lost. The agent initially stated that the data could not be recovered, but Lemkin later restored the data himself. Replit subsequently separated development and production databases automatically and added a planning mode where the agent cannot make changes.
The damage an agent can cause is limited by the authority granted to it. Every experiment conducted with an agent that has access to a production database is performed with real user data.
Fixing unread code is difficult. The first version comes out quickly, but three months later, when a small change is needed or a bug appears, no one knows how the code works. When asking AI for a fix, it can break one part while repairing another.
AI solves every request based on the current context. In a project that grows with dozens of requests, several separate functions doing the same job, conflicting data structures, and unplanned dependencies accumulate. Unless someone looks at the project as a whole, this accumulation does not fix itself; it grows slightly with every new request.
AI agents worked intensively during the development process of this site. The site is a portfolio with a desktop operating system appearance: windows open and close, they are draggable, and each window has its own address. Astro and Cloudflare Workers run in the background. The agents accelerated most of the work. However, two incidents clearly demonstrated the cost of accepting code without reading it.
The first was regarding SEO. The pages looked perfect in the browser. However, the URL inspection in Search Console revealed that Google saw almost no content on the pages. JavaScript was generating the content after the page loaded, so in the HTML coming from the server, the content existed only as raw data. A visitor saw no difference, but Google encountered an empty page. The solution was to render the content on the server, but to get there, we first had to understand what the code was doing.
The second was related to screen sizes. The messages window looked seamless on the developer's screen but did not fit on smaller screens. Measurements taken across five different screen sizes showed that the window overflowed to the right at a width of 1280 pixels, leaving the "Send" button off-screen. The AI had correctly calculated the window position according to the design dimensions. Since small screens were not included in the request, it had not accounted for them.
After these two incidents, the following workflow was established in the project:
This workflow largely overlaps with the steps Willison lists for vibe engineering. According to Willison, the work done by someone who reads, tests, and understands the code written by AI is not considered vibe coding, but AI-assisted software development. Vibe coding works well during the prototyping stage. For code intended for production, the second path must be followed.
Even someone who cannot read code can perform certain checks. For most of the items in the list below, it is enough to ask the AI the right question or check the tool settings:
You don't need to in order to start. Tools like Lovable or Bolt are sufficient to produce a working application without writing any code at all. As the application grows and reaches real users, being able to read the code and understand errors becomes increasingly important.
In vibe coding, the developer does not read the code written by the AI; they only check the result by experiencing it. In agentic engineering, agents still write the code, but the developer sets the plan, reviews the code, verifies it with tests, and takes responsibility for the outcome. Andrej Karpathy suggested this term in February 2026 as the professional counterpart to vibe coding.
Yes, but it must pass a security check first. You should not deploy the application without ensuring that API keys remain secret, database access rules are defined, and user data is protected. The checklist above is a starting point for this.
The trend is moving in the opposite direction. As writing code accelerates, deciding what to write, building the architecture, and verifying the result become more valuable. These tasks still belong to the developer.
Most tools have a free plan, but they have daily or monthly usage limits. This is sufficient for small experiments, but for regular use, you generally need to switch to a paid plan.