Why AI is relocating engineering work and what leaders need to know

I discussed some of my reflections in a recent article, but below you can find what I see as the key takeaways for business and technology leaders.

What is relocating and why it matters

One clear signal from the retreat is that when AI generates code it doesn’t remove the need for rigor; that need simply moves elsewhere. 

For instance, addressing quality in the future may no longer be an issue of line code reviews but instead one of tiering risk, clarifying specifications and verifying correctness.

This may mean that the type of work software engineers do evolves into something else. During the retreat, the group identified this as work situated in the ‘middle loop’. It was described as ‘supervisory engineering’ in which developers are responsible for orchestrating and governing agentic systems.

Although much of the discussion at the retreat was future-oriented, there was agreement that existing and well-established practices will become even more important. In fact, there appears to be a trend for rediscovering practices like test-driven development, pair programming and trunk-based development. There was a feeling across the group that such practices can help solve some of the challenges — nondeterminism and unpredictability, for instance — of handling code written by agents.

For leadership, then, the lesson should be clear: ensure AI adoption is done with rigor and attention to issues of quality and security. This is borne out in real-world research and data: the 2025 DORA report highlights that AI is an amplifier of both what’s good and bad; success, the report tells us, requires robust foundational engineering practices.

The bottleneck in delivery is changing

Traditional bottlenecks were about engineering capacity. That is shifting. Teams with AI tools are often able to clear backlogs quickly only to encounter bottlenecks in decision making, governance and architectural alignment.

Throughput increases; decision velocity does not. That creates frustration rather than acceleration. This shift means leaders need to look at governance processes and operating rhythms with fresh eyes.

Could productivity and developer experience diverge?

One of the more uncomfortable observations from our discussions was that developer productivity and developer experience may no longer move in the same direction. For a long time, we assumed they were tightly linked. Give engineers better tools, less friction, more autonomy and you get better outcomes; that assumption is now under pressure.

Writing code used to be a primary bottleneck; now, thanks to AI, constraints have moved in two directions:

1. Upstream in decision-making about what we should build and how.
2. Downstream in delivery and operations.

Why this creates a worse experience for developers

From a developer’s perspective, the job starts to feel more fragmented and constrained:

1. Faster creation, slower decisions.

2. More output, more queuing.

3. Increased cognitive load. 

4. System complexity becomes more visible.

5. More governance, poorly integrated.

    

In turn, this raises important questions for leaders.

What needs to change

The response is not to optimize coding further; we need to rebalance the entire system.

1. Optimize for system throughput, not coding speed.
2. Treat decision-making as a first-class engineering problem. 
3. Strengthen both upstream and downstream systems. 

These three things should inform how we approach developer experience in an increasingly agentic world.

An opportunity to embed better governance and security

It's also vital to stress that it is in this area that we have the opportunity to implement governance and security effectively, ensuring they are properly embedded inside engineering context and AI guardrails. 

This goes hand-in-hand with treating decision making as a first-class engineering concern. Together they demand: 

• Clear policies, not ambiguous guidelines.

• Role-based guardrails, not one-size-fits-all controls.

• Automated approvals where risk is low.

• Transparent escalation paths where it is not.

   

Despite the change we’re currently experiencing, we must not forget the fundamental foundations of building safe, secure and resilient systems: the way we think about developer experience should allow developers to take advantage of AI while also enabling long-standing testing practices throughout the SDLC that we know underpin good quality software systems.

Staying in touch with our thinking

Our thinking on these shifts continues to evolve and we share it in several places that may be of interest:

On the subject of sharing knowledge, we’re preparing to publish volume 34 of the Thoughtworks Technology Radar.

We publish the Radar every six months. That might seem like a lot but it's worth it to gain a snapshot of the technologies and practices we're seeing on the ground in our work with clients. This means the Radar provides a considerable level of detail and granularity. It's not a trend report and it's not even about predicting the future; it's a snapshot of what we are seeing now.

Finally, I’d like to flag a new article by my colleagues Danilo Sato and Tiankai Feng. Danilo and Tiankai are both leaders in data and AI — in the piece, they explore the evolution of human and machine collaboration over the last year as agents have been adopted by organizations. The first in a planned series, it’s a useful guide for leaders currently thinking through the opportunities of agentic systems.

All these resources can guide and inform conversations taking place across your organization. Given the rapid pace of change, anticipating the questions likely to matter in the months ahead is valuable: that’s precisely why we share our thinking and experiences with others in the industry. 

If you would like to dive deeper into any of the topics discussed please reach out to us. We would be happy to arrange a workshop or session for you and your team with one of our senior technologists.