In Class 35 you learned to use vibe coding for what it is good at: fast prototypes that answer one learning question. Now the project matters. Someone will rely on it, or it stores real data, or the next change builds on this one.

The question is no longer "Can the AI make this?" It is "Can I direct and verify the change well enough to own the result?"

That is AI-assisted development: you use a model to explain, investigate, draft, edit, test, and debug, while you remain responsible for the product decision, the scope, the access granted, and the final judgment that the output is correct. The implementation — the actual files, code, configuration, and behavior that make a requested feature work — may be largely AI-written, but it is human-owned.

This is not "vibe coding but slower." It is a different operating loop:

understand goal → inspect current system → agree a small plan
  → make a bounded change → review evidence → keep or revise

A vibe-coding loop ends when the screen looks right. An AI-assisted loop ends when you can explain what changed and point to evidence that it works.

Who owns what

A useful way to think about the partnership is that the AI accelerates production while you own direction and acceptance.

Notice what never transfers: if the feature leaks private data, breaks access rules, or bills the wrong customer, "the AI wrote it" is not an explanation. You approved it.

The 90% rule

Experienced builders let the AI write most of a change — often 90% of the characters — and still review what matters. You do not need to memorize every line of syntax in every language. You do need to understand five things about anything you accept:

1. Purpose — what user outcome does this change serve? 2. Inputs — what data, arguments, or state does it consume? 3. Outputs — what does it change, return, or display? 4. Permissions — what can it read, write, call, or charge? 5. Failures — what happens when input is missing, invalid, or unauthorized?

If you cannot answer those five, you are not done reviewing. Ask the model to explain them, open the named files yourself, and bring in a stronger review for anything involving authentication, money, private data, or infrastructure.

That is the professional standard: not "know every line," but "understand the purpose, inputs, outputs, permissions, and failure modes — and know when to escalate."

A concrete walkthrough: source dates on the brief

Take the course's running example: a small research dashboard where a user picks a public company, the app gathers approved sources, and it produces a source-linked research brief.

The feature request: "Add a source date next to every claim in the brief."

A good AI collaborator works like this:

1. Finds the current shape. It locates the research-record data structure and the component that renders citations. 2. Notes the gap. It reports whether source dates already exist in the data, or whether they must be added to the record and the display. 3. Proposes a minimal change. One data field, one display helper, one rendering update — not a redesign. 4. Touches a small set of files. It names them before editing. 5. Runs the relevant check. A test, a preview with dated and undated sources, or both. 6. States exactly what changed. Files, behavior, and what remains untested.

Your job at each step is to confirm scope ("do not change data fetching or navigation"), confirm the plan, then verify the evidence afterward.

Model routing is a development decision

From Part IV you know models differ in capability, cost, speed, and context limits. Here that becomes operational: different jobs deserve different models, and you test the assignment with real work.

• Implementation: a capable coding model edits the bounded files — for example, inspecting the architecture around an authentication change before touching it.
• Review: an *independent* model inspects the diff — the readable record of what changed between two versions of the files — for regressions, broken access control, or unrelated edits.
• Tests and supporting work: a focused, often faster and cheaper model generates test-case variations from the acceptance checks, drafts first-pass landing-page copy or summaries, cleans up documentation, or performs structured extraction for a well-specified job.

A concrete orchestration for the source-date feature: one model proposes the plan; a cheaper model turns your approved notes into the UI copy ("Published 12 May 2026" versus "Date unavailable"); the coding model implements the approved change; then an independent reviewer reads the diff. Each model receives only the context its job requires — the copy model gets product notes, not the production database.

That last point is least context — the start of least-context routing, giving each model only the minimum project information and access its job requires: never send every model the full repository, customer records, .env files, API keys, production logs, or authenticated sessions by default. Give each worker the minimum it needs.

Sloppy prompts are allowed — but junk in means junk out

Nothing here forbids quick natural-language prompts. Fire off a rough "make the card look better" when you are exploring — that is legitimate vibe-coding speed, and sometimes the fast answer is good enough to learn from.

Just know the tradeoff honestly: a vague prompt forces the model to guess your intent, your constraints, and your acceptance bar. Guesses produce plausible-but-wrong code, extra retries, longer conversations, and more tokens burned per accepted result. A few extra minutes writing the goal, the scope, the must-not-change list, and two acceptance checks often produces a correct change on the first try — fewer loops, fewer corrections, fewer tokens.

So it is your call per task, not a moral rule. Exploring? Go fast and loose. Building something that must work? Slow down and specify. And remember the money side: AI feels cheap on free plans, but tokens after free tiers add up fast — every failed retry to a flagship model bills like a success. Careful prompts are a cost control, not just a quality habit. Lesson 12's formula applies here: cost per *accepted* result, not per request.

Do not marry one model

Too many builders pick one famous AI and never test anything else — every job goes to the same chat window out of habit. That is the most expensive loyalty program in software: a flagship model writing landing-page copy it could have delegated, a weak model wrestling an auth change it should never have touched, retries piling up because the wrong brain got the job.

Use the right model for the right job and prove it with the same task, not the logo. Keep a cheap fast model for drafts, summaries, and variations; a strong coding/reasoning model for architecture, auth, and tricky diffs; an independent reviewer that did not write the code. Re-test when models change — last quarter's winner may not be this quarter's. Compare live options at OpenRouter and route deliberately instead of defaulting to one subscription for everything.

Use separate CLI sessions

This workflow is easier to see in a terminal-based setup from Class 6. Keep separate clean sessions rather than one enormous chat that does everything:

• Session 1 — run: starts the app and runs tests, so you see real behavior.
• Session 2 — build: works the bounded code task and nothing else.
• Session 3 — review: acts as a read-only reviewer with no edit permission.

You are the orchestrator. You compare outputs, carry a short Markdown handoff between sessions, and decide what gets kept. Separation keeps the builder's assumptions from silently infecting the reviewer's judgment.

The ask-before-edit pattern

In unfamiliar territory, do not open with "fix it." Open with investigation:

Name the files or folder. Forbid edits explicitly. Demand options with a recommendation and reasons. This turns the model from a fast typist into an investigator, and gives you a plan you can approve before any file changes.

Exercise: write an orientation memo

Take an existing file or small project and ask the AI for an orientation memo. Save the result as ORIENTATION.md.

Use a prompt like this:

Then verify it: open every file it names and confirm the description matches. A memo with checkable cites is useful. A confident paragraph with no verifiable references is not.

Reviewer prompt pattern (save for later)

When the project grows, use a second model as an independent reviewer:

Then verify every finding against the actual code before changing anything. A finding with a file:line cite and a verification step ("open brief.js:42 and confirm the fetch has no auth check") can be checked in minutes. A vague warning ("auth might be weak") cannot.

Check your understanding

• What is the difference between the vibe-coding loop and the AI-assisted loop?
• Name the five things you must understand about any change you accept.
• Why should the reviewer model be independent of the builder model?

Finish line

You are done when you have an ORIENTATION.md — or a saved chat-to-Markdown handoff — that names the project's purpose, entry point, files behind one feature, and one safe next step, and you have confirmed each claim against the real files.

Verify: pick two files cited in the memo, open them, and confirm the memo describes them correctly. Run one read-only command or preview (list a directory, run the app locally, run an existing test) and confirm the behavior matches.

Common failure mode: accepting a confident explanation without opening the named files. The model sounds certain, cites plausible paths, and is wrong about one critical detail — a permission, a data source, a missing check. Recovery: compare every claim to the files and run one read-only check before approving any edit. Never promote an unverified memo into a task brief.

Next, you will turn that understanding into a job the model can actually finish: a bounded task with acceptance checks and explicit boundaries.