You're spending thousands of dollars a month on AI tools for your developers. What are you getting for it?
Your developers may be writing code faster. Good. That gives them more capacity. Now you have to decide what the team should do with it.
You can put that capacity into features and into improvements to the system the team uses to deliver them.
The development system is a product
The way I look at it, your engineering team has two products. There's the software you sell, and there's the system your developers use to build it. The developers are the users of that second product. The business is the customer paying for it. I'd want to know where that system is giving the developers trouble and what we're going to do about it.
The development system determines how an agreed priority becomes working software. It includes the tools people use to build it and the rules that tell them when a change is ready to release. AI agents work within that system too, with instructions about what they can change and checks on their work. Somebody designed all of that, or the team accumulated it over time and now everybody has to work with it.
So give the development system the same kind of attention you'd give a product.
Find out where its users are having problems. Decide which problems are worth solving. Give somebody responsibility for the improvements, put them in a backlog, and check whether the changes worked.
Build capabilities the team can reuse
That includes deciding how AI fits into the work. Somebody has to determine what information an agent needs, what it's allowed to change, and when a person needs to review its work. Then the team has to maintain those decisions as the software and the tools change.
A developer with a coding agent has more ways to do that work. The agent can also help the developer build better tools for the rest of the team.
They are building the machine that builds the machine.
Suppose the team adds an AI review to catch problems before a human reviewer gets involved. Okay, does it help? Are changes spending less time waiting for review? How much work still comes back for correction, and are more defects getting through? You also have to count the work to set it up and keep that review useful. That's how I'd judge whether we've recovered any capacity.
Allocate capacity for the full engineering workload
If a developer can produce code faster, maybe you can run with one product manager, one designer, and one developer. I can see why that sounds attractive. But I'd want to know what that developer is responsible for. They still have to keep the product running and improve the system everyone uses to build it. How much time does that take? You need to count that work before deciding how small the team can be.
How much of the team's capacity will you put into improving the development system? What product work are you willing to delay while they do it? Who is accountable for choosing improvements and showing that they helped?
Start with a delivery problem you can recognize. The team might be losing time waiting for review, or spending hours doing manual work for each release.
If the team is already fully committed to the next release, where is the time for this supposed to come from? You have to decide which product work can wait. I'd ask the engineering leader what improvement they're proposing, what it will take to build and maintain, and why it's worth delaying that work.
Measure the return on each improvement
Then agree on how you'll judge the result. Did planned work reach customers sooner? How much time went into fixing things afterward? Once you account for the work to keep the improvement running, how much capacity did the team recover?
A useful change can benefit subsequent releases. You can use some of the recovered capacity for product work and some for the next improvement to the development system.
If the improvement costs more to maintain than the capacity it recovers, you need to reconsider it. If it helps, the team can use what it learned to choose the next investment.
The team still needs good product priorities. You want that improved delivery capacity spent on software customers need.
So when your engineering leader asks for more AI investment, ask which improvement to the development system they're proposing, how they'll make it happen, and what business result they expect.
If you'd like help examining that system and deciding where to invest, let me know. That's work we do with software companies.