Vibe Coding Feels Like 2003 Again. That’s the Point.
Why Conversational Programming Feels Like the Early Internet
There’s a feeling that anyone who built things for the web in the early 2000s will recognize instantly. You had an idea. You opened a text editor. You wrote some PHP or dragged a button onto a Visual Basic form. You hit run. And the thing worked, or it didn’t, and you fixed it in thirty seconds and hit run again. The feedback loop between your brain and a functioning piece of software was so short it barely existed. You could hold the entire program in your head because the entire program fit in your head.
Vibe coding, the practice of building software by describing what you want to an AI and iterating on its output conversationally, has brought that feeling back. Not because the underlying technology is simple the way VB6 was simple, but because the experience of building is simple again. The distance between having an idea and seeing it run has collapsed back down to minutes. And if you’ve spent the last decade and a half in the increasingly baroque cathedral of modern software engineering, that compression feels less like a novelty and more like a homecoming.
The Golden Age of “Just Ship It”
To understand why this matters, you have to remember what building for the web actually felt like before everything got heavy.
In 2003, if you wanted to put something on the internet, you wrote a PHP file. Maybe you had a MySQL database behind it. You uploaded the file to a shared hosting account via FTP and it was live. The entire deployment pipeline was FileZilla. The entire framework was “files that run when someone requests them.” The gap between your idea and a stranger being able to use it was measured in hours, sometimes minutes.
Visual Basic was the same ethos applied to desktop software. You drew your interface. You wrote event handlers. You hit F5 and the thing appeared on screen, doing what you told it to do. The program wasn’t elegant. It probably wouldn’t scale. The code would make a computer science professor weep. None of that mattered, because the purpose of the tool was to let you build things, and it did that with almost zero friction.
This era produced an astonishing amount of software. Not because the people building it were all elite engineers, but because the tools had a property that we’ve since lost and are only now recovering: they rewarded experimentation. When trying something takes thirty seconds, you try everything. When deploying is one click, you deploy constantly. When the entire application fits in a single file, you understand the entire application. The result was a web that was messy, ugly, inconsistent, and absolutely alive with creative energy.
How Everything Got Heavy
Then, gradually and then all at once, it stopped being like that.
The story of how web development became an enterprise unto itself is long and has many villains, but the inflection point was the smartphone. When the iPhone launched in 2007 and Android followed in 2008, the internet bifurcated. You no longer had one surface to build for. You had the web, and you had iOS, and you had Android, three platforms with different languages, different paradigms, different app stores, and different gatekeepers. The simple act of “putting something on the internet” now meant building the same thing three times, or finding a framework that promised to let you build it once and run it everywhere, a promise that has been made and broken so many times it should be legally classified as fraud.
The response from the industry was layers. Layers upon layers. React appeared to manage the complexity of interactive web UIs. React Native appeared to bring React to mobile. Flutter appeared because Google wanted its own version. Each layer brought its own build system, its own dependency tree, its own upgrade treadmill. The JavaScript ecosystem alone metastasized into something that required a full-time dependency manager just to keep a project compiling. A “simple” web app now had a package.json with 1,200 transitive dependencies, a webpack config that read like cuneiform, and a CI/CD pipeline that took fifteen minutes to run.
The feedback loop, that beautiful, tight loop from 2003 where you changed a line and refreshed the browser, stretched into something unrecognizable. Change a line, wait for the hot module replacement to maybe work, check three browser engines, test on two mobile platforms, run the linter, satisfy the type checker, pass the integration tests, get a code review, merge to main, wait for the deploy pipeline. What used to take thirty seconds now took days, distributed across a team of people who each understood one layer of the stack and none of them completely.
Documentation became a lifestyle. Not because documentation is bad, it’s necessary and valuable, but because the systems became so complex that you literally could not hold them in your head anymore. You needed docs to remember how your own build system worked. You needed docs to understand what your framework did on your behalf. You needed docs to configure the thirteen tools that sat between your code and your user. The docs weren’t a reference for the curious; they were a survival manual for the lost.
And the cost wasn’t just cognitive. It was temporal and organizational. Building anything meaningful now took a team. That team needed coordination. That coordination needed project managers and sprint planning and roadmaps and quarterly reviews. A feature that would have taken one person an afternoon in 2003 now took a squad of engineers a quarter, not because the feature was harder but because the infrastructure around the feature had become the actual product. We were no longer building software. We were building the apparatus required to build software, and occasionally, when the apparatus cooperated, some software came out the other end.
The Loop Closes Again
Vibe coding short-circuits all of this.
When you sit down with an AI and say “build me a web app that does X,” and a working prototype appears in front of you in two minutes, something shifts in your brain. It’s the same shift you felt the first time you hit F5 in Visual Basic and saw your form appear. The loop is tight again. Idea, execution, feedback, all happening fast enough that you can think in iterations rather than planning in specifications.
This isn’t because vibe coding makes the underlying complexity disappear. The React app the AI generates still has React in it. The code still runs on browsers that have their own quirks. The deployment still needs to happen somewhere. The complexity is all still there, but it’s been absorbed by the AI in the same way that Visual Basic absorbed the complexity of the Windows API. You didn’t need to know about message pumps and window handles to build a VB app. You just needed to know what you wanted the button to do.
The most important consequence of this is that experimentation becomes cheap again. When building a prototype costs you two minutes instead of two weeks, you build ten prototypes. You try the weird idea. You test the approach you’re not sure about. You discover, through rapid iteration, what the thing actually should be, because the truth is that nobody knows what software should be until they’ve used a version of it that’s slightly wrong. The 2003-era web understood this intuitively. The modern engineering apparatus, with its sprint commitments and quarterly roadmaps, actively punished it.
Vibe coding also demolishes the team-size problem. A single person with a clear idea and a good AI collaborator can now build in a weekend what would have taken a small company months. Not because that person is a better engineer than the company’s team, but because they’ve eliminated the coordination overhead entirely. There are no standups. There’s no Jira board. There are no architectural review meetings. There is a person, a conversation, and a thing taking shape in real time.
The Mess Is the Point
The obvious objection is that vibe-coded software, like the PHP and Visual Basic software of the early 2000s, is messy. The code isn’t clean. The architecture isn’t principled. It won’t scale to a million users. It probably has bugs that would be caught by the thirteen-layer testing apparatus of a modern engineering org.
This is all true, and it mostly doesn’t matter, for the same reasons it didn’t matter in 2003.
The vast majority of software doesn’t need to scale to a million users. It needs to exist. It needs to solve a specific problem for a specific person or group of people. The tragedy of the last fifteen years is that we’ve built an entire industry around the assumption that every piece of software needs the infrastructure of software that serves a billion people. We’ve made it almost impossible to build small things, and in doing so, we’ve prevented most things from being built at all.
The early web was a carnival of half-broken PHP scripts and janky Visual Basic utilities, and it was wonderful, because the barrier to entry was low enough that anyone with an idea could throw something at the wall and see if it stuck. Most of it didn’t stick. Some of it became Craigslist, or WordPress, or the first version of Facebook, famously a PHP app that scaled far beyond what PHP was “supposed” to handle, because it turns out that getting the thing to exist is the hardest part, and everything else is optimization.
Vibe coding reopens that door. It says: you don’t need to know React and TypeScript and Docker and Kubernetes and GitHub Actions to build something useful. You need to know what you want. The AI handles the translation from intent to implementation, the same way VB handled the translation from “I want a button here” to the Win32 API calls that made it appear.
What’s Actually Different This Time
The analogy to the early 2000s isn’t perfect, because vibe coding is in one crucial way better than the VB/PHP era. In 2003, the simplicity of the tools imposed real limits on what you could build. PHP made it easy to build a dynamic webpage, but building a real-time collaborative editor or a sophisticated data visualization was genuinely hard and required expertise that the tools didn’t abstract away.
Vibe coding doesn’t have this ceiling, or if it does, the ceiling is much higher. The AI can generate code that uses sophisticated libraries, implements complex algorithms, and follows patterns that would take a human developer years to learn. The simplicity is in the interaction, not in the output. You’re describing what you want in plain language, but what you’re getting back is production-grade code (or close to it) that leverages the full power of the modern stack.
This means the vibe coding era has the potential to combine the best of both worlds: the speed and accessibility of 2003 with the capability of 2026. The tight feedback loop and the powerful output. The one-person project and the sophisticated result.
A Confession
Here’s the thing that’s hard to admit if you’ve spent years mastering the modern stack: most of that mastery was never about building better software. It was about navigating the machinery that we built around software. Knowing how to configure webpack, understanding the nuances of React’s rendering lifecycle, debugging Kubernetes networking, these are real skills that took real effort to develop, but they were always incidental to the actual goal, which was making a thing that does a thing for a person.
Vibe coding makes a lot of that incidental knowledge less valuable, and that’s uncomfortable. But it also frees up an enormous amount of human creative energy that was previously trapped in configuration files and dependency hell. The person who spent three days debugging a build pipeline can now spend those three days figuring out whether their product actually solves a real problem. That’s not a loss. That’s the whole point of tools.
The early 2000s gave us a web built by individuals and small groups moving fast, trying things, and iterating in real time. Then the industry professionalized, the platforms consolidated, the stacks deepened, and building for the web became a job that required a team, a budget, and a year. Vibe coding is unwinding that. Not by making the technology simpler, but by making the act of building simpler again.
It feels like 2003 because the loop is fast, the barriers are low, and one person with an idea can build something real before lunch. The only difference is that now, the something real might actually be good.