Chris is a Global Practice Director for Engineering Excellence at Thoughtworks. He has over 15 years of technology experience across startups and large enterprises, with a significant focus on building scalable engineering teams, engineering metrics strategies, developer platforms, platform engineering, and technical product management. He is a vocal advocate for developer experience and is passionate about using data-driven approaches to improve it.
Chris Westerhold, Global Practice Director at Thoughtworks, joined Ankit Jain, CEO and Co-founder of Aviator, to unpack how the developer experience (DevEx) is evolving in the AI era. From tooling chaos and AI tools adding to cognitive overload, Chris shares candid insights on what’s working, what’s not, and how engineering leaders should rethink their AI strategy.
Developer experience was already a tough topic before AI. Now, the entire definition of what a developer is changing. It's no longer just someone writing code based on stories from a product manager. Now, devs might get a working proof-of-concept, maybe built by a product designer using an AI tool, and the engineer is stepping in to scale or stabilize it.
That’s a huge shift, a whole new way of thinking about software development. And when DevEx is already complex, throwing in all this new AI tooling makes it even more overwhelming, especially for teams trying to onboard or scale.
It feels like every day there’s something new on the market. On one hand, shiny new tools and new ways of working can be exciting for engineers. Then there’s pressure from leadership, what I’d call a bit of FOMO. You see executives thinking: “If we’re not using AI, we’re going to be left behind.”
The biggest anti-pattern I see is focusing on the tools instead of the problems.
What are you trying to improve? Testing? Code generation? Incident management? Start there. If you don't, you’ll make the developer experience worse. Giving them a landscape of 100 tools and wishing them good luck doesn’t solve anything, for devs or the organization.
I see two common paths.
Path one: A company signs a deal with a vendor and mandates its use across the board. But that rarely works well. The pace of change is just too fast for one tool to stay relevant everywhere.
Path two is opening the door for developers to explore and adopt tools organically. Let early adopters try things, discard what doesn’t work, and scale what does. That way, developers get the autonomy to change their workflows, you get better adoption, less central evaluation overhead, and avoid decisions based on personal tool preferences.
There’s a lot of hype about an AI future without software engineers. The reality is that you can’t remove complexity from engineering.
Yes, AI might handle some tasks, but it adds a whole new layer of cognitive load. Developers today might have 50 tabs open, five IDEs running, and 20 tools to keep track of. It’s overwhelming.And we’re not eliminating complexity, we’re just abstracting it. Someone still needs to train agents, monitor infrastructure, manage governance, audit AI decisions… All that complexity still exists, just in a different form. It’s not less work; it’s different work.
There are AI SRE tools that are great at surfacing anomalies, but they often give you 20 potential causes when you just need one. They lack the intuition of a human software engineer who says, “Oh yeah, that API change from last week caused this.”
What developers need is focused answers, not option overload. That’s a major gap right now. We’re in a hype cycle where more data and more signals are seen as better, but they just add to the noise.
The best platforms are the ones that developers barely notice. And that’s where AI should fit in. Not as a dashboard generator, but as a guide that surfaces the right info at the right time.
Many organizations use surveys that ask developers, “How much time did AI save you?” and they’ll give an optimistic answer. When you compare that sentiment with real quantitative data, the numbers don’t add up.People tend to think about personal time savings in isolation: “I finished my PR faster.” That pull request might sit unreviewed for three days before being tested, fail in testing, and bounce back for fixes. The result is inefficiencies across the engineering organization that eat up any productivity gained.
Boards are asking engineering leaders about their ‘AI strategy,’ and I think that’s the wrong question. A better one would be: “What are you doing to improve engineering efficiency by 15–20%?”
You don’t have to chase AI just for AI’s sake. Instead, focus on the biggest pain point, on whatever is slowing your teams down. In most orgs, it has nothing to do with needing faster typers. Fix those, and you’ll see productivity gains, whether AI is part of the solution or not.
The biggest anti-pattern I see is focusing on the tools instead of the problems. What are you trying to improve? Testing? Code generation? Incident management? Start there
.svg)
-1.svg)
00:00 Introduction to Developer Experience and AI
01:12 The Evolution of Developer Experience
04:30 Navigating Tool Proliferation in Software Development
09:35 Cognitive Load and Complexity in AI-Driven Development
18:04 Finding Focused Solutions Amidst AI Hype
20:58 Metrics and Measuring AI Impact
34:06 Developing an AI Strategy for Engineering Teams
Developer experience is evolving rapidly due to AI.
Organizations must focus on solving specific problems with tools.
Cognitive load increases with the proliferation of AI tools.
AI tools can add complexity rather than reduce it.
Metrics should reflect the actual impact of AI on productivity.
The role of software engineers is shifting towards understanding business value.
AI adoption should be strategic, not just driven by FOMO.
Complexity in engineering cannot be removed, only abstracted.
A good platform can reduce cognitive load for developers.
Identifying pain points is crucial for effective AI strategy.
