The Jenkins job I inherited in 2019 had forty-seven stages. Forty-seven discrete boxes in the pipeline visualization, each one a Groovy script somebody had copy-pasted from Stack Overflow and then wrapped in enough conditional logic to make it survive three different Kubernetes cluster migrations. Stage twenty-three was labeled build-maybe-docker and nobody—not the principal engineer, not the architect who'd left two quarters prior—could explain what the "maybe" meant or under what conditions it triggered. We shipped code through this thing twice a week. Sometimes it worked. build-maybe-docker That pipeline is what people mean when they say CI/CD is dying, though "dying" undersells the active hemorrhaging happening in organizations that tried to scale traditional approaches past their tensile limits. The model we built in the 2010s—linear directed acyclic graphs of bash scripts and YAML incantations, stitched together with plugin ecosystems that update on their own schedules and break in creative ways—can't withstand the pressure modern product velocity exerts. Not at scale. Not when your microservices architecture fragments into seventy-three repositories and twelve different runtime environments, each with its own peculiar notion of what "deployment-ready" means. The Accretion Problem Here's what actually happens when you run traditional CI/CD at a company growing past fifty engineers: tool sprawl turns metastatic. Developers report juggling fourteen distinct systems on average—not because they're inefficient, but because each tool solves one narrow problem exceptionally well and integrates poorly with everything else. You get Jira for tickets, GitHub for code, Jenkins for builds, ArgoCD for deployments, Datadog for observability, PagerDuty for incidents, Vault for secrets, Snyk for security scanning, SonarQube for code quality, Terraform for infrastructure, Helm for packaging, Artifactory for artifacts, Slack for coordination, and Confluence for documentation that goes stale within a week of writing it. Each integration point is a fracture zone. Data doesn't flow; it gets manually shepherded across boundaries by engineers who've memorized which webhook payload formats are actually stable versus which ones silently change fields between minor versions. I once spent four hours debugging why our dependency-scanning results stopped appearing in pull requests, only to discover that Dependabot had switched from security_advisory events to repository_vulnerability_alert events and our webhook router was still listening for the old schema. The code being scanned was fine. The seventeen-line bash script that formatted scan results into GitHub comment markdown had failed silently for three weeks. security_advisory repository_vulnerability_alert Complexity accumulates faster than you can pay it down. Research confirms the intuitive reality: once teams integrate four or five separate CI/CD tools into their workflow, half experience lead times exceeding a month. A month between code-complete and production. This isn't because engineers are slow—it's because the coordination tax overwhelms the marginal productivity gains each tool promised in isolation. You add a security scanner to shift left on vulnerabilities, which adds twelve minutes to every PR pipeline, which makes developers batch commits to avoid waiting, which makes code reviews larger and more error-prone, which creates more rollbacks, which demands more sophisticated rollback automation, which requires another tool. month The bitter truth practitioners learn after enough post-mortems: adding toolchains past a certain threshold doesn't accelerate delivery. It decelerates it. The system becomes a bureaucracy of automated gatekeepers, each one technically correct in its domain, collectively producing gridlock. decelerates What Traditional Pipelines Can't Express Static pipelines encode decisions that were reasonable when you wrote them and increasingly incorrect as the system evolves. Your test suite passes, but the integration tests don't exercise the new authentication flow because nobody updated the fixture data generator. Your deployment succeeds, but customer-facing latency spikes because the autoscaler configuration assumes last quarter's traffic patterns. Your security scan finds zero CVEs, but you just shipped a credentials-logging bug because the scan checks dependencies, not runtime behavior. The problem is ontological. YAML—and I say this as someone who has written tens of thousands of lines of the stuff—is a configuration language pretending to be a programming language. It can't introspect. It can't adapt. It executes the steps you specified in the order you specified them, and if the world has changed since you specified those steps, too bad. You wanted conditional logic? Here's a when clause that evaluates string equality. You wanted error recovery? Here's a retry block that runs the same failing command three times. when retry I've seen teams try to work around these limitations by layering scripting languages on top—Python wrappers around Bash wrappers around kubectl commands, all orchestrated by a Jenkins shared library that imports Groovy files from a separate repository. This works until the person who understands the cross-repository dependency graph leaves, at which point you're maintaining a distributed system written in four languages, none of which have proper testing infrastructure, all of which fail in ways that look like success until you check production manually. kubectl The cognitive overhead is real and measurable. Engineers context-switch constantly—between the code they're writing, the pipeline that builds it, the infrastructure it runs on, the monitoring that observes it, the tickets that track it. Every context switch burns twenty-three minutes of focus time on average, which means a developer interrupted five times a day loses nearly two hours to cognitive reload penalties. Not to email. Not to meetings. To the mental cost of remembering which of fourteen tools holds the information they need right now. Agentic DevOps: The Uncomfortable Pitch So here comes the industry pitch: replace your static pipelines with AI agents that can reason about your codebase, adapt to changing conditions, and autonomously handle the repetitive work that's currently crushing your senior engineers under operational toil. I'm skeptical by training. I've watched too many technology waves crest with maximum hype and minimum substance—blockchain for supply chains, microservices for every workload, Kubernetes for teams of five. But the agentic DevOps proposition differs from typical vendor vaporware in ways worth examining carefully. GitLab's framing is representative: AI transforms CI/CD by analyzing code changes in context, running appropriate tests, and deploying updates with minimal human oversight while continuously tuning for performance. That sounds like marketing copy until you realize what "analyzing code changes in context" actually means at the implementation level. The agent isn't just parsing diffs. It's reading the surrounding codebase, understanding architectural patterns, checking test coverage heatmaps, correlating with production error rates, and making deployment decisions based on multidimensional risk assessment that would take a human engineer forty-five minutes of investigation. GitHub and Microsoft are shipping concrete implementations now, not prototypes. The Copilot Coding Agent accepts task-level instructions—"refactor this authentication module to use our new RBAC system"—and produces pull requests. Not code snippets. Pull requests with tests, documentation updates, and dependency changes. The SRE Agent monitors Azure workloads, detects anomalies, and executes mitigation procedures autonomously. When a memory leak starts degrading response times at 3 AM, it doesn't page a human. It captures heap dumps, analyzes allocation patterns, identifies the leaking component, and either restarts the affected pods or scales horizontally while filing an incident ticket with its diagnostic findings attached. These aren't autocomplete features. They're systems that operate semi-independently within bounded domains of responsibility. What Actually Changes (and What Doesn't) The practical transformation looks less revolutionary and more like competent automation finally reaching areas we couldn't automate before. Dependency upgrades, for instance. Every Java shop knows the pain: a new Spring Boot release drops, you need to upgrade across twenty-seven microservices, each upgrade requires test execution and compatibility verification, the whole migration takes a quarter. An agentic system handles this differently. It clones the repository, updates the dependency declaration, runs the test suite, analyzes failures, attempts fixes based on common migration patterns, reruns tests, and submits a pull request. If tests pass, it can merge and deploy to staging. If they fail, it documents the specific breakage and hands off to a human with context already assembled. Microsoft's internal data suggests what used to consume months of .NET or Java upgrade cycles now completes in hours when agents handle the mechanical work. The "months" weren't developer time—they were calendar time lost to queueing, context switches, and the coordination overhead of scheduling upgrade work across teams. The agent doesn't eliminate the complexity; it serializes the work and executes it without forgetting context between steps. Security patching follows similar patterns. A CVE announcement triggers agent evaluation: which repositories use the affected dependency? What's the blast radius? Are there vendor patches or do we need to pin versions and add WAF rules? For each affected service, the agent can test the upgrade path, verify that security scanners confirm remediation, and either auto-deploy to production or flag for human review based on risk scoring. What previously required coordinating across six teams and three approval chains now happens in the background while engineers work on features. The continuous technical debt paydown model is where this gets interesting from a system design perspective. Traditional approaches batch debt work into quarterly sprints because context-switching cost makes it inefficient to tackle incrementally. You need dedicated time to understand a neglected subsystem, refactor it properly, and verify improvements. Agents invert this. They can spend unused CI/CD capacity—those hours between 2 AM and 6 AM when your runners sit idle—incrementally improving code quality. Pulling up test coverage in low-coverage modules. Refactoring methods that exceed complexity thresholds. Updating documentation that's drifted from implementation. The work happens continuously in tiny increments, rather than in disruptive sprints that block feature development. AJ Bajada's formulation captures the value proposition cleanly: AI removes toil, repetitive work, and cognitive overhead. Engineers get time back for architecture and innovation. But let's be specific about what "toil" means here, because not all toil is equivalent. Debugging a gnarly concurrency bug? That's skilled work, not toil. Updating forty-seven Terraform modules to use the new AWS provider syntax? That's toil. Writing a complex data migration? Skilled work. Clicking through twelve UI screens to manually promote a build artifact through environments? Toil. Agentic systems excel at eliminating the second category while leaving the first to humans who actually enjoy that kind of problem-solving. The Fracture Zones Nobody in vendor marketing talks about where this breaks, so let me: trust boundaries, observability gaps, and the attribution problem. Trust boundaries first. When a human writes code, reviews it, and deploys it, the accountability chain is clear. When an agent generates a change, who's responsible if it introduces a regression? The agent's operator—the engineer who invoked it—or the agent's creator—the company that trained the model? This matters immensely for regulated industries. Financial services and healthcare organizations already struggle with audit trails for infrastructure-as-code changes made by humans. Now imagine explaining to a compliance auditor that an AI agent modified your PCI DSS-scoped payment processing code autonomously at 4 AM on a Sunday based on heuristics learned from public GitHub repositories. The technical mitigation is enforcing review gates where agents propose changes but humans approve them. That works until it doesn't—until approvals become rubber-stamps because the agent's batting average is so good that humans stop reading its diffs carefully. We've seen this pattern with code review tools that automatically approve "safe" changes. Engineers trust the automation until the day it misclassifies a breaking change as safe and the production incident traces back to an auto-approved commit nobody actually read. Observability gaps are subtler. Traditional CI/CD pipelines are terrible at observability—half the time you can't even get decent logs out of a failed Jenkins stage—but they're at least deterministic. The same input produces the same output. Agentic systems introduce non-determinism. The same pull request analyzed at two different times might yield different deployment decisions if the agent's learned behavior has shifted or if it's incorporating different context from production metrics. How do you debug that? Your monitoring system can show that a deployment happened and what changed, but it can't necessarily explain why the agent decided to deploy now versus waiting, or why it chose deployment strategy A over strategy B. why The agent itself needs to be an observable system, not a black box. You need logs of its reasoning process, confidence scores for decisions, and the ability to replay scenarios deterministically. Some platforms are building this. Many aren't. The attribution problem compounds over time. Codebases become collaborative works between humans and agents, and after six months of continuous agent contributions, you can't cleanly separate human-written code from agent-generated code. This creates intellectual property questions—can you copyright code you didn't write?—and practical maintenance problems. When you're debugging a subtle bug, knowing whether a human or an agent wrote the problematic code changes how you approach the investigation. Human code likely has unstated assumptions and contextual knowledge. Agent code might have patterns that seem reasonable locally but violate system-wide invariants the agent doesn't know about. What You'd Change Monday Morning If I were advising an engineering organization right now—say, a mid-stage startup with thirty to eighty engineers, experiencing pipeline pain but not yet drowning in it—here's the migration path that minimizes regret: Start with read-only agents. Deploy AI copilots that analyze your pipelines and suggest optimizations without executing changes. Let engineers build familiarity with how these systems reason before giving them write access to production infrastructure. You'll discover quickly whether the agent's suggestions are insightful or garbage, and you'll learn what kinds of context it needs to make good decisions. Identify toil candidates with clear success metrics. Dependency updates are ideal because success is unambiguous: tests pass or they don't, security scanners report vulnerabilities or they don't. Let an agent handle npm audit fix and Dependabot merges for low-risk libraries. Measure time savings. Measure error rates. Prove value on low-stakes work before graduating to higher-risk automation. npm audit fix Instrument everything twice. Once for the application, once for the agent. You need separate telemetry streams tracking agent decisions, confidence levels, and outcomes. When an agent-initiated deployment causes a regression, you need to trace backward through its decision graph to understand what information it weighted and why. Build this observability infrastructure before agents touch production, not after the first incident. before Establish approval tiers with different automation thresholds. Low-risk changes—documentation updates, test additions, linting fixes—can auto-merge after basic validation. Medium-risk changes—dependency updates, refactors with good test coverage—require human approval but the agent does the legwork. High-risk changes—schema migrations, API contract changes, infrastructure modifications—always require human design and review, though agents can assist with implementation. Critically: maintain human-written reference implementations for core workflows. Don't let agents become the sole source of knowledge about how deployments work or how rollbacks execute. When—not if—the agentic system fails or produces nonsensical output, you need engineers who can still deploy manually and understand the underlying mechanics. The goal is augmentation, not dependency. The Honest Trade-Off Agentic DevOps offers a genuine value proposition: it trades increased system complexity for decreased operational toil. That's not a free lunch. You're replacing a system you understand poorly (traditional CI/CD pipelines full of accumulated cruft) with a system you understand differently (AI agents making probabilistic decisions based on learned patterns). Whether that trade makes sense depends entirely on what's currently killing your team. If your bottleneck is coordination overhead—too many tools, too much context switching, too many manual handoffs—agents help. They excel at orchestration tasks that require integrating information from multiple sources and executing multi-step workflows consistently. If your bottleneck is architectural complexity—poor service boundaries, tight coupling, inadequate testing—agents can't help. They'll automate your mess faster, but it remains a mess. The organizations that will win with this technology are the ones that combine agentic automation with disciplined engineering practices. You still need good test coverage. You still need clear ownership models. You still need incident response runbooks and disaster recovery procedures. The agents don't replace those fundamentals; they amplify them. What dies here isn't DevOps as a discipline—it's DevOps as manual orchestration of static scripts. The future looks like pipelines that adapt to what they're building, agents that learn from production outcomes, and engineers who spend more time designing systems and less time babysitting deployments. Whether your organization makes that transition in the next twelve months or gets disrupted by competitors who do is the only question with money attached. The technology works. The vendor platforms exist. The migration path is navigable. The static pipeline you're running today? It doesn't know it's obsolete yet. But somewhere in your engineering organization, someone just spent four hours debugging a Groovy script in Jenkins, and they're wondering if there's a better way. There is. It's just not the way we built things last decade.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

CI/CD Is Dead. Agentic DevOps is Taking Over

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AI in DevOps: Rise to Agents and Why You Need Agentic Workflows in 2026

A Guide to Building an AWS Serverless API and CICD Pipeline

AIOps: The Secret Weapon for CI/CD Security

Automation and the CI/CD Pipeline

Best Practices for Implementing Test Data into Your CI/CD Pipeline

Bon Appétit: An Introduction to CI/CD and DevSecOps With a Delicious Bakery Story

AI in DevOps: Rise to Agents and Why You Need Agentic Workflows in 2026

A Guide to Building an AWS Serverless API and CICD Pipeline

AIOps: The Secret Weapon for CI/CD Security

Automation and the CI/CD Pipeline

Best Practices for Implementing Test Data into Your CI/CD Pipeline

Bon Appétit: An Introduction to CI/CD and DevSecOps With a Delicious Bakery Story

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps