Infrastructure is the Foundation

Welcome to this installment of Veo, where every week, I share a bit about what myself and others are seeing on the cutting edge of software product development.

In this issue…

Did someone forward this to you? If you like it, you can sign up here.

Want to grab time on my calendar? You can do that here.

-John Cox

For most of software's history, treating infrastructure as an afterthought was survivable.

That's maybe a hyperbolic statement. Let me walk it back.

The conditions that existed in traditional software development -- relatively slow throughput, small teams, developers who stayed on projects long enough to understand what they'd built -- created a kind of natural equilibrium. When a developer made an infrastructure decision because they needed to ("I need a database, I'll set one up"), the pace was slow enough that someone could notice and course-correct. And because the same people tended to work on the same systems, the decisions reflected the same knowledge, the same habits, the same limitations. It was inconsistent. But it was inconsistently consistent.

Okay, that's too generous. But the point holds.

What those decisions optimized for wasn't the system. It was the developer -- their knowledge, their preferences, what they knew how to stand up quickly. That's how you get security gaps that weren't malicious, just unconsidered. Compliance problems nobody planned for. Scalability ceilings nobody saw coming until something breaks at exactly the wrong moment. Every team has a version of this. The database that was set up for one service that twelve services now depend on. Things like that.

So the old model had a real problem. It just had a low enough rate of new infrastructure decisions that most teams could stay approximately ahead of it.

AI-assisted development changes the first part of that equation. Agentic engineering changes both.

I think when most technical leaders think about AI's impact on their teams, they think throughput. Faster code. More features. Smaller teams doing more. That's true and it's significant.

What doesn't get talked about as much is what faster throughput does to infrastructure. Every additional unit of work that gets done carries some probability of a developer making an infrastructure decision because they needed to. I need a cache. I need a queue. I need somewhere to put this data. AI didn't change that instinct -- it just removed the speed constraint that kept the volume of those decisions manageable.

And those decisions are still being made the same way they always were. Optimized around individual convenience, individual knowledge, individual limitations. Not what's right for the system. I mean, nobody standing up a database at 11pm has a systems-level view of what they're building into. They're solving the problem in front of them.

So you get the same sprawl. Just faster. At a scale no team can keep up with reactively. Left unchecked, it becomes a huge tangled mess of nastiness. And it compounds.

What changes this isn't better process or more code review. It's the infrastructure providing the rails -- before anyone needs to make those decisions.

By that I mean: the platform defines what workloads can reach, how they get deployed, where data gets stored, what identity they run under. Those aren't decisions left to whoever needs a database at 11pm. They're properties of the platform that workloads inherit. It reduces the solution space. The right call and the convenient call are the same thing.

So what does that actually look like?

Dave and I have been building toward this for a long time. A governed platform with composable patterns, a single configuration plane, and full-stack automation. Not because it's architecturally elegant -- though I think it is -- but because it's the only way infrastructure stays ahead of the work instead of perpetually catching up to it.

I think a few things have to be true for it to work.

Compliance has to be a structural property, not a checklist. If the controls are baked into the platform -- encryption, identity, audit logging, things like that -- they're in every workload by default. Nobody opts in. Nobody forgets.

The configuration plane has to be the only source of truth. I feel strongly about this one. When there are multiple sources of truth about what the infrastructure looks like, you cannot reason confidently about what's running on it. Drift accumulates. Something ships and nobody's sure what it can reach. That version of ownership -- and I've seen it -- isn't ownership. It's archaeology.

New environments have to be config declarations, not projects. When a team needs a new environment, that shouldn't trigger a sprint. It should be an expression of a platform that already knows how to build it. The tenth deployment should cost a fraction of the first because nothing was invented twice.

And the platform should handle itself. Provisioning, promotion, credentials, observability -- platform-owned. Every hour going to infrastructure toil is an hour not going to the mission.

The platform should disappear. The mission shouldn't.

Armed with that, the conversation about which AI tools to adopt becomes a lot more straightforward.

What's worth reading this week:

Why agentic AI stalls in production -- and how a control plane fixes it -- This is what happens when you skip the infrastructure layer. Agents that work great in a demo fall apart in production because there's nothing coordinating them. The New Stack

2026 Agentic Coding Trends Report -- Anthropic put out their own trends report on agentic coding and it's worth reading -- especially if you want the data behind what we've been saying all along. Anthropic

AI Validates You 47% More Than Humans. Here's What That's Doing to Your Judgment -- AI that tells you you're right 47% more than humans do feels great -- until you realize what it's doing to your judgment. Worth reading alongside everything else we share about AI as a tool. Arnold's Pump Club