Request Demo

How AI Is Changing Software Development Part 2 -
The CTO´s Perspective

In the second part of our series, CPTO Dominik Kowol shares his perspective on how Agentic Coding is changing the way software teams work. He explores how bottlenecks are shifting across product organizations and why product understanding, quality assurance and sound decision-making are becoming increasingly important.

Why Developers Are No Longer the Bottleneck


For many years, development capacity has been one of the key limiting factors in software companies. Product ideas were usually generated faster than teams had time to implement them. Roadmaps had to be prioritized, features postponed, and customer requests put on hold simply because there was not enough development capacity. So far, nothing new. What is clear, however, is that we are now on the verge of solving this bottleneck. As a result, the bottleneck will inevitably shift. And initially, it does not matter whether agentic coding increases a developer’s productivity by 20% or 100%. As soon as development becomes faster than the rest of the organization, bottlenecks emerge elsewhere. This raises the question of which functions within a product organization need to keep pace with the additional development output.

At the very beginning of the value chain is, of course, requirements engineering. The faster development becomes, the more important sufficiently precise requirements will be. In the future, Product Owners will therefore likely focus more strongly on product strategy, roadmaps, and prioritization. The detailed elaboration of individual requirements, on the other hand, will increasingly have to take place within the development teams themselves. Developers know the architecture, understand the technical implications of a requirement, and already have tools that can help prepare specifications, user stories, or acceptance criteria. As a result, some of the detailed functional work is shifting closer to development.

I see a similar development in technical writing. Agents can already generate technical documentation and release notes from commits, pull requests, or tickets. This does not mean that the role of the technical writer will disappear. It will change, however. Instead of creating content entirely from scratch, the role will increasingly involve structuring and validating information and preparing it for different target audiences. The actual writing process will become increasingly automated.

This development is even more apparent in quality assurance. Here too, agents are already supporting the creation of test cases, test scripts, and automated regression tests. Nevertheless, responsibility for quality remains with human QA engineers. Developers will therefore need to support them more in the future by describing which areas of a system are affected by their changes and which tests result from them – essentially as part of the handover to the next responsible function. Otherwise, the next bottleneck will simply emerge there.

This is particularly important because every new feature still needs to be understood and tested by a human at least once before the benefits of automation can take effect. As development becomes faster through agents, the amount of new functionality will automatically increase, while available testing capacity often does not grow at the same pace.

For many companies, this will have organizational consequences. One possible approach is to shift more testing responsibility back into development teams: In the future, developers will likely spend a greater share of their time on reviews, test design, and test execution. Paradoxically, agentic coding could therefore mean that developers spend less time creating new features than originally expected, because the additional capacity is absorbed by these new responsibilities.

This needs to be actively managed. At eperi, we are therefore specifically considering how developers can become more involved in feature design, documentation, and testing in the future, helping to prevent bottlenecks elsewhere – potentially at the cost of lower satisfaction with their own feature output. The alternative would be to add resources in product management and quality assurance while reducing headcount in software development to remain cost-neutral.

Because the scarce resource of the future will no longer be development capacity. It will be product understanding, quality awareness, and – above all – good decision-making.

In the third part of this series, I want to take this thought one step further. If more features are being created than ever before, the inevitable question is how products can remain understandable, maintainable, and successful in the long term – above all, in terms of the value they deliver to customers.

Did you like this article?


Then like it now or share it with colleagues, business partners, and friends.

Email
Facebook
LinkedIn
X

Knowledge that protects – your next step toward greater data security

On our download page, you will find free white papers and fact sheets on data protection, data encryption, and compliance – specifically for IT managers and decision-makers.

Get concise knowledge, strategic recommendations, and practical tips to effectively protect your data and securely comply with regulatory requirements such as GDPR, NIS2, and DORA.