Liad Elidan
Opinion

The software engineer’s role is moving beyond code

"Code written by AI still needs someone to review it, fix it and maintain it," writes Milestone CEO Liad Elidan. "Engineers now have to decide how much work to hand over and how much they will inherit back."

A software engineer no longer has to write every line of code to produce working software. An AI agent can take a specification, work inside an existing codebase and return an implementation before the engineer has typed much at all.
That changes where the human work sits: less in direct execution, more in defining intent, supplying context, deciding what to delegate, reviewing what comes back and judging whether the result is good enough to ship.
1 View gallery
ליעד אלידן מנכ"ל Milestone
ליעד אלידן מנכ"ל Milestone
Liad Elidan
(Photo: Amit Elkayam)
As code generation gets faster, pressure shifts downstream to review, testing, integration, architecture, security and rework. Those activities can take a larger share of the process. A team may generate more code yet create more work for the senior engineers who have to validate it. A pull request may arrive sooner but need more changes before it is safe to merge. Faster production can therefore increase coordination and maintenance costs even when the first part of the workflow looks dramatically more efficient.
Coding speed is becoming a weak proxy for engineering impact. What matters is how AI affects the outcomes engineering organizations ultimately care about: delivery, quality, cost and the ability to execute business priorities.
When companies first rolled out AI coding tools, the immediate management question was whether developers were actually using them. Teams tracked licenses, active users, prompts and tool usage. That made sense during the first phase of enterprise AI, when adoption itself was the question. But adoption and impact are not the same thing. The next phase is about contribution: what work AI actually performed, what that work cost and what changed as a result. Leaders need to know whether delivery improved, whether review effort rose, whether defects fell, whether the code remained stable and what the completed work cost.
Prompts, tokens, tool usage and generated lines of code are activities. Software that survives review and reaches production is output. Faster delivery, stronger quality and more efficient engineering spend are outcomes.
Faster authorship can leave delivery unchanged if review becomes the bottleneck. A shorter cycle time can lose much of its value if defects or later rewrites increase.
The useful comparison is therefore not simply between teams that use AI and teams that do not, but between AI-influenced work and meaningful organizational baselines for delivery, quality, rework and cost.
AI’s impact has to be measured against the organization’s own reality: how similar work was delivered before, how long it took, what it cost and what happened to quality afterward. That is the point at which AI usage becomes evidence rather than a proxy.
Autonomous agents make the management problem more complex. A developer using one assistant still sits at the center of a relatively familiar workflow. A team working with several agents may be delegating different parts of software delivery to systems with different purposes, costs, permissions and levels of autonomy.
One agent may generate tests, another may refactor code, another may investigate incidents, and another may be allowed to modify production infrastructure. Engineering leaders are managing a production system made up of people and agents with different responsibilities.
A mixed human-agent system needs different definitions of success for different kinds of work. An agent that generates tests should not be evaluated like one that fixes routine bugs or changes production infrastructure. The acceptable error rate, required review and useful level of autonomy depend on the job.
An agent that consistently produces changes that survive review and remain stable in the codebase may deserve more freedom on the work it has already proven it can handle. Another may need tighter supervision or a narrower scope.
This also changes the economics of engineering. A seat license is relatively easy to understand and budget for. An autonomous agent consuming tokens, invoking models and performing large volumes of work introduces a different cost structure. Engineering leaders increasingly need to understand not only what AI produced, but what that production cost and whether the investment resulted in better outcomes.
The engineer’s role changes most clearly at the point where autonomy has to be earned. The engineer increasingly defines the boundaries of delegated work, decides what evidence counts as success and determines when an agent has earned more room to act.
But that decision requires visibility into the complete lifecycle of AI-generated work, not simply whether an agent ran. Teams need to know what the agent was built to do, who owns it, what it can reach, what it costs, where its work enters the engineering process and what happens to that work after review. Without that record, autonomy becomes an assumption rather than an engineering decision.
An agent that produces ten times more code but creates a large review burden, expensive rework or unstable code may have moved work rather than removed it. As AI becomes a meaningful part of engineering spend, leaders will increasingly need to connect the completed outcome back to what was invested to produce it.
AI can already produce meaningful software work. Using it well requires learning where to delegate, where to review, how to evaluate the result and when to expand or restrict autonomy. That turns AI adoption from a tooling decision into an engineering management discipline. Leaders have to decide where AI should do more of the work, where human judgment remains critical, which tools and agents are earning their cost and whether AI effort is actually landing on the priorities that matter most to the business.
AI will make producing code dramatically cheaper and faster. That does not automatically make engineering better. The engineering organizations that win with AI will understand where AI creates value, where human judgment still matters and how the two perform together.
Liad Elidan is Co-Founder and CEO at Milestone.