2.3 "You drive, the model types" as the default posture

What “you drive, the model types” means

This posture is the difference between sustainable velocity and a chaotic repo.

• You drive means: you define the destination, choose the route, and decide when you’ve arrived.
• The model types means: it generates the concrete draft quickly—code, tests, refactors, docs—within your boundaries.

In other words, the model is a high-throughput implementation assistant. It is not the owner of your architecture, correctness, or risk.

Division of responsibilities

Make the division explicit. It prevents the two most common failures: (1) letting the model overreach, and (2) micromanaging the model into uselessness.

You own

• Problem definition: what is being solved and what is not.
• Constraints: runtime, libraries, style, security requirements, “don’t change” zones.
• Architecture: boundaries, interfaces, data flow, dependency direction.
• Acceptance criteria: what proves success (tests, outputs, user flows).
• Risk decisions: what requires extra verification, review, or approvals.
• Shipping decisions: scope, tradeoffs, and when it’s ready.
• Verification: running tests, checking logs, measuring performance.

The model helps with

• Drafting: scaffolding, boilerplate, “first correct-ish pass.”
• Mechanical work: repetitive edits, renames, refactor patterns (with tests).
• Option generation: 2–3 approaches with tradeoffs for you to choose.
• Debug acceleration: hypotheses and targeted checks (you confirm with evidence).
• Documentation drafts: that you validate against code and reality.

How you keep architectural control

Architectural control is mostly about forcing the model to operate inside a constrained space.

1) Define boundaries up front

• What module owns what behavior?
• What are the public interfaces?
• What are the “don’t touch” areas?
• Where do model calls live (if building an AI app)?
• Where do side effects live (I/O, network, DB)?

Then tell the model those boundaries explicitly.

2) Use file allowlists and change budgets

Scope control is the fastest path to safe results:

• Allowed files: list them.
• Forbidden files: list them.
• Diff size: “keep it small,” “no rewrites,” “touch at most N files.”

3) Require intermediate artifacts

Instead of “write code,” ask for:

• A short plan.
• A minimal diff.
• A verification command list.
• Optional: a risk list (“what could go wrong?”).

Artifacts keep the model from drifting into a giant rewrite.

4) Treat interfaces as contracts

When you’re using the model to modify code, ask it to treat public APIs like contracts:

• Inputs and outputs don’t change unless explicitly migrated.
• Error behavior is explicit (no surprise exceptions leaking to users).
• Backward compatibility is preserved when required.

How to review AI-generated changes

Review is where you regain control. A good review process turns “fast draft” into “safe change.”

A high-signal review checklist

• Scope: did it touch only the allowed files?
• Intent: does the diff match the stated goal?
• Architecture: did it respect boundaries, or leak responsibilities across layers?
• Correctness: are there tests or checks that prove behavior?
• Failure behavior: what happens on invalid input, network failure, or missing data?
• Security: any secrets, unsafe evals, injection risks, permission changes?
• Maintainability: can a human understand and extend this in a week?

“Smell tests” for generated code

• Too much code for the change: likely overreach or unnecessary abstraction.
• New dependencies without justification: increases long-term cost.
• Silent behavior changes: same API, different semantics.
• Lots of branching without tests: brittle and hard to trust.
• Magic constants / unclear naming: the model optimized for completion, not clarity.

How to talk to the model like a builder

Talking to the model like a builder means you communicate in engineering artifacts, not vibes:

• Specs: goal, constraints, acceptance criteria.
• Evidence: logs, failing tests, reproduction steps.
• Interfaces: schema, function signatures, expected I/O.
• Diffs: small, reviewable changes.

Ask the right questions

• “What assumptions are you making?”
• “What’s the smallest diff that could work?”
• “What could break, and how do we verify?”
• “What files do you need, specifically?”

Boundaries and “don’t touch” rules

Boundaries are how you keep the model from “improving” things you didn’t ask to improve.

Types of boundaries that work well

• File boundaries: “Only change these files.”
• Module boundaries: “This module is the only place allowed to call the model.”
• Behavior boundaries: “No behavior changes; refactor only.”
• Dependency boundaries: “No new dependencies.”
• Security boundaries: “No secrets in code/logs; no dynamic eval; sanitize inputs.”

How to enforce boundaries

• State them at the top of every implementation prompt.
• Repeat the highest-risk ones (e.g. “do not touch auth”).
• Ask for a diff and review it before applying.
• Use tests/linters and reject changes that break them.

Feedback loops that improve output quality

You can train the model’s behavior within a project by giving consistent feedback.

When output is good

• Tell it exactly why: “The diff was small, tests were added, and constraints were followed.”
• Ask it to produce a reusable template: “Write a prompt I can reuse for future changes like this.”

When output is bad

• Don’t re-prompt with the same vague request.
• Instead: tighten scope, add acceptance criteria, and provide evidence.
• Explicitly correct assumptions: “That API doesn’t exist; here’s the real one.”

Common failure modes (and what to do)

Failure: it rewrites too much

• Fix: enforce file allowlists, “diff-only,” and “touch at most N files.”
• Prompt: “Undo the rewrite; propose the smallest diff instead.”

Failure: it guesses missing context

• Fix: require questions first; ask it to request specific files/functions.
• Prompt: “List unknowns + the minimal info you need.”

Failure: it doesn’t include verification

• Fix: make verification a required deliverable in every prompt.
• Prompt: “Add a verification section: exact commands + expected results.”

Failure: it produces fragile clever code

• Fix: request “clean, boring, readable” solutions; add tests; prefer standard patterns.
• Prompt: “Refactor for clarity; no clever tricks; add tests.”

Copy-paste templates

Template: enforce roles

You are my implementation assistant.
I own architecture and correctness.
You must:
1) Ask clarifying questions if needed.
2) Propose a small plan.
3) Provide a minimal diff within allowed files.
4) Provide verification steps.

Template: boundary-first prompt

Goal:
...

Boundaries:
- Allowed files: [...]
- Forbidden files: [...]
- No new dependencies
- No behavior changes unless specified

Acceptance criteria:
- ...

Deliver:
Plan + minimal diff + verification commands

Template: review my diff

Review this diff for:
1) Scope violations
2) Behavior changes
3) Missing tests
4) Error handling gaps
5) Security concerns
Then suggest the smallest improvements.

Where to go next

• 2.4 The 80/20 rule: get to runnable, then get to correct
• 2.5 The “spec first” habit that prevents spaghetti