A few weeks ago, I spoke about Platform Engineering & DevOps - Building the Software Factory of the Future. At the time, I was thinking primarily about how we make software delivery faster, safer, and more scalable.
But, what happens when the ability to build software is no longer limited to engineering?
Designers can prototype and build. PMs can turn ideas into working experiences. Engineers can use agents to build entire services, automate tests, and provision infrastructure.
For years, one of the biggest constraints in software organizations was simple: there weren’t enough people who could get an idea all the way to production. Engineering capacity was scarce.
That scarcity created:
- Backlogs
- Prioritization
- Handoffs
- Estimates
- Review queues
- Release processes
AI is beginning to change that.
A developer can ask an agent to implement a feature. A designer can prototype something themselves. A PM can explore an idea before handing it to engineering. Agents can generate tests, documentation, infrastructure, and even help operate systems.
The constraint starts moving.
From “Can we build it?” to “Should we build it?” And eventually: “Can we operate everything we’re now capable of building?”
That’s a very different problem. Because when the cost of creating software falls dramatically, we may discover that production capacity was never the only bottleneck.
Decision-making becomes more important. Architecture becomes more important. Customer validation becomes more important. Operational simplicity becomes more important.
And perhaps most importantly: the organization needs to become better at deciding what should NOT be built.
I’m increasingly convinced that the next evolution of Platform Engineering isn’t just about building a better software factory. It’s about building the operating system for an AI-native engineering organization. That’s the question I’m exploring next.
The Old Constraint
Historically, software organizations had a fairly obvious constraint:
There weren’t enough people who could take an idea all the way to production.
And there was another constraint:
Leadership couldn’t make decisions fast enough about what should go to production.
AI is attacking the first constraint very aggressively.
%%{init: {"themeVariables": {"fontSize": "22px", "primaryColor": "#f0f0f0"}}}%%
flowchart LR
A[IDEAS]
B["Product / Design"]
C[Engineering]
D["CONSTRAINT #1:<br/>HUMAN CAPACITY BOTTLENECK"]
E["Code / QA"]
F["CONSTRAINT #2:<br/>DECISION BOTTLENECK<br/>(should this ship?)"]
G[Production]
A --> B --> C --> D --> E --> F --> G
classDef constraint fill:#fff3b0,stroke:#333,stroke-width:2px;
class D,F constraint
There was also a lot of “paper pushing”: handoffs, tickets, specifications, waiting for engineers, review queues, coordination, implementation estimates, prioritization ceremonies. Some of that existed because production capacity was scarce.
AI Changes Constraint #1
Now:
%%{init: {"themeVariables": {"fontSize": "22px", "primaryColor": "#b2dfdb"}}}%%
flowchart LR
A[Idea]
B["Designer / PM"]
C[Agent]
D[Prototype]
E[Production]
A --> B --> C --> D --> E
A designer can increasingly go from “I have an idea” to “I built it.” That is a profound organizational change.
The bottleneck moves. Before: can we build it? Increasingly: should we build it? And then: can we safely operate it?
The Shipping Paradox
This creates the paradox you identified. If production capacity becomes abundant, you can end up shipping too much. Not too little. That’s a fascinating inversion.
---
title: Regular SDLC (Before AI)
config:
themeVariables:
fontSize: 22px
primaryColor: "#f0f0f0"
---
flowchart LR
O1[Ideas] --> O2["Limited engineering capacity"] --> O3[Prioritization] --> O4["Selected ideas"] --> O5[Production]
classDef important fill:#fff3b0,stroke:#333,stroke-width:2px;
class O2,O3 important
In the old world, engineering capacity was the filter. Ideas passed through prioritization because only a few could be built, and the ones that survived went to production.
---
title: AI-Assisted ERA
config:
themeVariables:
fontSize: 22px
primaryColor: "#f0f0f0"
---
flowchart LR
A1[Ideas] --> A2["Very low implementation friction"] --> A3["Many ideas"] --> A4["Many prototypes"] --> A5["Many production candidates"] --> A6["???"]
classDef important fill:#fff3b0,stroke:#333,stroke-width:2px;
class A2,A5,A6 important
In the AI world, nothing filters the pipeline anymore. Every idea can become a prototype, and every prototype becomes a production candidate. What happens next is the open question.
Suddenly the organization’s ability to decide becomes more important than its ability to build.
Operational Overhead Moves Downstream
This is the part I’d emphasize. If everyone can ship, you don’t eliminate operational complexity. You move it downstream.
---
title: Regular SDLC (Before AI)
config:
themeVariables:
fontSize: 22px
primaryColor: "#f0f0f0"
---
flowchart LR
B1[Idea] --> B2[Build] --> B3[Review] --> B4[Release] --> B5[Operate]
BS["bottleneck"] -.-> B3
classDef important fill:#fff3b0,stroke:#333,stroke-width:2px;
class BS important
In the old world, the bottleneck sits in the middle: at Review. Ideas flow freely until they hit review queues, approvals, and release processes. Once past that gate, shipping is comparatively easy.
---
title: AI-Assisted ERA
config:
themeVariables:
fontSize: 22px
primaryColor: "#f0f0f0"
---
flowchart LR
D1[Idea] --> D2[Build] --> D3[Review] --> D4[Release] --> D5[Operate]
DS["decision bottleneck"] -.-> D1
OS["operational overload"] -.-> D5
classDef important fill:#fff3b0,stroke:#333,stroke-width:2px;
class DS,OS important
In the AI era, the middle collapses. The friction moves to the two ends: deciding what should exist at the start, and operating everything that ships at the end. The overload doesn’t disappear, it moves downstream.
You may get:
- More services
- More features
- More experiments
- More dependencies
- More APIs
- More infrastructure
- More telemetry
- More security surface
- More things to maintain
So the question becomes: how do we prevent the organization from turning abundant production capacity into production sprawl?
The Cost Curve Splits
If engineers can ship more, designers can ship, PMs can prototype, and agents can implement, the cost of creating software collapses.
But the cost of understanding, operating, securing, maintaining, and retiring doesn’t necessarily collapse at the same rate.
So you potentially get:
---
title: The Cost Curve Splits
config:
themeVariables:
fontSize: 22px
primaryColor: "#f0f0f0"
---
flowchart TD
C1["COST OF BUILDING"] --> D1[collapses]
C2["COST OF OPERATING"] --> D2["drops slowly"]
C3["COST OF DECIDING"] --> D3[rises]
C4["COST OF COMPLEXITY"] --> D4[rises]
classDef important fill:#fff3b0,stroke:#333,stroke-width:2px;
class C3,D3,C4,D4 important
That’s a very strong enterprise architecture argument.
A New Role for Leadership
Leadership used to control scarce engineering capacity.
“We only have 20 engineers. Which 10 things should they build?”
With AI: “We could build all 20. Which 3 should exist?”
That’s a radically different management problem. The scarce resource becomes organizational attention.
And then those judgments become the entire game. Product judgment matters because when everyone can build, the ability to know which problem is worth solving is the only filter left, and a feature that ships easily is still a feature nobody asked for. Architecture judgment matters because easy building makes easy sprawl, and the constraint is no longer creating the next service but keeping the whole system coherent, integrable, and simple to reason about as it grows. Customer insight matters because the validation loop moves from “did we build it right” to “should it exist at all,” and the teams that talk to customers will consistently out-decide the teams that merely ship faster to them. Risk judgment matters because more production candidates mean more exposure, more security surface, more probabilistic failure, and the leader’s job becomes deciding which bets are reversible, which are contained, and which should never be taken at any speed. Capital allocation matters because when implementation is nearly free, the real investment is attention, and where you point that attention - which bets get funded, which get starved, which get killed - becomes the definition of strategy. And operational simplicity matters most of all, because everything that is cheap to build is expensive to operate, and the organization that cannot say no to ambition will drown in the maintenance of its own ideas.
What I’ve Learned
For decades, software organizations optimized around scarcity. Scarce engineers. Scarce production capacity. Scarce implementation bandwidth. AI is beginning to remove that scarcity. And that creates an unexpected problem: what happens when everyone can ship?
The bottleneck moves from building software to deciding what deserves to exist. When implementation friction collapses, the constraint that matters is no longer production capacity. It is judgment. The organization’s ability to decide becomes more important than its ability to build.
Abundant capacity can mean shipping too much, not too little. That is the inversion no one planned for. The failure mode shifts from “we couldn’t get it out” to “we couldn’t stop getting things out.”
Operational complexity doesn’t disappear. It moves downstream. If everyone can ship, you get more services, more features, more experiments, more dependencies, more security surface. The cost of operating, securing, and maintaining falls slower than the cost of building.
The scarce resource becomes organizational attention. Leadership used to allocate limited engineering capacity. Now it allocates attention. Product judgment, architecture judgment, customer insight, risk judgment, capital allocation, and operational simplicity become the real constraints.
The next generation of engineering leadership won’t be about controlling who can build. It will be about creating the systems that decide what should be built, what should be shipped, and what should never reach production.