# Why standards beat handing out AI licenses

> When the AI bill climbs, the instinct is to ration seats. That is the wrong lever. It caps your upside to save a fraction of your downside. Control cost through standards that live in the tooling and through engineering, so a small team moves like a large one.

Published 2026-06-27 · 8 min read · AI enablement

Source: https://prasad.tech/blog/standards-beat-licenses

---

When the AI bill climbs, the reflex is to control it the way you would control any climbing cost: cut back. Fewer seats, a cheaper assistant, an approval step before anyone can expense a tool. It feels responsible. It is the wrong lever, and it is worth seeing why from first principles before reaching for it.

The upside of AI in a company is the expensive, repetitive workflows you rebuild so they take an afternoon instead of a week. That is where the returns are. Rationing seats does nothing to those workflows; it only trims some unused licenses, which industry benchmarks put at around 21% of the seats bought ([Opsera 2026](https://opsera.ai/knowledge-base/ai-code-assistant-analytics/github-copilot-vs-cursor/)).

So the trade is to cap the upside you have not captured yet in order to save a fraction of a downside that was never large. It also tells your best builders that the company is nervous about the tools, and that signal costs you in a way no invoice will ever show.

I run internal AI enablement as a [P&L](/blog/ai-enablement-pnl/), so cost control matters to me directly. The lever I actually use is standardisation.

## A license does not change a workflow

Handing out a license produces two things: some private time savings, as people speed up their own tasks, and a lot of experimentation, much of it toy apps. It produces no change to any shared workflow, because changing a workflow is a project and a seat is not a project. The seat is a door. Value is on the other side of it, and getting there is work that a license does not do.

So the question is how to make the work on the other side of the door cheaper and more repeatable each time you do it. That is what standards are for.

## Standards only count when they live in the tooling

A standard written in a wiki is a suggestion. Someone has to know it exists, remember it at the right moment, and choose to follow it, and under deadline it usually gets skipped. The same standard installed as a default is a different kind of thing: it applies whether anyone remembers it or not.

On our team that principle drives everything. Every project is self-describing in a way both people and coding agents can read, generated from a single set of templates, so producing a compliant project is a copy-and-fill rather than a blank page.

A one-command setup installs the same tools, the same guardrails, and the same cost controls for everyone, so a new project or a new person starts from the shared baseline without a meeting to align on it. The rules that keep AI spend and behaviour in check are installed as defaults and editor hooks, so they are followed by construction rather than by discipline.

I wrote about the version of this that keeps a fleet of coding agents safe in [loops, harnesses, and memory](/blog/loops-harnesses-memory/); the same idea applies to a team of people.

```mermaid
flowchart LR
    subgraph wiki["Standard in a document"]
        w1["Someone must know it"] --> w2["remember it"] --> w3["choose to follow it"] --> w4["often skipped under deadline"]
    end
    subgraph tool["Standard in the tooling"]
        t1["Template, default,<br/>setup script, hook"] --> t2["applied by construction"] --> t3["followed whether or not<br/>anyone remembers"]
    end
```

The payoff is that a small team moves like a large one. Two people with good standards do not spend their time re-deciding how to lay out a project, wire up cost controls, or set guardrails, because those decisions are already encoded. The standards do the coordinating that a bigger team would need meetings for. Every project reuses the last one, so the marginal cost of the next one keeps falling, which is the opposite of what happens when everyone builds their own way from a fresh page.

## Control model cost through engineering

The part of the bill that is genuinely worth managing is model spend, and the way to manage it is engineering rather than access limits. Route the high-volume, low-stakes work to a cheaper model, and keep the expensive frontier model plus a human for the parts that gate a customer-facing change. Add prompt caching, where the provider stores the fixed part of a prompt so you pay for it once instead of on every call, so repeated context is not paid for twice, and let agents pull structure and prior knowledge from a store instead of rediscovering it by reading whole files.

These moves routinely take out a large share of the cost while leaving everyone's access untouched ([one team went from 59% to 70% saved with caching](https://projectdiscovery.io/blog/how-we-cut-llm-cost-with-prompt-caching); I wrote up the levers I use in [cutting a coding agent's token bill](/blog/cut-coding-agent-token-bill/)).[^savings]

Notice what this does to the original reflex. The person worried about the climbing bill wanted to cut seats, which would have saved a little and cost the upside. Routing and caching cut the same bill by more, cost nothing in capability, and leave the door open for anyone to rebuild the next expensive workflow. Standards and engineering are how you get the cost curve down and the output curve up at the same time.

## Key takeaways

- Rationing seats caps the upside you have not captured to save a fraction of a downside that was never large, and it signals to your builders that the company is not serious.
- A license is a door. The value is the workflow on the other side of it, and reaching that value is a project a seat does not do on its own.
- Standards only change behaviour when they live in the tooling. A guardrail in a wiki is a suggestion; the same guardrail installed as a default is a standard.
- Templates plus a one-command setup let a small team move like a large one, because each project reuses the last and the standards do the coordinating meetings would otherwise need.
- Control model cost through routing, caching, and reuse rather than access limits. You get the bill down and keep the capability up.

This is the deep version of the fourth move in [running AI enablement as a P&L](/blog/ai-enablement-pnl/). If your AI spend is climbing and rationing seats is on the table, [a short call](/book/) is a good place to talk through the alternative.

[^savings]: How much caching saves depends on how much of your traffic reuses the same context, so the 59% to 70% is one team's shape rather than a rate to expect. The way to size it for yourself is to check what fraction of your tokens is fixed prefix that repeats across calls before and after turning caching on.

---

## Common questions

**Why is rationing AI seats the wrong way to control cost?**

Because it trades away the thing worth the most to save the thing worth the least. The upside of AI is the expensive workflows you rebuild, and rationing seats does nothing to those; it only trims some unused licenses, which benchmarks put at around a fifth of seats bought. It also signals to your best builders that the company is not serious about the tools, which is expensive in a way that never shows up on the invoice.

**What does 'standards as code' actually mean?**

It means the rules for how work is done live in the tooling rather than in a document. A guardrail written in a wiki is a suggestion someone has to remember. The same guardrail installed as a default, a template, a setup script, or an editor hook is a standard that applies whether anyone remembers it or not. Standards only change behaviour when following them is the path of least resistance.

**How does standardisation let a small team move faster?**

Because each new project starts from the last one instead of from a blank page. Shared templates mean a compliant project is a copy-and-fill rather than a fresh setup. A one-command environment means everyone has the same tools, guardrails, and cost controls without a meeting to align on them. The standards do the coordinating that a larger team would need meetings for, which is how two people can move like ten.

**How do you control AI model cost without limiting access?**

Through engineering rather than access limits. Route the high-volume, low-stakes work to a cheaper model and keep the expensive frontier model plus a human for the parts that gate a customer-facing change. Add prompt caching and reuse of structural knowledge so tokens are not spent rediscovering the same things. These moves routinely remove a large share of the bill while leaving everyone's access intact.