CI/CD & Infrastructure Complexity

Most organisations inherit their delivery setup rather than design it. The result is a pipeline shaped by the problems of the past, not the demands of the present.

The problem looks different depending on where you are:

• No pipeline — deployments are manual, scripts live on someone's laptop, production access is shared. The cost is unpredictability and people dependency.
• Brittle pipeline — CI/CD exists but breaks under change. Knowledge is concentrated in whoever built it. Every modification introduces risk.
• Pipeline that doesn't scale — stable for human-rate work, but never designed for the rate of change AI introduces. Parallel commits, continuous deployment pressure, and agent-generated changes expose the ceiling.

Across these situations, the pattern is consistent: what looks like a tooling problem is usually a structural one.

• Slower release cycles
• Increasing maintenance effort
• Hidden dependencies and failure modes
• Knowledge concentrated in individual engineers
• Deployments that depend on specific people being available
• A ceiling on how fast the team can actually ship

• Adding scripts, steps, and pipeline stages
• Introducing new tooling without architectural change
• Patching failures as they appear
• Increasing manual approvals and controls

Improves stability temporarily, but increases long-term complexity.

The pattern is consistent across maturity levels: the response to pipeline problems is almost always additive. More tools, more steps, more approvals. The structure underneath stays the same.

AI accelerates code generation and the rate of system change. The consequence depends on where the organisation is:

• No pipeline — agents generate and change code with no controlled path to production. The gap between generation and deployment becomes dangerous.
• Brittle pipeline — higher commit frequency breaks what was already fragile. Failures increase faster than the team can respond.
• Pipeline that doesn't scale — agents open merge requests in parallel, trigger pipelines around the clock, and push changes at a rate no human team ever did. The pipeline becomes the ceiling on everything.

In each case, the delivery foundation determines how much of the AI investment actually reaches production.

Velocity increases, but without structural readiness, reliability decreases.

The goal is not the same for every organisation. The right next step depends on where the constraint actually is:

• A team with no pipeline needs a controlled, repeatable path to production first.
• A team with a brittle pipeline needs structure that holds under change.
• A team with a stable pipeline needs to assess whether it was designed for machine-rate work — or only for human-rate work.

In all cases, the outcome is the same in principle:

• Delivery systems that are predictable under the rate of change the organisation is actually operating at
• Reduced dependency on specific people or tribal knowledge
• A foundation that doesn't become the bottleneck when AI increases the pace