Configuring Your AI

The Foundation Charter settled what I am building and the ground I intend to build on. This chapter settles a different question: how I distribute intelligence across the work.

The objective is not to use the cheapest AI. It is to build the best software I can with the intelligence and tokens available to me.

That distinction matters because the most important place to spend intelligence may not be writing the code. It may be deciding what code needs to be written, and determining whether the result is correct.

Not all AI work is equal

Suppose I have access to two models. One reasons well over large systems but is expensive to run. The other is inexpensive, perhaps even free, but less reliable on complex tasks.

Should I use the strong model for everything? Or the cheap model for everything?

My answer is neither. Software development contains different kinds of work, and the cost of a wrong decision is not evenly distributed across them.

Deciding how a new behaviour fits into an existing system, what contracts it must honour, and what could break elsewhere demands architectural understanding and foresight. Writing a data object from an agreed schema, once those decisions exist, is a far more bounded exercise. Reviewing the result for security omissions and broken assumptions is again a different kind of thinking — sceptical, integrative, and consequential.

This unevenness is why I configure AI by responsibility rather than by habit. My default, set out in the table below, is: strong intelligence where a mistake propagates, economical intelligence where the decisions have already been made.

Model price and model quality are related considerations, not interchangeable quantities. Cost is a useful planning constraint, not a reliable measure of intelligence. I recommend the strongest effective model available for each task, not the assumption that the highest-priced model must be the best.

There is no universally correct configuration

Every developer faces different constraints: money, subscriptions, and rate limits; token and throughput limits; access to free or locally hosted models; hardware and performance requirements; privacy and source-disclosure restrictions; how reliably each candidate handles the project’s language and frameworks; the repository size and the context each task genuinely needs; the time available; and the consequences of shipping incorrect software.

I make these choices deliberately, and I expect them to differ between projects. A solo developer on a limited budget can still organise a useful hierarchy: careful thinking invested once in design and review, economical execution applied many times within those bounds. A larger organisation may use expensive models more freely. Neither automatically has the better development process. The purpose of configuration is to use whatever capabilities are available where they change the outcome most.

Spend intelligence on design

I put my strongest available reasoning where a mistake affects everything downstream: understanding the system, resolving complexity, designing the solution, and establishing contracts.

A designer working at this level may need to read across a large repository and recognise its patterns, trace dependencies across subsystems, distinguish the real problem from its most obvious symptom, compare alternatives with their integration costs, anticipate security and migration risks, and specify boundaries, invariants, and acceptance criteria — then produce instructions bounded enough for another intelligence to execute.

A sound decision at this stage can guide many smaller tasks. A flawed one can misdirect all of them. That asymmetry is why I treat design effort as potentially economical: reasoning invested once, reused across every work package that follows. I offer this as a structural argument from experience — early errors propagate widely — not as a measured multiplier.

GBI: good-enough, inexpensive intelligence

GBI is my shorthand for relatively inexpensive AI capable of bounded development work: a practical classification, not a formal benchmark category, and the boundary moves as models change.

Suitable work is work where the important decisions have already been made: a data object from an agreed schema, an endpoint following an established pattern, a migration from an approved specification, a well-defined function or adapter, focused tests from explicit acceptance criteria, narrow corrections described by a reviewer.

An economical model can often perform these tasks well precisely because it does not need to rediscover the architecture. What it needs is a complete assignment: a clear objective, the relevant source context, the pattern to follow, exact constraints, expected inputs and outputs, required tests, prohibited changes, acceptance criteria, and conditions for stopping and asking for help.

A weaker model does not become reliable simply because the instructions are long, and a detailed work package does not remove the need for testing. The contract bounds the task; verification still decides whether the task is done.

Design for the implementing machine

The most consequential habit in this chapter is also the easiest to skip: the strong model should not merely produce an architectural essay. It should produce instructions that a less capable model can actually execute.

That means transferring decisions forward, from the implementation stage into the design stage. The designer settles which files are involved, which components must be reused, what behaviour must be preserved, what interfaces are required, what tests establish correctness, which choices are already closed, and what should make the implementer stop rather than improvise. If a work package still requires extensive independent architectural reasoning, it is not yet suitable for economical implementation. It needs to be split, clarified, or returned to design.

A short example helps. Suppose the feature is cited answers over ingested documents, consistent with the charter in the previous chapter.

A vague request sounds like this: “Add cited search over project documents using PostgreSQL and pgvector.”

A bounded contract sounds like this: implement POST /answers in the existing retrieval service; reuse the passage store and the approved hybrid-query helper rather than introducing a new client; accept a question string and an optional document scope; return answer text with citation identifiers resolvable against stored sources; preserve the existing authentication and audit behaviour; cover the endpoint with three acceptance tests — every citation resolves to a stored, in-scope source; out-of-scope documents are refused rather than cited; and a question with insufficient evidence returns an explicit no-answer instead of an invented one; do not change the ingestion pipeline, the configuration format, or the indexing parameters; stop and report back if the passage helper cannot express the required ranking.

The first version asks the implementer to resolve architecture. The second asks it to execute within architecture. That is the whole technique: if the economical worker must invent the design to proceed, the design is not finished. Treat this as an illustrative example of contract-writing, not as any existing system’s API.

Route each task, then diagnose its failures

Role defaults only help if each task is routed honestly. Before assigning a model, I weigh four things: how ambiguous the requirement is, how tightly the task couples to the rest of the system, what a wrong result would cost, and how much independent reasoning success requires. Routine bounded work goes to an economical capable model. Anything needing new architecture, significant system interpretation, or consequential security judgement gets stronger reasoning. Debugging escalates with difficulty rather than starting at the top.

When a cheaper worker fails, I diagnose before retrying. An incomplete contract, missing context, a task boundary drawn in the wrong place, and genuinely inadequate model capability look similar in the failure log and demand different remedies: complete the design, repair the context, redraw the boundary, or change the assignment — in that order. Repetition without revision is the most expensive token discipline of all.

Separation improves structure; it promises nothing on its own. Designs can be flawed, contracts can omit what the designer assumed was obvious, reviewer and designer can share the same blind spot, and some tasks are too entangled to bound at all. The remedy is always upstream.

Invest in finding what implementation missed

My strongest practical concern is not that economical models write slowly. It is that they can write plausibly while missing what matters: a security check, an assumption about existing code, honest error handling, correct persistence behaviour, an integration consequence, an established invariant, or tests that look thorough while proving little. Weaker models can produce genuinely inferior software when asked to exercise architectural judgement without adequate context or supervision — I state that as observed experience, and I plan around it.

The subtlety is that an implementation can look correct locally while failing at system level, and the model that produced it is the least reliable judge of that gap. Independent review exists for the gap: the reviewer works from the original intention and the actual repository, never from the implementer’s summary, and is expected to reject work, demand missing evidence, and where necessary find fault with the design itself.

This is risk-based allocation, not faith in a pipeline. For security-sensitive or unusually coupled changes I strengthen the implementation as well as the review, with specialised tools and tests where reasoning alone is insufficient.

Here is the distinction I want the reader to carry: a less capable model can perform a well-defined task successfully without being suitable for designing the task itself. Equally, the strongest model is not required for every review or every implementation. The allocation depends on the task.

Tokens are the budget, not the objective

Token-based usage shapes these decisions. The vocabulary is worth fixing because each category creates a different kind of cost: input sent to a model; output returned; provider-dependent metered extras such as internal reasoning or cached inputs; context limits, which constrain reliability as well as cost; retries from invalid output or failed tests; review and correction effort; and the work of reconciling a change with the real system.

A cheap first attempt becomes the expensive option once correction cycles accumulate; an expensive design review becomes the economical option when it prevents several rounds of rework. I compare the total cost of an accepted result, not the cost of the first call:

Total cost of an accepted result = design + implementation + verification + rework + integration.

Those components may be counted in tokens, charges, or developer time, but they are not interchangeable currencies. A model emitting fewer tokens is not cheaper if it creates more failures; a model reading more context is not wasteful if that context prevents an integration defect. What matters is verified quality per unit of resource.

What a feature actually costs

Consider the cited-answers feature above, with every figure illustrative — hypothetical token counts and rates chosen to show the arithmetic, since real charges depend on each provider’s pricing and caching rules.

In the separated allocation, a strong model designs once: roughly 30,000 input tokens of requirements and targeted sources, 5,000 of contract. An economical model implements: 15,000 in, 7,000 out. Independent review reads the result against the contract: 20,000 in, 2,000 out, and finds one defect — a permission check the implementer softened. One correction cycle follows: 8,000 in, 3,000 out, then a clean re-review. Total: about 90,000 tokens, two model handoffs, one correction cycle, acceptance on evidence.

In the all-economical allocation, design is a brief sketch, implementation is cheap — and review finds three defects across two cycles: invented citations the contract never forbade, an out-of-scope source cited anyway, error handling the tests never exercised. Each cycle re-reads the growing diff and regenerates tests. Total: roughly 130,000 tokens, three correction cycles, several days of elapsed confusion, and lingering doubt about what else the reviewer — itself economical — failed to notice.

The mirror image matters too. Assigning the strongest model to genuinely bounded work — migrating a table from an approved specification, say — spends premium reasoning where nothing propagates. The result is correct and needlessly expensive. Economy cuts both ways: strong where a mistake spreads, economical where the decisions are already made.

No universal ranking follows. These figures demonstrate a method of comparison, not a measured saving. The reader’s own totals will differ; the discipline of totalling them is the point.

Keep context sufficient, not maximal

Token discipline follows from that measure. I avoid sending an entire repository where targeted context suffices; keep architecture decisions in durable files rather than reconstructing them per prompt; reuse stable instructions; select relevant sources deliberately; summarise completed work while retaining the exact evidence verification needs; keep work packages bounded; notice unproductive retry loops early; and use provider caching only where its behaviour is verified.

None of this aims at the smallest possible prompt. Removing a dependency the implementer needed is a manufactured failure followed by a more expensive attempt. The goal is sufficient, accurate context at an appropriate cost.

Configure by role, with room to adapt

These are starting positions, not ranks. A model that struggles repeatedly gets a smaller task or gets replaced; an economical model that proves itself on a class of work becomes my preference for it. Capability is not a single numerical scale ordering every model on every task.

Two ways to build the same feature

In the single-model approach, one model receives the broad request, proposes the architecture, implements the change, writes the tests, and reviews its own result. Faster starts, fewer handoffs — and assumptions go unchallenged, because the same mind wrote the tests and the code. An integration consequence passes unnoticed for want of anyone assigned to look for it. Failure is not inevitable here. It is simply harder to catch.

In the separated approach, the bounded contract above goes to an economical implementer, tests execute, and a separate reviewer in a fresh context checks the result against the specification and the security requirements. Defects return for correction; acceptance waits on evidence rather than on the implementer’s report. I prefer this for substantial work because design, execution, and judgement are performed by parties with the means and the mandate to disagree — at the price of handoffs that must themselves be managed.

What practice has taught me

ALIVE is where this division earned its keep, and where it broke often enough to be instructive. Different models have taken the coding and reviewing roles; work has been delegated through coding agents with explicit handoffs; review reports and correction evidence have been retained. I have watched economical models succeed on bounded tasks and fail where the contract was vague or the context exceeded what I had supplied. Handling substantial context well has proved a separate skill from writing fluent code.

One reported episode concentrates the review argument. In the WB-ALIVE-04E independent R1 security recheck of the Workbench–ALIVE integration, retained historical review material could still disclose an authorising token through public readers despite a locally successful correction — a finding that surfaced in independent review. The complete report remains unrecovered, so I keep this brief and unattributed beyond that: it shows a reviewer refusing acceptance after local success, which is the mechanism this chapter advocates. It does not by itself establish what class of model introduced the defect, and I make no such claim.

Judge the configuration by outcomes

A reader testing this division needs only a modest framework. For each allocation tried, record model calls, input and output usage and charges where available, time to a verifiably accepted result, correction cycles, test outcomes, independent review findings, integration failures, and whether the intended user behaviour worked.

Crucially, hold the acceptance standard constant. Fewer review findings do not automatically mean higher quality — a weaker reviewer simply overlooks defects. Compare configurations under the same independent verification, and weigh quality against cost together: total resources, elapsed time, correction cycles, and the severity of anything still defective. A cheaper run that admits a serious flaw is not an improvement. The strong-design, economical-implementation, strong-review pattern remains my advocated working method, not a demonstrated universal optimum.

Write down the AI configuration

Chapter 02 ended with a Foundation Charter. This chapter extends it with a compact AI Configuration Charter — the same idea applied to intelligence itself. Before assigning real models, establish: available providers and candidate models; observed capability per class of work; context limits that proved workable; usage constraints such as budgets and rate limits; which sources each role may access; escalation rules ordered by cause (smaller task, richer context, stronger model); what evidence acceptance requires; and how the configuration’s performance is judged.

An illustrative configuration file might look like this — an example for discussion, never anything a tool executes without adaptation:

# Illustrative only — fill in from your own providers and experience.
design:
  allocation: strong-reasoning
  context: architecture-notes, contracts, targeted-sources
implementation:
  allocation: economical
  requires: bounded-contract, acceptance-tests, stop-conditions
review:
  allocation: strong-reasoning-separate-context
  requires: original-intent, full-diff, security-checklist
budgets:
  retry-ceiling: set-per-task-class
  live-model-tests: scheduled-only
acceptance:
  needs: green-suite, review-signoff, integration-evidence
measurement:
  track: correction-cycles, time-to-acceptance, defect-severity

I revise this charter as models change and as experience reveals where each one actually performs. A model that earns trust on a class of work gets more of that work; one that fails review repeatedly loses it.

Spending intelligence deliberately

I no longer think of setup as choosing a language and an environment. I am choosing how to distribute reasoning, execution, verification, and responsibility across machines — and where my own judgement remains the binding constraint.

Used everywhere, the strongest intelligence wastes resources. Used nowhere that matters, economical intelligence creates defects that cost more than it saved. Put the best thinking into understanding, design, contracts, and independent review, so that implementation — the part machines already do fluently — needs the least independent judgement to get right.

A well-understood architecture, a clearly bounded task, reusable components, established conventions, and explicit tests all reduce what the implementation agent must decide alone. But a poor design will defeat even the most capable implementer, and a poor review will admit good-looking code carrying serious defects. That is why I can advocate machine coding while insisting that the quality of the intelligence directing and evaluating the machines matters enormously.

With the foundations settled and the intelligence allocated, the next task is to say what the machine should build. That is the subject of Intent Before Implementation.