In his February 2025 X post[1], Andrej Karpathy gave the name vibe coding to a delightful experiment: describe the result, let a model write the code, accept changes quickly and keep going even when the implementation becomes hard to follow. It made the experience of making a little application feel remarkably different.
A detail in his description matters: he presented it as something amusing for disposable weekend projects. He did not claim that a company should stop understanding the software on which employees and customers depend.
Where that method is excellent §
For a prototype, the cost of exploring an idea can drop from days to an afternoon. Someone without a conventional programming background can build a personal utility. A designer can try a new interaction in the browser. An engineer can discover what they want before investing in a permanent architecture.
The risk arrives when a prototype inherits responsibilities its author never planned for. A billing system can lose money. A support form can expose customer details. An impressive demo can fail when a second person uses it under a different account. At that point the software needs tests, clear ownership and a way to repair it without guessing what the code means.
A useful distinction the debate lost §
Simon Willison's 2025 essay[2] makes a distinction between using AI to write code and vibe coding as deliberately not reviewing the implementation. The former can include responsible engineering. The latter is an unusually accessible form of experimentation.
We have encountered that difference throughout Aurekai. A room planner becomes a real shopping application only when it preserves the selected product and price. A generated CRM screen becomes useful only when it opens the customer's actual records under the correct account.
The response is not to reject Karpathy's idea. It is to keep his original context intact. Experiment freely, then do the additional work the product requires when somebody else begins depending on it.
Sources and further reading
References point to original material linked in the essay, not independently invented citations.
- February 2025 X postx.com↩
- Simon Willison's 2025 essaysimonwillison.net↩
Related reading
More articles that explore this subject from another angle.
As code gets cheaper to produce, maintenance, trust, distribution and coordination may matter more.
Read the earlier argument ↗Another essay leads hereA vulnerability has a number. Your risk has a context.CVE identification, technical severity, exploit conditions and business exposure must not collapse into one red badge.
Read the earlier argument ↗