Generated by Codex with GPT-5

The Pragmatic Engineer surfaced this piece in its June 17 episode, CI/CD with Robert Erez, a conversation between Gergely Orosz and Octopus Deploy principal engineer Robert Erez about how modern teams ship software safely.

The episode’s central argument is that deployment practice should optimize for recoverability and control, not for maximal automation. Continuous deployment—sending every successful change directly to production—is useful in some environments, but continuous delivery is often the more practical goal. A team can keep every change tested and ready to release while retaining a deliberate production gate when its risk profile demands one.

Design for the next version

Erez prefers rolling forward over rolling back when a system carries state. Reverting application code does not necessarily revert a database schema, queued message, or external side effect, so returning from version two to version one can create a combination that never existed safely. The better operational posture is to make the path to version three fast and routine.

Feature flags support that model. A team can disable a faulty behavior immediately, limit exposure while investigating, and then ship a corrected implementation without treating deployment itself as the emergency brake. The tradeoff is accumulated complexity: every flag creates another possible system state. Flags need owners, removal dates, and regular cleanup or they become permanent branches hidden inside production.

Progressive delivery extends the same principle. Instead of asking whether a release is globally safe, teams expose it to a small cohort, observe real behavior, and expand only when the evidence is good. Canary releases, staged rollouts, and flags turn a launch from a single irreversible event into a controlled sequence of decisions.

GitOps is a control loop, not a brand name

The conversation also strips GitOps back to its underlying mechanics: desired state should be declarative, versioned and immutable; agents should pull that state; and the running system should be continuously reconciled toward it. Git is a common implementation, not the definition.

That distinction matters at scale. Thousands of clusters repeatedly polling one repository can make the repository itself a bottleneck. Teams also create security problems when they force secrets or other unsuitable state into Git merely to satisfy a literal reading of the label. The architecture should preserve auditability and reconciliation without pretending one storage mechanism fits every kind of configuration.

This is also why platform teams become more valuable as organizations grow. They can provide paved deployment paths, ephemeral per-branch environments, policy enforcement, and shared observability while product teams retain control of their services. The platform earns its keep by removing repeated operational work, not by becoming a central ticket queue.

AI makes safety cheaper than waiting

The most forward-looking point is that coding agents change the economics of CI/CD. Human developers feel every minute spent waiting for a build and may shorten test suites to preserve attention and flow. An agent can wait through slower, broader validation without losing context or becoming frustrated.

As agents produce more changes, the scarce resource shifts from code-writing time to confidence. It can become rational to run more exhaustive tests, simulations, security checks, and staged rollouts—even if the pipeline takes longer—because the automation absorbs the latency while the organization avoids multiplying deployment risk.

The practical takeaway is not to chase a fashionable deployment stack. Build a delivery system that makes small changes routine, failure containable, and recovery boring. AI increases the amount of code a team can attempt to ship; disciplined CI/CD determines whether that extra output becomes useful software or faster-moving instability.