DEV Community: Denis Butko

How to Best Integrate AI into the Software Development Process Material for Managers and PMs

Denis Butko — Fri, 02 Oct 2026 09:00:00 +0000

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.

AI Will Replace Programmers. So What Happens to Developers?

Denis Butko — Wed, 30 Sep 2026 09:00:00 +0000

AI will replace you!”

Have you heard that? I hear it often, and I wanted to figure this out and understand for myself how software development will live in the conditions of universal AI, when just about anyone can use AI to generate a website, a bot, or use a neural network to generate applications. And it seems that, indeed, programmers are no longer needed, but intuitively we understand that it is not that simple.

Let’s figure out who a developer is and how they differ from a programmer, an architect, and an agricultural engineer.

But first, let’s conduct a thought experiment.

Suppose you need to move into one of two skyscrapers on the 99th floor. Both skyscrapers have 100 floors, foundations, the same amount of apartment and common-area space, and each has a built-in fire safety system, but in neither case has it ever been activated. But there are also differences: the first building passed a full inspection by the relevant state fire, technical, and consumer-safety authorities, and it was designed and built by people according to all modern standards. The second building was built by AI without the involvement of human specialists. The relevant state fire, technical, and consumer-safety authorities did NOT participate in putting the second building into operation.

Which building would you prefer for the next 5–10 years?

For some reason, it seems to me that the first one.

We can conduct a similar experiment with doctors. If you eat the wrong mushroom, who would you go to for treatment? A human or AI? For some reason, it seems to me that everyone would go to a human doctor for the final treatment. And that is understandable. We do not yet trust AI that much, especially when it comes to things like health.

And the reason is not that AI is bad. And it is not even that the words of a human doctor can soothe our emotional traumas. The reason is the same reason why people choose the creative work of other people.

AI music has surpassed 50% of new music uploads

The study “Human Bias in the Face of AI: Examining Human Judgment Against Text Labeled as AI Generated” and the article “AI music has surpassed 50% of new music uploads for the first time” by Deezer clearly point to this. The latter gives some interesting numbers: more than 50% — around 90,000 — of all tracks uploaded to the platform every day are created with AI, while the share of streams of such tracks is only 1–3%. Makes you think, doesn’t it?

Let’s nevertheless get to the main question. What is an architect, what is an agricultural engineer, and how is an architect or agricultural engineer different from a developer? All these specializations have one thing in common: specialized knowledge and responsibility taken upon oneself.

A building architect is responsible for ensuring that a design complies with applicable standards and requirements. A bridge architect is responsible for ensuring that loads, operating conditions, and safety requirements are taken into account in the design. A software architect is responsible for architectural decisions that allow a system to withstand loads, scale, and evolve. A developer is responsible for ensuring that the software they create can be maintained and used for its intended purpose.

And a programmer writes code. Of course, they can solve algorithmic problems, pass interviews, and follow instructions… But for some reason, it seems to me — and I am almost certain about this — that neural networks do these things better and faster. And therefore, the task of every programmer is to become a developer.

Agricultural engineer.

I did not choose this profession by accident. We can look at the evolution of this field roughly, and we can already see new synergies between AI and agriculture.

Until the 19th century, fields were cultivated with plows using people and animals. Later, steam engines and internal combustion engines appeared, and at the beginning of the 20th century, the first motor cultivators appeared. By the first half of the 20th century, tractors began to spread widely, and by the end of the 20th century, tractors and combines had become an integral part of large-scale agriculture around the world.

Then mechanization began to transition into automation of technological processes and production: electronic controllers, sensors, and automatic control of individual operations appeared.

Later, satellite data and remote sensing came into agriculture. Today, there are already projects where computer vision and AI are used to identify and map weeds, estimate their density and biomass, and detect plant diseases.

And every stage was accompanied by the elimination of a large amount of simple work and an increase in the importance of more specialized knowledge.

The same thing is happening in IT.

Within IT, every developer is first and foremost an engineer, and only then a programmer. Programming has constantly been getting rid of low-level routine work. We moved from machine instructions and assembly language to high-level languages, libraries, frameworks, and IDEs. Each such stage removed part of the routine and allowed developers to operate at a higher level of abstraction and develop more complex software.

Generative AI is taking the next step — now the routine work of describing functions can be handed over to the machine itself, while we focus on architecture and software design.

That is why AI implementation in business processes and AI implementation in processes in general are becoming less a question of code generation and more a question of properly designing these processes.

The same applies to process automation. If previously a developer automated an individual operation using code, now they can design an entire system in which some of the operations are performed by AI.

A few words about vibe coding.

Most people will not build a multi-story house themselves without the help of specialists. I believe that each of us can build one or two floors ourselves, but building three or four without the necessary knowledge is already dangerous. Anyone can run a wire to move an electrical outlet, but organizing all the wiring in a house so that it can handle the loads requires knowledge. And we all understand this perfectly well.

We know what to do when we have a cold, but if something more serious happens, we go to a specialist. We know the approaches of juniors and some middle-level developers very well. We have experienced all the pain of incorrectly chosen architecture ourselves.

The euphoria will pass, but hundreds of thousands of projects killed by vibe coding will remain, and they will require specialized knowledge.

That is why implementing process automation with AI is not simply about connecting a neural network. You need to understand which processes should be automated, where a human is needed, where a model is sufficient, and where full engineering control is required.

I am not an enemy of vibe coding. It is a wonderful tool that requires proper handling and precisely those specialized skills in architecture, development, and even programming.

Conclusion

And when it comes to complex systems, implementing AI agents in business processes requires an even higher level of understanding: an agent must not simply generate an answer, but operate within specific business constraints, use tools, access data, and handle errors correctly.

Otherwise, it will be like with music: 97% of people versus 3% AI. AI is already capable of producing a gigantic amount of content. But the Deezer story shows an interesting paradox: production has become cheap. Something else has become expensive — creating something that someone actually needs.

Perhaps this is exactly what is happening with programming right now.

Code is becoming cheap. Engineering is not.