From the free book Delta: Closing the Specification Gap (Dhuri, 2026). The PDF is the canonical edition — figures, tables, and code formatting are simplified online.
The Specification Frame applies to every knowledge work role. Here is how.
“Prompting is not a developer skill. It is a specification skill. Every knowledge worker who can describe precisely what they need can use it.” — The engineering manager who masters the techniques in this chapter becomes the person their entire organization turns to when AI tools produce inconsistent results. In This Chapter
What was the last document you spent more than two hours writing that you could describe precisely in a specification? A performance review? A headcount business case? A technical requirements document? The Specification Frame works for those too.
16.1 Performance Review Narrative BEFORE — Tier 1 (What most developers type) "Write a performance review for Sarah, who was a strong contributor ,→ this year and ready to move to the next level" AFTER — Tier 3 (Specification Frame) "<role>Engineering manager. You write specific, growth-oriented ,→ reviews. Never generic phrases.</role><engineer>[Engineer Name ,→ ], Senior Engineer, 3 years tenure</engineer><contributions>Led ,→
,→ 0. Mentored two junior engineers through their first production ,→ deployments. Delivered the patient notifications feature two
,→ weeks early by identifying and removing a blocking dependency ,→ .</contributions><development_areas>Technical communication: ,→ presentations to non-technical stakeholders could be more ,→ structured.</development_areas><task>250-300 word review. Opens ,→
with most specific impact. Development area framed as next
,→ step, not weakness. Forward trajectory in final sentence.</task ,→ ><constraints>No: 'team player', 'goes above and beyond', ' ,→ great attitude'. Every sentence grounded in contributions or ,→ areas. No rating suggestion.</constraints>" Result: Tier 1 produces: 'Sarah was a strong contributor who went ,→ above and beyond.' Tier 3 produces a review citing specific ,→ deliverables, quantified impact, and a concrete development ,→ trajectory — the kind that survives HR scrutiny and means ,→ something to the recipient.
16.2 AI Impact Assessment — The Required New Artifact Every team building AI into a product needs this document. It doesn’t exist yet in most governance frameworks, which is why so many AI features go to production without anyone having formally asked: what happens when this goes wrong at scale? <role>Business analyst assessing an AI feature for compliance and ,→ governance review. Your audience: compliance, legal, and senior product stakeholders.</ ,→ role> <feature> <name>{{feature name}}</name> <description>{{what the AI does, in plain English}}</description> <model>{{which AI model and organization}}</model> <data_inputs>{{what user/business data goes into prompts}}</ ,→ data_inputs> <decisions>{{what the AI decides or recommends}}</decisions> </feature> <task>Write an AI Impact Assessment covering: 1. BUSINESS CASE: problem, measurable benefit, success metrics 2. AI DESCRIPTION: plain English — in, out, what oversight exists 3. DATA GOVERNANCE: regulated data involved, where it goes 4. LIMITATIONS: what the model gets wrong + what happens when it ,→ does 5. HUMAN OVERSIGHT: autonomous decisions vs. decisions requiring ,→ review 6. REGULATORY: EU AI Act category. HIPAA/PCI/GDPR if applicable. 7. INCIDENT RESPONSE: harmful output at scale — what happens </task> <constraints> - Limitations must be honest. Do not minimize. - Human Oversight: who, when, by what criteria, with what authority. ,→ - Write for a compliance officer who has never used an AI tool. </constraints> 16.3 Board-Level Investment Recommendation ANTI-PATTERN — Vague AI Strategy Recommendation
AVOID: ”We should explore AI to improve developer productivity and stay competitive.” USE: ”RECOMMENDATION: Invest $X over 12 months in AIassisted development infrastructure (prompt library, MCP integration, evaluation framework) to reduce feature cycle time by 25-40% based on pilot results. Go/no-go at 6 months.” Why: ’Explore AI’ is not a recommendation. It is a hedge. Boards approve specific investments with specific expected returns and specific success criteria. They reject exploration budgets. Give them a recommendation.
FOR ENGINEERING MANAGERS The CFO test for AI investment recommendations: would your CFO find the financial case credible? ’We expect 3x productivity improvement’ will be challenged. ’We measured 28% reduction in feature cycle time across three pilot teams over eight weeks’ will be taken seriously. The risk executives most underestimate is organizational change risk. AI adoption requires engineers to change habits built over careers. Invest in change management alongside tool adoption — it is the difference between L2 and L3 maturity.
16.4 The Cost of a Specification Through 2025 and into 2026, the price of a token fell by roughly eighty percent, and at the same time AI became the fastest-growing line in many corporate technology budgets — at some firms, a meaningful fraction of total IT spend. Both things are true because cheaper tokens get used in far greater volume. For an executive, the lesson is not ’AI is cheap now.’ It is that AI spend, like any usage-based cost, rewards the teams that manage it deliberately and punishes the teams that do not. Specification is a cost-control mechanism, not only a quality one. This is the part most cost guides miss. A vague prompt produces an answer that is plausible but wrong for your domain; the engineer then iterates — three, five, ten more round-trips — each one billing input and output tokens, each one consuming the most expensive resource of all, the engineer’s attention. A precise specification produces a domain-correct answer closer to the first try. The industry’s own cost research keeps arriving at the same sentence: a single precise generation beats multiple iteration loops. That is the Specification Frame stated as an accounting fact. Two structural features of token pricing make this concrete. First, output tokens cost several times more than input tokens — commonly about four times — so an unconstrained prompt that lets the model ramble is expensive twice over: once for the wasted output, again for the re-run after you trim it. A constraint that bounds the output (’one paragraph’, ’JSON only’, ’no commentary’) is a direct cost control. Second, the stable part of a well-built prompt — the role, the domain context, the constraint block — is exactly what providers let you cache, at up to ninety percent off the per-token rate on the cached portion. The Specification Frame’s most reusable component is also its cheapest to send repeatedly. You structured the prompt for clarity; the same structure is what makes it cheap. None of this argues for the cheapest model on every task. It argues for matching the model tier to the job and specifying tightly enough that you pay for one good answer instead of several mediocre ones. The boardlevel version of the point: the organizations that control AI cost are not the ones that picked the cheapest provider; they are the ones whose engineers write specifications precise enough that the work is done once. ANTI-PATTERN — Optimizing the Token Price Instead of the Token Count AVOID: ”We cut AI costs by switching to the cheaper model.” — then quietly absorbing the iteration loops, retries, and re-reviews that a weaker model on a vague prompt produces. USE: ”We cut cost per completed task by specifying tightly (fewer round-trips), bounding output length, caching the stable spec prefix, and matching model tier to task complexity — measured per task, not per month.” Why: Per-month spend hides the real metric. Cost per completed, accepted task is what reveals whether your prompts are efficient. A precise specification lowers that number in four ways at once; a cheaper model often raises it.
COST-CONTROL CHECKLIST (FOR ENGINEERING MANAGERS) Measure cost per completed task, not per month. Per-month spend grows with adoption and tells you nothing about efficiency. Bound the output. Output tokens cost ~4x input; an unconstrained prompt pays twice — for the ramble and for the re-run. ’One paragraph / JSON only / no commentary’ is a budget line.
Cache the stable spec prefix. Role, domain context, and constraints rarely change between calls and cache at up to ~90% off; structure prompts so that block is reusable. Match model tier to task. Reserve frontier reasoning models for tasks that need them; route routine generation to mid-tier models. A 16x price gap between tiers is common. Count the iteration loops. The most expensive token is the one in the third re-prompt. Track average round-trips to acceptance; a falling number is your specification discipline paying for itself. Attribute spend per team and per feature. You cannot control what you cannot see; budget overruns discovered only when the monthly bill arrives are already sunk.
edge work role. Role + Context + Task + Constraints. The domain changes. The structure does not. + Specification is a cost lever, not only a quality lever: a precise prompt is done in one generation instead of several, output constraints cut the most expensive tokens, and the stable spec prefix caches at up to ~90% off. Measure cost per completed task, not per month. + The AI Impact Assessment is the new required governance artifact for AI-integrated features. Build it before launch, not after the compliance review. + Performance reviews, headcount cases, PRDs, and board recommendations all follow the same discipline: specific, grounded, honest about gaps. + For board recommendations: specific dollar amounts, ranges not false precision, explicit acknowledgment of uncertainty. Vague recommendations are not approved. + Engineering managers in 2026 are accountable for both the productivity opportunity of AI tools and the security risk of AIintegrated features.
3. Write your headcount business case using the structured prompt. Does making the cost of the gap explicit change how you frame it?
UP NEXT — Chapter 17: What Is Next — The Honest View
Most ’future of AI’ content is either breathlessly optimistic or reactively pessimistic. Chapter 17 is neither. It is a factual account of where the field is in 2026, what that means for your career, and which four structural truths won’t change regardless of how capable models become.