The Soil Line: Where Vibe Coding Fits, and Where It Cannot Follow
Somewhere in your organisation in recent times, an engineer described a feature to a model, accepted most of what came back, and shipped something that works. They may not have read all of it. Ask them to walk you through a particular function and there is a fair chance they would have to go and look.
That is what a lot of engineering leaders and executives are worried about. Code is getting built faster than anyone is reading it. The discipline it took a decade to build is not being adhered to. I can appreciate the concern but it is aimed at the wrong target.
Vibe coding is not the problem
Andrej Karpathy coined the term in early 2025 for the mode where you “fully give in to the vibes” and forget the code exists. What may have got lost in transition is that he scoped it when he named it: prototypes, weekend projects, the afternoon you spend finding out whether an idea is worth pursuing at all.
Think of it as a seedling in a pot. The pot is cheap, the soil is shallow, and if the thing growing in it turns out to be wrong you empty it out and plant something else before lunch. That disposability does not indicate a weakness in the arrangement, it is the entire point of it. Putting a change advisory board kind of governance around a pot plant would be absurd, and teams that try mostly succeed in killing the exploration without improving anything downstream.
A pot essentially has one job: to prove or kill a hypothesis before you take the expensive step of building the real thing. Looked at that way, a pot you empty out has not failed. It bought you an answer for the price of an afternoon, which is the cheapest answer you can ever get. The teams that get the most out of vibe coding are the ones who start with the question they are trying to settle, rather than with the thing they are trying to build.
So developers experimenting in pots is not the problem. The problem is the afternoon someone carries the pot inside and buries it in the garden.
Adoption raced ahead. Trust went backwards.
Three numbers from the past year set up the problem.
Figure 1 · The gap: adoption and trust moved in opposite directions in the same year, and the third number says why.
DORA’s 2025 verdict explains that gap better than anything else I have read. AI is an amplifier. It magnifies whatever a team already has: strong delivery practice gets multiplied, and so does every existing dysfunction. Throughput rises, and instability rises alongside it. I have written before about why most companies stall between AI-assisted and AI-Led. This is one of the reasons why.
Which means the question was never whether to let people use AI. It is what the amplification is running through.
Where the ground changes
The soil line is not drawn by the tool you used. It is drawn by what happens when the thing is wrong. Almost everything else follows from that.
| Above the soil line: the pot | Below the soil line: the roots |
|---|---|
| Exploration | Production |
| Speed | Reliability |
| Disposable by design | Maintained for years |
| Nobody inherits it | Someone owns every merge |
| Lightweight controls | Explicit, enforced controls |
| Vibe coding can work | Engineering discipline required |
Everything above the line is legitimate. Vibe coding is how an idea gets explored in an afternoon, and plenty of internal tools belong there. Lighter oversight there is a deliberate choice. Below the line the tooling can be identical. The consequence is what changes, and every row in that table follows from it.
Seedlings transplant. Prototypes don’t.
In a garden you can lift a seedling out of its pot and plant it in the ground. That is the one move the metaphor invites, and the one move that breaks down here. A vibe-coded prototype is not a young version of the production system. It is a different artifact with a different job, and it has already done that job. What you got from it was the answer.
What crosses the soil line is the learning: the spec, the shape of the solution, the approaches you tried and discarded, the feedback you got. The code gets regrown under roots.
Figure 2 · What crosses over: the code stops at the line; the learning crosses it and the system is grown again underneath.
That sounds like throwing away working code, and working code feels like an asset. It is not. The return on a prototype is the certainty it bought you, not the source it left behind. And the rebuild is usually faster than people expect, precisely because the prototype removed the uncertainty. A clear specification plus deterministic verification is exactly the case where agentic generation is genuinely reliable.
The caveat though: this is a rule for work that crosses the line, not a universal law. Plenty of internal tooling should be promoted as it stands and not gated, because nothing bad happens when it breaks.
What the roots actually are
When people say production-grade, they usually mean something narrow: bugs, test coverage, a quality gate or two. Here is my list. None of it is new, which is the point.
- Reviewable specs. Intent becomes an artifact before code exists, so a human can disagree while disagreeing is still cheap. This is the root that makes everything downstream checkable.
- Quality gates. Nothing advances because it looks finished. It advances because it passed something, and the same something every time.
- Verification loops. The agent iterates until the checks pass. The generator stays probabilistic; the verifiers are what bring determinism. CI pipelines, test suites, parity checks and policy scans have no opinions.
- Audit trail. Every change traces from prompt → spec → diff → review → merge. At any point you should be able to reconstruct why a line of code exists, and who decided it should.
- Human accountability. A named person owns every merge. AI drafts, humans decide. This is the one root you cannot hand to an agent, and the one that leadership and incident reviews all eventually ask about.
This is also what unlocks the next step. Once the roots are real, you can hand a much bigger share of the work to agents, run them in verification loops until the checks pass, put a second agent’s review in front of a human’s, and still get the quality you expect. That is the move from AI-assisted to AI-Native. The roots are what make it possible.
Two things to expect to get to this level of maturity. The first is called the J-Curve. Teams get slower before they get faster, from the learning curve, the tax on reviewing generated code, and the process changes that follow. DORA calls this the cost of transformation and warns that leaders who read the dip as failure tend to give up at exactly the wrong moment.
The second is that adoption increases individual effectiveness and delivery instability at the same time. In one healthcare software organisation I worked with, a review of recent production incidents found that five of the last six had been discovered by users rather than by any gate the team had in place. Nobody was careless. The gates simply did not exist yet in the places the new speed had started to reach.
You already know this shape
Leaders worry that design documentation, architecture records and review discipline quietly disappear in the agentic era. The answer is reassuring: spec-driven development has constitution, design, specs and tasks. It is the same methodology you knew from Agile, codified differently so that agents as well as humans can execute against it. GitHub’s Spec Kit, OpenSpec, Amazon’s Kiro and others put a specify, plan, break down, implement pipeline in front of the agent, so teams arriving at this shape independently are on the mainstream path, not off it. This is what tells you that there is a method to the madness, albeit a different one tuned for Agents.
If you build in a regulated industry it should feel less new still. HIPAA already requires you to “record and examine activity” in systems handling patient data. FDA design controls already require verification that design outputs meet the design inputs, documented, with the individual who performed it identified.
Your product has lived under that standard for years. Agentic engineering holds how you build to the same standard as what you build.
The fair objection to all of this is that spec-first work degrades into mini-waterfall: requirements written up front, frozen, handed down, discovered to be wrong at integration. The criticism is valid. What makes spec-driven development work is treating the spec as emergent rather than ready. Its job is to make intent reviewable without shutting down discovery, and continue to evolve as the code evolves so it doesn’t get stale.
The bigger failure, and in my view the more common one, is adopting the full root system everywhere, including on work where nothing bad happens if it breaks. That is not engineering rigour, it is waste, and it is the fastest way to make engineers hate the whole idea.
Where does your line sit?
Three questions do most of the work here. They are adapted from Addy Osmani’s blast-radius framing for agentic code review. He uses them to decide how deep a review should go. I use them one step earlier, to decide which side of the line the work sits on.
Figure 3 · Three dials: the clean answers at either end are rare. Most real work sits in the shaded middle. Adapted from Addy Osmani’s blast-radius framework for agentic code review.
Low across: it is a pot, so optimise for speed. High across: it needs roots, every one of them, every time. Most real work sits somewhere in between, and that is fine. The three questions still help, because now the team is arguing about blast radius rather than about who is being careless.
One practical note: decide this as a working agreement, not for each ticket. A team that keeps debating the soil line every sprint has replaced governance with ad-hoc negotiation.
Two questions worth asking this week
If you are an executive or senior engineering leader: ask what sits below your soil line, and how robustly it is governed. You are not auditing. You are finding out whether the team has a shared answer, because the absence of it is the actual risk.
If you are an engineer: leadership is not only asking for higher productivity. They are asking whether the SDLC stays as reliable and controlled as it was before AI. Knowing when a pot is enough, and when it is not, is now part of the craft. Showing you know is what builds trust.
The teams I worry about are not the ones vibe coding. They are the ones where the line is getting drawn anyway, by whoever happens to be typing that afternoon, because nobody ever agreed where it should sit. In my experience that is also where companies stall between AI-assisted and AI-Native. Most teams I talk to cannot tell where their soil line sits.
Can yours? I would love to hear where you drew it. Reach out.