For most of the history of software engineering, the primary constraint was production. Code was expensive, skilled engineers were scarce, and shipping features required concentrated human effort.

Velocity was limited by how fast people could reason, implement, test, and deploy. That constraint shaped everything from team size, architecture, release cadence, through to how we thought about technical debt.

When production is expensive, you optimise for output. You remove friction from shipping. You invest in tooling that increases developer productivity, and you accept some structural mess in exchange for forward motion.

For decades, that trade-off made sense. The dominant bottleneck was human output. But AI has materially shifted that constraint. The marginal cost of producing code is falling meaning that:

• engineers can scaffold features rapidly;
• refactors that once required hours can be attempted in minutes;
• tests can be generated;
• documentation summarised; and
• boilerplate eliminated.

The friction to produce change has been reduced. But whenever a constraint is relaxed in a system, another becomes dominant. If production is no longer the primary bottleneck, what is?

Increasingly, it is comprehension under operational stress. The constraint has moved.

Every engineering organisation operates within a Production–Comprehension Balance. It is not a metric on a dashboard. It is a structural relationship, and it describes the balance between:

• how quickly the organisation generates change; and
• how well it understands and operates that change under stress.

Production refers to the rate at which new code, features, and structural changes are introduced.

Comprehension refers to the shared mental models, observability, ownership clarity, documentation, and operational readiness that allow teams to reason about system behaviour; especially when it fails.

As long as production and comprehension scale together, the system feels resilient:

• you can increase deployment frequency if recovery remains fast;
• you can expand surface area if ownership and observability keep pace; and
• you can accelerate delivery if shared understanding evolves alongside complexity.

The problem therefore isn’t velocity; it’s imbalance.

When production accelerates faster than comprehension, fragility begins to accumulate. That shift is rarely dramatic at first; it’s gradual.

Imbalance does not typically appear in the roadmap. Velocity may remain high. Features continue to ship, and output is visible and celebrated.

The cost appears elsewhere:

• code reviews start to slow because intent is unclear;
• engineers hesitate around certain services;
• onboarding takes longer; and
• incident retros contain phrases like, “We didn’t realise it worked that way.”

The system still functions. Until it doesn’t.

During an outage, degraded comprehension reveals itself quickly:

• time-to-detect increases because signals are harder to interpret;
• time-to-resolve increases because hypotheses are weaker;
• escalations multiply because ownership boundaries are blurred; and
• postmortems uncover interaction effects that few anticipated.

Let’s consider a common pattern.

A team accelerates delivery using AI-assisted development. Deployment frequency increases significantly. New services are introduced quickly, and interfaces evolve rapidly.

Months later, an incident occurs involving an unexpected interaction between two services modified weeks apart by different teams.

The code in isolation is sound. Failure emerges from interaction:

• the logs are dense;
• the metrics are noisy; and
• ownership is unclear.

Resolution takes hours; not because the fix is complex, but because reconstructing system behaviour under stress requires rebuilding shared context.

Nothing “went wrong” in the traditional sense, but production had outpaced comprehension.

Modern SRE practice already provides language for managing trade-offs.

• deployment frequency;
• change failure rate;
• Mean-time-to-recovery (MTTR); and
• error budgets.

These are not just operational metrics. They are economic signals. They describe how efficiently an organisation converts change into value without incurring unacceptable risk.

When AI increases deployment velocity, several second-order effects follow; for example:

• more changes increase potential interaction effects;
• observability must interpret a denser stream of signals; and
• recovery processes must handle higher concurrency of failure modes.

If MTTR remains stable while deployment frequency rises, production and comprehension are scaling together.

If MTTR drifts upward while change volume increases, imbalance is emerging.

If change failure rate rises as output accelerates, the marginal cost of change has not disappeared – it has shifted into recovery.

The Production–Comprehension Balance is visible in these signals, and it is measurable.

Whilst AI lowers the friction to produce code, it does not eliminate coordination cost. Parallel change increases:

• context switching;
• review complexity;
• cross-team dependencies; and
• implicit coupling.

In distributed systems, interaction effects multiply quickly. The difficulty is rarely in writing the code, but rather it is in reasoning about its interactions.

And whilst AI can suggest improvements to a function, it can’t resolve organisational misalignment. It can’t automatically update the unwritten assumptions that exist between services.

Coordination therefore remains a human constraint.

As production accelerates, coordination load increases unless architecture, communication, and observability evolve in tandem.

Monitoring provides the feedback loop required to manage the Production–Comprehension Balance. It answers these critical questions:

• Is recovery capability keeping pace with deployment velocity?
• Are incidents becoming harder to diagnose?
• Are alerts becoming noisier or less actionable?
• Are certain services becoming operationally fragile?

Without instrumentation, imbalance is felt subjectively. With instrumentation, it becomes visible.

So whilst monitoring does not eliminate cognitive debt, it does reveal when production is outpacing comprehension. It transforms fragility from a surprise into a signal. In this sense, monitoring isn’t just operational tooling, It’s the nervous system of a high-velocity organisation.

Let’s be clear, acceleration is rational. Competitive environments reward speed, and customers expect rapid iteration. Internal ambition drives improvement.

As such when the cost of production falls, organisations will produce more. That higher rate of velocity is visible and rewarded. But the comprehension degradation is subtle.

The responsibility of engineering leadership is not to resist acceleration. It is to preserve balance. That may require:

• investing in observability before expanding surface area;
• treating MTTR as a first-class metric;
• protecting error budgets;
• reinforcing service ownership clarity; or
• time-boxing complexity growth.

AI changes the slope of production, but it does not (and should not) remove the need for discipline.

Whilst AI has lowered the cost of producing software, it hasn’t lowered the cost of misunderstanding software.

Incidents still require coordinated reasoning. Recovery still depends on shared mental models, and reliability still rests on clarity and observability.

As production accelerates, comprehension becomes the scarce resource.

As such, the primary constraint has shifted. Recognising and managing the Production–Comprehension Balance may be one of the defining engineering leadership challenges of this era.