Ask an engineering team using AI how it’s going and you’ll hear about speed. Features that took months now take weeks. Ask where the review queue is, and the tone changes.
I run an online webinar series for engineering leaders, bringing a small group together at a time to talk honestly about what AI is doing to their teams. In one recent session, a single phrase landed so hard that two other people stopped to say it described their team exactly. The phrase was shift right.
Faster at the start, stuck at the end
A technical lead from a large public sector organisation used it first. He’d been running trials, and the pattern was clear. “In the effort of doing everything faster using the agent, we’ve shifted everything to the right,” he said. Code arrives quickly, then sits in review, where someone has to work out whether it does what was intended. His question was one plenty of teams are quietly asking: are we stuck in an endless loop of PRs that we have to keep going over before we can move on?
The head of engineering at a creative agency recognised it straight away. It was the first time he’d heard the phrase, and he said it captured the pattern his team finds itself in. Everything moves right, so the first time anyone really sees the code is when it lands for review.
An engineering manager at a fast-growing start-up described the same thing from the inside. Her agents raise PRs while they work on something else, spot other things to fix along the way, and raise PRs for those too. PRs stack on top of PRs. Her hardest daily call is deciding what is safe to hand to an agent and what has to stay with a person.
Why shifting right is an anti-pattern
Shifting right doesn’t remove risk. It moves it onto whoever sits at the end of the line, usually the people with the least time and the most to check.
“The last thing you want to do is shift all the responsibility to the end,” the technical lead said. “The whole point is to shift it all the way to the left so that the risk is reduced.”
The human cost shows up fast. The start-up engineering manager sees engineers who are genuinely productive for a few hours a day, then worn down by reading agent output and holding too many contexts at once. In her words, the cognitive load of working with the system is, in a sense, slowing the team down. The agency head put numbers on the pressure: with five or six sessions running, you still have to review the code and step in when a requirement is unclear. The demand on people, he said, is considerable.
The head of engineering at a digital marketing business made the sharpest point. His team wants AI doing more and getting things through faster, and he still has to keep multiple people in the loop to make sure nothing strange slips through. “AI is just highlighting weaknesses in the controls you have quicker,” he said. If your review process was thin before, AI doesn’t create the problem. It finds it faster.
What shifting left actually looks like
Nobody on the webinar thinks the answer is to slow AI down. They described moving the effort earlier instead.
The technical lead pointed to an acceptance test driven approach, with clear rules set for the model up front, so the work is built iteratively rather than handed over in one lump at the end. Review doesn’t disappear, but it stops being the first moment anyone checks anything.
The agency head said his team uses AI right from the start of the pipeline, helping to scope requirements, not only to write the code. He also leans hard on the old disciplines: static analysis, test coverage, clean code principles. His reasoning is simple. You never want a codebase that only an agent has the bandwidth to decode. Anyone should be able to open it and read it.
Then there’s the “why”. The digital marketing head put it neatly: AI will happily tell you why it made a choice, but it can’t tell you why it was told to do something. That part is human, and it has to be captured early. The start-up engineering manager is working on exactly that, trying to keep a trail of the decisions behind the system so whoever picks up the work later, person or agent, has the reasoning to hand.
The workforce planning question underneath
If the pressure lands at the end of the line, that’s where your capability has to be. Most plans I see still count the people who write code. Far fewer count the people with the judgement to review it.
The digital marketing head said it plainly: the software developer role is turning into much more of a management role, directing very junior workers and checking what comes back. That changes who you need, what you train them in, and where you can least afford to run thin. It’s the kind of shift we keep coming back to in Beyond Headcount: plan around the capability you need, not the seats you fill.
Who this is for
I’m putting these webinars together for engineering leaders who are actually in it, running teams that are adopting AI, wrestling with what to trust it with, and figuring out what it costs when nobody’s watching. If that’s you, and you’d find it useful to compare notes with others facing the same thing, I’d genuinely like you there.
If you’re interested in being at the next online webinar, reach out to me.