25 Years in IT: What Vibe Coding Reminds Me About Past Tech Revolutions

A 2023 GitHub-commissioned survey of professional developers found that 92% of them were already writing code with an AI assistant at their elbow, months before most boardrooms had approved a single AI budget line. Stack Overflow's 2024 Developer Survey put the number even higher, with 76% of respondents using or planning to use AI tools in their development process that year. That gap between what practitioners quietly adopt and what leadership notices is not new, and it is the reason so many companies keep getting the timing of every tech shift wrong.

I have watched that gap open and close four times now. Each time, a new tool showed up promising that the old rules no longer applied, and each time, the teams who ignored the fundamentals paid for it later, usually in a rewrite nobody had budgeted for.

The Myths I Keep Hearing About Vibe Coding

The first myth is that vibe coding is a fundamentally new kind of risk. It isn't. It is the same trade as every "anyone can build it now" tool before it: speed up, understanding down, and a bill that comes due later.

The second myth is that this time the tool is good enough to skip the engineer entirely. A junior developer on one of our teams shipped a working checkout flow in an afternoon using an AI pair-programming tool, and it looked done. It wasn't. It had no idempotency check on the payment webhook, so a flaky network retry would have charged a customer twice. We caught it in review, not because the code looked wrong, but because someone senior knew what question to ask.

The third myth, and the one I find most tiresome, is that people who raise concerns about AI-generated code are simply afraid of change. Some are. Most of the ones I respect are afraid of exactly one thing: shipping code nobody on the team actually understands.

What Actually Made FrontPage, Open Source, and Cloud Migration Stick?

The tools that lasted were the ones that got absorbed into an engineering discipline rather than replacing one. GeoCities hosted more than 38 million pages at its peak before Yahoo shut it down in 2009, and FrontPage-built sites died out just as fast once the web needed real applications — not because the idea of visual tooling was wrong, but because nobody paired it with version control, testing, or a review process.

Open source is the clearest case. Netcraft's web server survey tracked Apache running well over half of all active websites through most of the 2000s, and when we started pulling Apache, MySQL, and PHP into client projects instead of buying licensed stacks, the resistance wasn't about the code being free. It was about trust — could you audit it, patch it, and support it when the maintainer disappeared. The answer turned out to be yes, but only for teams that already had the discipline to read someone else's code critically before shipping it. The ones without that discipline got burned by unpatched CVEs sitting in production for years.

Cloud migration told the same story a decade later. Moving off owned data centers and onto Amazon Web Services or Microsoft Azure wasn't really an infrastructure decision. It was a bet that your team could design for failure — for a node dying mid-request — instead of assuming the hardware underneath would just behave. Teams that treated the cloud as "someone else's data center" and kept their old architecture got surprised by outages. One migration we ran in 2013 cut a client's server costs by roughly 40% in the first year, but only after we rebuilt the retry logic that owned hardware had let the team ignore for a decade. Teams that redesigned around failure got resilience they never had before.

The tool never carries the discipline. It only ever reveals whether you already had it.

The Principles That Outlive Every Tool

Three things have held constant across FrontPage, open source, cloud, and now vibe coding. First, code you cannot explain is a liability regardless of who or what wrote it. Second, review catches what confidence hides — the more fluent the output looks, the more it needs a second pair of eyes, not less. Third, the fastest path to shipping is never the fastest path to maintaining, and every generation of tooling forgets that lesson until it relearns it the expensive way.

How to Put Vibe Coding to Work Without Getting Burned

After working through this shift with teams across several client accounts this year, the sequence that actually works looks less like a policy memo and more like a habit. I sat next to one of our senior architects in January while he prompted an AI tool to draft a database migration script, watched him reject its first version because it silently dropped a foreign key constraint nobody had told it to keep, and watched the second version come back clean only after he added an explicit schema diff to the prompt. Nothing about that process was automatic — it took a human who already knew what a dropped constraint would break.

Start by treating AI-generated code as a first draft from a very fast, very confident junior engineer — never as a finished pull request. Then route every AI-assisted change through the same review gate as human-written code, with no exceptions carved out for "the AI wrote it, so it's probably fine." Next, ask the engineer who prompted it to explain the change in their own words before it merges; if they can't, the change waits. After that, track defect rates by origin for ninety days so you have real numbers instead of a gut feeling about whether the tool is helping or just feels faster. Finally, invest the time saved on drafting into the parts AI still can't do well — architecture decisions, edge-case thinking, and the conversations with clients about what the software should actually do.

Will AI Replace Software Engineers?

No, but it will replace the engineers who define their value as "can produce working syntax" rather than "can decide what should be built and verify that it was built correctly." Vibe coding shifts the scarce skill from typing code to judging code, and that judgment still has to live in a human who is accountable for the outcome.

What nobody tells you is that the hybrid model — an engineer directing an AI tool, reviewing its output, and owning the decision — consistently outperforms both the all-human team and the "just let the AI do it" team on the projects I've watched closely this year. Not because the AI is weak. Because unmonitored speed without judgment is exactly how every previous tooling wave produced its worst technical debt, and this wave has no immunity to that history.

Frequently asked questions

What is vibe coding?

Vibe coding is building software primarily by describing what you want in natural language to an AI tool and accepting its generated code with light or no manual editing. It produces working output fast, but the code's correctness and maintainability still depend entirely on whether a human who understands the system reviews it before it ships.

Is vibe coding similar to the dot-com era's drag-and-drop website builders?

Yes. Tools like FrontPage and GeoCities-era builders let non-engineers publish working websites without understanding HTML, the same way vibe coding lets people generate working applications without understanding the code. Both raised the ceiling on what a novice could produce while leaving the underlying engineering risk unchanged.

Should engineering teams adopt AI coding tools now?

Yes, but only inside an unchanged review process. Teams that route AI-generated code through the same code review, testing, and ownership standards as human-written code capture the speed benefit; teams that relax those standards to move faster typically discover the cost later, in defects and unreviewable code.

Pick one AI coding tool today, run it on a single real ticket through your team's existing review process before end of day tomorrow, and write down exactly what it saved and what it missed. That one exercise will tell you more about where vibe coding fits on your team than any framework I could hand you here.