Read the AI Tool List Before You Answer the Budget Number

What does a tool budget ask tell you that the loop did not?

A tool budget ask tells you which steps of the work this person has already handed to something else, and which ones they kept. A tool list is a set of decisions about their own week, priced. Four rounds of interviews rarely produce a document that specific.

What the list does not tell you is whether any of it works, which is the question the budget number is actually about.

The two questions come apart, and only one of them is cheap to answer.

A METR randomized trial between February and June 2025 had 16 experienced open-source developers complete 246 real tasks on repositories they had worked on for roughly five years. With early-2025 AI tools allowed, they finished 19% slower ¹.

The developers did not notice. They had forecast a 24% speedup going in, and after finishing the work they still estimated a 20% one ¹. Sixteen developers on code they knew intimately is a narrow setting, and the size of that gap will not transfer.

The direction of that gap is the part that travels.

So a finalist's estimate of what a tool saves them is a belief about themselves, and beliefs of that kind have been measured running the wrong way. What each tool does is a different question, and they can answer it. You can check the answer against the work they described three rounds ago.

Naming the tools and the rules in the posting is the cheaper version of the same conversation. It happens when the role is posted, with every applicant, instead of once at the offer with the person you have already chosen.

Ask what each line replaces in their week

Go down the list once, out loud, and ask three things of every line: what the tool does in a normal week, which step of the work it removed, and what they still do by hand afterwards. Five minutes covers a six-item list. The answers separate a person describing a working structure from a person reciting a shopping list, and neither one is disqualifying.

The good answers are boring and specific.

• A named step. The tool writes the first version of a client summary, and the recommendation section is still rewritten by hand.
• A price they already know. The seat costs a stated amount a month, and they can say who paid for it before.
• A check that stayed. One thing the tool produces still gets verified against a source, and the source has a name.
• A tool they dropped. Something bought, used for two months and abandoned, with the reason attached.

A list with no steps behind it is not a lie.

More often the person read the same recommendations everybody else read, which makes the tools aspirational rather than load-bearing. Price them that way: aspirational tools are a training question and a much smaller number.

The same tool moves output in both directions, depending on the task.

Boston Consulting Group consultants got GPT-4 in a 2023 pre-registered field experiment, on 18 realistic tasks chosen to sit inside the model's capability. Of the 758 consultants, those given the model completed 12.2% more tasks and produced work graded more than 40% higher in quality than a control group ².

A separate task in the same experiment was chosen to sit outside that capability, and on it the tool was worth less than not having one. The control group solved it 84.5% of the time. The two AI conditions came back with 60% and 70%, which put the consultants holding the model 19 percentage points worse off on average ².

Nobody could see which side of the line they were standing on.

What decides the answer is the task, not the tool. A license buys nothing on its own, which is why the step behind each line is the part worth asking about.

What your team can already do with AI is the baseline this ask is measured against.

Who decides whether you can say yes to the stack?

The negotiation does not decide whether a tool can be bought here. The security review does, along with the data-handling rules the role sits under, the approved-vendor list, and whoever holds the budget line. A hiring manager who promises a stack before checking those four has made a commitment somebody else will break, and the person who finds out is the new hire in week three.

Four answers, and a recruiter can get all of them in a day:

• Whether the vendor is already approved, and for which classes of data.
• Whether the seat comes out of a central budget or out of the team's.
• How long a review runs for a vendor not yet on the list, in weeks.
• Who signs, and whether that person has refused this category before.

If the answer is no, say so before they accept, in the words the constraint is written in. A hire whose method depends on a tool the company will not approve is a ramp problem you were warned about in advance and chose to ignore.

Hiring for AI you have not approved internally is the same contradiction one stage earlier.

Article 4 of the EU AI Act has applied since 2 February 2025, and it reaches deployers rather than only vendors. An employer switching on an off-the-shelf AI tool owes measures to support the AI literacy of the staff operating it ³.

The wording moved in 2026. Amendments in force since mid-July 2026 dropped the requirement of "a sufficient level of AI literacy" from the wording many summaries still quote, and the Commission's own answer is that the obligation remains for providers and deployers ⁴. Supervision and enforcement apply from August 2026, through national market surveillance authorities rather than the AI Office ⁴.

None of these obligations reaches an employer with no EU exposure.

One case cuts against reading the list as evidence at all. Some tool asks are really pay asks: a finalist who could not move the salary number moves an easier one, sometimes on a recruiter's suggestion, and the list then describes what the person read about rather than what they do.

Write every yes into the first two weeks, with a date

Whatever the answer is, it belongs in the onboarding plan: the tool, the owner of the request, the date access is expected, and the fallback if that date slips. An offer letter is the wrong home for it. Tools get discontinued, repriced and replaced, and a list written into a hiring document outlives every one of those changes.

The expectation attached to the tools belongs in the same place.

Putting the AI expectation in the role rather than in the offer letter keeps the tools and the expectation somewhere they can be revised without reopening the employment terms.

Then hold the date. Approvals for a vendor not on the list run in weeks, and a new hire waiting on an account nobody has opened is being judged on a ramp that has not started.

Six weeks without tool access is a foreseeable cost, and it is cheaper to name in week zero than to explain in the first review.

The seat is also worth different amounts to different people.

Pooling three company-run randomized trials at Microsoft, Accenture and an anonymous Fortune 100 firm, covering 4,867 developers, the ones who used an AI coding assistant completed 26.08% more tasks ⁵. The standard error is 10.3%, so the honest range runs from roughly 6% to 46%, and less experienced developers both adopted the tool more and gained more from it.

Volume is what those three trials measured, in weekly completed pull requests, which says nothing about defect rates or review burden.

Even so, the shape of the result is the argument for deciding the tool budget per hire rather than by policy. The same license bought different amounts of work depending on who held it, and the number your finalist quoted came out of somebody else's week.

Keep the list. Six months from now it is the only written account of how this person meant to work, and the first document to read beside what they actually did. Ask them then which lines they stopped using.

See the benchmarks >