The Four Vs of Code
Code isn't solved, but it will be fundamentally different from now on
The Unwinnable Race
I recently gave a talk framing the AI transition as the industrialization of software engineering. The parallel held—the audience nodded along as I connected AI-assisted engineering to the cloud transition as an earlier shift in the economics of production.
But something nagged at me afterward. The cloud transition changed where and how we ran software, but it didn’t change the fundamental nature of the thing being produced. It was a change in the plumbing, not the water.
Then, last week, I found myself in yet another conversation with a platform lead about “optimizing code review.” They were looking for the right combination of assignment logic, reminder bots, and “reviewer fatigue” metrics to make their process “work really well.”
As we talked, I realized they were trying to win an unwinnable race. They were trying to apply human-rate friction to machine-rate volume.
That’s when it clicked. The cloud wasn’t the right parallel. The data wave was.
Cloud, mobile, and big data arrived together and broke our existing data infrastructure. The “4 Vs of Data” (Volume, Velocity, Variety, Veracity) gave us a language for why. We aren’t in the first industrialization of software engineering. We’re in the second. The data wave was the first.
And just like before, the axis scales of what we produce are shifting, and that shift is what breaks the infrastructure.
The “Solved” Fallacy
You’ve probably seen the headlines: “Coding is solved.” Boris Cherny, head of Claude Code, recently said exactly that. The token sellers love this framing because it sells, well, tokens. It’s the Hadoop moment all over again.
In 2012, people claimed data was “solved” because we had Hadoop. But Hadoop only solved the obvious first problem: storing and processing at scale. It didn’t solve data quality, lineage, or governance. In fact, Hadoop behaved more like a problem scaler than a creator. These issues existed before, but the presence of those problems was scaled out with Hadoop to a point where they could no longer be ignored.
AI producing code is the Hadoop equivalent. It’s the enabling condition, not the solution. The forces that AI-rate code production creates are the actual problem. And if we want to survive this wave without drowning in a swamp of “good enough” boilerplate, we need to understand the 4 Vs of Code.
The Four Forces
The same forces that broke data infrastructure are now breaking code infrastructure.
1. Volume: The Infinite Monkeys. We’re moving from a world where code was a scarce resource written by expensive humans to one where it’s a commodity. Engineers using AI effectively are reporting 2-5x productivity uplifts. That’s not 2-5x more typing; it’s 2-5x more functioning software moving through our systems. More branches, more PRs, more surface area to understand and maintain.
2. Velocity: Continuous Generation. The gap between idea and running code is shrinking. We’re moving past Continuous Integration into Continuous Generation. Cycle times are compressing, and the rhythm of engineering work is accelerating past the point where a human can “keep up.”
3. Variety: Polyglot Sprawl and Cheap Retries. When you can produce code quickly in unfamiliar territory, you stop routing around your skill gaps. This leads to “variety”—engineers working across more languages and frameworks than they’d ever attempt solo. It also means we can generate multiple implementations or “tries” at a problem for nearly the same negligible cost, leading to a proliferation of approaches to the same issue. It sounds like a superpower, but it stresses ownership models. Who owns the Python script inside the Go service that was generated by someone who doesn’t actually know Python? Or the three alternative implementations an agent generated while trying to find the “best” one?
4. Veracity: The Hallucination of Correctness. Generated code has a trust problem. AI produces plausible output with variable correctness. It looks right, it’s well-structured, and it might even pass initial tests. But it can be subtly broken or insecure in ways that are hard for a human to spot at scale.
The Squeeze: Volume × Velocity
The Vs individually are manageable. It’s the interactions where the wheels fall off.
Take Volume × Velocity. This is the “unwinnable race” I was discussing with that platform lead. Every organization running AI-assisted engineering at scale has the same complaint: the review queue.
More code is arriving faster than humans can read it. Our current response is to ask humans to read faster or to “be more diligent.” The arguments that this approach is already breaking are getting louder. This is the “bigger-Postgres-instance” response. It works for a while, but it doesn’t scale.
When an agent produces a complete feature implementation in minutes, requiring a human to read every line before merge isn’t rigor; it’s a scaling constraint wearing the costume of rigor. We don’t read every line of compiler output or generated protobuf code because we have verification infrastructure that makes line-by-line review unnecessary.
Agent-produced code doesn’t have that infrastructure yet.
The “Data Lake” Moment for Code
This is the “Data Lake” moment for our craft.
The data lake didn’t emerge because someone thought it would be fun to store everything in one place. It emerged because volume and variety made “schema-first ingestion” (the data equivalent of code review) untenable.
The infrastructure inverted: store first, schema on read.
Code is heading for a similar inversion: merge first, verify continuously.
Our platforms—Git, GitHub, our CI pipelines—were built on the assumptions of the data warehouse: human-rate production, sequential process, and specialist operators. Those assumptions are currently under a level of pressure they weren’t designed to handle.
The Infrastructure Demand
We’re in the “patching” phase right now. We’re adding better reminder bots and longer review times. But the real shift is going to require new categories of infrastructure:
Verification Infrastructure: Continuous, automated, and probabilistic. We need systems that can verify the veracity of code without requiring a human to “look at the diff.”
Context Infrastructure: Making our platforms legible to AI. If your platform confuses humans, it really confuses AI. We need machine-readable context (API docs, schema registries) that turns inference into fact-based operation.
Absorption Infrastructure: Systems that can handle higher code volume without proportional human review cost. Smarter merge systems and automated quality gates are no longer “nice to haves.”
Stop Typing, Start Stewarding
The ground is shifting. It’s uncomfortable, it’s noisy, and it feels like we’re losing our bearings. But we’ve navigated a wave like this before.
We need to stop treating code as a precious artifact and start treating it like the industrial output it’s becoming. This means shifting our focus from writing to reading, from owning to stewarding, and from gatekeeping to verifying.
If the monkeys are going to be this fast, we’d better be great stewards.
The question isn’t whether the infrastructure will be re-engineered. The question is whether we’ll build ahead of the curve or get dragged past it.
For platform and infrastructure engineering, this is going to be a very interesting few years.