When Software Becomes Speech
Vibe coding promises to democratize programming. It may instead make technical judgment harder to see, teach, and value.
Software used to begin with a blank file. Increasingly, it begins with a sentence.
Describe the thing you want, wait while a model produces it, and continue the conversation until the result looks approximately right. This is an extraordinary change in access. People who could not previously make software can now make something that behaves like it. Experienced developers can move from idea to prototype before the coffee has had time to become disappointing.
The usual name for this is “vibe coding.” The phrase is deliberately unserious, but the shift underneath it is not. Programming is becoming less like writing instructions for a machine and more like explaining an intention to one.
That sounds like the democratization of software. It may be. But when production becomes conversational, the knowledge required to judge the result can disappear from view. The machine makes code cheaper. It does not make consequences cheap.
The New Interface
Natural language is now an interface to computation. That matters because far more people can describe a desired outcome than can express it in a programming language.
The gain is real. A founder can test an idea without first assembling a technical team. A designer can make an interactive prototype rather than a static approximation. A developer can delegate boilerplate, migration work, tests, and documentation. Software becomes available to people whose expertise lies in the problem rather than the syntax.
Yet speech is imprecise in ways that code is not allowed to be. “Make the login secure” is a perfectly understandable request and a nearly useless specification. Secure against whom, under what conditions, with what recovery path, and at whose expense? A model can answer the unstated questions on your behalf. It cannot guarantee that you would have chosen the same answers if you had known the questions were there.
In 2026, the Association for Computing Machinery framed the practical question directly: can vibe coding scale to the high-quality systems on which people increasingly depend? Its answer placed renewed emphasis on verification through testing, static analysis, and proof.[1] The point is not that generated code is uniquely bad. Human beings have been producing insecure software with great confidence for decades. The difference is that generation allows uncertainty to scale faster than understanding.
Judgment Is the Work
Programming is often described as the act of writing code. That is the visible residue of the job, not the whole job.
Much of software engineering consists of deciding what must be true: where trust begins and ends, which failure can be tolerated, what state must survive, which dependency is worth accepting, and how a system should behave when the ordinary path stops being ordinary. Seniority is partly the accumulation of failures one has learned to anticipate before they become incidents.
Vibe coding can conceal this work because the generated artifact arrives before the reasoning that would normally produce it. The screen fills with competence. The unresolved questions remain blank.
Developers seem to understand the distinction. Stack Overflow’s 2025 survey found that 84 percent of respondents used or planned to use AI tools, while 46 percent distrusted their accuracy and only 33 percent trusted it. The most common frustration was a solution that was almost right; 45 percent said debugging generated code could take more time.[2] Adoption and trust are moving in opposite directions.
This is not necessarily a contradiction. We use many systems we do not fully trust because their output is useful when supervised. The danger appears when the ability to produce is mistaken for the ability to verify. Judgment becomes more important at the precise moment it becomes less visible.
The Missing Apprenticeship
Every craft contains work that looks inefficient from the outside because part of its product is the worker.
Junior developers learn by tracing boring bugs, reading unfamiliar systems, making small changes, breaking things, and discovering why the obvious solution was excluded three years earlier. The task is completed, but the person is also altered. Repetition builds the mental model later used to review larger decisions.
If a model absorbs the routine work, a company may receive the output without producing the experience. New developers can be placed in the strange position of supervising code they could not yet have written. They are promoted from apprentice to reviewer without passing through the long middle in which judgment is formed.
This is not an argument for preserving drudgery as a moral good. Calculators did not require schools to retain long division as the center of mathematics. They did require education to decide which understanding still mattered once arithmetic became abundant.
Software needs the same decision. If syntax, scaffolding, and implementation become cheap, training must move toward systems, debugging, security, specification, and evidence. Otherwise the industry will automate the ladder after its current experts have already climbed it.
More Code, Less Software
The economics of generated code are deceptively simple. When the cost of producing a line falls, we will produce more lines. But organizations do not create value by accumulating code. They create value through systems that remain useful, legible, and changeable.
Google’s 2025 DORA research described AI as an amplifier of the organization already using it. Strong feedback loops, clear documentation, good internal platforms, and disciplined review become more productive. Weak systems generate weakness faster.[3]
A controlled study by METR offered a related warning. Experienced open-source developers working on familiar repositories took 19 percent longer with early-2025 AI tools, even though they believed the tools had made them faster.[4] The result was narrow and the tools have improved, but the gap between perceived and measured speed is instructive. Generation feels like progress because something appears immediately. Integration, verification, and maintenance arrive later, when the feeling is harder to attribute.
As code becomes abundant, review becomes scarce. The bottleneck moves from typing to knowing what should exist, proving that it works, and remaining able to change it. A repository can grow while the software inside it becomes less understood.
What Becomes Valuable
The optimistic version of this transition is not a world without programmers. It is a world in which more people can make software and programmers spend more time on the parts that require judgment.
Getting there will require treating generated code as an acceleration of responsibility rather than an escape from it. Tests must become stronger, not ceremonial. Systems must expose their assumptions. Organizations must reward deletion, clarity, and restraint even when generation makes volume impressive. Education must teach people how to interrogate an answer that arrives fluent, plausible, and wrong.
The old status hierarchy rewarded the person who could make the machine obey. The new one may reward the person who can decide what obedience means, recognize when it has failed, and accept responsibility for the result.
When software becomes speech, fluency becomes cheap. Meaning what you say—and answering for what it does—does not.
Sources
[1] Association for Computing Machinery, Software Verification in the Age of Artificial Intelligence, 2026
[2] Stack Overflow, 2025 Developer Survey: AI
[3] DORA, State of AI-assisted Software Development 2025
[4] METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity