Let's talk about the process in which development is handled entirely by AI. We will try to understand how the constraint of the system shifts when specific stages are fully automated. We will not try to figure out what is better; instead, we will try to consider different ways of using agentic systems without going deeply into the details of the development itself. Only processes. Only constraints. Only development.
This article is for managers and leaders who are wondering how best to use AI agents in software product development. And how definitely not to do it.
Let's start by describing the functions that exist in software development. We will need them to understand what follows. Any mature development process includes:
Business analysis. Roughly speaking, this is where we determine what business problem exists, for whom it exists, why it needs to be solved, and what business result we want to achieve.
Systems analysis. Here we translate business requirements into a description of how the system should work after the changes, including functional and non-functional requirements.
Development preparation. The technical specification is broken down into tasks and refined based on the current state of the project and its constraints. The resulting set of tasks goes into the backlog and is planned for implementation. This is also where grooming, technical research, and estimates necessary to determine the timeline and scope of implementation are carried out.
Development. Here we turn prepared requirements and technical solutions into a working software product.
Code review. Usually performed by team members before changes are included in the shared codebase. This is where shortcomings, architectural errors, and violations of development standards are identified.
Testing. The implementation is checked for compliance with the requirements, and errors in the new functionality are identified.
Release. The verified implementation is delivered to production and becomes available to users.
For simplicity, let's imagine development as a linear process. In large, pipeline-style teams, each of these functions is handled by a specific person.
It is easier to understand this on a linear graph, without branches. Each feature moves from left to right, from an idea to the user. Now that the formalities are out of the way, we can conduct a series of thought experiments.
Experiment #1
Let's try to speed things up as much as possible by handing testing and release over to agents. The system automatically verifies its own results and delivers them to our servers. We hand over the entire right half of the process to automation once the tasks have been prepared.
We get maximum acceleration, and our only constraint is the preparation of the tasks themselves and the requirements for them. In large teams, this process can take weeks, which means there will still be a serious constraint in the system in the form of preparation work. Handing this work over to agents as well would mean developing for the sake of development.
But along with maximum speed, we get two significant uncertainties: not only do we not know how our system works, we do not even know whether we achieved the desired result. In other words, we effectively get a "black box". In large projects, the first assumption is already unacceptable; the second can threaten the business.
The situation even looks comical, because in this case we would learn how our system works from its users. This is definitely not how it should be done.
It is worth noting that there are attempts to build companies around this approach. I have seen at least one such company. A person uploads an instruction and gets a result. It immediately goes to the servers and becomes available to all users. Then a new task is created to fix the errors in the previous one.
Experiment #2
What if we try to eliminate some of the negative consequences from Experiment #1 by automating only development together with code review? We get the following chain: tasks are prepared, agents implement them, a QA engineer checks the result, and if it meets expectations, the release is made. Sounds reasonable. We write the code automatically, and the result is also checked.
With this approach, what a developer does in a day, a machine does in an hour. But despite the speed of releasing new features, a bottleneck appears in the form of the QA engineer.
Good testing is not simply "clicking a button." It is thoughtful reading of the task or specification, analysis of whether the implementation meets the requirements, checking related functionality, and describing the incorrect cases that were found.
If we assume that a QA engineer spends one hour checking each feature, then one person can check no more than 8 features per day. This is a significant constraint. The speed at which new features can be released is limited by the number of QA engineers.
At the same time, the code itself becomes a black box for us. Important engineering knowledge about the system is lost. We no longer know what is happening inside; we simply guess how it works. We guess because we cannot see all the background processes.
This approach could probably work for releasing an MVP — for quickly testing a hypothesis or for freelancing. But not much beyond that.
It seems that we saved money on development and even accelerated it. But we forgot to think about who would investigate incidents.
It is fine if an hour of downtime costs 10–15 dollars. But what if it costs 1000? Or 5000? And there are quite a few companies like that.
Understanding a problem without understanding how the system works is not a simple task. And every failure affects not only money, but also customer loyalty. This kind of saving on development makes server failures more expensive.
Of course, we could hand over only development to AI-assisted automation while keeping all functions from code review onward under our control. But this also requires specialized knowledge, which means we will not be able to significantly reduce costs.
As we have already understood, the speed of the entire process is limited by the bottleneck, which means that something will still slow us down — either code review, result verification, or something else.
An agent does not eliminate the constraints of the development process — it moves them. If you automate one stage, the bottleneck appears at the next one. Therefore, maximum code generation speed does not by itself mean maximum product delivery speed. And it certainly does not guarantee quality or reliability.
Experiment #3
The first two experiments showed us the problems and constraints that we will inevitably encounter if we try to completely replace a stage with an agent.
So how can we accelerate development, or at least reduce its cost?
The first thing that might come to mind is hiring less competent developers for less money, because AI will help! It won't.
AI reduces the cost of performing individual engineering tasks, but it does not reduce the cost of engineering competence. This is the foundation on which stable software products are built.
This turns out better than in Experiments #1 and #2 — but it is still not good.
So what could a structured development process with AI agents or LLMs look like, so that the result remains understandable, the codebase remains maintainable, and the speed remains reasonable?
Let's try adding an assistant in the form of an agent to each role. What do we get?
It looks like the best way to use AI in development is for each participant to use it to make their work easier and automate routine tasks.
If we assume that introducing an agent at each stage gives us an average gain of just 3%, we get a 21% saving across the entire process.
That's already one-fifth of the time, without losing quality! And that means reducing development costs by ~20%. That already sounds good.
By slightly reducing the effort at each stage, we can significantly reduce the cost of the entire process.
For some, it will help analyze business requirements; for others, it will answer questions about the code. Somewhere it will find gaps or describe tests; somewhere it will perform a preliminary review and even write part of the code, or write documentation.
But each function must have a responsible person behind it, if, of course, you want your project to live for a long time and develop stably.
Summary
This is similar to transportation.
At first, humans traveled on foot. It took a long time to get from one settlement to another distant one. Then they switched to horses and horse-drawn carts. The speed of travel increased because the very method of transportation changed.
Then the first automobiles appeared, but the speed of travel did not increase much and even decreased — the first automobiles moved at 15–20 km/h.
The real leap happened later, when roads and infrastructure appeared alongside automobiles. You could no longer travel in any direction, but you could move quickly wherever it was possible.
And only when a fundamentally new method of transportation appeared — airplanes — did we truly begin moving rapidly around the planet.
It is the same here.
With current programming languages, which are designed for humans, and with the current development approach, we cannot significantly increase speed while preserving quality. We will inevitably encounter constraints or have to accept the consequences.
Right now, we are trying to integrate AI into the existing development process in roughly the same way as the first automobiles were used on infrastructure built for horses.
Perhaps the next leap will happen when we no longer need to write code as the primary form of describing a software product.
Top comments (0)