Engineering as a Service Is What Happens When You Let Vibe Coding Win

Vibe coding is not a programming technique. It's an organizational event dressed up as one. When GitHub Copilot launched in 2021, the narrative was "AI as pair programmer." When ChatGPT arrived, it shifted to "AI as junior developer." By the time Cursor and Windsurf and Devin entered the picture, the goalposts had moved so far that we stopped noticing where they used to be.

The term itself — coined by Andrej Karpathy in early 2025 — describes writing software by describing what you want and iterating on AI output until it looks right. No architecture upfront. No deep understanding of the internals. Just prompt, review, adjust, ship. The name is almost deliberately casual. Vibe. As if the whole thing is low-stakes.

It is not low-stakes. Not even close.

What's actually happening is that the cost of producing a working prototype has collapsed to near zero. A product manager, a designer, a technically literate founder, or a business analyst with a ChatGPT subscription can now produce something that looks — and often behaves — like what an engineering team would have spent two sprints building. The artifact exists. It runs. It answers to a curl command.

And that is exactly what makes the next part so uncomfortable.

What "Engineering as a Service" Actually Means on the Ground

The phrase Engineering as a Service — EaaS — has been floating around enterprise architecture circles for a few years. It originally described platform teams offering standardized, self-service infrastructure to internal product teams. Sensible concept. Reasonable organizational model.

That is not what I mean when I use the term now.

What I'm watching happen — across teams I've worked with, consulted for, and frankly in my own org — is a quieter version: engineers becoming a validation and production-hardening layer that sits after the AI has already done the creative work. The product manager vibe-codes a proof of concept. The engineering team is handed it and asked to "make it production ready." Requirements arrive pre-defined. The architecture decision has already been made, implicitly, by whatever structure the AI generated.

The engineer's job, in this model, is to clean up after the vibes.

"The most dangerous moment isn't when AI writes bad code. It's when the organization stops asking engineers to think before the code exists."

That shift is subtle. Gradual. And it doesn't announce itself in a restructuring memo. It shows up in how sprint planning conversations change. In the questions that stop being asked. In the job descriptions that quietly remove "system design" and add "AI code review." In the fact that your most technically sophisticated colleagues are increasingly valued for their ability to spot what the model got wrong — not for their ability to envision what should be built in the first place.

It's hollowing. And the hollow feels comfortable for a surprisingly long time.

The 80% Problem Nobody Is Talking About Honestly

The statistic getting passed around is that AI can write 80% of the code. Maybe 90%. Some teams will tell you it's higher. They're probably right, for a certain definition of "code."

What nobody says in the same breath is what that 20% contains.

It contains the decision to use a distributed lock instead of an optimistic concurrency strategy, because you know your write contention pattern at 3 AM on the first of the month. It contains the choice to put that third-party API call behind a circuit breaker, because you were the one paged at midnight when their service went down for six hours two years ago. It contains the knowledge that your payment processor has a 30-second timeout that doesn't appear anywhere in their documentation, and that the retry logic the AI generated will double-charge customers under exactly the conditions that will occur in production.

That 20% is not filler. It's the residue of lived system knowledge. And it cannot be prompted for, because it lives in people, not in documentation.

The Skill Inversion Nobody Budgeted For

Here's the part that makes people genuinely uncomfortable when you say it in a room: the engineers who are worst positioned for this transition are often the best coders.

Think about it. If you built your professional identity around the craft of writing clean, efficient, elegant code — if that's the thing you're proud of, the thing you've spent ten years sharpening — you are now in a profession where that particular skill is the one being automated away fastest. The engineers who wrote beautiful Ruby. The ones who could implement a red-black tree from memory. The ones whose pull request diffs were a pleasure to read.

Those skills are not worthless. But they are no longer the differentiator.

The differentiator is now something harder to teach, harder to credential, and much harder to interview for: the ability to look at an AI-generated system and know — without running it — which assumptions it made, which failure modes it ignored, and which organizational constraints it has no way of knowing about.

That requires something I'd describe as systems intuition. It's not algorithmic. It's not certifiable. It's the thing you develop after you've been on-call for two years, after you've traced a cascade failure through six services at 2 AM, after you've had to explain to a CFO why a "working" deployment is losing the company $4,000 an hour. You can't vibe-code your way to it.

What Gets Built When Engineering Is a Service

Let's say the EaaS model wins. Let's say your organization fully embraces the idea that non-engineers will prototype, AI will build, and engineers will review and harden. What does the resulting software actually look like?

I know, because I've seen early versions of it. Across four teams that went deep on vibe-coding workflows in 2025, there are common artifacts starting to emerge.

The code is structurally fine. Readable, even. Comments are excellent — AI comments well. Test coverage looks good on paper. But the systems have a specific flavor of wrongness that takes a while to name. They're built for the happy path with unusual thoroughness. And they fail in ways that are not in any test suite, because the failure modes weren't imagined in the prompts that generated the code.

One team I spoke with — a Series B SaaS company, roughly 40 engineers — went vibe-coding-first on a new data pipeline in late 2024. Shipping velocity tripled. Incident rate was flat for two months. Then they hit Black Friday. The pipeline had no backpressure mechanism. The AI had generated clean, efficient queue processing code that assumed queue depth was bounded. Under real peak load, it consumed memory until the service OOMed, cascading into three downstream consumers. Recovery took nine hours.

The postmortem finding: no one had asked the AI "what happens when the queue grows faster than we can consume it?" Because the PM who wrote the initial prompt didn't know to ask. And the engineers who reviewed the output were reviewing it for correctness, not for production failure modes they hadn't witnessed yet.

So Who Actually Survives This?

If the question is "what does the engineering career look like in a world where AI generates 80% of the code," the answer isn't just "learn to prompt better." That framing is too small. It optimizes for the wrong thing.

The survivors are the engineers who never let their professional identity live entirely in the code. They're the ones who were always curious about why a system needed to exist, not just how to build it. The ones who sat in product strategy meetings when they didn't have to. The ones who wrote design docs before anyone asked and kept them updated after nobody read them.

They're also the engineers who carry operational scar tissue. Production incidents are an education that no prompt can replicate. Every major outage you've lived through deposits something into your mental model of systems — a new category of "things that go wrong under conditions that weren't in the spec." That library of failure is, right now, one of the most underappreciated professional assets in engineering.

The survivors will be engineers who can sit across from an AI-generated system and run it through a mental gauntlet: what happens when the third-party API goes down? What happens when this queue backs up for six hours? What happens when someone sends a payload that's technically valid but semantically adversarial? What happens when this runs in the EU and GDPR applies to this field? Not because they're pessimistic — but because they've seen all of those things happen.

The Uncomfortable Truth About Fighting Back

I want to be careful here, because the easy response to all of this is: good engineers will always be needed. And that's technically true in the same way that good writers are always needed in the age of generative text. It doesn't tell you much about the market. It doesn't tell you which specific kind of good engineering will be compensated.

The uncomfortable advice, the kind I give to engineers who ask me directly: stop being the person who writes the most code, and start being the person who knows the most about what the code needs to survive in the real world. Those are different identities. They require different habits. And the transition is not comfortable, especially if you built your self-image around your coding ability.

The engineers who will own the next decade are the ones who can walk into a room where an AI has already generated a candidate architecture and say — clearly, specifically, with evidence — why that architecture will fail, what it will cost, and what needs to change before anyone touches a production database. Not because they can write better code than the AI. But because they've seen this movie before, in a dozen variations, and they know how it ends.

That's not a skill you can automate. Not yet. Maybe not ever.