TLDR; Software development, as it has been done for decades, is over. LLM coding tools have changed it fundamentally for the better or worse.

“Talk is cheap. Show me the code.” — Linus Torvalds, August 2000

When Linus Torvalds, the creator of Linux, made this quip in response to a claim about a complex piece of programming in the Linux kernel, ^[1] I was an oblivious, gangly, fledgling teenage n00b coder learning by copy-pasting open source Perl and VB snippets over dialup internet.

The quip has since become an adage in the software world. The gist of it back then was that, it was easy to talk about all the software stuff one would like to do, or could be hypothetically done, but unless one actually put in the effort and proved it, talk wasn’t of much value. Writing and proving good software was a high-effort, high-cost, high-skill endeavour.

Even when armed with a crystal clear software development plan and the exact know-how to implement it, any sufficiently complex piece of programming is high-effort, tedious, and time consuming to actually write and get to a form where it is functional, reliable, and at least reasonably future-ready. In the process of developing software, any number of unforeseen complexities and gotchas can arise with many unresolvable trade-offs,^[2] both technical and external. It is not uncommon for software architectures to change mid-way multiple times. The cost of just trying things out is so exponentially high that the significant majority of ideas are simply never tried out.

After all, the real bottleneck is good old physical and biological human constraints—cognitive bandwidth, personal time and resources, and most importantly, the biological cost and constraints of having to sit for indefinite periods, writing code with one’s own hands line by line even if it is all in one’s head, while juggling and context-switching through the mental map of large systems. And if it is more than one individual, a whole host of interpersonal coordination and communication dynamics come into play. It is thus very difficult to prototype and try out not just grand ideas, but even reasonably simple ones. As many of us have done, most ideas are generally appended to a bottomless wishlist where they very likely stay forever. That’s how I have programmed and written software on a regular basis and enjoyed it—from hobby stuff to critical systems that millions of people depend on—for about 25 years.

All that has now been thrown out of the window, of course, for better or worse.

Coming back to Linus, fast-forward 25 years, when he merges a chunk of AI-generated code into his toy project and comments “Is this much better than I could do by hand? Sure is.”, ^[3] I, no longer the fledgling n00b, but someone with decades of software development scars and calluses (both physical and metaphorical), am able to grasp its implications. Not only that, now with a sizeable amount of first-hand experience with LLM-assisted coding, I am compelled to say, software development, as it has been done for decades, is over. Along with that, many other things are too.

I say that with the full awareness that it smacks of Fukuyama’s The End of History, ^[4] but I will reiterate:

Software development, as it has been done for decades, is over.

I

I was lucky to be in the transitionary Goldilocks era to witness and to partake in the breakneck evolution of the internet and software landscape—dialup to DSL to gigabit; Basic, Visual Basic 4/5/6 and Delphi; rise and fall of cgi-bin; Altavista to Google; XMLHttpRequest kicking off Web 2.0; rise and fall of Flash; death of IE and the rise of Chrome; WAP to Symbian to Android and smartphone apps; the demise of SourceForge and the massive proliferation and success of FOSS (Free and Open-source Software); git and GitHub; rise of SaaS; ExpertsExchange to StackOverflow; the growth of the Linux world; sysadmin to devops to whateverOps; the ominous birthing of Node.js and MongoDB in the same year; microservices; the explosion of VC-funded software “unicorns”; crypto and web3 shams; the rapid darkening of patterns; widespread enshittification and monetisation of privacy, attention, and dignity; and the monumental bloating of software that has since become the norm.

All throughout this, I have been writing, maintaining, and deploying software both as a professional developer and as a FOSS hobbyist dabbling in a gazillion languages, frameworks, tools, and methodologies. From thinking that “indenting code is lame” (cringe) as a teen, from copy-pasting to CVS to svn to git, fighting space vs. tab battles, to maturing to “whatever floats your boat” and still regularly compressing PNGs to shave off a few KBs, I have been a dabbler, dilettante, and an addict, someone who has unconditionally enjoyed writing code and developing software.

But now? How I develop software now is not how I have done it all these years, all the right, wrong, good, bad, easy and hard bits combined. With the advent of code-assisting LLMs, it has been completely flipped on its head, and I don’t think there is any going back.

Now, that is some “Tears in rain”-esque ^[5] monologue right there.

Code

Barring a bunch of obvious objective 101s, there is no universal measure of what makes a codebase good or great. Styles, idioms, patterns, architectures all vary greatly. Even objectively provable technical choices are subject to trade-offs that defy consensus. For a software developer like me, historically, there have been a few rule-of-thumb indicators for quick evaluation of software. When I evaluate a FOSS project, I look at a bunch of factors, all a mix of objective and subjective, weighted differently under different contexts—the project’s age; is the commit activity overly sparse or frantic; frameworks and dependencies; is code consistently organised and commented without being over-abstracted; is there a community around it; are maintainers responsive; can I actually get it up and running quickly from a clear README; the quality and depth of its documentation …

Many of these rule-of-thumb signals give a reasonable glimpse of the mental model and the style of working of the maintainers and the likely future trajectory of the project. For example, concise comments, README, and documentation indicate thoughtfulness, extra effort, and empathy for other developers (and self). Mainly because, for mortal developers like me, documentation and tests are a necessity, but unpleasant, boring, and tedious things to write and maintain.

Well, those notions have now been abruptly and violently defenestrated by LLMs. They can now one-shot generate stunning looking documentation pages, dense (ironically, pedantically detailed) READMEs, build great looking user interfaces, neatly organise code with proper idioms, patterns, and comments. One can no longer know whether such a repository was “vibe” coded by a non-technical person who has never written a single line of code, or an experienced developer, who may or may not have used LLM assistance. These no longer indicate the quality of a codebase. On the contrary, the more stunning or perfect looking something is, the more suspicious it is now—was it low-effort, one-shot vibe coded?

With the tell-tale, rule-of-thumb measures of code and software quality being outright dead, without a much closer inspection and a bit of expert forensic analysis, it is now difficult to tell the wheat from the “slop”. One is now slowly being compelled to also look much more closely at the provenance of software—the who, why, their track record, and plans of governance.

Effort

Historically, it would take a reasonably long period of consistent effort and many iterations of refinement for a good developer to produce 10,000 lines of quality code that not only delivered meaningful results, but was easily readable and maintainable. While the number of lines of code is not a measure of code quality—it is often the inverse—a codebase with good quality 10,000 lines of code indicated significant time, effort, focus, patience, expertise, and often, skills like project management that went into it. Human traits.

Now, LLMs can not only one-shot generate that in seconds, they can handle many technical aspects of the software development workflow, from testing to sysadmin to publishing. Unlike the unpredictable outcomes of frenzied vibe coding, when steered with human expertise, the output can be high quality and highly effective.^[6] This has been my personal experience as well. On a regular basis, I have been compressing work that would have taken me weeks and months to mere days and even hours. That too, without vibe coding, an AGENT.md file, or any fancy multi-agent workflows or orchestration. Just an LLM agent CLI at arm’s length.

As a developer with a bottomless wishlist of things I wish I could have done or tried out, I have been able to use LLM tools to not just rapidly prototype and validate complex ideas, but actually write good quality production-grade software (my own subjective metric, of course) with better code than I could have written manually—things where I knew exactly what I had to do, but was constrained by physical limits, and also things that were unclear to me and needed novel ideas, approaches, and leaps. All the while, learning and bettering my own understanding of things.

The physiological, cognitive, and emotional cost I generally incur to achieve the software outcomes I want or am capable of engineering, has undoubtedly reduced by several orders of magnitude. The time and bandwidth this has freed up, I now spend on engineering, architecting, debating, tinkering, trying to expand my imagination, and writing much more concise and meaningful code that I actually want to write.

Remember the old adage, “programming is 90% thinking and 10% typing”? It is now, for real.

Slop

Given all that, what is the value of code as an artefact, when it can be generated at an industrial scale within seconds by someone who has never written any code? Barring obviously bad LLM-generated code, when code is neatly structured and functional (yes, LLMs can write good code when steered competently), what makes it valuable or not? We wouldn’t want LLM-generated code in systems out there in the real world, but would instead prefer pure unadulterated human code, yes? Well, that would be a wonderful joke.^{[7] [8] [9] [10] [11]}

The reality is that the significant majority of the code written by humans globally on a daily basis, is likely borderline junk.^[12] Software development is not even a discipline that has reached any objective level of maturity. Medical doctors and civil engineers go through rigorous training to be issued licenses that are contingent on real world ramifications of their work. How about software developers and engineers? The world runs on shoddily engineered, poorly cobbled together, bloated systems with garbage code that humans have written, mostly directed by people in positions of power with perverse incentives who have absolutely no technical know-how or have any grounding in the humanities—the tyranny of non-tech “tech leaders”.^[13]

One could, to trigger emotions, argue that AI slop is at least neatly formatted, well documented, and more syntactically consistent than the vast majority of human-written code. ( ͡° ͜ʖ ͡°)

Kidding aside, I am no fan of AI slop. Reading those obvious soulless LLM-generated messages and articles on the (dead) internet^[14] is a waste of neuronal activation in the amygdala, if there is any activation at all. That so many people across the world LLM-speak and emote in the exact same manner on the internet, is creepy self-Pluribus-ification.^[15] Without human creation, perfection and flaws, language, literature, art, music etc. are unenjoyable (to most). Infinite, instantly-generatable stuff without human constraints and limits, is actually very difficult to value.

As is code, then? Well, code is a bit different from art, literature, or any form of direct communication and evocation. Code was always a means to an end. Unlike poetry or prose, end users don’t read or care about code. They don’t care what language or framework or the architecture the hundred systems running behind a portal are made of. Code is hidden. They interact with the effect and outcomes of code through various forms of UX. I say that, slightly begrudgingly, as someone who enjoys writing, organising, and even nurturing code. For those who are immersed in it, there is an element of creativity and art in it, and many like me, are borderline curmudgeons on all things software.^[16]

Ignoring outright bad code, in a world where functional code is so abundant that “good” and “bad” are indistinguishable, ultimately, what makes functional AI code slop or non-slop? I am strongly inclined to think that it is the framework of accountability, and ironically, the element of humanness. That is, all things (code) being equal, the ability to hold someone accountable at least emotionally and morally (and sometimes legally), for an artefact, instills value.

When one gets that big pull request (PR) on an open source repository, irrespective of its quality, if it is handwritten by a human, there is an intrinsic value and empathy for the human time and effort that is likely ascribed to it. It is known that there is a physical and cognitive cost that has been paid writing a lot of code before raising a PR. That is what makes that code “expensive” and not cheap.

When a PR is obviously LLM-generated, irrespective of how good it is, the first reaction is likely to be “slop!”, because it is no longer possible to instantly ascertain the human effort behind it. On the other hand, the effort required to read and validate it is disproportionately and exponentially high—setting aside people who have also offloaded reading of code to LLMs. It may very well be the best possible functional code, but it is one out of an infinite possible variation that could have been generated with no human cost or effort. Emotionally, it feels wrong and unfair to be burdened by such code dumps.

And, at that point, our reality has become a version of Borges’ Library of Babel.^[17]

FOSS

Speaking of libraries, FOSS is perhaps the greatest public commons that humanity has created. The genesis of FOSS and its predecessors, various schemes for sharing code, can be traced to the fundamental premise that software was prohibitively expensive and required immense specialist skills to create. Only a tiny handful of people in the world had the ability to do that, and everyone else was naturally forced to use the creations of the few (proprietary or not). While the global developer ecosystem has exploded since then, the ratio of makers to users has largely remained the same. Largescale FOSS collaboration and community dynamics all stem from that—codebases as valuable shared artefacts.

What happens in a world where code is cheap and small to medium-sized software libraries and modules can be quickly created by an expert, perfectly customised and attuned to their needs, no matter how niche? Forget expertise, a world where anyone reasonably savvy can vibe code the small things they need for their private use, however they please. I see this happening everywhere. What is happening to StackOverflow^[18] is also happening to software, although not as dramatically. This seems to strike at the very heart of the human dynamics, societal conditions, and incentives that drive FOSS collaboration and sharing. Add to that, if one considers the impending Cambrian explosion of FOSS projects manufactured at an unprecedented scale, the high-quality FOSS projects that remain and thrive, expert governance, curation, and trust are likely to become more valuable than the code itself.

Missing the forest for the trees

Humans have produced amazing software when there was no syntax highlighting, IDEs, or any kind of tooling. And humans also produce trash despite all the tooling and resources in the world. A good competent developer with good articulation skills and care for quality will use LLMs, or any other tools, in their own ways to produce quality outcomes. An incompetent developer with poor articulation skills or one with a lack of care for quality, will produce bad stuff, LLMs or not.

Thus, the extreme proponents of manic “agentic” vibe coding,^[19] and the outright denouncers of LLMs, are both missing the forest for the trees. That there is a pragmatic middle path, where people who have the experience, expertise, competence, and the ability to articulate can use these tools to get the outcomes they desire with the right sets of trade-offs.

Vibe coding has its place, especially for non-technical people, who, for the first time, can tinker, explore, have fun, and empower themselves with software. I see this happening all around me. However, the fanatical acolytes of vibe coding are missing a very important thing that makes humans take artefacts seriously—finitude. They’re generating a vast Borgesian library where they themselves are likely to be lost in an ocean of slop generated by sycophantic agents. Slop, not because the code is of poor quality, but because anything that can be generated infinitely without effort and has no meaningful provenance, is very hard to value or take seriously. Humans fundamentally do not deal well with an infinite supply of anything, especially choices. Completely unsurprising because we are heavily constrained biological beings that have evolved on a finite planet with finite resources to live out finite lifetimes.

And then, the denouncers, they can’t seem to get past the argument from incredulity.^[20] They denounce LLMs because they don’t personally like them for whatever reason, or have been unable to get desirable outcomes, or had the wrong expectations about them, or have simply gotten sick of them. But that is immaterial because there is a sizeable population who are using the exact same tools fruitfully and have the opposite experience. I am one of them.

All that said, the widespread braindead and outright stupid and harmful implementations of these technologies fuelled by hype, frenzy, and greed are an unfortunate reality and a massive cause of concern. The AI-business bubble is perhaps one of the biggest in history. The rise of FOSS AI technologies makes one hopeful. However, to incorrectly conflate bad actors, bad actions, bean-counting, and nonsensical implementations with fundamental, physical capabilities of these technologies—not theoretical, but the regular, proven, and practical—is irrational. It is missing the forest for the trees.

The human cost

All of this has been from the perspective of an experienced developer and engineer. For someone who has been weathered and bruised enough, these AI technologies provide extremely effective and powerful assistance.

But what about the young folks who are just starting out? If one does not have their fundamentals in place, if one has not developed an innate and nuanced understanding of systems and the process of software development, then these technologies are unreliable, dangerous genies. One asks for code, it gives code. One asks for changes, it gives changes. Soon, one is stuck with a codebase whose workings one doesn’t understand, and one is forced to go back to the genie and depend on it helplessly. And because one is hooked on and dependent on the genie, the natural circumstances that otherwise would allow for foundational and fundamental skills and understanding to develop, never arise, to the point of cognitive decline.^[21] What then happens to an entire generation of juniors, who never get an opportunity to become seniors meaningfully?

Personally, I don’t care about the extreme vibe coders or denouncers or even slop. We are all going to drown in a deluge of slop, from which, many islands of sanity, recovery, and a new order of software will emerge. The real concern is for generations of learners who are being robbed of the opportunity to acquire the expertise to objectively discern what is slop and what is not. Even worse, the possibility that experienced folks who use these tools effectively, will feel disincentivised from mentoring and training junior folks in foundational ways, something that was a natural part of societal evolution. And not just with software development, but the wholesale offloading of agency and decision-making to black boxes.

Talk

At this point, for a hands-on developer, reading and critically evaluating code have become more important than learning syntax and typing it out line by line. Of course, that is still an important skill, because the ability to read code effectively comes from that in the first place. But, the daily software development workflows have flipped over completely.

An experienced developer who can talk well, that is, imagine, articulate, define problem statements, architect and engineer, has a massive advantage over someone who cannot, more disproportionately than ever. Knowledge of specific language, syntax, and frameworks—code—is no longer a bottleneck. The physiological constraints of yore are no longer impediments. The machinery for instantly creating code at scale is now a commodity and available to everyone, just a pip install equivalent away. It requires no special training, no new language or framework to learn, and has practically no entry barriers—just good old critical thinking and foundational human skills, and competence to run the machinery.

Conventional software development methodologies and roles—Waterfall^[22] to Agile,^[23] developer to tester, senior to junior—have fundamentally changed with traditional boundaries consolidating into unimaginably fast, compressed, blurry, iterative “agentic” loops. The dynamics of people, organisations, and public communities in software development, the very human incentives for sharing and collaboration,^{[24] [25] [26]} are all changing.

For the first time ever, good talk is exponentially more valuable than good code. The ramifications of this are significant and disruptive. This time, it is different.