Vibe Coding is here, what next?

Karpathy coined “Vibe Coding” to describe a flow-like state where developers code as if in a creative trance. The developer drives intent; the editor delivers code. Despite its pitfalls, vibe coding is here to stay. So what comes next?

With vibe coding, accuracy becomes crucial. You can’t afford silent errors from the editor.

Most importantly, we need to know what code is being written. Not a single line of code needs to go into production without the following two things:

• Reviewed by at least two people
• Tested with thoughtful, human-crafted test cases

If you are speeding up development by creating code, then are we not free to review and learn what came out of it?

If vibe coding gives you speed, use the headroom to explore better alternatives and make smarter choices.

For example:

• Flask vs FastAPI vs Django — which suits your needs best?
• Functional vs OOP — what fits the problem better?

Vibe coding may document functions well, but the overall system still needs human-level clarity — through tests, examples, and diagrams. As Guido van Rossum said, “People read more code than they write.” The same applies to systems.

Finally vibe coding helps you read through the created code and make faster iterations on it, helping you to be in control of the code that is being generated. You need to be in a position to read fast, evaluate fast and identify the drawbacks of the created code helping you to understand what modifications can make it better at every step.

In the next article we will learn how to exactly use vibe coding as a process highlighting the steps and components in vibe coding that help devs to rapidly prototype and build systems.

TL;DR

• Code faster, think deeper.
• Learn what your tools just wrote.
• Make better choices before coding.
• Document so others (and you) can follow.
• Less time per dev cycle = More dev cycles per sprint