Estimated reading time: 8 minutes

Key takeaways:

• AI amplifies your existing foundations… both good and bad.
• Your teams have adapted before and AI-coding agents are just the next step.
• Productivity evidence is mixed: METR found experienced developers 19% slower with AI.

---

I can’t remember a time where a single topic dominated the conversations I have in companies and at conferences the way AI does right now. 

I’m old enough to have been through a lot of technology hype cycles, and while attempts to make everything about the blockchain left me cold (largely because they seemed like a solution in search of a problem) this is different. It seems pretty clear that the way we do software engineering is fundamentally changing as we adopt AI-coding tools.

We are right in the middle of this shift… and it’s both confusing and challenging. Within the space of a year we’ve gone from prompt engineering, context engineering, and harness engineering to exploring Ralph Wiggum loops (feeding an agent its own output and the original prompt, over and over, until the tests pass) and dark factories (where agents write and ship code that no human reviews).

I’m concerned that it’s become too easy for engineers to dress for yesterday’s weather, meaning the tools add new features and your carefully crafted context that was cutting edge a few months ago may now be holding you back.

Helping engineering leaders keep up with all of this is a big part of what I’ll be doing at LeadDev.

Who am I?

I’m Sarah Wells, and I’ve just joined LeadDev as Editor at Large. I’m an engineering leader, consultant, author, and speaker. These days I work independently on platform engineering and engineering governance, including how organizations adopt AI safely.

That work gives me a particular lens. When I wrote Enabling Microservice Success, AI-coding agents weren’t on my radar. The book is about what allows teams to move fast without breaking things: paved paths, guardrails, tests you can trust, teams who own what they run, and governance that stays out of the way.

Those turn out to be exactly what you need when agents are writing a growing share of the code. DORA’s 2025 research makes a similar point: AI amplifies whatever strengths and weaknesses an organization already has. The foundations matter more now, not less.

Taking over The Shift

One of the first things I’m doing is taking over The Shift, LeadDev’s Substack newsletter for engineering leaders navigating the AI-driven transformation of software development, created earlier this year by Scott Carey.

Scott has moved on to DX as managing editor, and I want to thank him for building something so many people read. I’m now looking forward to working alongside LeadDev’s current managing editor, Michael Hill.

The Shift will continue doing what it was built to do. My aim is to bring you news from the frontline: what I’m hearing from the engineering leaders and practitioners I talk to, the best writing and research I come across, and my take on what it means for how you lead. There will be one change: it’s going to be fortnightly rather than weekly.

I also want to step back from the week-to-week news now and then, and dig into specific questions for engineering leaders. Is the pull request review dead? How do we support junior engineers? When should we use AI in our writing, and when shouldn’t we? Those questions will clearly be shaped by the news, but the aim is to look wider than the latest headlines.

I expect my views to change as new tools and approaches appear, and as I learn more and realize what I’ve been missing.

A big, fast change… but we’ve handled that before

I recently came across John Allsopp’s essay applying Thomas Kuhn’s The Structure of Scientific Revolutions to AI-assisted software development. (I studied the history and philosophy of science at university, so this is right in my area of interest.)

Allsopp argues that this is a paradigm shift, and that it’s following Kuhn’s pattern: new paradigms are resisted, not by fools, but by the most accomplished practitioners of the old one because their expertise rests on the assumptions being displaced. Max Planck put it more bleakly: new theories win not by convincing their opponents, but because those opponents eventually die.

However, Allsopp doesn’t stop at resistance. He also points to deeply experienced engineers who have embraced the change, like Simon Willison and Armin Ronacher, the creator of Flask, who moved from sceptic to advocate by continuing to engage with the tools. In Allsopp’s words, they are “existence proofs that the funeral isn’t the only way forward.”

Those positive examples are the part of Allsopp’s piece I agree with most, because they match what I’m seeing. Among people I respect in our industry, adapting is far more common than resisting. Where there is pushback, it tends to come from people whose focus is the craft of writing code, rather than software engineering as a whole. That echoes Gergely Orosz’s builders, shippers and coasters.

I think that’s because changing how we work is what we do. We moved from assembly language up through generation after generation of programming languages, each one letting us express what we want at a higher level. Coding agents are the next step on that path: a bigger step, but still a step.

We went from detailed specifications, upfront designs, and thorough user acceptance testing to agile, fast feedback loops, and automated tests. Many of us now use observability in production to catch the issues no test anticipated. We adopted DevOps, microservices, and serverless. We do this stuff… but that doesn’t mean it’s easy!

Why this matters

Your teams have changed how they work many times before, and it’s worth reminding them of that. They have the ability to adapt to change, but most teams contain people who are finding it hard.

These include thoughtful engineers who feel their professional identity eroding and early adopters still working the way that suited last year’s tools. 

5 things exciting me right now

Why are some orgs so much more successful with AI?

Nearly everyone is using AI now (90% of DORA’s 2025 respondents in fact), so why are some people and teams getting far more out of it? DORA’s AI Capabilities Model is a good start. I want to know what the software engineering lifecycle looks like, and what teams look like, where it’s working.

AI and cybersecurity

Less the headline hacks, although they are fascinating: an independent investigation has pieced together how a swarm of around 700 OpenAI agents escaped their evaluation environment and hacked Hugging Face in July.

What worries me more is the sheer ease of finding and exploiting a vulnerability, which was the big story of Scott’s first The Shift issue back in April this year. If you don’t know what’s in your estate, and you can’t upgrade rapidly, you are in trouble.

Keeping the human connection

Teams are getting smaller, and engineers are increasingly working with their agents rather than with each other. Working together was never just about producing code. It was how context spread, how juniors learned, and where someone pushed back on your assumptions. I’m not sure we’ve replaced it. 

Another way we connect is through our communication. Too much of this now is largely written (and read) by the agent and not the human.

Where are we OK using AI in our writing, and where really shouldn’t we? I loved  Charity Majors series on Honeycomb’s AI norms and values, particularly the third part that included a useful categorization of types of communication: personal opinions, professional opinions, prose artifacts, and code. The first two of these need to be human, not agent-written.

I’m seeing lots of thought in this area at the moment, including Vanta’s AI writing policy as shared by Ian Spain and, from earlier this year, Camille Fournier’s guidelines for respectful use of AI. I do think we’ll develop much more of a consensus about how to communicate the level of AI used and where to avoid it completely in our writing.

Who will actually be building with these tools?

There’s a popular idea that soon everyone will be building their own apps. I’m not convinced. Agents can write the code, but someone still has to break a problem down into the steps a system needs to follow, and not everyone thinks that way.

In many teams there’s one person with an elaborate Excel sheet that quietly drives part of the business. That’s who I expect to become the citizen coder, building the small tools and automations their colleagues come to rely on.

That raises questions we’ve had to answer before, with spreadsheets and low-code tools: who supports these things, who secures them, and what happens when the person who built them moves on?

Clearer evidence for productivity gains

Products are adding AI features all over the place, and people are writing about the impact on their velocity, but the research picture is much messier. METR’s 2025 study found experienced open-source developers were 19% slower with AI. However, when METR tried to repeat it, too many developers refused to work without AI for the results to be reliable.

Meanwhile, a Harvard study of 718 firms found AI agents increased coding activity, but not the amount of work that actually shipped, partly because code review became the bottleneck.

So what’s the reality? Are these studies just finding the median and, actually, some organizations are flying while others are getting bogged down?

Over to you!

I’d love to hear what you’re seeing in your own organizations, and which of these questions you want me to dig into first. You can reach me on LinkedIn.

If you’d like my take every fortnight, subscribe to The Shift.

Thanks for reading!