Everyone's a Developer Now — So What?

We are living in a moment where the barrier to entry for building software has never been lower. Anyone with a keyboard and access to an LLM can produce working code in minutes. Natural language is becoming a programming language. Product managers are prototyping features over lunch, Designers are shipping functional components before the sprint planning meeting, and Marketing is building internal tools without filing a ticket.

It's also causing a bit of an identity crisis across the industry.

The prevailing narrative is that AI has democratized software development, and that's true in a narrow sense. What it has actually democratized is code generation, and the gap between generating code and building software has never been wider.

The vibe coding phenomenon

There's a pattern playing out at companies right now — Andrej Karpathy named it "vibe coding" in early 2025 — and it goes something like this: someone asks an LLM to build an entire solution in a single prompt. They get back something that looks remarkably complete. They accept it without much scrutiny because it runs and it looks right. Then they spend the next eight hours in what can only be described as "vibe fixing," wrestling with edge cases, mysterious behaviors, and architectural choices they didn't ask for and don't fully understand. Eventually, they hand the result to an engineer and say, "Deploy this." That gap is what this series is about.

If you think I'm exaggerating, talk to your senior engineers. They're seeing this. The code arrives looking polished: syntactically clean, well-formatted, superficially correct. That's precisely what makes it dangerous. It carries all the signals that historically triggered merge confidence, but none of the underlying engineering rigor. A December 2025 study of 470 GitHub pull requests found AI-co-authored code had 2.74× more security vulnerabilities than human-written code.

The vibe coder isn't malicious. They're a product manager who wanted to validate an idea, or a founder who needed a prototype fast, or a junior developer who figured the AI knew better than they did. The intent is fine. The process is broken.

Why this matters for engineering leaders

This is not a developer productivity story. It's an organizational risk story.

When everyone in your organization can generate functional-looking code, the bottleneck doesn't disappear. It moves. The question is no longer "can we build it?" It's "should we ship it?" And more critically: who in your organization is equipped to answer that question?

Every team I talk to is dealing with some version of this or is feeling pressure to allow this. AI-generated pull requests are stacking up. The volume of code entering the system has increased dramatically, but the capacity to understand that code hasn't scaled with it. Your most senior engineers, the ones with the system-level mental models to know whether something is actually safe to deploy, are now spending more time reviewing AI output than designing systems.

This is the new resource allocation problem, and if you're not thinking about it deliberately, it's allocating itself.

The accountability problem

There's a deeper issue here that Variant Systems articulated well in "The Cost of Delegation." Under the old model of delegation, when you hired an expert (a consultant, a contractor, a senior engineer) you were transferring two things simultaneously: the execution of the work and the responsibility for the outcome. If the work failed, someone's reputation was on the line. The money you paid bought more than labor. It bought accountability.

AI broke that contract in half.

You can now delegate execution at a fraction of what it used to cost. You can spin up agents that function as entire workflows. The execution scales almost infinitely. But accountability? That doesn't transfer at all. It stays with you. The AI agent has no legal identity, no financial exposure, no career on the line. If it generates code that introduces a security vulnerability or quietly breaks a downstream service, nobody gets fired. There's nothing to fire. The loss is yours entirely.

Here's the part that should keep engineering leaders up at night: the more you delegate to AI, the more responsible you become, not less. Every AI-assisted workflow you deploy is another surface area of failure that funnels back to the people accountable for the system. Scale doesn't distribute the risk. It concentrates it.

The developer vs. engineer debate, restarted

The industry spent years debating the distinction between "developer" and "engineer." AI has resurrected that argument in a form that actually matters now.

Code generation — taking a description of what you want and producing something that compiles and runs — is a developer activity. It always has been. The tools have changed (from writing it by hand to prompting an LLM), but the fundamental nature of the activity is the same: translating intent into code.

Engineering is something different entirely. Engineering is the discipline of building systems that are reliable, scalable, secure, and maintainable. It's the practice of identifying constraints before you write a single line. It's understanding that the code that runs in a demo and the code that runs in production are separated by an ocean of decisions about failure modes, edge cases, observability, data integrity, and operational complexity.

AI has made the developer activity nearly free. It has not made the engineering activity any cheaper. If anything, it's made it more expensive, because the volume of code that needs engineering judgment applied to it has exploded, while the supply of people capable of providing that judgment has not.

This is where the vibe coding process breaks down. It skips the engineering design loop: identify the problem, brainstorm solutions, select a design, build a prototype, test and evaluate, optimize. AI can accelerate every step of that loop. But the loop itself is non-negotiable. When you skip it, when you go straight from prompt to production, you're not doing engineering. You're doing something that looks like engineering from a distance, and the gap between those two things is where failures live.

The real question

If your only response to the AI moment is "now everyone can code," you're focused on the wrong capability. Code was never the hard part. Deciding what to build, defining how it should behave under stress, ensuring it doesn't break the systems it connects to, and maintaining it over time? That was always the hard part. AI didn't change that. It just made it easier to skip.

The organizations that will thrive in this era are the ones asking a different set of questions. Not "how do we generate more code?" but "how do we ensure that what we generate is worth deploying?" Not "can everyone be a developer?" but "who is responsible for the engineering judgment that separates a prototype from a product?"

These aren't technical questions. They're organizational ones. And they require a framework, a way of working that channels AI's speed through engineering discipline rather than around it.

That framework exists. It's called Spec-Driven Development, and we'll get to it later in this series. But before we talk about the solution, we need to understand what's actually scarce in an AI-native organization. It's not coding ability. It's the engineering mindset.

That's next.

---

Next in the series: "The Engineering Mindset Is at a Premium" — why constraint design, not code generation, is the most valuable competency in an AI-native company.