When a company decides its developers should use AI tools, the first instinct is to buy seats. That gets you nineteen people with nineteen different setups, nineteen billing surprises, and no idea whether any of it helped. We did it differently, and most of what follows would work for any team between ten and a hundred people.
One gateway, not nineteen API keys
Every model call from the team goes through a self-hosted proxy. Developers get a key to the proxy, not to any vendor. The proxy holds the vendor keys, routes each request to the model configured for that team, logs usage per person and per project, and enforces spending caps.
This one decision solved four problems at once:
- Cost visibility. A weekly report shows who used what, on which project, at what cost. Nobody argues about the AI bill any more, because it is itemised.
- Model changes without disruption. When a better or cheaper model appears, it is one config change at the proxy. Nobody edits their editor settings.
- Off-boarding. Revoke one proxy key and the person's access is gone everywhere.
- A place to add rules later. Rate limits, allowed models per project, redaction of secrets in prompts: all of it lives in one place.
We used an open-source proxy. It runs on a small VPS, took an afternoon to set up, and has needed almost no attention since.
Standardise the workflow, not the editor
People are attached to their editors, so we did not fight that battle. We standardised on an agentic command-line tool for the heavy work, and let people keep whatever editor they like for the rest. The workflow that stuck:
- Read before writing. The agent reads the relevant part of the codebase and states its plan in a few lines. The developer approves or corrects.
- One logical change per run. Not "build the feature", but "add the migration", then "add the endpoint", then "add the test".
- Verify against something real. Type checks and tests, then the actual page in a real browser. An agent that only reports "tests pass" is not finished.
- Commit with the time it took. Every completed change is logged in the tracker with the commit hash and the measured, AI-assisted time. Clients know the work is AI-assisted, and they see honest numbers.
The fourth rule turned out to be the important one. Measured time makes the productivity claim concrete, and it stops the temptation to bill imaginary hours.
Evaluate tools relentlessly, and expect to say no
Over about six months I ran 38 structured evaluations of AI tools, plugins, models and services. Each one followed the same short template:
- What job would this do for us, in one sentence?
- One hour of real use on a real task from a live project.
- What it did well. What it did badly. What it would cost per month at our size.
- Recommendation: adopt, trial for a month, or decline. Written down, with a date.
Most ended in "decline". A few became standard. The value of the exercise was not the wins; it was that every "no" came with a reason, so the same tool was not re-evaluated by a different person three weeks later. The written verdict is the product.
Invest in people, not just seats
Twelve engineers enrolled in a vendor's certification programme for building on its platform. Not because certificates matter, but because a structured course gives a shared vocabulary. When everyone understands tool use, context windows and evaluation the same way, the arguments get shorter and better.
What changed, honestly
- Prototypes for sales conversations went from weeks to days. More than forty were built in six months, and several converted into paid work.
- Small client projects that used to wait for a free developer now get built by whoever holds the brief, with the agent doing the typing.
- The senior developers spend more time reviewing and less time writing boilerplate. They like this.
- Junior developers need more supervision, not less. An agent will confidently build the wrong thing at speed. Read-before-write and one-change-per-run exist for this reason.
- The bill is real, itemised, and lower than the licensing route would have been, because heavy users and light users are no longer paying the same flat fee.
If you are about to do this
Set up the proxy first, before anyone gets a key. Write the four working rules on one page. Pick one evaluation template and use it every time. Measure time honestly. Then buy the seats, if you still need them. In our case, we mostly did not.