Every retail technology function has a backlog of small, valuable work that never reaches the top of the list. AI tooling changes the economics of that work, but only if you are honest about what it speeds up.
Ask why the backlog exists and the answer is always headcount. Add two engineers and it would clear.
Look at what is actually in it and a different picture appears. The items are small. A merchandising report nobody has time to automate. A data fix that takes a day but requires context three people have. An integration between two systems that both teams want and neither owns. A performance issue everyone has learned to live with.
These do not sit there because the team is too small. They sit there because each one carries a fixed overhead that dwarfs the work itself. Understanding an unfamiliar area of the codebase. Finding out why it was built that way. Writing the tests. Getting a review from the one person who knows the domain. For a two-day task, that overhead can be a week, which is why the two-day task never gets picked up over the feature with a launch date.
That is the thing AI tooling actually attacks. Not the typing, the context acquisition.
Reading unfamiliar code. The largest and least discussed win. An engineer dropped into a codebase they have never seen can get a working understanding of a subsystem in an afternoon rather than a fortnight. For backlog work, which is nearly always in an area the available engineer does not know, this is the whole game.
The first draft. Not perfect, rarely shippable as-is, but a starting point that removes the blank-page cost and usually gets the structure right. Reviewing and correcting a draft is faster than writing from nothing, particularly for well-trodden patterns.
Tests. Comprehensive test coverage is the classic casualty of time pressure on small tasks. Generated tests, reviewed by the engineer, close that gap cheaply and make the change safe to ship.
Review depth. Automated review on every pull request catches the routine issues before a human looks, so human review time goes to design and correctness rather than style and obvious bugs. On a team where review latency is the bottleneck, this alone can change throughput.
Routine fixes from monitoring. Performance tooling identifies a slow query or an inefficient path, and the fix for a large share of those is mechanical. Turning a monitoring finding into a proposed change, with the evidence attached, converts a class of work that nobody schedules into a queue of small reviewable changes.
Being straight about the limits is what makes the rest credible.
It does not know why your business works the way it does. The rule that looks like a bug is often a hard-won accommodation of a supplier, a regulation, or a legacy migration. Only your people know that, and the fastest way to break production is to let someone confidently tidy up a rule they do not understand.
It does not remove the need for review. Volume of change goes up, which means review capacity becomes the new constraint. If review does not scale with it, quality falls and the gains evaporate in incident time.
It does not resolve prioritisation. A team that can now do three times the work will simply do three times as much of the wrong work if nobody decides what matters.
And it does not fix an architecture that makes every change dangerous. If a small edit requires touching four services and a manual deployment, tooling speeds up the smallest part of the problem.
The model that works is deliberately small. One or two engineers who work this way already, embedded with the existing team for a few weeks, pointed at a visible slice of the backlog.
Week one is selection and context. Pick items that are genuinely wanted, independently shippable, and low blast radius. Avoid anything on the critical path of a launch. The point is throughput and demonstration, not heroics.
Weeks two and three are delivery, in the open, using the team's own repositories, review process and deployment path. Not a side project in a separate environment. If it does not go through the normal pipeline, it proves nothing about how the team will work afterwards.
The final week is transfer. The team's own engineers drive, with the embedded pair reviewing. This is where capability actually moves, and it is the part most often skipped.
What comes out is a measurably shorter backlog, plus something more durable: a group of engineers who have watched the workflow up close on their own codebase, with their own constraints, rather than in a training exercise on a toy repository.
Lines of code and number of pull requests are worse than useless here, because the tooling inflates both by construction.
Measure cycle time from ready to deployed, because that captures whether the whole path improved rather than just the writing. Measure the age profile of the backlog, since the value is in old items finally shipping, not new ones arriving faster. Measure change failure rate before and after, because throughput gains that come with more incidents are a loss. And measure review latency, which is where the new bottleneck usually forms.
If cycle time falls, old items clear, and failure rate holds steady or improves, the change is real. If throughput rises and failure rate rises with it, you have bought speed with quality, which is the same false economy as cutting service to cut cost.
For a technology function under pressure to show progress on AI, this is an unusually safe place to start. The value is visible to other departments within weeks, because the things clearing the backlog are things those departments asked for. The risk is contained. The learning is genuine, since your engineers use the tooling on real work rather than hearing about it. And it produces internal advocates, which matters more than any pilot result when the larger programme starts.
It also answers the question every board asks eventually, which is whether AI does anything for the business rather than for the demo. A shorter backlog and faster delivery of work the business was already waiting for is an answer anyone can understand.
We embed engineers alongside your product team for a few weeks, clear a visible slice, and leave your developers working the same way.