Today, virtually no one doubts the benefits of agentic engineering, even though just a few years ago it was the subject of open debate. And the claim that machines would write 100% of the code - which until recently seemed ridiculous to us - has now become a reality for many modern companies.

Indeed, agentic engineering significantly speeds up the build phase. The transition from prompting and using LLMs in chat mode to “human-in-the-loop”, then to “human-on-the-loop”, and finally to fully autonomous execution often allows us to achieve the anticipated 10x speedup.

However, the build phase is just one - albeit a very important - part of the software development lifecycle (SDLC). By creating such powerful throughput at one stage, we immediately run into a bottleneck at another.

But while the downstream shift is obvious, there’s another, less visible shift happening in the opposite direction.

The Obvious Shift: Downstream

By speeding up development in this way, we’ve encountered two side effects.

1. Volume. The amount of code produced grows in proportion to throughput. And all of this code ends up in code review.
2. Lack of firsthand experience. The developer no longer has firsthand experience writing this code. Consequently, this code is new to the reviewer, who must approach it with skepticism. Moreover, the code itself may look quite elegant, but the logic implemented in it may turn out to be flawed because the developer overlooked a non-obvious scenario or logic that isn’t documented anywhere.

As a result, the burden shifts downstream. Code verification, code reviews, and testing in all their forms become more complex and require increasingly more time and resources.

This effect is quite obvious and widely discussed. There are many approaches to solving this problem - ranging from full automation to hybrid “human-machine” systems.

However, there is something else.

The Hidden Work of Software Engineering

There is something called the “Doorman Fallacy” - a misconception in which we reduce a hotel doorman’s job to his most obvious function: opening and closing doors.

However, they have many other responsibilities: greeting guests, helping with luggage, calling taxis, recognizing regular guests by name, and ensuring security through their mere presence, deterring unwanted visitors.

Replacing a doorman with an automatic door may seem, at first glance, to significantly reduce costs, but it simply eliminates these additional functions - the absence of which, in the long run, leads to significant and often immeasurable losses.

We’re used to thinking that a developer’s main job is writing code. Sometimes software engineers are even called “coders.” In the days of punch cards and magnetic tapes, coding was much more labor-intensive, and programs were often simpler in design.

Today, however, modern business applications are complex, multi-component systems, and designing their architecture requires many years of practice and training.

A significant portion of engineering work revolves around writing code and often goes unnoticed:

• Requirements clarification, edge case analysis, and failure scenario discovery.
• Identifying technical constraints and limitations, and making architectural decisions.
• Identifying dependencies between components and teams.
• Continuously analyzing the overall state of the solution to understand when it needs to be modernized.

Often, this work has never been formalized and is carried out directly during implementation. AI automates code writing, but it does not eliminate the need for such solutions.

The Less Obvious Shift: Upstream

Now the machine handles the entire end-to-end implementation. However, all the related activities that an engineer used to perform during the development process haven’t gone away.

And we have two options.

1. We can pretend these activities never existed. In this case, the agent will attempt to fill in the gaps on its own and make decisions for which it often lacks the necessary context and knowledge. As a result, these decisions trickle down - in the form of errors and suboptimal architectural solutions - which the engineer will then have to identify and fix.
2. Move these activities upstream. The second, less obvious alternative is to move this work to where it logically belongs: discovery, refinement, and solution design.

It’s important to emphasize here that this isn’t simply about the need to describe detailed requirements for agents in advance. No, it’s a much more complex process that includes:

Making product and architectural decisions.

• Technical research.
• Identifying dependencies and logical relationships.
• Detecting flaws in the initial requirements.

It is precisely the act of making technical decisions that has always been one of the main tasks of a software engineer.

Shift Left as an Opportunity

Thus, a truly large volume of work is shifted to the left rather than automatically replaced by an agent-based system. However, this isn’t necessarily bad news.

In the past, many technical and product-related issues weren’t discussed sufficiently during the solution-shaping phase - either due to a lack of information or simply because these decisions could be postponed. And often, responsibility for them was shifted from the product owner or architect to the developers.

This led to development stalling midway when technical limitations or dependencies on other teams and external APIs were discovered. Furthermore, discovery during the development process often resulted in additional rework.

Now, however, there is an opportunity to address these issues earlier:

• Identify dependencies even before implementation begins and coordinate them with other teams to better synchronize delivery.
• Detect technical limitations, allowing us to immediately discard tasks that are unfeasible or too costly.
• Reduce the rework rate and the need for late-stage requirement adjustments, thereby relieving pressure on downstream processes, especially bottlenecks such as code reviews.

In addition, architectural and engineering decisions themselves become clearer and more deliberate. At the same time, the engineer’s domain knowledge and technical maturity are not replaced by the agent during the coding process but are fully utilized when making complex, well-thought-out decisions.

Engineering Doesn’t Disappear. It Moves.

Thus, AI does not replace developers or eliminate engineering work. However, it allows for the automation of the most routine aspects of the work and provides engineers with information in an aggregated and synthesized form that is useful for making complex technical and product decisions.

A well-thought-out, systematic approach to this process relieves downstream teams of unnecessary work that requires significant cognitive effort from engineers, while allowing them to apply their domain and technical expertise where it will have the greatest impact.

And the role of the software engineer is evolving into that of a product engineer - a person with deep technical understanding who makes decisions at the intersection of technology and business requirements.