“The presence of those seeking the truth is infinitely to be preferred to the presence of those who think they’ve found it.”
— Terry Pratchett, Monstrous Regiment
At some point, CI/CD pipelines became the thing you’re supposed to have. Not because you’ve identified a specific problem they solve — just because they’re right. Professional. Proper. The kind of thing serious developers do.
I’ve spent years building them. I know how to make them elegant: staged deployments, approval gates, environment promotion workflows, automated rollbacks triggered by failed health checks. There’s genuine craft in a well-designed pipeline.
So when I started spinning up side projects with Claude Code, my first instinct was to set up a proper pipeline. Then I noticed I was spending more time waiting for pipeline cycles than I was writing code. And I started asking an uncomfortable question: what problem is this pipeline actually solving for me?
What Pipelines Are Actually For
CI/CD pipelines are genuinely excellent at a specific set of problems. Just not the ones most people assume.
They’re designed for coordination: making sure the right people can deploy, that the wrong people can’t, that production changes are visible and accountable, that approvals are documented and auditable. They solve the problem of multiple developers touching the same system, of regulated industries that need immutable deployment records, of teams that include people who shouldn’t have direct production access.
These are real problems. They matter enormously in the right context. SOC 2 compliance, PCI DSS requirements, team coordination across time zones — if any of that describes your situation, pipelines earn their keep.
But coordination and governance aren’t the same as speed. In fact, they’re often in direct tension with it.
The Hidden Tax of Remote Execution
A well-optimised CI/CD pipeline for a mature project has real costs that compound quickly. Typical GitHub Actions PR pipelines average 18–22 minutes per run. GitLab CI frequently runs past 25 minutes for backend-heavy changes. During peak hours, you can add another 5–10 minutes of queue wait before a single step runs.
Even if you strip everything back to a minimal deploy-only pipeline, you’re still paying for repository cloning, package installation from scratch, runner spin-up, and asset packaging. All of it remote. All of it sequential. None of it benefiting from the local cache that’s already warm on your machine.
For an enterprise team running one or two production deploys a week, that overhead is invisible. For a solo developer deploying multiple times a day, it’s a substantial chunk of your working time spent watching a status spinner.
The maths aren’t complicated. Twenty minutes per cycle, fifteen cycles per day: five hours waiting for pipelines. Even if the real number is half that, it’s significant.
Agentic Development Makes This Worse
Here’s where things get interesting — and why I think this conversation matters more now than it did a few years ago.
When you’re working with an AI coding agent like Claude Code, context and momentum matter in a way they didn’t with traditional development workflows. The agent is holding a model of your codebase, your recent changes, the problem you’re solving, and the failures you’ve hit. That context degrades when you break the loop.
With local deployment tooling, the loop stays intact:
- The agent runs the deploy script directly
- Captures the output in real-time
- Diagnoses failures immediately
- Iterates on fixes without leaving the session
With a CI/CD pipeline, you break the loop at every step:
- Copy pipeline output
- Paste into the agent prompt
- Wait for a fix suggestion
- Commit, push, wait 20 minutes
- Check if it worked
- Repeat
Context switching is one of the best-documented drains on developer productivity — and this is context switching with an AI collaborator, not just your own mental state. The agent loses the thread. You lose the thread. What should be a rapid iteration cycle becomes a series of disjointed 20-minute-wait experiments.
What Local Tooling Actually Looks Like
This isn’t a new idea. Cloudflare has had Wrangler for years. Vercel has vercel deploy. Heroku has its CLI. Ansible, Make, Justfile — local orchestration tooling has existed through the entire CI/CD era. The difference now is that AI can help you build and maintain this tooling rapidly, iteratively, and without needing to be an infrastructure specialist.
My current setup for side projects uses Ansible playbooks for Django sites running on Linode (now Akamai Cloud) and Wrangler for anything on Cloudflare Pages — including this blog. The Ansible playbooks were built through Claude Code with my direction and implement what you’d expect from a “proper” deployment: blue-green switching, health checks, automatic rollback on failure.
When something breaks, I can attempt multiple fixes in the time it would take a single pipeline cycle to complete. The agent sees the entire process — the playbook, the error output, the host state — and can reason about it in real-time. That feedback loop is worth a lot.
Know When the Pipeline Is the Right Answer
I want to be direct about where this advice stops applying, because the boundary matters.
Use local deployment tooling when:
- You’re working solo or in a very small team where everyone has ops context
- You value iteration speed over process enforcement
- You’re using AI agents extensively and want to keep them in the deployment loop
- You have enough infrastructure knowledge to build robust deployment scripts
Use pipelines when:
- Multiple people need to deploy, with different permission levels
- You need a compliance audit trail (SOC 2, PCI DSS, HIPAA)
- Your team includes people who shouldn’t have direct production access
- Approval workflows are genuinely required, not just nice-to-have
- You’re in a regulated industry where deployment records must be immutable
The pattern I see at my day job is the inverse of the problem I’m describing here: teams pile responsibilities onto pipelines, pipelines slow down, developers complain about the pipelines, then someone “optimises” the pipeline while keeping all the same governance requirements. The pipeline gets faster but the underlying frustration doesn’t resolve, because the frustration was never really about the pipeline itself — it was about using a coordination tool in a context where coordination isn’t the bottleneck.
The Trade-offs, Honestly
I’m not describing a free upgrade. Local-first deployment has genuine costs.
You lose the GitOps audit trail — commits and deployments are decoupled, so you can’t necessarily reconstruct who deployed what and when from git history alone. You lose process enforcement — nothing stops you from deploying broken code to production. You lose the protection that a pipeline provides from your own worst instincts at 11pm.
Bad local deploys can cause outages. I’ve had them. The difference, in my experience, is that the resolution loop is dramatically shorter. When a pipeline deploy breaks production, the recovery path is: troubleshoot → fix → commit → push → wait 20 minutes → verify. When a local deploy breaks production, you can be running a remediation attempt before a pipeline cycle would have even started.
There’s also a floor on who this approach works for. If you don’t understand your deployment stack deeply, local tooling might give you enough rope to do real damage. Platform CLIs like Wrangler or vercel deploy mitigate this significantly — they abstract the dangerous parts. Custom Ansible playbooks do not. If you’re not comfortable owning what happens if the playbook fails halfway through a deployment, build the pipeline instead.
An Unexpected Benefit
Here’s something I didn’t anticipate: going through the exercise of building local deployment tooling has made me better at pipelines, not worse.
When you’ve had to write an Ansible playbook that handles every failure mode, you understand exactly what a pipeline stage needs to do. When you know what wrangler pages deploy actually calls under the hood, you know what your CI/CD job should replicate. If I need to hand a project to a team or add pipeline-based governance later, I’ve already solved the hard part — I know what the deployment process is. I’m just deciding where to run it.
Local tooling and pipeline tooling aren’t philosophically opposed. They’re the same problem at different execution layers. Starting local often means you understand the problem better when you eventually need the pipeline.
A Question Worth Asking
I built pipelines because I thought they were part of doing it properly. It took working on side projects with real deployment frequency to realise I’d been confusing “the right tool” with “the tool serious people use.”
If you’re a solo developer, a small team with ops expertise, or someone who’s found themselves spending significant time waiting for CI/CD cycles while working with AI agents — it might be worth asking what specific problem your pipeline is solving. Not what pipelines are good for in general. What problem yours is solving for you, in your current context.
The answer might still be “the pipeline is right for this.” That’s a legitimate conclusion, and I’m not arguing against it. But if the honest answer is “I set it up because that’s what you’re supposed to do,” there might be a faster way to work.
This is one approach, tested in one person’s context, with one set of trade-offs. Your deployment frequency, team size, compliance requirements, and risk tolerance will all push the answer somewhere different than mine landed.
The best deployment workflow is the one that gets out of the way and lets you ship. Where that runs is a secondary question.