Code has always served two purposes: causal and expressive. The causal element is straightforward: code as recorded in a text file can bring about desired effects in the world (more directly an interpreter, or less directly through compliation, distribution to multiple machines, etc.).

The expressive element is just as economically important. Code expresses some view of a problem and its solution which the author can refer to in the future, and which others can in principle understand (see Peter Naur's "Programming as Theory Building", linked below).

Apologists for vibe coding argue that only the former role of code is economically relevant today, because LLMs can take an expression in prose (natural language) and bring about desired effects. Whether code is an intermediate step in that process is now an uninteresting implementation detail.

This view is premised on a misunderstanding: that natural language is suitable for expressing what needs to be expressed. In fact, programming languages (e.g. Rust, Typescript) are the end product of tremendous amounts of investment in figuring out how to think clearly about the effects a computer program can bring about. Efforts to replace formal languages with prose have been attempted in every generation since the 1960s, have never succeeded, and will not succeed so long as our purposes in programming computers are so different from our purposes in talking to one another.

In the main, LLMs are in fact useful for manipulating code, but code will remain an indispensable moment in the software development lifecycle.

https://pages.cs.wisc.edu/~remzi/Naur.pdf

Notwithstanding the above, there are of course domains where truly "single serving" programs (i.e. generated once, run a few times, never modified) are genuinely valuable. But most demand for software is not single serving and cannot be transformed into demand for single serving software.

For my latest project, I did spec driven development and Opus 5.5 generated 7000+ lines of code. Around 500,000 tokens were spent on iterating on the spec document alone, while me and Opus both asked clarifying questions to each other to nail down specifics.

Granted, Opus writes better code than me and has better picture of the codebase which comes in handy when making small adjustments, once the code is ready and tested. I do ask Opus to keep cyclomatic complexity of the code low, so it does not look obfuscated at all and the blast radius of such changes are smaller.

While stepping through the code, I still found issues. For example, it did not validate max_turn value for an agent harness, so it was possible to run infinite turns with a non-integer input. We have some organizational complexity with multiple model gateways, and Opus made some wrong assumptions about model availability. There were 4-5 such issues that wouldn't be visible if I was not doing step-by-step debugging.