Why DevSecOps Becomes the New Bottleneck in the AI Coding Era
Explains how AI-generated code shifts software engineering's bottleneck from writing code to verifying it, making automated DevSecOps the critical layer of trust.
This article is published in English.
Sources: As AI Is Making Code Cheap. DevSecOps Is About to Become Much More Valuable
In brief: For decades, one of the costliest parts of building software was the act of writing it. Engineers had to turn requirements into architecture, produce thousands of lines of code, chase down bugs, write tests, wire systems together, and finally push everything live. Generative AI is upending that math. Today a developer can simply describe what they need in plain language, and an AI coding agent will produce a striking share of the actual implementation — APIs, SQL queries, test suites, infrastructure-as-code, documentation, migration scripts, sometimes entire applications. This is no longer a fringe experiment. Google's 2025 DORA research reported that 90% of surveyed technology professionals were already using AI in their daily work, and more than 80% said it made them more productive. But there's a catch worth sitting with: once building software gets dramatically cheaper, checking that software becomes dramatically more important. More code produced means more surface area to test. More dependencies pulled in means more exposure through the supply chain. More applications shipped means more infrastructure to manage. More releases means more changes hitting production. And more AI-authored code means more open questions about where it came from, whether it's secure, whether it's compliant, and who's accountable for it. So the next real inflection point in software engineering might not be AI-assisted coding at all — it might be AI-driven DevSecOps: the automated layer of trust standing between AI-generated code and the systems running in production.
The Current Dynamic: AI Is Attacking the Coding Bottleneck
The classic software engineering flow has generally looked like this:
Requirement → Design → Code → Test → Secure → Deploy → Operate
For most of that history, writing the code itself ate up the bulk of the effort.
Building a new API by hand could easily take a developer several days.
Now, a developer can instead instruct an AI agent along these lines:
"Build a REST API for onboarding new customers in Python. Include input validation, a persistence layer, authentication, unit tests, a Dockerfile, and deployment manifests."
The agent can turn around a large chunk of that work in a matter of minutes.
That's a fundamental shift in the economics of building software.
The cost of producing one more feature, one more service, one more app keeps dropping.
And AI's reach isn't limited to autocompleting code anymore — it's extending into agentic behavior: parsing entire repositories, editing across multiple files, executing test suites, fixing what breaks, and opening pull requests on its own.
Gartner frames this trend as AI-native software engineering — a model where AI is woven throughout the development lifecycle instead of just assisting with code snippets. The firm projects that by 2028, 90% of enterprise engineers will rely on AI code assistants.
Yet writing code faster doesn't automatically translate into shipping software faster.
That gap is the important part.
We Are Moving the Bottleneck
Picture an engineering organization that used to ship:
100 software changes every week.
Its testing pipelines, security checks, and deployment infrastructure were all built around handling roughly that load.
Now bring AI agents into the picture.
Developers suddenly move much faster, and weekly output climbs to:
300 software changes.
That's a huge jump in raw coding capacity.
But now:
300 changes require code review.
300 changes require testing.
300 changes require a security pass.
300 changes might introduce new dependencies.
300 changes need to be checked against policy.
300 changes require a deployment decision.
And all of that eventually adds up to more running software that needs to be watched in production.
The constraint hasn't disappeared — it has relocated.
The old question was:
Can we build software fast enough?
The new question is:
Can we validate and safely run software fast enough?
DORA describes AI's effect as that of an amplifier — it magnifies whatever engineering practices already exist, good or bad. Their findings suggest AI can boost delivery speed while simultaneously exposing cracks in systems that weren't built to absorb that much velocity.
That reframing matters a great deal.
The New Software Engineering Equation
Put simply, the pattern taking shape runs something like this: AI adoption drives a surge in code output, which drives a surge in the number of changes moving through the pipeline, which in turn demands far more validation, which pushes teams toward heavier automation, which ultimately pushes organizations toward investing more in platform engineering.
Or, condensed into one line:
Writing code gets cheaper. Trusting it becomes the valuable part.
That's the core reason DevSecOps is poised to grow in importance as AI-assisted development becomes the norm, rather than fade into the background.
What Exactly Is DevSecOps?
It's easy to reduce DevSecOps to "bolting a security scanner onto your CI/CD pipeline," but that undersells what it actually covers.
DevSecOps is far more expansive than that.
At its core, it fuses:
Development + Security + Operations
into one ongoing delivery pipeline.
Picture it as the apparatus that decides whether something built by a developer — or increasingly, generated by an AI agent — is actually fit to run in production.
A full DevSecOps pipeline typically includes:
Source Control
Tracking code, branches, commits, pull requests, and history over time.
Code Quality
Linting, static analysis, architectural checks, and maintainability scoring.
SAST
Static Application Security Testing scans source code directly for security flaws.
Secrets Detection
Scanning for passwords, API keys, certificates, or tokens accidentally committed to the repo.
SCA
Software Composition Analysis flags risky or vulnerable third-party dependencies.
SBOM
A Software Bill of Materials catalogs the actual components bundled inside an application.
IaC Security
Scanners that examine Terraform, CloudFormation, Kubernetes manifests, and similar infrastructure code.
Container Security
Checking container images for vulnerable OS packages, outdated libraries, and misconfigurations.
Testing
Unit, integration, regression, API, performance, and increasingly AI-generated tests that confirm behavior is correct.
Policy & Compliance
Enterprise-specific rules that verify software meets organizational, regulatory, and architectural standards.
CI/CD
Once approved, software gets built, packaged, and pushed through environments.
Deployment
Rollout strategies such as canary releases, blue/green deployments, and feature flags govern how code reaches production.
Runtime Security & Observability
Live applications are continuously watched for vulnerabilities, attacks, crashes, unusual behavior, and performance dips.
That whole apparatus only becomes more critical as machines take on a growing share of the actual coding.
AI Changes DevSecOps Too
There's another dimension to this shift worth examining.
DevSecOps won't just handle a larger volume of AI-written code.
DevSecOps itself is becoming AI-driven.
Right now, a typical scanner might flag something like:
Critical vulnerability detected in dependency X.
An AI-powered version of that same system can push further:
Critical vulnerability detected. Here's why it matters. Here's the affected code path. Here's the recommended version. I've generated the fix. I've run the regression tests. Here's the pull request.
That represents a completely different way of operating.
From Detection to Autonomous Remediation
Look at how this capability tends to evolve in stages.
Generation 1: Detection
The tool alerts a human:
"There's a vulnerability."
The engineer then digs in to investigate.
Generation 2: Recommendation
The tool goes further:
"There's a vulnerability, and here's how to fix it."
The engineer carries out the suggested fix.
Generation 3: Remediation
The tool takes another step:
"There's a vulnerability. I've already written the fix and opened a pull request."
The engineer's job becomes reviewing it.
Generation 4: Autonomous DevSecOps
Eventually, for changes carrying low enough risk, the entire chain:
Detect → Understand → Fix → Test → Validate → Deploy → Monitor
can run largely without human intervention.
Rather than carrying out each step by hand, people shift toward setting policy, handling exceptions, and overseeing the system as a whole.
The Software Supply Chain Becomes Critical
There's a second reason this transition matters so much.
Modern software is rarely written entirely from scratch. Instead it gets pieced together out of many outside sources: libraries pulled from open-source registries, third-party APIs, prebuilt container images, application frameworks, managed cloud services, reusable infrastructure modules, and now, output produced directly by AI tools.
AI dramatically speeds up this assembly work.
Sonatype's 2026 research on software supply chains describes the ecosystem as approaching machine scale, pointing to automated builds, expanding dependency graphs, and AI agents that make provenance and trust more important than ever.
As a result, organizations increasingly need answers to questions like:
Where did this code originate?
Which AI produced it?
Which model version generated it?
What dependencies did it pull in?
Were those dependencies vetted and approved?
What security checks ran against it?
Which policies were applied?
Who signed off on the deployment?
What's actually running in production right now?
That pushes DevSecOps well past simple automation.
It turns into an enterprise-wide trust system for software.
AI Accountability Becomes a New Requirement
This concern is already surfacing in industry surveys.
A 2026 GitLab survey found that 80% of respondents said their organizations had rolled out AI tools faster than they'd built governance policies to match, and 92% reported facing governance difficulties tied specifically to AI-generated code.
Picture an auditor asking:
"Why is this piece of code touching customer financial data?"
In the past, you could simply name the developer responsible.
In an agentic development workflow, the honest answer might instead be:
"An AI coding agent produced it while working on feature #4821."
That opens up a whole new set of governance questions.
What prompt triggered its creation?
What context did it have access to?
Did it pull in a new dependency?
Was that dependency cleared for use?
What tests were actually run?
Did any human review the change before merge?
Which AI security agent, if any, evaluated it?
In short, AI provenance is shaping up to be a new required artifact within the software supply chain.
The Rise of the AI DevSecOps Platform
Enterprises today typically run a patchwork of disconnected tools, something like:
Developer → GitHub → Jenkins → SonarQube → Snyk → Artifactory → Kubernetes → Datadog → ServiceNow
Each tool addresses one slice of the workflow.
AI makes this fragmentation far more costly, because agents need visibility across the whole lifecycle to be useful.
An AI agent troubleshooting a production incident might need access to:
- The original requirement
- Source code
- Commit history
- Test results
- Vulnerability data
- Deployment history
- Infrastructure configuration
- Runtime logs
- Production telemetry
- Past incident records
That need is driving the market toward unified engineering platforms.
Gartner already lists platform engineering and GenAI-enabled platform engineering among the key trends in software engineering, projecting that by 2027, 70% of organizations running platform teams will have embedded GenAI features into their internal developer platforms.
DORA makes a related point: the quality of a platform strongly determines whether AI adoption actually boosts organizational performance, or whether it just creates "downstream disorder" instead.
Where the Value Moves
This shift carries major consequences for the tech industry at large.
During the first wave of generative AI hype, most of the attention centered on one question:
Which coding assistant is best?
That question still matters.
But a bigger enterprise question is emerging alongside it:
Who controls the journey from an AI-generated idea to trustworthy production software?
That journey is where enormous value now concentrates. Consider the layers involved:
AI Coding
Tools like Copilot, Claude Code, Cursor, and their peers.
↓
Source & Collaboration
Platforms such as GitHub, GitLab, and Bitbucket.
↓
Security
SAST, SCA, secrets scanning, container security, and supply-chain security.
↓
Artifact Management
Packages, containers, and provenance records.
↓
CI/CD
Automated building, testing, and deployment.
↓
Cloud Platforms
Infrastructure and runtime environments.
↓
Observability
Logs, metrics, traces, incidents, and production insights.
↓
Governance
Policies, approvals, audit trails, and compliance records.
Whichever platform manages to unify these layers stands to become extraordinarily strategically important.
The Future: Developers Become Orchestrators
None of this means the developer role disappears.
What changes is what the job actually involves day to day.
Most developers currently spend the majority of their hours typing out implementation logic.
Going forward, that shifts toward acting as an orchestrator of intelligent systems.
Rather than telling the machine:
Write this function.
the engineer will more often say:
Build this capability.
The AI handles producing the implementation.
The human's attention moves to judging architecture choices, business rules, and risk exposure.
Security agents scan for weaknesses.
Testing agents confirm the behavior is correct.
Deployment agents handle rollout mechanics.
Observability agents keep watch once the system is running live.
Increasingly, the person's job is to oversee the system as a whole rather than assemble it piece by piece.
Gartner has made a comparable prediction, describing developers moving toward orchestration, problem framing, system design, and confirming that AI-produced results actually satisfy quality expectations.
DevSecOps Engineers Change Too
The DevSecOps function shifts in a similar direction.
The job has traditionally revolved around:
- Writing pipelines
- Maintaining Jenkins
- Configuring scanners
- Managing deployment scripts
- Troubleshooting environments
It's increasingly coming to mean things like:
- Architecting the platforms that deliver software end to end
- Setting up the guardrails an entire organization relies on
- Writing the security rules that agents must obey
- Overseeing what autonomous coding agents are allowed to do
- Designing systems that fix problems automatically rather than waiting for a human
- Tracking where every piece of software actually came from
- Building shared templates that teams can reuse instead of starting from scratch
- Quantifying how much engineering risk the organization is carrying
- Keeping autonomous delivery systems running reliably
Put another way:
The DevSecOps job stops being about keeping pipelines alive and becomes about building the control layer that governs AI-produced software.
Security Changes from Gatekeeper to Guardrail
In most organizations today, security operates as a checkpoint.
Development finishes something.
Security looks it over.
An issue turns up.
Development patches it.
Security checks it again.
That back-and-forth becomes impractical once AI pushes development speed far beyond what it used to be.
The model taking its place looks more like:
Policy → Automation → Continuous Enforcement
Security teams write the rules once.
The platform then applies those rules nonstop, without waiting for a human to sign off each time.
Here's how that plays out.
Rule: No API exposed to the internet may skip authentication.
An AI agent ships an API missing that check.
The DevSecOps platform notices immediately.
The deployment gets blocked automatically.
The coding agent is told exactly why.
The coding agent patches the API.
Tests run again.
The security rule is now satisfied.
Deployment moves forward.
No person on the security team reviewed this by hand.
Yet the policy held at every point in the process.
That's the real payoff of AI-powered DevSecOps.
Why Enterprises May Spend More on DevSecOps, Not Less
It's easy to assume AI will let companies get by with fewer tools and less spend on engineering infrastructure.
In critical parts of the stack, the opposite is more plausible.
AI lets organizations produce far more software than before.
But each additional application shipped also drags along its own tail of consequences: another API to expose, another container to run, another set of dependencies to track, more cloud resources to provision, another round of security scanning, one more deployment to manage, extra telemetry to sift through, fresh vulnerabilities to patch, and additional compliance evidence that has to be collected and stored.
In short, more software in production simply means more of everything that has to be watched, verified, and kept trustworthy.
GitLab's earlier DevSecOps survey work already found security practitioners worried that AI-generated code would add to their workload, and its 2026 research points to what it labels an "AI efficiency paradox," where faster code output combined with disconnected tooling can create new choke points later in the pipeline.
So the economics move away from:
Paying people mainly to produce code
and toward:
Paying for platforms that can manage a massive volume of software output safely.
A Simple Example
Here's a concrete illustration.
Imagine a bank needs a new feature:
Let customers freeze their credit card from the mobile app.
Yesterday
A product manager writes up requirements.
A developer designs the API.
That developer writes the code.
A colleague reviews it.
QA builds out a test suite.
Security runs its scans.
DevOps puts together the pipeline.
Operations handles the rollout.
The whole thing might take days or weeks to complete.
Tomorrow
Instead, a product manager writes:
"Let authenticated customers freeze and unfreeze a card, log every action for audit purposes, and notify the customer when it happens."
An engineering agent takes that requirement and runs with it.
It produces:
- API
- Database changes
- Business logic
- Unit tests
- API tests
- Infrastructure changes
- Documentation
This might take a matter of minutes.
Now the AI DevSecOps platform steps in.
It spots that the AI left out a required authorization check on the new endpoint.
Security agent: BLOCK.
It also finds that a newly pulled-in open-source library has a critical known vulnerability.
Supply-chain policy: BLOCK.
The coding agent swaps in a safer dependency.
Tests run once more.
Testing agent: PASS.
The platform confirms encryption, logging, and authentication are all in place.
Compliance policies: PASS.
The app ships to a test environment.
Synthetic transactions run against it to simulate real usage.
Runtime validation: PASS.
A canary rollout sends a small slice, say 5%, of live traffic to the new version.
Observability shows nothing unusual in error rates.
Traffic is scaled up gradually until it reaches everyone.
The feature is now live.
The whole sequence leaves behind a full audit trail:
Requirement → AI Agent → Code → Dependencies → Tests → Security Decisions → Approvals → Deployment → Runtime Evidence
That's AI DevSecOps in action.
And here's the interesting part.
Generating the code was actually the easiest step.
The valuable part was the machinery capable of confidently answering:
Is this software actually ready to go into production?
The Bigger Shift
For a long stretch of time, conversations about AI in software engineering have mostly focused on one thing: developer output.
How much faster can AI make people who write code?
That question is starting to feel too limited.
A bigger question deserves more attention:
What happens once producing software stops being the scarce resource?
Once code is abundant, what organizations actually need is a way to establish trust at the same speed the code gets written.
That means testing.
Security.
Managing the software supply chain.
Governance.
Enforcing policy automatically.
Automating deployment.
Watching systems in production.
Tracking where AI-generated work actually came from.
And, more and more, fixing problems without waiting on a person.
Taken together, these form the next generation of DevSecOps.
The earlier phase of AI in software engineering was mostly about helping people write code faster.
The phase coming next is about letting people and AI agents run entire software factories together, safely.
Seen that way, DevSecOps isn't a function that sits after development and cleans up afterward.
DevSecOps becomes the control plane the whole AI-driven software factory runs on.