Thought Leadership 11 min read

# The Future of Software Engineering After Vibe Coding

The debate everyone is having — do AI agents replace engineers? — is the wrong one. The real shift is not human-written code versus AI-written code. It is exploratory generation versus accountable production. Vibe coding discovers what could exist. Engineering decides what is allowed to persist. And the work of deciding is about to become the whole job.

By Theo Valmis·June 2026

In May 2026, Bloomberg ran a segment titled “Why Vibe Coding Isn’t the End of the Software Engineer.” It follows a warehouse owner who rebuilt his shipping software by prompting an AI, and a designer who shipped her first app with no technical background — and then a Google Cloud AI director making the case that none of this means the end of serious engineering. In passing, it notes something sharper than its own headline: junior-developer hiring is falling fast, and researchers warn that companies are making a dangerous short-term bet.

That tension is the whole story, and the usual framing misses it. The question is not whether AI writes code instead of humans. It is whether the thing being produced is an exploration or a system someone is accountable for. Those are different activities with different success criteria, and conflating them is how teams get hurt.

Vibe coding — a term Andrej Karpathy coined in February 2025 — names one end of that spectrum precisely. In his original sense it means giving in to the vibes: you prompt, you run, you copy-paste, and you largely stop reading the code. He framed it as fine for throwaway weekend projects. It is not a synonym for all AI-assisted or agentic engineering, and the difference is the entire subject of this essay. Vibe coding is what happens when generation is unaccountable on purpose. Engineering is what happens when it cannot be.

## Vibe coding is a discovery primitive

Start by giving vibe coding its due, because the reflex to dismiss it is as wrong as the reflex to worship it. Vibe coding is a genuine advance in one specific thing: compressing the distance between an idea and a working artifact. It removes friction from experimentation. It lets a non-engineer turn a hunch into something runnable. It pulls engineering earlier into discovery, where the cost of trying an idea used to be the thing that killed it. As a way to find out what could exist, it is the best tool the industry has ever had.

What it is not is a way to decide what should exist, or what is allowed to stay. A prototype is not an operational system. Generated code inherits no accountability for the system it lands in. An agent optimizing for completing the task in front of it is not optimizing for the maintainability of the codebase around it — and the very speed that makes vibe coding feel magical is what hides the architectural drift it produces. The output looks finished, which is exactly the problem: nothing about looking finished tells you whether it belongs.

Vibe coding discovers what could exist. Engineering decides what is allowed to persist. The first is a generation problem and AI has largely solved it. The second is a judgment problem, and it is the part that does not automate.

So the interesting question is not whether vibe coding is good. It is good, at the thing it is for. The interesting question is what happens at the boundary — the moment an explored artifact tries to graduate into a system people depend on. That boundary is where engineering now lives.

## The unit of engineering work inverts

Here is the shift the “replacement” debate cannot see. When agents absorb the writing of code, the engineer’s unit of work does not disappear. It inverts. The job stops being author the diff and becomes specify and enforce the envelope the diff is generated inside. The agent authors the content. The engineer authors the boundary.

This is what “software engineering moves from producing code to governing systems that produce code” actually means in practice. It is not a slogan about engineers becoming editors. It is a concrete relocation of where the human adds value: from the implementation, which is now cheap and fast, to the constraints the implementation must satisfy, which are now the scarce and load-bearing thing. The decisions — which dependencies are allowed, which boundaries are inviolable, which patterns are standard, which older choices have been superseded — are the work. Writing them down in a form a system can apply before generation is the work. Making them machine-evaluable so they hold across every agent and every run is the work.

The industry has done this before, every time it added an abstraction layer. Cloud raised leverage and created a whole security-and-compliance discipline around it. Continuous delivery raised velocity and pulled observability and SRE into existence. Platform engineering productized the boundary so product teams could move inside it safely. Each layer increased what a team could do and increased what had to be governed for that power to be survivable. AI coding is the same pattern at a higher altitude: the leverage is enormous, and the governance requirement scales with it, not against it. This is the through-line in the AI SDLC and in why AI is becoming the operating layer for software execution — delegation, not interaction, is the new default, and delegation only works inside a boundary the delegator defined.

## What governing the systems actually requires

If engineering becomes governing, it is worth being precise about what that demands — and three of its hard parts already have their own treatments, so this is the short version with the pointers.

You supervise fleets, not files. Engineers increasingly oversee many agents working in parallel, and a console that shows you what they are doing is not the same as a layer that constrains what they are allowed to do. A control plane without policy is just visibility, the distinction drawn in the agent manager as the new control plane.

Tests and evals are necessary and not sufficient. Linting, benchmarks, security scans, and behavioral evals all matter, and none of them defines correctness. A run can be graded as having behaved acceptably and still merge a diff that contradicts a decision the team ratified — the gap examined in GitHub’s Trust Layer validates behavior, not architectural conformance. A system can pass every check and still be locally correct and globally destructive.

Visibility shrinks as autonomy grows. The more the system does, the less of its actual reasoning a human sees — you review summaries, plans, and diffs, not the full cognitive process. Monitoring records the drift; it does not prevent it, which is why observability is not governance. As execution surface expands, visibility contracts, and the blind spot is where failure accumulates quietly.

None of these is the headline of this essay, because each is already its own argument. Together they describe the shape of the new job: the engineer is accountable for systems they did not directly author, and the only way to be accountable for what you did not write is to govern the conditions under which it gets written.

## The apprenticeship was the governance

Which brings us to the thing the Bloomberg segment mentioned almost in passing, and the part of this shift that is genuinely under-discussed. The risk to engineers is not replacement. It is the quiet collapse of how engineering judgment was ever made in the first place.

There is hard data underneath the anxiety. Stanford’s “Canaries in the Coal Mine” study, built on ADP payroll records, found that since generative AI spread, workers aged 22–25 in the most AI-exposed occupations — software development among them — saw roughly a 13% relative employment decline (revised to about 16% in late 2025), while older and less-exposed workers held flat or grew. That is a relative shift controlling for firm-level shocks, not an absolute collapse in headcount — but the direction is unambiguous, and it points at the entry level. Meanwhile Stack Overflow’s 2025 survey found 84% of developers use or plan to use AI tools while only 3.1% say they “highly trust” their output. Adoption is near-total; trust is near-zero. That is the signature of a tool doing the work without anyone learning from it.

Now look at what apprenticeship actually was. Juniors learned by debugging, by taking incremental ownership, by being exposed to architecture, by failing and repeating. But the loop ran in both directions, and the upward direction is the one nobody counts. Mentoring forced seniors to make tacit architectural intent explicit. To teach a decision, you have to articulate it, defend it, and watch a junior stress-test it with a naive question that exposes the part you had stopped examining. Apprenticeship was not only how juniors absorbed intent. It was how the organization re-encoded and refreshed its intent, generation after generation.

Vibe coding collapses that loop from both ends. Juniors ship through agents without ever metabolizing the decisions, so intent never gets absorbed. And seniors stop teaching, because the agent “already knows” — so intent never gets re-articulated. The mechanism that kept architectural intent current, contested, and alive simply stops running.

Apprenticeship was the org’s intent-renewal mechanism, not just its training program. “Intent debt” used to be paid down silently by mentorship — every time a decision was taught, it was refreshed. Remove the loop and intent debt compounds with no human sink. This is a different problem from the curriculum gap in agentic engineering education: that is about what we teach; this is about the renewal process disappearing entirely.

The cost of a lost architectural decision used to be bounded by review latency — someone, eventually, in a code review or a mentorship moment, would re-encounter the decision and either restate it or knowingly retire it. Under vibe coding that bound is gone, because the human who would have re-encoded it never enters the loop. A decision that is never taught and never enforced does not get retired. It gets forgotten while the code that depended on it keeps shipping.

## Governance has to do the work the loop used to

This reframes what governance-as-infrastructure is for. The homepage version of the argument is that AI writes more code, so you need a layer that enforces architectural decisions. True, but too small. The deeper claim is this: governance tooling now has to do the intent-renewal work that apprenticeship used to do, because apprenticeship is being decommissioned, not merely under-taught.

If the human institution that kept architectural intent current is going away, the intent has to live somewhere a machine can hold it, apply it, and surface it — compiled into explicit, versioned, machine-evaluable constraints, enforced before generation and at every gate, propagated to every agent and surface regardless of who or what produced the change. Not a wiki a junior was supposed to read. Not a senior’s memory that retires when they do. A governing layer that re-applies the decision every single time, which is the only form of “mentorship” that scales to a fleet of agents that never sat through a code review.

This does not bring apprenticeship back, and it should not pretend to — the human formation of judgment is a real loss the industry will have to reckon with separately, including by deliberately preserving the parts of the loop that make senior engineers. But it does keep the output of that judgment — the decisions themselves — alive and enforced after the process that used to carry them has thinned out.

## What the future engineer actually does

The future engineer is not replaced by agents. The future engineer governs increasingly autonomous execution. Coding becomes partially automated; accountability does not, and accountability is the part that was always the job. The engineers who thrive in this era are the ones who can define what quality means in their context, preserve architectural integrity as the system rewrites itself, encode organizational memory into something enforceable, set the governance boundaries agents operate inside, and — the rarest skill — know when not to ship.

Vibe coding earned its place by making discovery almost free. That is a real gift, and it is not going away. But free discovery raises the value of everything downstream of it: the judgment about what graduates into production, the constraints that judgment compiles into, and the layer that holds those constraints when the humans who would have carried them are no longer in the loop.

In the post-vibe-coding era, engineering stops being only about writing systems. It becomes about governing systems that can now write themselves — and about keeping the decisions those systems must respect alive after the apprenticeship that used to renew them is gone.

## Frequently asked questions

What is vibe coding?+
Vibe coding is a term coined by Andrej Karpathy in February 2025 for a mode of building software where you prompt an AI, accept what it produces, and largely stop reading the code itself. He framed it as fine for throwaway weekend projects. It is not a synonym for all AI-assisted or agentic engineering; the defining feature is the absence of review. The distinction between exploratory vibe coding and accountable, reviewed engineering is the whole subject of the post-vibe-coding conversation.
Does vibe coding replace software engineers?+
No. It changes what engineering is. As AI agents absorb the writing of code, the engineer’s unit of work shifts from authoring the diff to specifying and enforcing the constraint envelope the diff is generated inside. Coding becomes partially automated; accountability for reliability, security, and architectural integrity does not. Engineering moves from primarily producing code to governing the autonomous systems that produce it — which, as autonomy rises, requires more judgment and governance, not less.
Why is the decline of junior-engineer roles a governance risk?+
Apprenticeship was never only training. The junior-to-senior pipeline was the mechanism by which a team’s architectural intent got re-articulated, contested, and refreshed each generation — seniors had to make tacit decisions explicit in order to teach them. When agents absorb the entry-level work and juniors ship without metabolizing those decisions, that intent-renewal loop shuts down. The result is not just a skills gap; it is the loss of the process that kept architectural intent current. Intent debt that apprenticeship used to pay down silently now compounds with no human sink.
What replaces apprenticeship as the way architectural intent is preserved?+
Governance as infrastructure. If the mentorship loop that used to transmit “what is allowed to persist” is being decommissioned, the decisions it carried have to live somewhere a machine can read and enforce them: architectural intent compiled into explicit, versioned, machine-evaluable constraints that are applied before generation and at every gate, independent of which agent or which engineer produced the change. The governing layer now has to do the intent-renewal work the human loop used to do, because that loop is going away, not merely being under-taught.
Related essays

- AI-Native Engineering Has an Intent Debt Problem

  The debt apprenticeship used to pay down silently, now compounding with no human sink.

- The Rise of Agentic Engineering Education

  The curriculum companion: what the new discipline has to teach.

- GitHub's Trust Layer Validates Behavior, Not Architecture

  Why tests and evals are necessary and not sufficient for correctness.

- The Agent Manager Is the New Control Plane

  Supervising fleets of agents is not the same as constraining them.

Related governance concepts

- Governance Before Generation

  Applying the team's decisions as constraints the agent meets before it writes.

- Reliable Delegation

  Delegation only works inside a boundary the delegator actually defined.

- Governance Propagation

  The same constraints reaching every agent and surface, regardless of who produced the change.