Ready for Agentic coding tools?

by Michael Heß, Area Manager Software Development

Agentic coding tools amplify all the problems and risks associated with software development using GenAI exponentially.

Evidence of today’s problems can be found in part 1 of the GenAI series of articles. This follow-up article looks to the future. Basic assumption: In the next 24 to 36 months, agentic coding tools will not replace teams, but they will force us to rethink the way we specify, verify, measure and organise ourselves. Those who focus on the right issues today will be able to seize great opportunities in the future.

We will examine the path ahead based on five perspectives that reflect the current state of research: people, organisation, technology, measurement and opportunities. We hope that you will gain clear, evidence-based insights into how you can benefit from agent-based coding tools.

Agent-based AI has the potential to transform the way organisations develop and deploy software. The challenge lies not in introducing faster tools, but in adapting workflows, roles and guardrails to ensure that increased productivity does not lead to a loss of coherence.

How will teams change when agentic coding tools significantly increase productivity?

Automation shifts bottlenecks, it does not eliminate them. Possible candidates to watch out for as new bottlenecks:

Agents are still confined to clearly defined boundaries, typically in the form of containerised environments. This suggests that effective autonomy is limited to systems and does not extend freely across stacks. But what happens when these boundaries begin to blur? For example, what happens when agents request or implement changes across services? A direct agent-to-agent escalation path?

The human dimension of software development is evolving. As AI systems evolve from assistant co-pilots to autonomous agents, the role of developers is shifting from execution to control. The DORA data for 2025 already reflects this change: although developers report higher perceived productivity and better flow, objective delivery metrics remain unchanged. This shows a pattern of feeling faster while system throughput stagnates, suggesting increased systemic friction and cognitive overhead. This paradox signals a profound change: productivity is no longer (or even less) a function of individual speed, but of system throughput and orchestration capability. As AI becomes more autonomous, this tension will only increase.

Current research on promptable systems and agent-based workflows describes a decisive shift: developers are shifting their focus from writing code to expressing intent. Instead of mastering syntax, the crucial skill is articulating what success looks like, under what constraints it is achieved, and within what boundaries it is executed.

This transformation is similar to the transition from “AI-assisted coding” to “agent-based engineering”: instead of offering solutions, engineers now design missions for autonomous agents to execute and verify.

To succeed in this new landscape, teams must develop cognitive skills such as clarity in goal formulation and effective communication with non-human collaborators. In this emerging discipline, the ability to specify intentions clearly and verifiably will determine excellence in engineering – think, for example, of the buzzword “spec-driven development”.

Based on the hypothesis that agents will take over a significant portion of the work, research findings point to the development of new roles. These roles have not yet proven themselves in reality, but they provide an indication of what to look out for, similar to how the role of “prompt engineer” signalled that a new skill had become important. Notable roles include:

Continuing education does not mean taking a course in “prompt engineering.” It means developing a broader range of competencies, including AI literacy, data analysis, and systemic thinking. AI literacy, in particular, is becoming increasingly important. Understanding the limitations of models, probabilistic behaviour and biases is now an integral part of core software engineering practice. Sustainable and effective collaboration with agents depends on a shared conceptual model between humans and machines – a model based on transparency rather than blind trust.

Teams that integrate agentic coding tools face new cognitive risks, such as unclear authorship, verification fatigue and shifting responsibility. Psychological safety remains an important factor, especially in times of change and disruption to established patterns. This has been a criterion for success for teams in the past and is likely to remain just as important.

There is no formal, verified definition of “promptability.” In a world where people use systems less and agents use them more, the usability of machines is the central issue: Can a machine figure out what your system does, access it securely, observe the effects, and prove the results without custom integration? In this context, promptability is a buzzword that summarises the concept of machine usability across APIs, documentation, data contracts and runtime signals in the short term. Its implications are more practical than philosophical; it largely determines how well agents will function in your environment.

Put people at the centre of the process. Current research uses terms such as “evaluation harness” and “merge readiness package” to enable this. Interpret these as guidelines, not instructions. An “evaluation harness” means that the results of agents should be evaluated based on reproducible and verifiable evidence, not narrative claims. A merge readiness package means that reviewers should be provided with a clear evidence package that makes the intent, changes, and results clear at a glance. Neither term prescribes specific tools or rituals; both refer to the same goal: reducing cognitive load, bringing critical aspects into sharper focus, and empowering people to decide for themselves when to ask questions, when to proceed, and when to escalate. What constitutes “sufficient evidence” depends on the specific area, risk tolerance, and maturity of the stack, and will continue to evolve. The goal is not to standardise people, but to create clarity in areas where decisions add the most value.

It is not a silver bullet, but continuous integration is the place where rapid, machine-generated changes can be reviewed, corrected and mitigated. The biggest risks associated with LLM code generation are well known and are exacerbated by agent-based tools, including code inflation, technical debt, verification and integration bottlenecks, and security risks. CI is where these risks become visible and manageable. To benefit from higher throughput, the level of automation in CI must be increased. This requires more automated checks, clearer evidence, and faster feedback so that employees can focus on judgement rather than reconstruction. A practical point to note is that this does not happen by accident. The enabling and platform teams that provide small product teams with ready-to-use CI configurations, standards, and support are a silent success factor.

Teams often report faster progress with AI, while the objective parameters of project progress remain unchanged or decline. In an agent-oriented future, this discrepancy is likely to increase. The consequence is clear: a data-driven, results-oriented view of productivity will be imperative. It is not about measuring the activities of AI (or humans), but about determining whether value flows through the system faster, more securely and more reliably.
The lead time for changes, deployment frequency, change failure rate and MTTR, as defined in the DORA report, remain the true indicators of performance. Keep an eye on these metrics to determine whether autonomy improves flow and stability, not just local speed. Build a strategy around this core to identify hidden problems such as repeated bug-fixing patterns, code duplication, refactoring, keeping dependencies up to date, and dead code removal. Indicators for these show whether increased speed is causing technical debt.

Token prices may seem low today, but providers are changing their rates and features, so be aware that prices will change, especially as the cost of expanding data centres will eventually catch up with reality. In addition to the tokens, there are many additional costs associated with this change. The real question is not what tokens cost, but what they bring you.
In an agent-based future, activity will explode as agents will need to conduct more experiments or perform more iterations to achieve the right result. The temptation to interpret “more tokens” as “more progress” will become stronger. Resist this temptation. What matters is transformation: intentions into evidence, evidence into decisions, decisions into lasting change. Prices will move; autonomy will rise and fall with use cases. What do you get for your money?

Accept that measurement lags behind. There are no peer-reviewed substitutes or additions to the DORA metrics. There are also no validated metrics for promptability, automability, API agent friendliness, agent-specific DevOps outcomes, or success criteria for autonomous change. Organisations moving towards agent-based workflows will have to operate partially blind if they do not expand today’s measurements. The pragmatic approach is to retain DORA as a foundation and incorporate indicators for cost, quality, and evidence. Agentic coding tools have the potential to increase throughput. Only cost-conscious measurement at the system level will show whether this speed has been converted into reliable delivery and has not led to longer queues, greater variability, and more costly failures.

Agentic coding tools have great potential, but they can also exacerbate existing problems. By changing the way we specify, verify, measure and organise things, we can achieve more with the same number of employees. We can also develop products that previously did not have a viable business case.

Projects that were previously considered unimportant, such as internal tools, data cleansing, niche integrations, and custom reports, can become economically viable. The same effect applies to the modernisation of legacy systems: once contracts are explicit and test oracles exist, agents can work on migrations, documentation and refactorings that would never have been prioritised in a queue handled exclusively by humans.

In addition, research is faster. With a promptable architecture, teams can conduct more experiments per week, such as alternative algorithms, UI variations, and infrastructure configurations, without having to commit to extensive reprogramming. In terms of the product, this means more validated learning and fewer speculative epics.

In terms of personnel, work shifts towards activities with greater leverage. Software engineers spend less time on boilerplates and more time formulating problems, designing interfaces, and making trade-offs explicit. Agents can create initial versions that can then be refined by experienced staff, rather than recreating them from scratch. This is not a replacement per se, but a different division of labour that preserves human judgement. Be prepared for these changes.

At the organisational level, the opportunity lies in smaller, leaner, high-impact teams that coordinate in new ways and reduce the complexity that inevitably comes with the exponential growth of communication channels. Take a moment to think about the best product owner, engineer, and QA you’ve ever met, and imagine what these three people could achieve together.

The path will not be easy. However, the goal is worth striving for: more value creation, fewer delays and greater security. If we learn to use agentic coding tools effectively by changing not only the tools we use but also the way we work, we can achieve things that were previously impossible.