The Language of Control: The Orchestrator's Vocabulary and Structure

Compare two requests to an AI assistant.

The second request is not longer because it is more polite — it is more precise because it uses vocabulary that names the exact constraint. Vocabulary is the structure you impose on a task before an assistant ever starts reasoning about it. A team that shares precise terms for its architecture can direct AI-accelerated work in a handful of words. A team without that vocabulary has to hope the assistant infers the constraints the vague prompt failed to state.

The Constraint You Cannot Name, You Cannot Request

The first request in that pair is not lazy; it is under-specified in a way its author cannot see, because the team has no shared word for "the same as the rest of the site". The assistant fills the gap by predicting: it picks the most probable interpretation from its training distribution — which is the internet's conventions, not yours.

That gap is paid at review. A vague request produces output that looks right and must be checked line by line, because nothing in the request told you what to check it against. A precise request produces output that can be checked against a stated constraint — the difference between reviewing a decision and auditing a stranger's taste.

Vocabulary is what closes the gap. Not jargon for its own sake: a term earns its place when it makes a constraint requestable, checkable, or enforceable.

The Working Vocabulary

Four domains cover most of what an orchestrator needs to name. The words matter less than the fact that everyone — including the assistant — uses the same ones for the same thing.

Three of these deserve to be artifacts in their own right, because they turn the principles from Part 2 into repository reality rather than good intentions:

1. The auto-feedback loop — a check that runs on every change and reports pass/fail immediately. This is fail fast and idempotency enforced by a machine, every time.
2. The platform playbook — the documented, scoped procedure for a recurring task, written so a person or an assistant can follow it without re-deriving the approach. This is bounded context and least astonishment, written down instead of assumed.
3. The AI regression log — the record of AI-introduced failures that became permanent tests or guardrails. This is the self-improving repository: the same mistake gets structurally harder to repeat.

The Other Half: Code an Agent Can Read

Vocabulary names the concepts. The shape of the code is what the assistant actually loads, so the layout is not just a human collaboration surface — it is the strongest piece of context you supply.

Human-readable code is no longer sufficient on its own, because a bounded reader does not navigate the way a person does. A person jumps around an IDE, holds a mental model, and asks a colleague. An assistant reads in linear chunks, stops at a context window, and will not ask a clarifying question unless you have told it to.

Four rules carry most of the benefit.

Folder as Context

Grouping files by technical layer — controllers/, services/, models/ — forces a reader (of either kind) to cross the whole repository to understand one feature, which is how a context window is exhausted before the task starts. Group by feature or domain instead, so one directory answers one question:

src/
  features/
    billing/
      BillingService.ts      # logic
      BillingUI.tsx          # view
      billing.types.ts       # contracts
      billing.test.ts        # verification

The boundary of the directory is the boundary of the reasoning task. That is separation of concerns and bounded context expressed where the agent actually reads them — the same structure Part 2 of The Method designs deliberately. When you ask for a change to billing, the correct scope is visible before any search happens.

Explicit Over Clever

An assistant predicts the most likely next token. If your names are abbreviated or abstract, that prediction has to guess; descriptive, slightly boring names align it with your domain and reduce invention.

• Bad: const res = proc(d)
• Good: const finalTaxAmount = calculateTaxForUser(user)

Types as Guardrails

Even in a dynamically typed language, type hints and a type checker are worth the keystrokes. A signature like processPayment(user: UserDTO, amount: number) closes off whole categories of wrong output — a raw database entity, a string where a number belongs. Types shrink the generation space to a valid subset.

Comments Explain Why, Not What

Do not spend context restating what the code already says. Spend it on what the code cannot say: the business constraint, the workaround, the reason a decision was made. That is the context an assistant cannot recover by reading the file.

What This Buys You

• Review becomes checking, not auditing. A constraint that has a name can be verified; an unnamed intention can only be judged.
• Smaller, obvious scope. Feature-shaped directories mean a change has one home, which makes both the request and the review cheaper.
• Vocabulary as onboarding. A new engineer — or a new agent session — learns the team's terms once and applies them everywhere.
• Fewer invented conventions. When the right term exists and is written down, the assistant uses it instead of manufacturing a plausible alternative.

The Orchestrator's Takeaway

Keep a short, shared vocabulary for the things you ask for most — and use the smallest correct scope: the atom, not the page; the feature directory, not the layer. If you cannot name the constraint you are asking for, you are not directing the work; you are describing a wish and reviewing whatever comes back.

Next in the Series

Principles name what must hold; vocabulary gives those principles words and a shape. What is not yet settled is where each thing belongs — which concerns are the repository's to declare, and which belong to the tool reading it. Part 4 draws that line.

For the full method, see The DevOps Engineer's Guide to Effective AI Usage.