A Hundred Dollars of Tokens Does Not Buy a Hundred Dollars of Value.

A yellow legal pad sits in front of me on my desk, raw, unedited, and uncensored. It holds my full thoughts on whatever topic I have chosen to write about, and that is where my publishing workflow starts. From the pad, the work goes to Claude. I spend $125 a month on AI tools.

Claude interviews me, challenges me, and makes me think deeper about my own thoughts. It fact-checks me and provides sources, ChatGPT weighs in as well, and Grammarly double-checks all of it. Once I give approval, it handles the scheduling everywhere it can. That is how I keep up with an article every workday. What I feel about it is relief, because I get my thinking out without the production grind getting in the way.

The stories are mine, the judgments are mine, and the words are mine. Left to itself, AI builds what is asked of it; it would never scrap the idea on its own. So I built a mentor council specifically to argue with me: to point out flaws and to reject distractions from the business goals. I have a lot of ideas, and many of them are distractions from my primary purpose; the council has repeatedly helped me put those ideas aside. Nothing about that council is production; it is judgment I had to design into the workflow on purpose, because the capability would never supply it.

This month, technical leaders writing a 2027 plan are working through some version of a question someone posted bluntly to Hacker News in September: "Would you hire a new engineer, or get 300k worth of tokens for the team?" The budget answer is to put tokens and headcount in one line, compare what each buys, and fund the cheaper unit. A hundred dollars of token spend does not necessarily produce a hundred dollars of business value, though, or the multiple needed to make it profitable. Neither does hiring someone to fill a position. It is not the production work that matters; it is the judgment that aims that capability at the right business goals.

The trouble starts with the single line. One line forces one unit of comparison, and the unit that fits both tokens and people is output: cost per feature, per pull request, per article. On that unit, tokens win. So the plan shifts spend toward tokens, and every request for a person has to prove the work cannot be done by AI first. Think about the last thing your team decided not to build: where is that decision written down?

If the answer is nowhere, that is the mechanism. Judgment shows up two ways. The positive kind is easy to spot from the outside: the direction someone set, the bet that paid. Nobody catalogs the thing that was scrapped, and AI would never have scrapped it, because it builds what is asked of it. In a per-output comparison, the people who hold that judgment look like the most expensive line on the sheet, since the best thing they did all quarter left no output at all.

What a seat exists to hit is what I named Design Aim, and it is the one thing a single budget line cannot see. DX's Q2 2026 report, drawn from more than 500 teams, shows spend outrunning results: engineers using AI save an estimated four to six hours a week, the share of their time going to new features has stayed flat, and in DX's own words, "AI spend is accelerating faster than outcomes." The total budget still decides, but the line decides what the total is measured against, and judgment is the one item that cannot defend itself in units of output.

The leaders who protect the aim through this cycle do not argue harder for headcount than you; they refuse the frame the spreadsheet hands them. This planning cycle, the decision in front of you is whether to let the 2027 plan put tokens and headcount in one line. Refuse it. Add a line above both: the seats that decide what gets built and what gets scrapped, and name who holds them before the spreadsheet decides for you. If no seat on your plan owns the aim, the cheapest output wins by default, and you will have agreed to it by saying nothing.

Before your 2027 headcount request goes in, rewrite every justification on it as what that seat will stop you from building, and what it would have cost. Start with one seat, the one most likely to be traded for tokens, and write two lines: what the seat exists to hit, and one thing it stopped your team from building last quarter, with a rough cost. If you can write the first line and not the second, you are about to defend that seat in output terms. That is the comparison the cheaper unit always wins.

In TeamOS™, the first line of every seat is the first thing you write: the Design Aim Register, binder page OR-02, in Before You Begin, where you name what each seat was built to hit before anything else gets designed: https://TeamOS.Coach