Vibe coding is a way of building software. You describe what you want to an AI tool, accept the code it returns, and move on to the next feature. You do not read that code. Andrej Karpathy, a founding member of OpenAI, coined the term in February 2025. The idea spread fast because it works: a person with no programming background can get a working prototype in one day.
Why the shortcut is tempting
The first version of any product has one job: to show that the idea works. Vibe coding is good at that job. It is cheap and fast, and it needs no team.
A demo for investors, an internal tool for three people, a test of a new page layout: all of these are good examples. That code will be replaced or thrown away, so its quality does not matter much.
The problem starts when the prototype is not thrown away. It gets customers. Then it gets a second developer, a payment provider, a mobile app and a security questionnaire from a large client. Software that was built to show an idea now has to carry a business.
Where it breaks
A recent LinkedIn post by Craftsmen, a software engineering company, lists the moments when the difference shows. We see the same list in our own work.
Vibe coding can get software moving fast. The real engineering challenge starts when that software has to survive scale, changing requirements, multiple teams, production incidents, security reviews, and years of continuous development.
Each item on that list is a concrete event, not a theory.
- Scale. The site worked with 50 orders a day. At 5,000 orders, the page that loads every product into memory stops responding.
- Changing requirements. The discount rule was written in three places. Someone changed two of them. Customers in one country now pay a different price.
- Multiple teams. A new developer opens the project and finds no structure, no tests and no notes. Every change takes three times longer than the first version did.
- Production incidents. Something breaks at 2 a.m. There are no logs that say what happened, so the fix is a guess.
- Security reviews. A large client sends a questionnaire. The answer to the question “where do you check what a user sends” is “in the browser”. A browser check protects nothing, because a visitor can bypass it.
- Years of development. The libraries that the AI chose in year one have no updates in year three. Upgrading them breaks half of the features.
None of these problems is visible on day one. All of them are expensive on day five hundred.
What engineering discipline means in practice
Engineering discipline is a set of habits that keep software changeable and safe for years. It is not a document. Each habit has a concrete form.
- Architecture. Someone decided how the parts fit together and wrote the decision down with the reason. A new developer can read why, not only what.
- Clear boundaries. The price is computed in one place. The code that builds an email never touches the database. When a rule changes, it changes once.
- Standards. The code looks the same in every file, so a reviewer sees a mistake instead of a difference in style.
- Automated tests. A machine checks the important rules before every release. A wrong price fails the check instead of reaching a customer.
- Observability. Observability means logs, measurements and alerts. When something breaks, the team knows what broke and when, without guessing.
- Security. What a user sends is checked on the server. Secrets stay out of the code and the logs. Someone reviews the system for weaknesses on a schedule.
- People who own the decisions. An engineer can explain every part of the system and takes responsibility when the system fails.
How we use AI
We use AI tools every day. They write a large share of our code, and they draft documentation and tests. We do not plan to stop. The speed is real, and our clients get it.
What we do not do is skip the engineering. In our projects, every change passes the same automated checks before it can enter the main branch. The code must compile without type errors and the style rules must pass. The production build must succeed, and the texts and prices of the site must pass their own checks.
Anything that involves money is computed on the server and is never trusted from the browser. Our price configurator shows a live total in the browser. The server computes the same total again from the raw choices before it sends an order confirmation.
Every decision that a future developer will ask about is written down with the date and the reason. A person reads and signs every change. AI writes the code. A person owns it.
Six questions for your vendor
If you are ordering software, you do not have to read the code to judge the discipline behind it. Ask these questions and listen for concrete answers.
- Who decided the architecture, and where is that decision written down?
- What runs automatically before each release, and what happens if it fails?
- Where are the price, the discount and the tax computed, and can a visitor change them?
- When something breaks at night, how does the team find out, and what does it see?
- How does a new developer learn the system in the first week?
- When was the last security review, and what did it find?
A vendor with discipline answers each question in one or two sentences. A vendor without it changes the subject.
Speed and discipline
AI did not remove engineering from software. It moved the engineering. The engineer now decides what the code must do, checks that it does it, and owns the result.
Vibe coding is a good way to start. It is a bad way to continue. The companies that get the most from AI use it for speed and keep the discipline for everything the software will depend on later. That combination costs less than the alternative: build it fast, then build it again.
