Vibe coding means building an app by describing what it should do to an AI tool in plain language. I explain what that looks like in practice, which tools I use, where savings are made, and where the risks lie, using the example of a 3D print farm management app that I built in less than a month.
Vibe coding is a way of building software where the application is not written line by line, but instead, you describe what it needs to do to an AI tool in plain language, and it generates the code. The term was coined in early 2025 by Andrej Karpathy, one of the founders of OpenAI and former Director of AI at Tesla, and in a short time, it went from a social media joke to a common way of working.
In this text, I explain what vibe coding is, which tools are used today, where the actual savings are, and what the risks are. I will show all of this using the example of a 3D print farm application that I built this way. If you run a small business and are interested in what the service itself looks like, read the text vibe coding and app design for small business.
What is vibe coding
Classic software development is like building a house. A designer draws a plan, and programmers spend weeks or months bringing it to life. Any change on the fly means that something already done has to be torn down and rebuilt, which costs money.
With vibe coding, large language models write code based on descriptions. Instead of syntax, you give the AI tool intent: what the application should do, for whom, with what data, and under what rules. The tool returns a working version, you try it out, tell it what is wrong, and so on in a loop until the result is good.
From syntax to intent
The biggest change is in who can lead the development. Previously, it had to be someone who knew a programming language. Today, it is more important for someone to be able to describe the problem precisely and recognize if the solution is good. For you as a client, this practically means three things:
- The person who understands your business directly instructs the AI tool what to build: the database, logic, and screens. There is no middleman between the idea and the creation.
- Changes are done quickly. If you want the data to be displayed differently, it is usually a matter of minutes or hours, not a new development cycle.
- The goal of the first version is not perfect code, but a working application that people can try out immediately.
How it differs from no-code tools
No-code tools give you pre-made blocks that you assemble into an application, so you can only build what the platform allows. With vibe coding, actual code is generated, the same as a programmer would write. This means there are no predefined limits, but also that someone has to understand what was built and verify it.
Tools used in 2026.
There are many tools and they change rapidly. I choose them based on the project, and these are the groups worth knowing:
- Google AI Studio: the tool I used to build the application in the example below. You describe what you need, and it generates an application that you can immediately open and try out.
- Lovable and Bolt.new: tools that build complete web applications with a database directly from the browser. They are good for quickly reaching a first working version. I described how I use Lovable and how you can build your first app in my step-by-step Lovable guide.
- Replit Agent: an agent that, in addition to writing code, can also set up the environment in which the application runs.
- v0 (Vercel): useful for generating individual interface components that look neat and professional.
- Cursor and Windsurf: code editors with a built-in AI assistant. They are useful when the first version needs to grow into a more serious product, meaning the code needs to be cleaned up and reviewed.
The math: where the savings really are
A first version of a product (MVP) or an internal tool traditionally requires multiple roles: a project manager, a designer, frontend and backend developers, and a tester. Each of these roles costs money, and a good portion of time is spent on coordinating them. Vibe coding does not make thinking about the product cheaper, but it shortens the phase where the idea is turned into code.
Classic development vs. designer-led vibe coding
| Item | Classic team | Designer-led vibe coding | What this means for you |
|---|---|---|---|
| People | Multiple roles: project manager, designer, developers, tester | One designer with AI tools | You pay for the work of one person, with no coordination overhead |
| Time to first version | Usually several months | In my practice, a few weeks for a smaller tool | You see sooner if the solution works |
| Cost of changes | High, because already written code is being changed | Low while the application is small and simple | You can change your mind while learning what you need |
| Biggest risk | Budget and deadline | Code quality and security without review | Verification must be part of the process |
For founders who self-fund their projects, this is often the most sensible first step. Instead of the entire budget going into one version of the product, you can make a working version, get it into people's hands, and only then decide what is worth investing in further.
A real-world example: an app for a 3D print farm
The client runs a 3D printer farm. Tracking printers, material inventory, orders, and finances was done through notebooks and Excel spreadsheets, which became unmanageable as the business grew. Classic development of a system of this scope would mean a multi-month project with an entire team.
What I built
I built the application in the Google AI Studio tool. It has three main sections:
- Dashboard with analytics: a central view showing the operation of each printer.
- Inventory and orders: the flow from receiving an order to deducting the used material from stock.
- Work management: logic that helps determine the printing queue.
The complete, functional application was delivered in less than a month. Instead of spending weeks writing specifications for programmers, I built the logic and database directly, through conversation with the tool. Most of the time was spent on what is normally my job: how the owner and employees move through the application, what they need on the first screen, and where they might make mistakes.
Where the application is today
The application is a finished product that the client uses internally for the needs of their farm. Daily operations show which features are used most and which can be left aside, so further changes are made based on actual usage.
Important note: the client could later license this application commercially, but it is currently used only internally. If licensing happens, I recommend that the code first be reviewed and optimized by a team of developers, as a product used by other companies has stricter requirements than an internal tool. Since the application already exists and works, that job requires less time and money than development from scratch.
If you are interested in what such a project would look like for your company, in another text I described step-by-step what collaborating on app development looks like.
Why the outcome depends on design, not the tool
It is a common misconception that AI builds the application on its own. If you give the tool vague instructions, you will get bad software, just faster than before. The quality of the result depends on how well someone understood the problem before they started describing the solution. I addressed the broader question, will AI replace designers, in a separate article.
A designer is trained to think about the user: in what order people do their work, what information they need at what moment, and what will confuse them. When such a person leads vibe coding, they do not deliver a screenshot for a programmer to interpret, but a working application.
No loss in translation
In the classic process, a designer imagines how something should behave, and a programmer implements it as much as the deadline allows. Part of the vision gets lost along the way. When the same person both designs and builds, there is no such translation, so the details of the user experience remain as imagined. With internal tools, this is visible in whether employees use them gladly or try to avoid them.
Risks and the "Vibe & Verify" approach
Speed must not come at the expense of security and sustainability. AI writes code that works, but it does not guarantee that the code is secure or clean. That is why I work on the "Vibe & Verify" principle: everything the tool builds must pass verification.
- Verification of critical parts: everything related to money, user login, and personal data is reviewed and tested manually, regardless of who wrote the code.
- Technical debt control: code generated by AI can easily become messy if features are just stacked on top of each other. That is why I set up the application structure at the beginning and stick to it during development.
- Testing with the help of other AI agents: I use agents whose job is to try to break the application and find bugs before users run into them.
- Testing with real users: the people who will work in the application test it with their own data before regular use begins.
When vibe coding is not the right choice
This way of working is good for internal tools, smaller applications, and first versions of products. It is not a good choice when the system processes sensitive data of a large number of people, when it has to support many concurrent users, when it depends on complex integrations with multiple external systems, or when it is subject to strict regulations. In those cases, you need a team of experienced developers, and a working version built with vibe coding can serve as a precise specification of what needs to be built.
Conclusion
Vibe coding has shortened the path from idea to a working application, but it has not eliminated the need for someone to understand the problem, set up the structure, and verify the result. With that oversight, a small company can get a custom-tailored tool in a few weeks, as shown in the 3D print farm example.
A real-world example is the design of the SimpleCRM platform.
If you have an idea for an internal tool or a first version of a product, get in touch. I will tell you openly whether this is a good path for your project or if you need a classic development team.
