The Reinvention Of The Dev Team

I don’t need to tell you that AI has changed software development forever. You know this. Whether you’re positive, negative or indifferent to this change, you can’t deny that the past 2 years have radically changed the role of the software developer.

Just a few years ago I would have advocated for The Balanced Team. A Product Manager, a Product Designer, an Engineering Manager and 4-8 Developers. It worked.

18 months ago I was telling people that “I’ve never seen a dev team get to the end of their backlog, I don’t see that happening”. I’ve seen it now. Actually, I’ve seen it more than once.

The balanced team as we knew it doesn’t work any more.

How do we figure out the new normal? How do we regain our balance?

Agentic coding is the new normal

Cursor published this insight back in February 2026 calling it The Third Era Of AI software Development. They observed the shift first hand. On their coding platform Agent requests exceed tab accepts.

Working with AI native startups I’ve personally observed the difference in velocity, but I’ve also observed some of the new challenges this speed brings with it.

• Feature development exceeding the speed of decision making
• Feature bloat and degraded user experience
• Ownership and support of AI generated systems in production

As a profession we have been obsessed with velocity. Writing code was the bottleneck and we organised our teams, processes and practices around that constraint. For decades we have been relentlessly shuffling our backlogs and roadmaps trying to maximise the business impact of our most limited resource, developer time.

The velocity has arrived and many of us don’t know what to do with it.

How do I think about this problem?

I’ve seen enough to believe that The Dev Team needs a rethink. Or maybe a complete reinvention!

When I consider what the future Dev Team might look like I orient my thinking around three anchors. These are things that I believe will remain true no matter how fast or how accurate coding agents become.

• Build something worth building
• Speed requires safety
• People matter

I’ll be diving into each of these areas in detail at AI DevCon on 1-2 June. Below I’ve described some of the topics I’ll be covering on the day!

Build something worth building

Keeping developers busy isn’t the point. We must make sure everyone on the team is adding value to our organisation.

Enshittification is a thing and we don’t serve our users well by stuffing our product full of new features that seemed like a good idea but no one really needed.

In most organisations it is a product owner or product manager that decides what to build, but we’re seeing an increasing amount of teams experience backpressure from developers where the product person simply can’t keep up. The backlog that was once relentlessly prioritised is not populated with enough of the right quality of qualified work to deliver the maximum value.

If and when you find yourself in that situation here are a few things to try:

• Adjust the ratio of product managers to developers
• Inform decision making with real working prototypes
• Forward deployed engineers working side by side with customers
• Product engineers who are empowered to make product decisions (this one works really well if you’re building products for developers!)

Speed requires safety

Think about your path to production. How long does it take for a small change to travel from the developers machine into the hands of your users? Are there manual steps along the way? What processes and practices do you use to make sure you haven’t accidentally broken something?

Now imagine it’s not a single small change, instead it’s thousands of lines of AI generated code. Larger changes and a lot more of them! Does your path to production still work or are you going to end up with a code pileup at the next process bottleneck?

And importantly, how do we make sure every change is safe? How do we make sure that we’re not impacting availability or security?

Your customers will never ask you to deliver a reliable product, they just expect it. They won’t ask you about security either, but your reputation will be ruined forever if you get hacked.

For me there is no compromise, to go fast we must go safely. These practices aren’t new but they aren’t universally adopted. Now is the moment to invest in your path to production.

• Progressive delivery practices such as blue / green deployments and feature flags
• Adopt SRE standards like SLIs, SLO and Error Budgets to continuously monitor your reliability, ensuring user needs are met
• Address that tech debt (Coding agents are great at this by the way)
• Automate those tests (Coding agents are great at this too)
• Identify and eliminate the manual repetitive work or toil (Coding agents have a role to play here too)

If your dev team doesn’t have enough feature work to keep them busy (for reasons discussed above) why not spin up a task force to address your path to production, tech debt or testing coverage. The balance of engineering teams could well shift away from product and more towards platform, SRE, devops and security work as these bottlenecks emerge.

Maybe we don’t need more capacity to deliver features. Maybe we need more people solving the bottlenecks and eliminating risk.

This doesn’t need a reorg, you could try it out within your current team.

People matter

I’ve always been That Woman. The one who shows up to tech conferences and advocates for the people in tech. Nothing has changed!

The role of a software engineer has completely changed and that’s going to be tough for some people. Being brilliant at code might give you a sense of pride, it might feel like part of your identity. With AI writing the code what’s left for you? And is it any fun?

Three key areas are front of mind for me when I think about the humans wielding the agents

1. Code review
2. On-call
3. Career development

Can we realistically review all the code?

My most controversial opinion is that reviewing code is not fun and it is not sustainable. Having AI do the writing and humans review it line by line doesn’t scale and it’s miserable work.

This is one of the most important challenges teams need to navigate as they adopt agentic coding.

I’ve met teams who are now categorising changes, with some lower risk changes skipping code review. I’ve also seen teams “shift left” the peer review process to make sure design decisions and architecture considerations are articulated by humans and not guessed by an LLM.

Who is holding the pager?

We also need to remember that on-call is still a thing. An AI Agent can’t own a service in production, it can’t hold the pager.

For me this is an immovable constraint in team composition - we need a sustainable on-call rota and it needs to be staffed with people who are informed enough to respond to an incident.

That sets the absolute minimum number of developers in a team to 4 because you need a primary and a secondary responder, and no one can be on call more than 50% of the time.

Supporting a critical service that was authored by AI, that you’ve never looked at, is terrifying. However, having an AI Assistant to support you during an incident is way better than trawling through logs.

It remains to be seen whether we end up with more or less sustainable on-call but if we don’t pay attention we won’t be able to address the new challenges that emerge.

What skills do I need to be successful?

I believe we’re entering an era of generalists instead of specialists. With AI assistants by our side we can more rapidly get up to speed in a new domain, we can experiment faster and we can become reasonably productive in very little time.

Sophie Weston, principal engineer at ClearBank advocates for the “Broken Comb” instead of the T-shaped or Pi-shaped engineering skills profile.

"You need to become a broken comb—someone with expertise in multiple areas and the ability to connect insights across domains."

If you’re an engineering manager you might want to think about these questions:

• Which engineers would be interested in developing product skills?
• Which engineers would be interested in developing context engineering skills?
• Which engineers would be interested in developing platform engineering, SRE, devops or security skills?

There are still many ways to develop your engineering skills in this new age of AI, but we shouldn’t assume that our existing career progression frameworks are suitable for the team and the work we have today.

Experiment, but with empathy

The seismic shift in software is only just getting started. I don’t offer a proven strategy to navigate this change, we are sailing these turbulent waters together.

What I propose is that we go back to fundamentals, refocus on outcomes and evaluate our options for evolving team composition. What are we trying to achieve? What problems are we trying to address?

It is a time for experimentation, but no one wants their career to be a novel experiment. Design your experiments with your team, take them with you, listen to their fears and check in regularly.

Experiment with empathy.