Most engineering leaders adopted AI coding tools the same way: a few developers installed an autocomplete plugin, it made line-by-line suggestions feel faster, and adoption spread informally with little policy or measurement in place, and no change to how code gets reviewed or shipped. Checkmarx’s 2025 Future of AppSec study, based on a survey of over 1,500 CISOs, AppSec professionals, and developers, found that 99% of development teams use AI to generate code, yet only 18% have a policy governing that use and around a quarter have no policy at all, confirming that adoption has run well ahead of governance at most organisations. That pattern works for autocomplete. It breaks down completely once the tool in question can read your whole codebase, run shell commands, edit files across a repository, and open a pull request on its own.
That is the situation Heads of Engineering now face with agentic coding tools such as Claude Code, from Anthropic. The thesis of this piece is straightforward: moving from autocomplete to agentic delivery is not a tool upgrade, it is an organisational and process shift, one that touches security permissions, code review, prompt and workflow standards, and how engineers are trained. Teams that treat it as a procurement decision rather than an operating model change are the ones whose pilots stall. Zartis, as a Preferred Services Partner in the Claude Partner Network, works with engineering teams to implement AI-Enabled SDLC deliberately, rather than by accident.
Autocomplete and agentic coding are different categories of tool
Inline autocomplete predicts the next line or function as a developer types. The developer stays in control of every keystroke; the tool is a suggestion engine sitting inside an existing workflow. Agentic coding tools work differently: they read the full codebase, plan an approach across multiple files, execute changes using real development tools such as git and test runners, and iterate on failures until the task is done. The developer defines the goal and reviews the result rather than approving each line.
That distinction matters because it changes what the tool is allowed to touch. An autocomplete suggestion never runs a command or commits code. An agent with shell and file access can install packages, modify configuration, and open pull requests, which is precisely why treating it like an autocomplete rollout, informal, individual, ungoverned, creates risk that autocomplete never did.
Anthropic’s own analysis of roughly 400,000 Claude Code sessions between October 2025 and April 2026 found that just over half (56%) of sessions involved writing, fixing, or testing code directly, with the remainder split across operating software (17%) and analysis or documentation (13%). Over that seven-month period, the share of sessions spent fixing already-broken code fell from 33% to 19%, while operating software and analysis work grew, a sign that teams were shifting from using the agent to patch problems towards using it to build and run things directly. The same analysis found that engineers rated as experts directed the agent through roughly 12 actions per instruction and produced around five times the output per prompt compared with novice users, and that expert-rated sessions reached a verified successful outcome more than twice as often as novice ones. In other words, the tool itself does not create the productivity gap. How well someone directs it does.
What agentic delivery actually looks like day to day
Claude Code runs as a terminal-based agent that reads files, runs shell commands, and calls APIs, directed through natural-language instructions rather than a fixed UI. Three features matter most for teams scaling beyond individual use:
- Subagents. A subagent is a separate session with its own context window, used when a task benefits from isolation or parallel work, for example running a security review, a test suite, and a documentation update as separate, bounded jobs coordinated by a main agent.
- Hooks. Hooks inject rules at defined points in the agent’s execution, before or after a tool call, at session start, or on completion. Teams use them to enforce standards automatically: run the test suite before the agent can stop, block edits to generated files, require a linked issue ID before a commit, run a dependency scan after a package change.
- MCP integrations and plan mode. The Model Context Protocol connects the agent to external systems, GitHub, databases, deployment APIs, so it can query live context rather than working from the repository alone. Plan mode has the agent produce and share an approach before executing it, giving a human a checkpoint before changes are made.
These are the mechanisms that turn an individual habit into a governed practice: instead of trusting that each engineer prompts carefully, the hooks and plan-mode checkpoints enforce the standard for everyone using the agent.
Anthropic has published customer accounts illustrating the scale of what this can do in defined, bounded projects: Stripe reported completing a 10,000-line migration in four days against a ten-week estimate, Wiz reported migrating 50,000 lines in roughly 20 hours of active work against a two-to-three month estimate, and Ramp reported an 80% cut in incident investigation time. These are Anthropic-published figures from named customers using Claude Code on specific, scoped tasks, not universal benchmarks, and any team quoting them should treat them as a directional signal about what focused agentic workflows can achieve rather than a promise of equivalent results on unrelated codebases.
The part that does not show up in a product demo: governance
The obstacle most teams hit is not capability, it is control. Industry reporting on enterprise AI agent rollouts puts the scale of the problem bluntly: 88% of enterprise AI agent pilots never reach production, and Gartner is cited in the same analysis forecasting that over 40% of agentic AI projects will be cancelled by 2027, for reasons that are largely about unclear business value and inadequate risk controls rather than model quality. The infrastructure gap most commonly cited: no single sign-on mapping agent sessions to a named engineer, audit logs that never reach the SIEM, no sandbox isolation for what the agent executes, and pull request gates that do not apply equally to agent-authored changes.
None of this is exotic. It is the same governance discipline engineering teams already apply to human access: every agent session should map to an identity, every shell command and file change should be logged somewhere your security team already watches, execution should happen in an isolated environment rather than directly against a developer’s machine, and secret scanning should run before any pull request, human or agent-authored, can merge. Skipping these controls is what turns a promising pilot into the security review that kills the programme.
Code review has to change shape, not disappear
Once an agent is producing a meaningful share of pull requests, review has to adapt or it becomes the new bottleneck. Data from CircleCI’s 2026 State of Software Delivery, discussed in coverage of AI’s effect on code review, shows feature branch throughput up 59% year over year while main branch throughput for the median team fell, meaning the constraint has moved from writing code to deciding whether it is safe to merge. Teams handling this well are pushing baseline checks, formatting, known vulnerability patterns, license compliance, into automated gates ahead of human review, and reserving human attention for intent and architectural fit: does this change solve the right problem, does it fit the system it is joining, does it introduce a dependency or pattern the team will regret. That is a genuine shift in what senior engineers spend their review time doing, and it needs to be designed rather than left to happen by accident.
Making the shift deliberately
Moving an engineering organisation from scattered autocomplete use to a governed agentic practice touches four things at once: access and audit controls for an agent with shell and file permissions, review workflows redesigned around automated baseline checks and human judgement on intent, written standards for how engineers prompt and structure agent tasks, and training so that engineers direct the agent as capably as the expert-rated users in Anthropic’s own data, not as novices who abandon sessions the moment something goes wrong.
This is where Zartis works alongside engineering leadership rather than beside it. Through AI-Enabled SDLC engagements, we help teams redesign the development lifecycle itself, from access controls and review gates to CI pipeline integration, around agentic tools. Claude Code Workshops and broader AI Training and Enablement give engineers the hands-on practice that separates a productive agentic workflow from a stalled one. And through AI Development engagements, we deliver the working software alongside that transition, rather than handing over a framework and leaving a team to figure out execution alone. Our AI experts advise you on the operating model and build the systems that run on it, because a team that only gets one or the other tends to end up back where it started: individual engineers experimenting with a powerful tool, and no organisational capability to show for it.
The teams that get real value from agentic coding are not the ones with the most enthusiastic early adopters. They are the ones that treated the shift as what it is, a change to how software gets built, reviewed, and shipped, and built the practice to match.