Book Review — Re-Reading 'Continuous Delivery': From 'What Abstract Nonsense' to a Pitfall Avoidance Guide in the AI Era

I just finished re-reading the Chinese edition of Continuous Delivery.

In software engineering, this book has long been revered by many seniors as a bible. How important its theories and concepts are needs no extra elaboration from me.

This was actually my second time reading this book.

First Reading: What Abstract Nonsense Is This?¶

When I first read this book, I had just transitioned into software engineering. Honestly, reading it back then was extremely painful. My genuine thought was: "What abstract nonsense is this? Why make things so complicated?"

Back then, my eyes only saw syntax, APIs, and how to render UI elements. I couldn't comprehend why so many processes, rules, and seemingly tedious tests were necessary.

Second Reading: So This Is the Pitfall Avoidance Guide from Seniors¶

Three or four years later, after accumulating real project experience and falling into countless production incident pits, re-opening this book felt completely different.

I realized this book isn't floating abstract theory at all; it's a "pitfall avoidance guide" written for future generations by seniors who stepped in every trap before us.

Precisely because people pointed out the importance of these matters back then, the entire software ecosystem underwent massive evolution in recent years. Although some early tools mentioned in the book (like early build tools or version control systems) are rarely used today, modern tools born from those pain points — Git/GitHub, TDD, cloud services, CI/CD automated deployment, smoke testing, GitOps — have blossomed and become standard.

This made me realize something fundamental:

Software vendors and tools will replace one another over time, but the core problem-solving concepts behind them never move; they only get continuously optimized.

This perfectly mirrors the essence of the Three Ways in The Phoenix Project: first make the path work, then make the path smooth, and finally continuously optimize.

Fast Forward to 2026: CI/CD Thinking in the AI Era¶

Fast forward to today, and we are clearly sitting in an "extremely optimized" AI era.

With AI today, setting up automated pipelines or training AI to follow specific SOPs has become exceptionally easy. Just enter a prompt, and AI can output an automation script or set up a CI/CD pipeline in seconds.

Yet in this era where AI dramatically lowers execution barriers, we as engineers need our brains to maintain even higher awareness of the pitfalls seniors stepped in.

Many assume that with larger context windows and smarter AI, they can hand everything to AI. But in reality, when handling long workflows, AI is prone to "memory dilution" or forgetting basic pipeline steps. To write code quickly for you, it might silently omit smoke tests or skip basic defensive design.

My Current Engineering Paradigm: Strategy by Me, Details to AI¶

After reading Continuous Delivery, I transformed its principles into workflow guardrails for AI collaboration:

1. Discuss Concept & Conceptual Alignment: Define strategic direction and boundaries.
2. Enforce TDD: Have AI write test cases first to lock down edge conditions.
3. Write Code & Validate: Let AI execute inside the protective net.
4. Automated Deployment & Acceptance: Conduct final checks myself on whether architecture principles were violated.

My role shifted from "manual road paver" to "supervisor setting strategic direction and accepting results."

As tools evolve and AI grows stronger, foundational concepts become even more critical. People who don't understand CD and architecture are more likely to let AI generate mountains of unmaintainable code; while those who understand underlying mechanics enable AI to become a high-output, disciplined top-tier assistant.

If you read Continuous Delivery long ago and found it abstract, re-read it with a few years of development experience — you'll find it remains one of the most timeless classics in software engineering.