A Brief History of "AI" Coding

While scrolling social media today, I saw a tech influencer's post explaining why my "graph coding" strategy was all wrong and how his sponsor's product could help me fix it. "Graph Coding," I thought... "that's a new one." And although I could pretty quickly figure out that it referred to something I've already been doing myself without having a name for it, the novelty of the phrase sparked the thought "What new trend have they cooked up now to keep up everyone's interest in LLMs?" I mean, didn't "loop coding" just come out like a few months ago?

Indeed it did. But loop coding is, apparently, dead already and the industry has moved on to the next phase. The skeptical read might be that we have to keep coders, investors and the media actively interested in the industry... but a slightly more nuanced read might be that graph coding really is a new approach, and that this process is evolving so fast that it's really hard for people to keep up and make sense of it all.

And to that end, I present to you my take on the development of "AI" assisted coding and the process of its don't-blink-or-you-might-miss-something" evolution.

Pre-History: Copy & Paste

Back in the olden days, programmers used to have to search for code samples on existing websites or dig through message boards where other coders (who were maybe a bit smarter or a bit further along a particular skill branch) would post their solutions to common coding problems. Sometimes developers shared their work out of the goodness of their hearts or for community cred, but you had to be mindful as there were those who would deliberately post badly written or even malicious code to troll each other into doing obviously (or not so obviously) dumb and destructive things. Copying and pasting someone else's code made the process easier but wasn't always the safest thing to do... and the odds that you'd come across a "magic number" that just made things work or a code fragment that would break everything were nearly equal... either one of which would be hard to explain to your boss or your customers, particularly if you didn't understand it yourself.

Despite the insistence of some who may say this was not how "real" coders worked, I can say with a high degree of certainty that the very second software developer to emerge in the world looked over the shoulder of the first one for hints, and pretty much everyone who's ever written a complete software product has borrowed code from someone else. I have to admit that probably 30 to 45% of my first SaaS app was either directly lifted from someone else's public-facing website or built on pieces borrowed from other developers examples... definitely more from these sources than from documented API guides, that's for sure.

And though I did and still do consider myself a real programmer, I have to admit to one very real "magic number" I employed to create a virtual 3D object out of a point array using scale and transparencty for the z-axis. I still couldn't tell you what that number was or how it made those points into a sphere... but it was impressive and got me a lot of work and I'm grateful to the person who created it who clearly did better in math than I did. The point here is that while copy and paste was de regueur part of writing code, you did have to understand how the code worked if you wanted to be able to call it your own and maintain and expand on it.

The Transition Era: Auto Complete

Integrated Development Environments (IDEs) have been delivering (with varying degrees of success) auto-formatting and template-driven auto-complete for some time... some of it going back to the 80s... but the first real integration of an LLM into a development environment happened around 2021 with the arrival of OpenAI's Codex and GitHub's Copilot which would attempt to finish the line of code you were writing by trying to predict what you were working toward.

As a result of my multi-year hiatus from hands-on developing, I'm glad to say I largely missed this experience... my freshly installed copy of VSCode tried to auto-complete on my behalf for a few weeks until the Copilot trial expired and I never bothered to renew it. Although the first few times I saw it happening I found it to be invasive and not particularly helpful, I'm sure it was pretty exciting for the people who had been coding by hand up to that point. The code, or at least the decision of whether to keep or discard what you were being offered, was still yours, and coding likely felt a lot easier when you weren't spending hours having to search for examples of proper syntax.

LLMs Step Up: Natural Language Programming

This is what I'm going to call the period from 2022 to 2024... when the workflow shifted from models offering in-line predictive auto-complete to developers telling the models what they wanted and the model offering complete (or near-complete) solutions.

During this period of rapid growth and innovation, a lot of new and exciting tools were developed and a lot of coders stopped doing the typing and started letting the LLMs "write" the code while still reviewing and doing their own pull requests. A pull request, for the record, is when a developer asks to have their code merged into the main codebase, a process in which other developers should review and judge the value and proper functioning of the new code. More code means more mistakes, of course, and quite a few shipping applications or fixes to existing code turned out to be, well, less than ideal. LLMs were making coding easier, resulting in more of it, even if they weren't necessarily making the code itself better.

Redefining the Human Role: Vibe Coding

This one you've probably heard before... around early 2025, AI researcher Andrej Karpathy coined the term "Vibe Coding" to describe the experience of going "hands-off" and letting the AI do the work for you. Instead of typing, copying, reading, comparing old to new (called diff-ing as in reviewing the difference between two files) and deciding what code changes to keep and which ones to send back for improvements, in vibe coding you just "go with the flow", accept changes without reading them, paste the errors back into the LLM to be fixed and just trust the process.

Not reading the output saves a developer a LOT of time, but it also puts the burden on the LLM to "get it right" which is a far more complex request than it might seem. "One-shotting"... the act of giving an LLM a single prompt and expecting it to develop a complete, functional app, site or game, became something like a badge of honor and a lot of people shipped a lot of code that they didn't write, read, understand or know how to support because they believed in the AI's ability. And, as you might imagine, because developers weren't reading diffs and PRs weren't being reviewed as often, or even at all, the quality level of the resulting code declined even further.

It's also worth mentioning here that the naïve trust in LLMs - which will just as cheerfully deliver financially ruinous security issues as they will working code - has also either driven or helped justify the mass firings of developers across all skill levels as of late 2025 to early 2026. Security, among other things, takes real effort and it's hard to deliver good software when nobody who understands how it works (or fails to work) is reviewing the code. But who needs programmers (say the headlines) when you've got a magic programming genie, right? And even though some may argue those companies were overstaffed and under financial pressure already, it's easier to sell "AI can do the job" to investors and the public than "we hired and paid for a bunch of people we can't afford and may have never needed in the first place."

Your Code Became Our Code: Agentic or "Loop" Coding

It didn't take long for the vibe coders to realize that, as models got better... more capable and with greater capacity to "remember" what they're working on... you could avoid shipping bad code by giving the LLM a somewhat better definition of what you wanted and then just telling it to keep working on it in a loop until it got it right. It's at this point that the developer essentially removed themselves from the process almost entirely, treating the coding process kind of the way you would a dating app... tell it what you want and then swipe left until you see something you like.

This doesn't solve the underlying problem that a developer who doesn't understand what's behind the wallpaper can't provide meaningful instructions on how to frame a house, but the tools were getting better and LLMs were beginning to accept pre-made instruction sets called "skills" that coders could store for use across projects and share with each other. Don't know how to set up a secure database? Simple, just use someone else's skill! Of course, skills were also a great source of old-fashioned trolling and more than a few people who were happy to "plug in" another person's instructions into their LLM and grant it access to their entire computer and server got more (or lost more) than they expected.

Nevertheless, a reasonably skilled and experienced code architect and developer could use these tools to do some impressive things... so long as they were willing to stay "in the loop" and educate themselves on the right kinds of questions to ask so that their finished products weren't obviously vibe coded disasters. While looping can improve code quality, it's particularly helpful if the loops involve writing proper requirement contracts, utilizing adversarial coding (where one agent builds and a different one tests) and providing appropriate guidance to implement real security, performance and deployment hardening.

Many Tasks, Many Agents: Graph Coding

Like that scene in The Matrix Reloaded where Agent Smith decides that the best way to capture Neo is to replicate himself until there's nobody left except for a bunch of copies of himself and Neo... we're coming to the point where just looping a single LLM on a single task doesn't really do the job any more. Instead, we break the problem down into multiple, unique tasks and fan out a bunch of agents to take on each task, all of them orchestrated by a central agent.

Let's say you want to review 50 documents in ten different folders and make sure they're all up to date with regard to the actual state of your project, and that they all share the same formatting and style and are cross referenced to each other where appropriate. Rather than waiting for a single agent to read all of the files and do all of those edits, you might have your primary agent spawn 10 new agents, each of which scans one of the folders and reports back. Then when your orchestrating agent has a picture of the full set of data, it might spawn one agent to check for formatting, another to create cross references, a third to check assertions against actual code, and a fourth to update your database as to the changes to all of the files' metadata. Each agent acts independently (consuming its own tokens) and reports its results back to the orchestration agent which reports back to you.

People are setting up agents that run around the clock, spawning new agents as necessary to address individual tasks, keeping operations separate, providing parallel efficiencies and guaranteeing that a single failure doesn't stop the entire workflow. And, like the image above shows, this goes beyond programming. Agents are now running within the applications themselves managing (hopefully) the deterministic elements of sites and offering inferences about datasets in conjunction with other agents doing other tasks. Such an array of live agents working behind the scenes can providing real-time functionality that coding alone may not be able to capture or keep up with.

What's Next? Ephemeral Code

This is my theory... software code is really nothing more than "cached computation". Something needs to be done a lot so we create a process and formula for doing it, then those processes and formulas fit together to become an application. Most users interact with a specific application in a predictable way to achieve a repetitive task so software exists to encode those actions in order to make them swift, consistent and efficient (and accurate too, one can hope).

What LLMs (or their upcoming successors) will do, I think, is combine natural language with deep data insights and rapid tooling to create solutions to user needs on the fly. Imagine a 3D printer in your kitchen that could make you whatever plate, bowl or utensil you need out of solid but re-usable material nearly instantly, then recycle it back into its component parts to be remade again as something else. Now imagine that in your garage for tools to work on your car... and you don't even have to ask, you just reach out a hand and there's a 10mm socket wrench just the right length to reach the bolt you're trying to tighten. This is what I believe the future of software development will look like, and it's going to happen far sooner for software than it will for forks and wrenches.

We're not quite there yet, but we're headed in that direction... and the first step is the one we're seeing already, the democratization of code. That's the idea that because software can be written more quickly and easily, not to mention completely if you do it right, businesses and individuals no longer need to depend on app store applications and monolithic cloud services, which themselves had killed the notion of "shrinkwrap box" software that had been instrumental in bringing computing out of the research labs and to the masses in first place.

The More Things Change

There was a time when you had to be an actual engineer to have access to computing... that gave way to the era where everyone received the same user experience delivered in a box which a huge company had taken years to develop and which required massive resources to support and maintain. Subsequent improvements in infrastructure and coding methodologies eventually replaced shrinkwrapped applications delivered on disks with mobile apps and cloud-based software as a service, and in that same spirit of making computing power easier to access and use, that process continues today as software development is rapidly evolving to the point where anyone who wants to can try... with varying degrees of success of course... to write their own.

Soon they won't even have to do that. Once the general public begins to understand that computing power can be theirs to wield as they see fit without needing any programming skills whatsoever, you're going to start seeing some real change in this industry. If I were you, I'd be ready for it.