Sergey Marchuk is CTO & Co-Founder at Oxagile, a software engineering company enhancing online video experiences with AI.
Agents have lowered the cost of producing code, but writing code was never the whole job.
A production feature still needs someone to figure out what it should do, make architectural decisions, break the work down, test the result, review it and take responsibility when something goes wrong. Give an agent a vague Jira ticket and ask it to code, and you’ll still have to solve all of those problems.
In other words, even as implementation gets cheaper, ambiguity in the requirements, weak architectural decisions and gaps in verification can cost you more than before.
For example, as reported by Ars Technica, a recent study from Harvard University researchers found that introducing coding agents leads to a 30% increase in total lines of code generated, but that the time between a pull request being submitted and the code being merged into the codebase rose 49%.
The distinction I find useful is between giving developers AI coding tools and building an engineering operating model around agents.
As the CTO of a software development and consulting company, I’m seeing the results firsthand. My team is still experimenting with what works, and I don’t think anyone can credibly claim yet that the industry has settled on one model, but I’m seeing several patterns becoming clear.
The SDLC doesn’t disappear, but the work inside it moves
Requirements, architecture, decomposition, implementation, review, testing. AI didn’t break or reinvent the software development life cycle, but human effort is being redistributed inside it.
In my experience, writing code by hand becomes an exception in an AI-native SDLC. Instead, engineers spend more time on interfaces, constraints, architectural decisions and decomposition. My team breaks work into atomic tasks with their own completion criteria, small enough to finish inside a single clean agent context.
Code review, however, can consume more of the development process than it does in a conventional SDLC. Agents can handle routine checks for correctness, test coverage and conformance to the spec. Human review goes deeper on changes that are costly or hard to reverse, including security, architecture, public interfaces, data operations and business-critical logic.
In that sense, the human role moves up a level. People focus more on deciding what to build, expressing intent precisely, defining boundaries and invariants, setting acceptance criteria, reviewing generated work and identifying where human judgment is still needed.
Those responsibilities don’t necessarily map neatly to traditional roles. In a highly automated team, the same person may work across requirements, architecture, implementation and verification. That puts a higher premium on engineering expertise because effective AI-native work requires a broader understanding of how the software is built, tested and operated.
AI raises the cost of ambiguity.
There is an uncomfortable property of the capable coding agents that I’ve worked with: Give it an underspecified task, and it may still give you a very convincing answer.
An engineer who knows the project will often notice when something sounds off and ask, “What did you mean here?” An agent may simply fill the gap itself and keep going, which makes ambiguity expensive.
On the AI-native projects my team works on, we start with a specification that captures functional requirements, constraints, acceptance criteria and what is explicitly out of scope. Before implementation, the spec is checked for gaps and contradictions and the answers go back into it. Otherwise, unanswered questions become assumptions in the code.
The specification has to carry enough context into the technical plan and implementation so that the agent isn’t left inventing missing requirements. The acceptance criteria defined in the spec are then used to verify the result.
Harness surrounds the model.
An experienced developer carries far more project context than is written in the current ticket. They understand the architecture, the patterns the team follows and the shortcuts that caused trouble before. An AI agent doesn’t inherit any of that history.
By harness, I mean the project instructions, tools, permissions, checks and feedback loops that surround the model. On our projects, harness lives in the repository and captures architecture, conventions, anti-patterns and other context the agent needs. I recommend keeping the context modular and starting unrelated tasks with a clean context, so the agent isn’t carrying irrelevant history from one piece of work into the next.
That harness needs continuous maintenance as the project changes. Lessons from code review, continuous integration, observability and incidents feed back into the harness and tooling.
Guardrails move into the tooling
Engineering teams have plenty of rules that amount to “developers know not to do this.” That’s a weak control when an agent is doing the work.
Some of those rules can be enforced directly in the agent loop. Secrets are blocked before the file opens, destructive commands before they run and every tool call leaves an audit trail.
For decisions that can’t be encoded that way, I’ve found it’s important to have four review gates for requirements, architecture, decomposition and implementation. Each should be a concrete artifact and a named person responsible for sign-off, and the agent shouldn’t advance itself through the process.
Where do we draw the line?
There is a temptation to treat AI-native development as a shortcut around the practices software teams spent decades learning. My experience so far points in the opposite direction: Those practices become part of the environment the agent works against.
Tests are a good example. In our current setup, each unit of work comes with its own tests, written by the agent in the same session as the implementation. The harness runs them alongside static checks, while version control, CI/CD, observability, infrastructure as code and isolated environments make the agent’s changes easier to verify and trace.
But the question I’m more interested in is how much implementation we can delegate to AI without handing over engineering judgment with it.
That boundary is still moving. I expect our own answer to look different a year from now. Yet that, more than any individual AI tool, is where I believe the real work of becoming AI-native is happening.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?