Vibe coding might be the most consequential trend of the decade. People contest over its definition. But mine is simple: If you don't understand the code AI wrote, you're effectively vibe coding it.
Vibe coding is not coding at all. The word is technically oxymoronic. Part of coding requires that we actually understand it. If you know it works, but don't know why it works, you're a vibe coder.
Last week, the CEO of Cursor made an announcement. Their agent vibe coded a browser. FastRender took a week and produced three million lines of code. I admit this is technically an amazing feat.
But what caught my attention from the announcement, however, was also what may be the most expensive sentence in the history of software: “It kind of works.”
Google's Chromium has 37 million lines of code. Its development spans 19 years and stands as a testament to how complicated browser development really is. Microsoft moved Edge to Chromium for a reason.
So the question becomes unavoidable: can three million lines of code, written in a week, scale to the carefully crafted 37 million lines of code written over decades?
On another note, the whiteboard app tldraw recently announced that they are pausing contributions from external contributors because of AI slop. Curl also recently announced that it's shuttering their bug bounty program for similar reasons. And human-in-the-loop is made mandatory at LLVM.
This exposes a fundamental reality. Making good software is far too different from making "just usable" ones. Because good software isn’t written. It’s painfully grown by humans who remember why things broke in the first place.
AI can scale shoddy code. But to scale good code that is performant and secure, we need iterative development. This requires feedback, reviews, knowledge sharing, coordination, communication, collective context, and, most importantly, responsibility.
Pre-defined tests rarely limit critical bugs. Because they usually arise when users use the tool in unintended ways. They cannot be predicted. Let alone be tested. For those, we need raw human intelligence, not AI brute force.
AI makes writing code fast. But also makes understanding it hard. Because we don’t understand the code, it nullifies our ability to improve it over time.
Yet, and this is a big yet, AI has created a precedent among product owners to have things built far too quickly. They need speed over quality. They need “good enough” software that can be shipped fast. AI excels here.
People in charge of the products are usually not engineers. They don’t understand codebases. They don’t understand the implications of shipping shoddy code. They just want to ship features the next day. And test them for business viability.
The responsibility of making sure the codebase is maintainable, scalable, and secure falls on the engineers. The engineers will be forced to leave behind AI-driven technical debt for them to fix in the future. And hope that the future never arrives.
This creates a paradox. Short-term business requirements are satisfied, gambling on long-term sustainability. This is not a new problem. But a mightier comeback of an existing one.
The new software engineer has a weighted responsibility of appeasing both ends of the business early on. While the people in charge of deliverables may never understand this bargain. And might never will.
The fix is simple: understanding must again be a first-class citizen.
Regardless of how good or terrible human programming was, being forced to understand what we wrote played its own part in making the software better over time.
But now with AI, understanding has become optional. It needs discipline from the engineer's end to prevail. Maybe a larger cultural transformation has become the need of the hour.
Remember, AI grants you enormous power. And as Uncle Ben said — with great power comes great responsibility.
Top comments (0)