What if "vibe coding" is the real future of coding? Is "programming as theory building" a dead-end? Having a bit of an existential crisis here. Anyone else?
What is this "vibe coding"?
A certain level of existential crisis certainly seems warranted.
"Vibe coding" is letting an LLM handle the implementation while you as author care only about output/outcomes.
Popularized by Andrej Karparthy here: x.com/karpathy/status/1886192184808149383
š¦ Andrej Karpathy (@karpathy) on X: There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper
A better explanation here, with obligatory Rick Rubin references: linkedin.com/pulse/rick-rubin-meets-ai-vibe-codings-creative-takeover-cam-smith-nzvmc
š Rick Rubin Meets AI: Vibe Codingās Creative Takeover
Have you heard of "vibe coding"? Itās the latest shift in software development thatās making wavesāand itās not just for tech geeks anymore. Picture this: instead of grinding through lines of code, developers simply describe what they want in plain languageāābuild a sleek login page,ā ācut the sideb
Kartik Agaram that's literally my life philosophy in an image. In practice if I can't take a "nanna nap" in the afternoon, I just say "f?ck it!" and go think of something fun to do
thanks for helping me understand what this "vibe coding" is, folks! I have to go back over my twitter history and re-read all those references, now that I know what they're on about!
clearly the danger now is the same as the danger faced by non-technical managers of software projects: they had to trust that they're not paying for a tangled pile of unmaintainable cruft.
currently managers and "the business" look out for teams doing agile (in its latest incarnation) as the only reassurance of that, but as a dev I know teams still can get entangled even with simplest-code-that-works and constant refactoring and clearing of tech debt.
there'll be a Vibe Coding Manifesto soon where it'll be declared important that the AI documents everything it did and constantly refactors to recognise and remove tech debt
But as Jonathan Edwards and others (including me even as one of them) have explained - software engineers are paid big money to make things as complex as possible. It's a simple economic incentive structure.
At some point we'll reach the point where the AI's refactoring and abstraction approach simplifies away this incidental complexity - it'll start by them creating DSLs to express themselves better, then gradually all the layers will be dissolved away as unnecessary
At the end of that painful process, we'll hopefully be left with transparent technologies like end-user-focused, app-free and Data-First approaches, where we can genuinely be partners in coding even as non-coders, as it'll be a bit like discussing a spreadsheet with your accountant at that point.
On "app-free": AI is already "app-free" in the sense that no-one will or wants to talk to it in terms of apps! You just discuss the goal states of the domain objects in your digital life. Again there'll be a transition where the AI basically gets to the point where it's simply no longer efficient for it to have to do everything through these app and service boundaries, it'll simply arrange one way or another that the data and its (permissioned) access is simplified and normalised.
Key thing though for all that is humans persistently demanding transparency and simplicity from the AI
@Greg Bylenok I think you are setting up a false dichotomy. I expect that there will be a place for vibe coding, but it will complement rather than replace programming as theory building.
Consider the limits of vibe coding. What it comes down to is saying, in plain English, what you what to get done, and letting some machine fill in the details from an implicit context. That can only work as long as (1) your implicit context, i.e. your culture, is sufficiently similar to the machine's implicit context, which is its training material, and (2) the job you want to get done is a simple combination of well-established routine from the implicit context.
Something I'd love to see done in order to illustrate these issues is training an LLM exclusively on written material from 1900 or before. I expect that its users would quickly get frustrated.
That can only work as long as (1) your implicit context, i.e. your culture, is sufficiently similar to the machine's implicit context, which is its training material, and (2) the job you want to get done is a simple combination of well-established routine from the implicit context.
šÆ