A New Coding Workflow: Conversation Over Syntax
When former OpenAI founding member Andrej Karpathy recently described a style of development he called "vibe coding," the term spread quickly. His description was direct: build projects by talking to AI, see what comes back, run it, and repeat until it mostly works. The reaction split opinion—some saw a creative unlock, others saw the erosion of programming fundamentals. Either way, the label gave a name to a practice many developers were already exploring.
The underlying idea is not entirely new. Software development has always moved toward higher levels of abstraction, from assembly to C to Python and onward. Nick Baumann, Product Marketing Manager at Cline, frames AI-assisted development as the next chapter in that abstraction story. What changed is the interface: instead of writing instructions line by line, the developer describes intent and the model generates code. The skill shifts from syntax to direction.
Faster From Idea to Working Prototype
For some practitioners, this conversational loop restores an early sense of play. Charmaine Lee, Product Manager at Val Town, compares the casualness of building this way to scribbling in a doc or spinning up a spreadsheet. Vincent van der Meulen, Software Engineer at Figma, credits the approach for letting him build a running coach without knowing SwiftUI, and later a loading animation for a Wikipedia-like app. He sees colleagues already using it for prototypes.
The accessibility argument is backed by usage numbers. Amjad Masad, CEO of Replit, reports that 75% of the company's customers never write a line of code. Historically, the gap between conceiving an idea and expressing it in a working program has been a bottleneck. Nikolas Klein, Designer working on prototyping at Figma, describes vibe coding as less about coding per se and more about a faster route to expressing and iterating on interactive ideas.
Where the Workflow Breaks Down
The honeymoon phase, however, does not last indefinitely. Van der Meulen notes that projects start enjoyably but hit a "valley of despair" once complexity outgrows what the model can handle. Figma Software Engineer Anro Robinson describes getting 80% of the way to a goal, only to end up with disorganized code lacking a coherent internal model, after which prompting fails to fix details and manual editing becomes unmanageable.
Julius Tarng, Research Engineer Resident at Anthropic, compares the outcome to a late-night fever dream with blocks of commented-out code and a working result that would never pass review. The concerns go beyond untidy files. Carmen Ansio, Design Engineer at LottieFiles, warns that skipping code review leads to problems with maintainability, accessibility, and long-term quality. Without reading the output, debugging becomes trial and error, and interfaces may function while lacking structure and inclusivity.
Several observers argue the terminology itself is off. Designer Ryan Mather says the practice is less like steering by vibes and more like "QA whack-a-mole." Figma Developer Advocate Jake Albaugh agrees that the word "vibe" misleads: when you have a precise goal, the process is not a vibe but a source of frustration.
A Tool for Those Who Already Know the Craft
Despite the messiness, the approach has earned a place in the toolbox. Barron Webster, Founding Designer at Sandbar, suggests it benefits people with prior programming experience more than complete novices, much as a pastry chef knows why croissants fail to rise while a cafe customer would not. Charmaine Lee now handles low-lift tasks directly instead of delegating every tweak, comparing it to editing a Google Doc rather than emailing the owner.
The effect also shows up in role boundaries. Van der Meulen sees engineers thinking like designers and designers thinking like engineers, with everyone acting as "orchestrators." He describes vibe coding as one of the first concrete examples of how the roles of design, engineering, and product management are converging.
The consensus is not that careful engineering has become obsolete. Carmen Ansio stresses that AI serves as a creative partner but still demands thoughtful engineering to build scalable, accessible experiences. Charmaine Lee argues that removing friction makes the craft of software more vital, not less. And as the workflow matures, new review mechanisms will be needed; Van der Meulen suggests teams may one day review diagrams rather than code diffs.
The question may not be whether this conversational style replaces traditional development—it will not—but how much it widens the circle of who can build software and how teams structure the work.
