AI builds the feature

Here is the claim the whole course rests on. Met through a chat window, generative AI is a superb way to search. Commanded as an agent, it takes the iterative work off your hands, and your attention returns to the questions worth a human hour: what to build, what standard it must meet, and when to say no. What it produces is only as good as your ideas, and only as powerful as the hands that mold it. Everything in this module is a mold, a way of putting your judgment into a form the machine has to obey while it types.

A coding agent faces a problem none of the earlier specimens had: the thing it works on is far larger than what it can hold. Module 1.01 established the context window as a hard budget, and gave it a size: a 128,000-token window holds roughly 96,000 words, a 350-page book. A real repository blows past that at once. Paste a codebase in and you fill the window with material the current task does not need. Every token in the window conditions every token that follows, so the irrelevant bulk drags the output away from the instructions, and you still miss the file that mattered. Overfill it and one of two things happens: a raw API call comes back an error, or the harness trims the oldest turns to make the request fit and says nothing about what it dropped. So agentic coding is mostly an exercise in deciding what enters the window and when.

We build two things in this module, and you can hold both before we start. The first is the agentic coding loop: plan, edit, run, verify, commit, with the fourth step done by execution rather than by reading. The second is the set of four repository instruments, four kinds of file that hold the instructions for working on a codebase and load at four different moments, so the agent never needs the whole repository in its window to work in it correctly. Our specimen is this site’s own build: the trace below is the real workflow that produced the checkpoints you have been typing answers into, compressed, and the four instruments are the ones in this repository. By the end you will be able to run the loop yourself, choose the instrument a given piece of knowledge belongs in, and say what accumulates in a repository worked this way and what does not.

the loop, end to end

Five steps, and the fourth is the one people skip.

Plan. Read the relevant parts of the codebase, work out what needs to change, and write a human-reviewable plan before touching anything.

Edit. Apply targeted changes to specific files.

Run. Execute the build, the linter (the program that scans code for mechanical mistakes), the local server, whatever makes the change real rather than hypothetical.

Verify. Run the tests. Inspect the actual output. Confirm the change works and that nothing else broke.

Commit. Update the documentation the change affects, and commit it together with the code.

When tests fail, the loop goes back to the edit step with the failure in hand, and around again.

verification means execution

Why can an agent not verify software by reading it? Because “the code looks correct” is exactly the output the machinery is best at producing. Recall the mechanism from module 1.01: a model generates the statistically likely continuation, and after a plausible-looking diff, “this change is correct” is overwhelmingly likely. That sentence carries no information about whether the code runs. It is confabulation with code as its subject, and module 1.01’s conclusion applies to it word for word: nothing in the output distinguishes it from a true report, so the check has to come from outside the model.

Module 2.06 met the same failure one module ago, from the other side. Asked whether a write succeeded, an agent produces the likely continuation, “done”, and the control was read-back verification: no success is reported until a follow-up read shows the new state. Running the build is read-back verification for code.

So real verification means running the build and reading the exit code, executing the test suite and reading which tests failed, requesting the running page and reading the status code the server answers with. Facts from outside the model, applied to software. That is the last line of the reasoning, and it is the rule the loop is built around:

Verification comes from outside the model. It is a fact the run produced: an exit code, the name of a failing test, an HTTP status, a page exercised in a real browser. “The code looks correct” is a continuation, never a check. Anything not run is still a proposal.

The habit at this scale: when an agent tells you a change works, ask what it ran. If the answer is “I read the diff”, the loop has not reached step four.

Watch an agent run the whole loop on a real repository feature. This is the workflow that added the typed checkpoints to this curriculum, compressed to its beats:

Read the trace as the four instruments arriving in order, because that is what it is showing you. The rules file was already in the window before the first word was typed. The first skill fired before any design happened, and it read two knowledge docs. The plan the human had approved fixed the design before any file changed. The build ran, then the page was exercised in a browser, including the wrong answers on purpose. Two more skills fired at the close, and the docs went into the same commit as the code. The narrator’s tally is exact: one rules file, three skills, and one reviewed plan carried the human’s standards into a session where the human typed nothing. Now the instruments themselves.

the four repository instruments

Since the codebase cannot live in the window, the instructions for working on it get split across four file types, each loading at a different moment. Choosing the wrong instrument is the most common failure in setting up a repository for agents, so the question to carry into each one is: what does it cost, and when is that cost paid?

the rules file

CLAUDE.md or AGENTS.md, injected at the start of every session: build commands, directory layout, non-negotiable standards. In the trace it is the first thing the agent thinks about, and it had not been asked for: it was already there.

It costs tokens on every turn, so length here is expensive in a way it is nowhere else. Put in what is needed always, and push everything else into the other three instruments. The test for a line is plain: if it does not need to be true in every session, it belongs in a skill or a knowledge doc, with a pointer here at most.

skills

On-demand procedures in .claude/skills/. At startup only each skill’s header, its name and description, enters the window. The agent reads the full body when a task matches the trigger.

That two-stage load is the design. Twenty skills cost twenty short descriptions until one is needed. But it puts all the weight on the description, because the description is the only part of the skill the agent can see when it is deciding what to do. An agent discovers what it can do by matching the request in front of it against those descriptions; a skill whose description does not contain the words a task would contain is a skill that never fires. That is the last line of the reasoning:

Skills are found by their descriptions. Name them with active verbs and put explicit trigger conditions in the description. An agent discovers what it can do by matching the request against those descriptions.

Here is the shape of this repository’s sync-docs header, the skill that fires at the close of the trace:

---
name: sync-docs
description: Update documentation files in the knowledge/ directory to match code changes. Execute immediately before committing code.
---

Read that as: the name is a verb, so it says what will happen; the description says what it does and when to reach for it, in words a task about committing would contain. The body underneath, the full procedure, loads only after this header has matched.

You have seen this exact mechanism twice already. Module 2.03’s orchestrator chose a sub-agent by reading its description, which made that field an interface rather than documentation; module 2.06’s model chose an MCP tool the same way, from the description the server published. Description-as-interface is one idea appearing at three scales, and the failure is the same at all three: a vague description misroutes, and every individual part still works correctly in isolation.

knowledge docs

Present-tense documentation of architecture, schemas, and conventions, read when relevant. They describe how the system works now; what changed is git history’s job. In the trace, the first skill reads two of them, index.md and the interactive-modules doc, and comes back with the invariants and the pattern to reuse. That is the instrument doing its work: the agent did not scan the repository, it opened the two docs that cover the subsystem it was about to touch.

plan artifacts

A structured specification written before code: the change broken into phases, the risks named, and human approval required before editing begins.

This is module 2.07’s contract-first discipline, moved from images to code: define the contract in a structured form before rendering, because verification needs something to compare against. Same reason, too. It forces the judgment calls into the open while changing your mind still costs a sentence, and the plan is where you list the permanent decisions, the URLs and schemas and names, that cannot be refactored later.

And it does a second job that matters across long tasks. When work spans more turns than one window can hold, the written plan is the memory. Module 2.05 put it in one sentence: recall is grounding pointed at a store the system writes to itself. The plan artifact is that mechanism in its simplest possible form, the agent’s own conclusions written to a file and read back in, and in the trace it is what lets the agent design inside a decision the human made in an earlier session.

Practice the choice below:

the same idea across platforms

The instruments have different names in different tools, and the mechanism underneath is identical.

Claude Code reads project rules from CLAUDE.md, indexes skills from .claude/skills/, and loads a skill when the task matches its description.

Google Antigravity reads repository rule files and workflow definitions, works across terminals, editors, and browsers, and tracks its plans as markdown files.

MCP servers expose external development tools as JSON schemas over a network endpoint, exactly as module 2.06 described.

In all three, the precision of your description text decides whether the right thing gets selected.

what actually compounds

Two rules keep a repository worked this way honest, and both come out of mechanisms you already hold.

Start with the docs. Knowledge documents are the repository’s long-term memory, and module 2.05’s standard applies directly: a memory system must never hold a fabricated record, and if the store holds no matching data the agent says so. A stale doc is a fabricated record. It is a confident, dated, wrong recollection carrying the full authority of the codebase; the next session reads it into its window, where a false record conditions the output exactly as a true one would, and builds against a system that no longer exists. There is exactly one moment when the doc can be made true at no extra cost, which is the commit that changed the behavior it describes:

Docs ship in the commit that changed the code. A feature whose docs still describe the old behavior is unfinished, whatever the tests say, because the repository now holds a false memory.

Then the plan. The plan artifact is the human gate. Specification first, judgment calls in the open, approval before generation. It is the same contract-first move wearing a repository’s clothes.

Build ten features this way and the repository itself is what accumulates; be precise about that, because the tempting answer is the model. The weights never move; module 1.01 settled that on the first page of the course, and the mechanism modules opened up why: everything a model does with your repository is drawn from what the prompt supplied plus what training stored, and nothing you do in a session writes back to the second. Every feature deposits distilled knowledge: a sharpened skill, a new doc section, a decision-log entry explaining why an alternative was rejected. Feature eleven starts further ahead than feature one did, because the context available to it is better, not because anything learned.

This course practised these mechanisms on itself. Every module you have read shipped as a commit gated by a reviewed plan, verified in a live browser, and synchronised with its documentation in the same commit.

equip yourself with the materials

1. The complete repository starter templates — rules files, skill templates, knowledge docs, plan artifacts: agentic-coding-starter.md.
2. They mirror the production configuration this course’s own repository runs on. For a live public example, read AGENT_SETUP.md in the melchizedek-agents repo, also available as melchizedek-agent-setup.md.

what you can do with this today

Each mechanism in this module is a question you can ask of an agent, or of a repository, on a working day.

What did it run? When an agent reports that a change works, ask for the fact from outside the model: the exit code, the test names, the response. If it read the diff and stopped, send it back to step three.

Which instrument does this line belong in? For any instruction you are about to write down, ask when it needs to be in the window. Always: the rules file, and keep it short. When a certain kind of task comes up: a skill, named with a verb, with the trigger words in its description. When someone needs to know how the system works: a knowledge doc, in the present tense. For this one feature: the plan, approved before code.

Would this skill fire? Read its description as the agent will, against a task phrased the way you would phrase it. If the words do not overlap, rewrite the description, not the task.

Are the docs true after this commit? If a behavior changed and the doc that describes it did not, the work is not done, and the next session will pay for it.

Here is the whole loop on one card, in the vocabulary you now own:

your idea
  → PLAN      a plan artifact: phases, risks, the judgment calls listed for veto
              a human approves before any file changes
  → EDIT      targeted changes to named files
              [rules file always in the window · skills fire on description match
               · knowledge docs opened for the subsystem being touched]
  → RUN       build, lint, serve — make the change real
  → VERIFY    facts from outside: exit codes, failing test names, a page in a browser
              fail → back to EDIT carrying the failure text
  → COMMIT    code and docs in one commit, always; the gate skills last
  → DEPOSIT   a sharpened skill · a doc section · a decision entry
              the next feature starts further ahead

where part 2 ends

Seventeen modules, and you can now build the thing.

Part 1 gave you the instrument: what a model computes, how to run one on hardware you own, and the mechanism underneath — the vector that chooses each word from its three sources, what the weights hold, what your prompt does to them, and where the depth ceiling sits.

Part 2 gave you the craft: a written instruction that commits a model to one purpose, a testing discipline with five named variables, teams wired into shapes that fit the problem, and then the architecture — a whole agent network as one declarative file, memory that survives the session, tools discovered at runtime across a trust boundary, visual work checked by an eye that was never told what to expect, facts corroborated across independent channels, and a coding loop that proves its own work.

One principle runs through both: every guarantee you require from an AI system is a written constraint you can audit and test. A rule with a name, checkable against a transcript, a schema, or a test suite; never a hope about the model, and never a quality you asked for politely.

And none of it, this time, on trust. The prior that fills an empty slot, the window that drops the oldest tokens without a word, the reason a critic must be a separate call rather than a second question — you watched each of those mechanisms run in Part 1, and every design rule in this part stands on one of them.

What Part 3 adds is the evidence. Every agent in this part was judged by you, reading its output and deciding it was good enough, and that judgment does not scale past the last thing you happened to read. Module 3.01 turns it into a number: a dataset of real cases, judges independent enough to be trusted, a confidence interval before you believe a difference, and a gate in the deploy step that refuses a regression while it can still be refused.

Go on to Part 3, return to the syllabus, or reread Module 1.03 with a builder’s eyes; the mechanism reads differently once you have shipped something on top of it.