As AI agents move beyond assisting developers to executing increasingly complex, multi-step tasks across the software development lifecycle, enterprises are rethinking how software is built, reviewed, secured and deployed. The shift towards agentic software development is creating new opportunities for productivity while also raising questions around governance, visibility, accountability and human oversight.

GitLab is positioning platform-level orchestration and governance as key components of this transition, with organisations increasingly working with multiple AI models, coding agents and development tools. As AI-generated code accelerates development, the bottleneck is also shifting towards review, validation and governance, making engineering judgement and effective orchestration increasingly important.

In this interview with AI Spectrum, Manav Khurana, Chief Product and Marketing Officer, GitLab, discusses how AI agents are reshaping the role of developers and engineering teams, the controls organisations need as agents become more autonomous, and the importance of maintaining visibility across AI-generated changes. He also shares his views on AI-first DevSecOps practices, platform-level standardisation, agent governance and the metrics enterprises should track to measure the business value of AI across the software development lifecycle.

As AI becomes embedded across the software development lifecycle, what changes do you expect in the role of developers and engineering teams over the next two to three years?

Human ambition has always outpaced a team's capacity to deliver, and AI has not changed that. Agents let teams build faster and in greater volume, but the backlog of the world's software still outruns our ability to fulfill it.

The role is changing because agents can increasingly handle much of the code writing. Now, one of the skills that matters most is judgment. Agents can generate code faster than any developer, but engineering judgment does not become abundant because implementation does. The need for developers will continue to grow because all that output causes human attention to move upward: toward architecture, intent, constraints, unblocking agents, difficult exceptions and evaluating whether the system produced the outcome that meets an organization’s needs.

That shift shows up at the team level too. According to GitLab's recent AI Accountability report, 85 per cent of respondents say the bottleneck has moved from writing code to reviewing and validating it, so the work teams organize around moves with it.

Alongside judgment comes orchestration. Developers will increasingly be using agents as part of a software factory, which directs their agents, deciding how agents should be chained to handle which task, in what order, and how failures and handoffs get handled. As teams move from task-by-task assistance toward more autonomous software development, skills once expected only of senior or staff engineers are becoming baseline expectations for the whole team. Developers who understand systems deeply, not just syntax, and can trace work through pipelines, security findings, and production signals will be best positioned to make agentic engineering work.

AI agents are increasingly moving from assisting developers to independently executing multi-step tasks. What new controls or operating models will organizations need as these systems become more autonomous?

Autonomous agents don't just write more code, they act on their own inside systems that weren't built to govern that. The risk is an agent executing across repos, pipelines, and infrastructure with no record of why.

Our CISO, Chaim Mazal, frames this problem as governed vs. shadow software factories. One path runs through governed identity and audit controls, while the other runs through unmanaged agent sessions with no reliable trace of how the work got done. The second path is the one that scales risk fastest as agents get more autonomous.

The fix is controls built into the workflow. Organizations need a foundation they can inventory, approve, and prove, with clear identity and permission boundaries for agents, approved models and tools, policy-based controls, human approval gates, and a complete audit trail. Low-risk actions should move quickly, while higher-risk actions should automatically trigger the appropriate review. Governance should be embedded at the point of action with as little friction as possible, not added later as a manual compliance exercise.

The operating model also changes. Teams move from one developer working with one AI assistant to people orchestrating multiple agents across planning, coding, testing, security, review, and deployment. Humans set intent and define the guardrails; agents handle more of the execution within those boundaries. That's the governed alternative to the shadow factory Chaim describes.

The goal is not to slow agents down. It is to give organizations a governed foundation to scale agentic work with speed, control, and accountability.

How can organizations establish a clear chain of visibility from an AI-generated suggestion or code change through testing, approval, and deployment?

Organizations should be able to answer three questions about any AI-generated change: where did it come from, what was it meant to do, and who is responsible for it once it reaches production?

A clear chain of visibility requires every change to travel the same path, whether it was written by a person or an agent. That evidence chain must connect the original intent or work item to the merge request, testing, security and compliance checks, approval, deployment, and production outcome. Agent-authored work should create the same kind of reviewable record as human-authored work, including the identity involved, the tools and models used, the policies applied, and any approvals that were required.

Automated policy and security checks should run before human review, while people remain on the approval gates where risk requires human judgment. A context graph connecting code, work items, pipelines, security findings, deployments, and production signals helps teams understand not only what changed, but why it changed and what happened afterward.

That is the purpose of agentic infrastructure: it makes context, orchestration, governance, and execution part of one path. The result is a single source of truth for what changed, which controls were applied, and whether the change achieved the intended outcome.

What are the biggest cultural or organizational changes engineering leaders need to make to successfully integrate AI into existing DevSecOps practices?

Culture conversations about AI adoption usually start with getting teams comfortable with new tools, but that's not where the work is anymore. The backlog of software to build has always grown faster than any team's capacity to deliver it, and agents shift where that pressure lands. The organizational job is rebuilding processes built for a slower, more manual workflow so they hold up at agent volume.

The fix starts with processes. Every manual step built for a world where a person typed every line by hand is a candidate for reinvention. Code review is a good example because it’s a process designed to catch human mistakes at human volume, and breaks down at agent volume. An AI-first version has the agent triage and flag risk, while a person makes the judgment calls.

That reinvention depends on three things:

Automation across the full SDLC. Coding, testing, review, and deployment all need to move together, or a faster commit just shifts the bottleneck downstream.

Standards engineers will actually use. An agents.md file in each repo, carrying the constraints and context an agent needs, does more for consistency than a policy document nobody opens.

Tool discipline. Leaders need to identify which tools enable non-linear productivity gains and which just add noise and exposure, since every ungoverned tool is also something the company now has to protect against.

The task is reinventing every process built for manual work as an AI-first process. That happens one process at a time, not by retraining people or swapping in new tools.

As enterprises scale their use of multiple AI coding tools and agents, how important will platform-level orchestration and standardization become in preventing fragmentation across development teams?

Standardization does not mean requiring every team to use the same model or agent. It means giving teams a common framework for identity, shared context, policy, risk assessment, auditability, and cost visibility across the software lifecycle. It also helps organizations coordinate agents, prevent shadow tools from creating new security risks, and apply consistent guardrails across development teams.

Model choice is part of that governance picture. Frontier models may lead on raw capability, while open-weight models can give organizations more control over privacy and cost. The platform should support that choice and preserve context, policies, and audit evidence across models, clouds, and vendors.

The same principle applies to deployment. Enterprises need flexibility across SaaS, self-managed, dedicated, and air-gapped environments while preserving a consistent operating model. That is how organizations reduce fragmentation without giving up choice, security, or control.

Beyond developer velocity, which metrics do you believe organizations should track to determine whether AI is delivering genuine business value across the software development lifecycle?

Our mission at GitLab is to unlock every team to build trusted software at the speed of imagination. AI, and the platform approach behind it, is how we get there. The metrics that matter most are the ones tied to each organization's innovation velocity, its ability to turn that into higher revenue without linearly scaling the team, and each person's ability to be more creative and deliver more innovation every day.

That means end-to-end metrics: Cycle time from idea to production, merge request cycle time, deployment frequency, change failure rate, and mean time to recovery. It also means watching cost per accepted change, tracking how fast security issues get fixed and whether changes are actually following the guardrails teams put in place. Just as important, it means checking whether developers feel less overwhelmed as velocity goes up.