The Invoice ■ Episode 06
“git commit -m ‘fix ci’”
The most honest commit message in software engineering. Not “refactor authentication module” or “improve performance of dashboard query.” Just: the pipeline broke, and I am fixing the pipeline. Again. The code was correct. The YAML was not. Or rather, the YAML was correct but the indentation was wrong, which in a whitespace-sensitive configuration language amounts to the same thing.
CI/CD (Continuous Integration, Continuous Deployment) is the industry’s answer to the question “how do we ship software reliably?” The answer, it turns out, is a forty-five-minute pipeline that runs on every pull request, consumes six developer-hours per day in waiting time, and costs $13,445 per developer per year in lost productivity. Let us examine the invoice.
The Waiting Tax
A developer opens a pull request. The pipeline begins. Forty-five minutes later, it finishes, or fails on a flaky test that passed locally, or times out on a Docker layer cache that was evicted overnight, or discovers that a transitive dependency released a patch version that breaks the build in a way nobody could have predicted because nobody reads changelogs for packages four levels deep.
While the pipeline runs, the developer context-switches. Picks up another ticket. Loses the mental model of the code they just wrote. When the pipeline finally reports back, red, naturally, the developer must reload that mental model, diagnose the failure, fix it, push again, and wait another forty-five minutes. Two cycles of this, and the morning is gone.
Six hours per day. Twenty per cent of the working week. Not writing features. Not fixing bugs. Not thinking about architecture. Waiting for a machine to tell you what you already knew: the code works. According to JetBrains’ 2026 analysis of developer experience ROI, that waiting time costs $13,445 per developer per year. For a team of twenty, that is a quarter of a million dollars annually, spent watching progress bars.
The YAML Problem
The pipeline is defined in YAML. This is the first structural error. YAML is a serialisation format that was never designed to be a programming language, yet CI/CD platforms have collectively decided it should be one. It is whitespace-sensitive, which means a single misplaced space can invalidate the entire pipeline. Silently, because YAML does not throw syntax errors so much as reinterpret your intent.
It is not locally testable. The feedback loop for pipeline configuration is: edit YAML, commit, push, wait for the runner to pick it up, wait for the execution to reach your change, discover the error, repeat. This is not development. This is debugging by deployment, which the industry spent two decades condemning before enshrining it as standard practice for infrastructure configuration.
The file grows. Conditionals appear. Matrix builds. Caching strategies. Secrets management.
Environment-specific overrides. What began as a ten-line build script is now a
three-hundred-line YAML document that nobody fully understands, nobody dares refactor,
and everyone quietly hopes will not break on the next merge to main. It is the
Makefile of the cloud generation, except that make at
least runs locally.
The Supply Chain
The pipeline does not merely run your code. It runs everyone else’s. The modern CI/CD pipeline is a composition of third-party actions, orbs, templates, and plugins: a marketplace of executable infrastructure, maintained by strangers, pinned (if you are fortunate) to a specific version, and granted access to your build environment, your secrets, and your deployment credentials.
In March 2025, this arrangement produced its inevitable consequence.
CVE-2025-30066:
tj-actions/changed-files, a widely used GitHub Action, was compromised.
The attack injected code that extracted CI/CD secrets (API keys, deployment tokens,
cloud credentials) from the runner environment and wrote them to the build log.
According to
Palo Alto’s Unit 42,
23,000 repositories were affected. Twenty-three thousand codebases, each trusting a
third-party action with their secrets, each discovering that the trust was misplaced.
The marketplace model is npm for infrastructure. The same structural defect, the same implicit trust model, the same inevitable breach. Except that npm packages merely have access to your application. CI/CD actions have access to your deployment credentials, your cloud accounts, and the keys to every environment you have ever configured.
The Lock-In
GitHub Actions is not GitLab CI. GitLab CI is not CircleCI. CircleCI is not Jenkins. Jenkins is not Buildkite. Each platform has its own configuration format, its own runner model, its own marketplace of plugins, and its own set of limitations that you discover approximately six months after committing to the platform.
The migration path between any two of these systems is a full rewrite. Not of your application (the application, mercifully, does not care) but of your entire build, test, and deployment infrastructure. Every conditional, every cache strategy, every environment variable mapping, every secret reference. The YAML is not portable. The ecosystem is not interoperable. The abstractions do not abstract.
The CI/CD market is projected to grow from $1.73 billion to $4.53 billion by 2030. That growth is not driven by new capability. It is driven by lock-in. Once your pipeline is written in a vendor’s dialect of YAML, the switching cost exceeds the pain of staying. The vendor knows this. The pricing reflects it.
The Root Cause
The CI/CD pipeline does not exist because deployment is inherently complex. It exists because the stack beneath it is fragile. A pipeline that takes forty-five minutes is not protecting you from deployment risk. It is compensating for a build system that cannot be trusted, a test suite that cannot be relied upon, and a dependency chain that nobody has audited since the project began.
The pipeline is a ventilator for a patient that poisoned itself.
Consider what the pipeline actually does: it installs dependencies (because the application cannot declare them deterministically), it compiles (because the language requires a build step), it runs linters (because the language permits ambiguity), it executes tests (because the type system does not guarantee correctness), and it deploys (because the server cannot pull code on its own). Each step compensates for a weakness elsewhere. The pipeline is not the solution. It is the symptom.
When It Is Legitimate
Fairness requires the concession. CI/CD pipelines earn their keep in specific circumstances, and pretending otherwise would be dishonest.
Regulated industries: finance, healthcare, aerospace, where an auditable, reproducible build process is not merely desirable but legally mandated. The pipeline becomes a compliance artefact, and the cost is the cost of doing regulated business. Nobody disputes this.
Large teams: fifty developers or more, where the coordination problem genuinely exceeds what human review and trust can manage. At that scale, automated gates prevent the kind of integration conflicts that would otherwise consume entire sprint cycles.
Complex monorepos: where a change in one module can break twelve others, and the dependency graph is too dense for manual reasoning. The pipeline becomes a safety net, and the net is worth its weight.
For the remaining majority, the team of eight, the service with four endpoints, the application that deploys once a day to a single server, the pipeline is overhead dressed as best practice.
The Alternative
git push. A webhook fires. The server pulls. Two shell scripts: one
to build, one to deploy. The entire process completes in seconds, not minutes. No YAML.
No marketplace. No third-party actions with access to your secrets. No forty-five-minute
wait. No $13,445 per developer per year in lost productivity.
This is not a theoretical alternative. It is how software was deployed before the industry decided that deployment required a platform, a marketplace, and a configuration language that breaks on whitespace. It is how software is still deployed by teams that value their time more than their tooling.
The pipeline stabilises a fragile stack. If the stack were not fragile, the pipeline would not be necessary. Fix the disease, and the ventilator becomes redundant.
The Verdict
CI/CD is a $1.73 billion industry projected to reach $4.53 billion by 2030. That growth is funded by developer hours: twenty per cent of the working week, across millions of engineers, spent waiting for pipelines, debugging YAML, and trusting a marketplace that has already demonstrated it cannot be trusted.
The pipeline is not the solution. It is the longest-running workaround in the industry: a forty-five-minute confession that the stack beneath it was never reliable enough to deploy with confidence.
Forty-five minutes per pipeline. Six hours per day. Twenty per cent of every working week. Twenty-three thousand repositories compromised through a single action. And underneath it all, a deployment that could have been two shell scripts and a webhook.
The invoice is on the table. The ventilator is humming. Whether anyone asks what the patient is actually ill with is, as always, another matter entirely.