How coding agents shift engineers from drafting to reviewing

Buying coding agents also means redesigning software work

Buying a coding agent commits an enterprise to changing how software work is assigned, reviewed and paid for. A coding agent is an AI system that carries out software-development tasks with some independence, while people direct and review its work. That independence can increase development activity, but productivity gains depend on decisions about human responsibility, access to organizational knowledge and the cost of running agents alongside employees.

Those decisions matter more as enterprises continue investing despite disappointing results. Continued spending shows the importance companies place on deployment; returns depend on what happens inside the organization. For engineering leaders, choosing a capable tool is therefore part of a broader investment question: what must change for faster development to remain trustworthy, manageable and clear in its costs?

Rising investment establishes market commitment

The investment outlook shows how strongly companies are pursuing this opportunity. McKinsey forecasts that investment in agentic software development, meaning development carried out with agents, will grow “more than twelve times” from 2025 to 2026. McKinsey also has a commercial interest in this transition: as a consultancy, it can benefit from advising enterprises on AI adoption and the organizational changes that follow. Its forecast describes expected spending; productive returns will depend on how customers use that investment.

The broader AI market offers a separate measure of demand. Gartner’s recent forecast puts global AI spending at $2.7 trillion for “this year,” an increase of 49.5% year over year. Gartner’s figure covers AI overall, whereas McKinsey’s forecast concerns agentic software development. The forecasts describe different markets, so they should remain separate when assessing the scale of coding-agent investment.

Within that market, suppliers are competing for enterprise budgets. The reported purchase of Anysphere, maker of the AI coding agent Cursor, by SpaceXAI in August carried a price of $60 billion. Anthropic’s Claude Code and OpenAI’s Codex, both launched more than a year ago, are also major competitors. SpaceXAI, Anthropic and OpenAI stand to benefit from enterprise adoption, while their customers must turn those purchases into useful daily work.

Faster generation changes human work and raises the control burden

Turning a purchase into useful work begins with assigning responsibility. McKinsey describes enterprises introducing agents alongside employees and reorganizing work around that collaboration. As agents take on development tasks, engineers assume greater responsibility for managing AI outputs and deciding whether generated work is ready to move forward. Development capacity therefore depends on how much work people can assess and incorporate while maintaining delivery standards.

Review becomes harder to coordinate when agents and people work at different times. McKinsey finds that some organizations are beginning to use asynchronous agent workflows, in which agents work without a person participating at the same moment. These workflows extend “overnight” and “across weekends,” separating the production of work from the hours when people can assess it. So enterprises need a way to bring those outputs into human decisions without overwhelming the engineers responsible for them.

Coordination also becomes harder when agents change the rhythm of development. Prakhar Dixit, a partner at McKinsey, describes work previously organized through two-week sprints moving through a continuous cycle of drafting, testing, debugging and documentation involving agents and human reviewers. Each activity feeds further work, allowing delivery to proceed through repeated exchanges. Continuous development can coexist with conventional sprints, but review responsibilities must remain clear as revisions accumulate.

Keeping those responsibilities clear also means paying attention to developer confidence. According to McKinsey, nearly half of developers worldwide say they actively distrust the accuracy of AI tools. This finding measures confidence in AI tools broadly; it is separate from a coding-agent failure rate. Because developers are being asked to take responsibility for generated work, a successful workflow must give them a practical basis for judging whether it is reliable enough to use.

Developer judgment therefore remains central even as agents work more independently. Dixit puts the leadership challenge directly: “The leadership challenge is to increase speed without weakening maintainability, quality, or control,” he says. Maintainability means people can continue changing and supporting the software, while quality and control determine whether faster work remains acceptable to the enterprise. Generating more creates value when engineers can turn the output into software they are prepared to maintain and operate.

Agent usefulness depends on the context an enterprise can supply

Engineers’ ability to accept generated work also depends on the information available to the agent producing it. Enterprise code sits alongside policies, product history and operational rules that shape which changes are appropriate. An agent needs this organizational context to understand a task in the setting where its output will be used. Human review and access to knowledge therefore address connected parts of the same development process.

This need for context is creating demand for supporting infrastructure. Structured knowledge graphs organize information and the relationships between it, while advanced repository indexing makes information within code repositories easier to find. Enterprise context systems make broader organizational knowledge available during an agent’s work, including the rules and history surrounding the code. These tools help agents find and interpret relevant information; the right combination depends on the enterprise’s needs.

But the infrastructure is only as useful as the information it makes available. McKinsey says organizations with clear documentation may find it easier to get value from their AI investments because recorded policies, product decisions and operating rules can inform agents’ work. Documentation thus becomes an input to software development performed by agents. Its quality affects the context available for a task, even when the coding tool itself is capable.

Enterprises with unclear documentation or limited context infrastructure therefore face an additional readiness problem. A purchase-and-deploy strategy assumes the agent will find enough usable knowledge to work effectively within the organization. Where that assumption is weak, leaders need to include improvements to the information environment in the deployment decision. Those enterprises can still benefit, but making organizational knowledge usable becomes part of the work required to get value.

The cost model must account for people and AI usage together

Providing context and retaining human review both affect deployment costs. McKinsey observes that some enterprises are beginning to assess software-development economics by combining labor costs and AI-usage costs. This emerging practice reflects a process in which employees and agents contribute to the same delivered work. Engineers continue to direct and assess outputs while the organization also pays for AI consumption.

Because both resources contribute, evaluating a task means looking across the process that produces usable software. A task completed with less hands-on drafting may still involve human review and several rounds of agent activity. The relevant comparison connects those costs to the work the enterprise accepts, including the effort needed to reach that point. This gives organizations a basis for evaluation while leaving them to determine how to allocate costs within their workflows.

Making both forms of spending visible lets leaders examine whether development changes produce worthwhile returns. Total costs may rise or fall as the balance between human effort and AI usage changes. Measuring that balance helps enterprises assess productivity ambitions against the resources needed to achieve them. The financial decision then becomes part of designing how employees and agents work together.

Enterprise readiness sets the limit on autonomy

The resources needed for that collaboration also shape how much independent activity an enterprise can accept. Oana Cheta, a partner at McKinsey, defines the deployment boundary directly: “The defining question of the agentic era is not how autonomous agents can become but how much autonomy the enterprise can safely absorb,” she says. Greater technical capability expands the tasks available for delegation, while the enterprise must decide which activities it is ready to place under that level of independence.

Key executive takeaways

• Investment needs an operating plan: McKinsey forecasts more than twelvefold growth in agentic software-development investment from 2025 to 2026. Engineering leaders need to connect purchases to clear responsibilities, review capacity and delivery standards.
• Human review sets the pace: Overnight and continuous agent workflows increase the volume of work awaiting assessment. Engineering managers need explicit review ownership and workflows that keep generated work manageable while protecting quality and maintainability.
• Organizational context supports useful output: Clear documentation, repository indexing and access to organizational knowledge help agents produce work suited to the enterprise. Deployment plans need to address gaps in policies, product history and operating rules.
• Development economics combine labor and AI usage: Finance and engineering leaders need to assess AI consumption alongside the human effort required to direct, review and revise outputs. Compare those combined costs against the software the enterprise accepts.
• Enterprise readiness bounds autonomy: The appropriate level of agent independence depends on the organization’s ability to oversee and absorb its work. Engineering leaders need to align delegated tasks with available context, review capacity and controls.