Stop Buying AI Software Development Tools by Category. Buy Them by Bottleneck

Buy AI software development tools against the place your delivery actually stalls, not against the category a vendor happens to sell. For most teams that place is not typing. It is waiting: the ticket nobody clarified, the pull request sitting four days, the test suite nobody trusts, the release that needs three calendars to line up. A tool that makes the typing faster and leaves the waiting alone changes your invoice, not your ship dates.

Below is a buying framework you can put to use this week: five classes of tool that deserve a line item, their per-seat list price, three costs no pricing page ever shows, and a 30-day trial ending in a yes or a no rather than a renewal nobody questioned.

The gains get absorbed between the boxes

Sketch your delivery lifecycle as six boxes: requirements, design, build, test, release, operate. Nearly every tool on the market goes after one of them, and usually it is the same one. Build.

Now look at where the hours actually go. A developer waits on product to clarify a story. QA waits for a build to land in an environment that resembles production. Ops waits on the developer for a release note. None of that waiting lives inside a box. It sits between them, and it is measured in days while the work inside the boxes is measured in hours. Triple the speed of one box and the gain is swallowed by the queue in front of the next one.

Here the evidence flatters less than the demos do. In a 2025 randomized controlled trial run by METR, 16 experienced open source maintainers worked through 246 real tasks on repositories they knew well. Their forecast was that AI tools would cut completion time by roughly a quarter. Measured, they took about 19 percent longer, and afterwards they still believed they had been faster. The tools were not useless. What was off was the belief, which was uncalibrated, and that is exactly the condition under which budgets get approved.

Teams that stall usually end up at one of two extremes. With over-delegation, a model gets handed something vague, build us a checkout, and returns thousands of lines packed with decisions nobody made about payments, authentication and shipping. The code shows up fast and then sits, since the reviewer has to reconstruct intent that was never written down. Under-delegation is the mirror image. A senior does all the decomposition by hand and uses the model only to fill in functions. The code is good. Yet the expensive part of the job, deciding what to build, never moved. We went further into that split in what you actually hire for when AI writes the code.

The five classes worth a line item

Vendors sell on capability. You should buy on the bottleneck each class removes, and be honest about what it leaves alone. Five classes cover nearly everything on the market today.

Those bands are published list prices in late 2026 and they move constantly. Treat them as a planning range rather than a quote, and read the enterprise tier before you multiply by headcount: the jump from team pricing to enterprise pricing is routinely the largest surprise in the model.

What this costs a ten-person team for a year

Start from the figures real budgets tend to land on: $30 a seat for the assistant, $100 for the agentic tier, $24 for automated review and $35 for test generation. Per developer, that comes to $189 a month and $2,268 a year, or $22,680 for a team of ten.

Set that beside a single hire. Compared with a senior US engineer whose loaded cost tops $150,000 a year, the whole tool stack for ten people costs roughly eight weeks of one headcount. You can find current bands for the roles you would compare it with in our US software developer rate guide.

Which tells you something useful: the license is almost never the decision. At these numbers you can afford to be wrong about a tool. What you cannot afford is to be wrong about the second order effects, because those have their own invoice and it does not arrive as a subscription.

The three costs the pricing page leaves out

Review load. Generated code remains code you own, and you still ship it and maintain it. Review guidance older than all of this sets the useful ceiling at around 400 lines in one sitting and roughly 500 lines an hour before defect detection drops off. More diff volume means more review hours, and those hours fall on the two or three people you can least afford to put in a queue. Do the arithmetic against your own git history before the trial, not after it.

Context setup. What an agent is told about your codebase sets the limit on how good it is: a repository-level instructions file, house conventions, which services are off limits, what done means here. Someone has to write that, and someone has to keep it current. Plan on a few days up front per repository, then about an hour a week. Skip it and a team gets confident output that ignores every convention it has, which is worse than getting no output at all.

Trust debt. The third cost is code that passed review because it looked right, in a part of the system nobody now understands. The same capability that explains an inherited legacy system will also manufacture a new one faster than you can staff it. A written review standard is the cheapest control you have here; our pull request review checklist is a reasonable floor to start from, with one amendment: the reviewer is allowed to ask who decided this, and expects an answer that is not the model.

Where the leverage actually is, stage by stage

When the build box is already your fast part, the returns lie elsewhere. Before you buy another seat for that same stage, six places deserve a look.

• Requirements. Support tickets, survey free text, sales call notes and bug reports are unstructured, and nobody reads all of them. Synthesizing them into candidate user stories turns a pile nobody opens into the front of the funnel.
• Operate, feeding back into requirements. When an agent reads logs and incident write-ups to name recurring root causes, production becomes an input to the roadmap rather than a tax on it.
• Build. Small, well-defined tasks worked against a written specification. Here the spec is the unit of work, and output quality follows spec quality almost exactly. Vague in, thousands of unreviewable lines out.
• Test. Edge-case data and unit tests taken straight from the story, plus triaging a stack trace at three in the morning. Manual testing is a classic bottleneck, yet it is rarely called one.
• Release. Infrastructure as code is among the areas where models are genuinely strong: pipeline configuration, container manifests, provisioning playbooks. It is also the reason DevOps engineers usually feel the change first, and the reason a tidy CI/CD pipeline multiplies everything above it.
• Modernization. Explaining code whose authors left years ago, in a language nobody on the team writes any more. This is the use case with the least hype and the best returns.

Every one of those has the same shape. The human role moves from producing to validating, and the work that disappears is coordination rather than keystrokes.

A 30-day trial that ends in a decision

Most tool trials end in a renewal since nobody wrote down what would have counted as failure. Fix that in a single file before buying the first seat.

1. Name a single bottleneck. Productivity does not count. Think of the pull request review queue, or the gap between a story being written and a build becoming testable.
2. Take a baseline measurement before day one, using a query you can re-run verbatim thirty days later.
3. Limit it to one squad. Six seats, not the whole organization. Pilot across four teams and you measure nothing, since nothing else was held still.
4. Cap spending, metered usage included, and put an alert at half the cap.
5. Write down the kill rule. If the metric has not moved by day 30, the seats are cancelled, and there is no debate when that day comes.
6. Name an owner who is not the vendor and is not the most enthusiastic engineer on the team.

There is a reason thirty days is the right length. Day zero is the baseline. Context setup takes days one to five (instruction files and conventions), and those days will feel slow. From day six to day twenty-five it is ordinary work, with no special effort to make the tool look good. Then days twenty-six to thirty re-measure using the identical query. A shorter trial measures novelty, while a longer one quietly turns into the status quo before anyone decides.

Where to start this week

Open your issue tracker and look for the stage where work waits longest. That means not the stage your engineers complain about most, but the one where items sit with no owner acting on them. Only at that stage can a new tool show up in a number anyone outside engineering cares about.

Before the first license, write down four rules. No tool goes in without a named bottleneck and a measured baseline. The person who merges the diff owns it, whatever produced it. Data boundaries are put in writing: which repositories, which customer data, which models, what retention. Finally, outcomes over output, because lines generated and suggestions accepted are vendor metrics, not yours. Yours are change lead time, change failure rate and median pull request age.

If the honest answer is that nobody has the bandwidth to run a thirty-day trial properly, that is a staffing problem wearing a tooling costume, and it is worth saying out loud before you buy. A single senior engineer who can write specs, review generated diffs and own the measurement will do more for your delivery speed this quarter than any four subscriptions. If you want help finding that person, tell us the bottleneck and we will shortlist against it.