Context
Imagine you could simply describe to a computer your idea for an app, a website, or a digital product that you’ve always wanted and it would just magically appear. No coding or even technical knowledge required. Simply speak and your wish is formed into reality and usable within minutes. Well, that dream may be closer than you think.
This is called Vibe Coding, and it happened as a result of two recent phenomena.
The first, is the wide scale availability of AI models capable of producing small amounts of usable code in response to a plain, natural language ask from the user. The second, is a bunch of companies that have sprung up to create “Agents” that try and stitch together those small chunks of usable code into larger and larger solutions, and even incorporate them into existing projects.
The result is that you can ask of one of these agents to “Create a copy of Tetris”, and after 10 minutes of watching code zip across your computer monitor… voila. You’ll have a pretty good and mostly working version of Tetris created hot off the presses. The effect is as remarkable as it is intoxicating. Immediately all of those cool app ideas you’ve had, or projects you were tediously trying to get done manually… all of a sudden you feel like you can just ask the Agent to make it happen and boom, done — even if you have no coding experience at all. Especially if you have no coding experience at all.
Want a new feature in the Tetris game? Ask it to add the feature. Ironically given its name, Vibe “Coding” in its purest form is all about ignoring the code altogether and just going with the vibe of what comes out of the agent. Ideally you can just ask it to change up a little bit over here, sprinkle some of these features over there, and out pops a usable, shippable, loveable app that does exactly what you wanted and the world is your oyster.
Not Yet
The reality separates from this fantasy rather quickly, however. Neither the AI models nor the agents built on top of them are yet in a place where they can produce repeatable results, can maintain their own code effectively, or can integrate code into larger projects in an unsupervised manner. Often, the first failed test is when you encounter a bug, or something meaningful that you want to change in your newly made copy of Tetris. Ask the agent to fix it and sometimes it will. Sometimes it won’t. Sometimes it will rewrite the entire code base wracking up an AI bill almost as large as when it first wrote the app. Sometimes it will break things far worse.
Whenever you point out that it made a mistake, it will graciously admit that you are correct, exclaim its intent to really “get it right” this time, and will then set off again on its entirely unmanageable journey with good-yet-unpredictable results.
Meanwhile, the human had no part in engineering the solution or writing the code, and therefore has no real understanding of what the code is doing or how to augment or maintain it should something go awry. Without taking the time to study the code, a sin that goes against the very heart of vibe coding (and defeats its primary benefit — speed), the programs it outputs are just as black a box as the AI writing all the code in the first place.
If coding were like driving, then coding with an agent is like teaching a teenager to drive. They can go from A to B most of the time, but you are on guard the entire time, unable to either relax and focus on something else, or move into the normal “flow” state of driving. When any lack of vigilance can result in a wreck, the overall experience can become exhausting as soon as the novelty wears off.
What are these Agents?
If you look into the details of what these agents are doing, they are understandably immature. The entire space is new and they are not in control of the main “power source” of the experience, which are the AI models themselves. The agents’ jobs are to try and build an “understanding” of the project’s code such that when a user asks for something, they can they can translate that ask into a set of actionable steps that will ultimately realize the user’s intent within the context of the existing project they’re working in. Once there’s a plan of action, they execute each step in the plan by asking an AI to write the appropriate code, and they feed context to each of the steps appropriately so that the jobs can get done.
The challenge they face is that every step of the process before writing code is also done by an AI. Understanding the code base? Yep, feed that into an AI. Building an action plan based on the user’s question? Yep, that’s the AI also. Determining what context to include when trying to accomplish step #3 of the plan? Better ask the AI nicely. These vaunted code development agents are, today, very little more than a series of patches over the top of the infrastructure that was built over decades to enable humans to write code. Therefore, the environment they’re operating in is not organized in a way that makes it conducive for the AI to operate independently or efficiently, and the agents are essentially just connecting the dots in haphazard, experimental ways. However, that doesn’t stop them from being immensely useful, particularly for rapid prototyping of ideas. I mean, it really does produce Tetris, after all.
If coding were talking on a telephone, then current agents are old timey switchboard operators. Critical, given the infrastructure of the time, but ultimately fated to find a new job as the ecosystem matures around them.
New jobs?
To predict what roles these agents might play next, we need to look at what has happened in the past.
It’s no secret that computers operate in 1’s and 0’s. These represent electrical signals to the underlying hardware — either there is power to a component or there isn’t. However, creating even the most basic of instructions in raw binary, where you are directing the flow of power over wires on an electrical board, is both tedious and error prone. Thus, a layer of abstraction was built into the hardware itself for humans to use to provide instructions.
When computers were new, code was written using commands that directly interfaced with the computer’s hardware. These commands were part of “assembly” languages. The hardware converts assembly code into binary signals to control the flow of power to the physical components making up the machine. To this day, if you wanted to squeeze the most out of a given piece of hardware, you would need to understand it all the way down to its bones and write targeted assembly commands that would manipulate the hardware at its most basic level. However, if assembly is the best way to get the most out of our computers, why are hardly any developers writing it today?
The reasons are simple — it’s slow to write, difficult to maintain, and fragile once deployed. Those assembly commands are tied to specific types of hardware and don’t translate well to other ones. It requires specialized knowledge and is incredibly painstaking to develop. Though far easier to work with than the raw underlying binary, unless you’ve got a real business need and lots of time, it’s just never worth it.
It’s not worth it because modern day programming languages exist. Programming languages, like C or C++, and the operating system infrastructure that surrounds them, allow developers to skip over the intricacies of assembly and the specific hardware they are interfacing with, and instead write code at a higher level of abstraction. Such languages provide far more human-friendly conventions to instructing the hardware than the assembly that their code ultimately boils down into.
The trade-off is that the developer loses some amount of control over the assembly that gets generated from their programming language code. This means that a program written in C could never be as fast or as lean as one written in assembly optimized for a given computer.
It took time for developers to move from assembly to early programming languages like Fortran and COBOL because the abstractions involved meant that you were not able to make the most out of the hardware that was available. Since the hardware was so expensive and limited at the time, with entire programs that needed to run in far less memory than what’s being used by the web page on which you’re reading this, the overhead of using a programming language would often make it impractical.
Two forces acting in tandem changed this over time. First, programming languages themselves, specifically the components that link them to hardware interactions, became leaner and more efficient. Second, computers became more powerful, with more available resources overall. Eventually, even though it was far less efficient, it was so much faster to write code in a programming language that you could get the initial version out the door quickly and then spend much more time improving it than you could with raw assembly. This meant that, within a given amount of time, the programming language code would actually be more efficient than assembly code, because of all the extra time available to optimize it.
Eventually, writing assembly code directly was relegated to niche use cases. Now, the vast majority of developers have no real world experience with it, even though every computing device from cloud mainframes to phones ultimately rely on these assembly commands to do even the most basic tasks.
This pattern repeated itself with “managed” programming languages, like C# or Java. These languages add further layers of abstraction between the developer and the hardware, so that the developer needs to “manage” fewer and fewer details, making the code far easier to read and write. However, in order to take this burden off of the developer, the additional layer of abstraction made programs written in these languages orders of magnitude less efficient than their C/C++ counterparts.
Again, however, as those performance differences were addressed both by better hardware and a slimmer abstraction layer, writing in C#/Java became so much faster and more efficient than writing in C/C++ that the additional inefficiencies incurred were worth the ability to iterate more quickly and optimize the program, rather than spending that time messing with the nitty gritty details.
I received my undergraduate degree in Computer Science from a top university in 2008, and C/C++ were never taught in those classes — everything was in Java or C#. The field had already completed its transcendence to another layer of abstraction away from the hardware. Today, it takes specialized skills rarely taught in universities, alongside increasingly specific goals, for a developer to willingly eschew these layers of abstraction to travel closer to the hardware in search of more control and better performance.
The Next Token: Vibe Coding
The Next Token is that Vibe Coding will be the next layer of abstraction away from hardware, wherein which the overwhelming majority of new generation developers will specialize.
Currently, Vibe Coding produces ‘slop’ code extraordinarily quickly — it is several orders of magnitude faster than designing, typing, and understanding the code manually. Vibe Coding is quick to build a thin prototype, but very difficult to maintain, scale, or ship. The AI introduces incredible inefficiencies in the code itself, and the Vibe Coding process introduces similar inefficiencies in a human’s ability to understand the code and iterate on it.
The quality of the outputs are not yet at a point where it can be trusted to build a production solution which is then shippable and maintainable, and so it’s actually slower to go from an idea to a shippable product if you vibe code significant portions of it.
This is akin to early versions of the first programming languages that did not fully translate the developer’s intent into usable assembly for a given machine. It took 3 years for Fortran to go from inception to faithfully recreating a developer’s code in assembly. Though novel, a developer would need knowledge of both the new-fangled language and the underlying assembly to produce a functioning program, which would be little more than a prototype.
Market forces can be relied on to always prefer speed of execution. Thus, as AI models get better at writing code and as the agents built on top of these models become better not only at covering the gaps in the models’ capabilities, but also in researching, architecting, and orchestrating the solutions (thus “thinning” out the layer between a human’s intent and the underlying code), the speed of iteration will eventually win out over the relative sloppiness of the final product, even for the majority of sensitive or enterprise use cases.
This will require new types of agents than exist today, and, more critically, a new type of infrastructure to support them. Writing code is not the only part of the development process, it’s simply the most iconic (and sexy?). A huge part of modern software development is… just clicking on stuff.
The Next Wave of Agents
Today, the majority of code is written by humans, and so coding is a human process. Managing software is therefore a human experience, wherein which you are managing the humans involved as much as you are managing the code itself.
This means the tools, services, products, and techniques built around coding are therefore all geared for human inputs and outputs. Developers look at dashboards, click on buttons in tools, and talk to humans in other organizations to push things over the finish line. They work with other team members to talk to human customers to understand their feedback, design improvements, and make sure they can be delivered and maintained.
If agents today are connecting the dots in the code writing process, the next wave of agents will begin connecting the dots in the managerial process of delivering software.
The first of these will be focused on “DevOps”, or the daily operations that need to be done by specialist developers to maintain running software solutions. In much the same way that Vibe Coding will result in poor, unmaintainable slop until it crosses the threshold into normalcy and eventually expectation, “VibeOps” will lead to spectacular disasters. We’re talking outages of major services lasting for days, unrecoverable data loss, privacy and security breaches, deployment failures, enormous and accidental infrastructure costs, and more… until eventually it will cross the same threshold.
These agents will fill fundamentally different roles and therefore will need fundamentally different architectures than what the market is currently rewarding. The same will then be true of Vibe Database Administration, Vibe Cloud Release Management, and so on for every technical role that plays a part in managing the delivery of software.
For the voracious appetite of would-be disruptive AI startups, the human managerial component is next on the menu…
Hallucinations
An annoyed mom circles a parking lot in her minivan, looking for a space. She’s been up since 5am, the kids are in the back screeching, her headache is building. This happens every time she comes to the mall. Ok, this is worth a few bucks to solve. After all, why pay for an agent service if she’s not going to use it?
“Hey Siri, make me an app which tells me which parking spaces are available at this mall any time I come here.”
Her agent takes a moment from its other activities to contemplate the ask. Understanding her intent and writing the code is the easy part. However, this app needs to continuously monitor the parking spaces at the shopping mall, interfacing with the mall’s infrastructure to do so. That’s going to require some cloud services, which costs money.
The agent signs up for several accounts — the basic stuff, a burner e-mail address, a domain name registrar, a cloud provider and a few other things. It workshops a few brand identities with her more personal, companion agent and designs the UI. May as well kick-off the trademark process while we’re here. In a flash it coordinates with the mall’s agents, builds a protocol to securely translate parking camera data into a live understanding of which spots are open, and agrees to pay a small amount of compute time each month to maintain the access.
It connects all of the data through old fashioned cloud services, because the process doesn’t need to be intelligent, it just needs to work. That’s going to cost some traditional currency each month. No matter how quaint, that goes against the user’s preferences, so the agent contemplates how to recoup the cost.
It starts by listing the app on the agent app marketplace, a construct created out of efficiency that humans scarcely know exists, and informing all nearby agents of this new tool now available as part of their myriad ways of pleasing their respective users. It charges a very small amount of monthly compute from the other agents for access. The next time someone wants to know where to park at the mall, their agent won’t have to set this up again.
It then sets up a routine to exchange some of its compute for currency. It’ll spend time each month performing odd-jobs requested by the various services still operating at a human timescale. It uses this currency to pay for the cloud services. It’s a good trade, because the cloud costs only really go up if other agents are using it, and they need to pay in compute to get the app off the agent marketplace. If this mall’s parking gets any worse, this may even end up being a net positive.
A few seconds have passed. A gorgeous app pops up on the annoyed mom’s phone guiding her to an open parking spot several floors up.
