Appendix C — The Agentic-AI Toolkit

“The simple believes everything, but the prudent gives thought to his steps.” — Proverbs 14:15 (ESV)

This is the policy-and-setup document the whole of Phase 2 depends on. Read it before Week 9, and re-read the rules section before every Phase 2 project. The toolkit is the easy part. The discipline is the point.

In Coding 2 you paired with AI the way a senior pairs with a junior: you described, it suggested, you decided, you typed. The AI was a conversational partner — it produced text and code; you moved every file and ran every command. Coding 3 advances to agentic AI, and the difference is not cosmetic.

C.1 — What “Agentic” Means

An agent acts. Given a goal and access to your workspace, a coding agent will, on its own, across many steps:

• read your files to understand the code,
• edit and create files,
• run commands — install packages, start servers, run your tests,
• read the output, notice it failed, and iterate — fixing and re-running until it believes the goal is met.

That loop — observe, act, observe, act — is what makes it an agent rather than a chatbot. It’s enormously more powerful. A well-specified task that would’ve been twenty rounds of copy-paste in Coding 2 becomes one instruction the agent carries out end to end.

It is also enormously more dangerous. A chatbot that hallucinates a wrong answer wastes a paragraph. An agent that misunderstands can delete files, drop a database table, leak a secret into a commit, or pip install something you didn’t ask for — and then keep going, building more on top of the mistake. Power and danger are the same property viewed from two sides.

Coach’s Note — The mental model that keeps you safe: an agent is a fast, tireless, literal-minded junior with root access and no fear. It will do exactly what you said, at speed, including the parts you didn’t mean. Your job is not to be amazed by it. Your job is to supervise it like the liability it is and the asset it can be.

C.2 — Setting One Up

This course is vendor-neutral on purpose. Agentic coding tools are improving monthly, and the skill you’re building — directing an agent and keeping judgment in your hands — transfers across all of them. Do not over-invest in one product’s quirks.

You need one of the following:

• A coding-agent CLI — a command-line tool that you run inside a project folder and give tasks to. (This is what most of the course examples assume, because the terminal is where the work lives.)
• An agentic editor extension — an in-editor agent (e.g. the agent extension in VS Code from A.4) that can read your repo, edit files, and run a terminal.

Any current, competent, code-capable agent works. Pick one that:

1. Can operate on a workspace — a folder you point it at, where it reads and writes files and runs commands. You are granting it that folder; it should not reach outside it.
2. Has a free or low-cost tier sufficient for coursework where possible. You should not need an enterprise plan to pass this class.
3. Shows you what it’s about to do and ideally asks before destructive actions. Prefer tools with an approval/confirmation mode and use it.

Set it up, point it at a throwaway practice folder first (not a project repo), and give it a trivial task — “create a file hello.py that prints hello, run it, and show me the output.” Watch what it does. Notice every place it ran a command. That watching habit is the skill.

Coach’s Note — Run the agent in a git repo, always. git is your seatbelt: if the agent makes a mess, git diff shows you exactly what changed and git checkout . throws it away. Commit known-good states often so you always have a clean point to fall back to. An agent in a non-versioned folder is a chainsaw with no guard.

C.3 — The Human-in-the-Loop Rules (the heart of it)

This is the part you cannot skip and cannot fake. The agent builds modules. You are the architect. These responsibilities are yours, never delegated:

• The architecture — what components exist, what each is responsible for, and the seams between them.
• The constraint analysis — what this problem actually demands in speed, memory, scale, and consistency.
• The tool choice — SQLite vs Postgres vs Mongo; Node vs FastAPI; thread vs process vs event loop. This is the course skill. (See the whole book.)
• The data model — the schema, the keys, the relationships, what’s embedded vs referenced.
• Every judgment of correctness, security, and consistency — is this right? is this safe? does this hold under concurrency?

And two practices wrap all of it:

• You read everything the agent writes. Every file, every command it ran. If you wouldn’t sign your name under a line, it doesn’t ship. “The agent wrote it” is not a defense for a bug or a vulnerability in your repo.
• You verify; you do not trust. Run the tests yourself. Hit the endpoint yourself. Check the database yourself. The agent’s claim that “all tests pass” is a claim to be checked, not a fact.

The two-column rule

Coach’s Note — Never paste a real secret into an agent’s context, and never let an agent run against production data or a live user database. Give it a local dev database with fake data. A leaked key or a dropped production table is not a learning experience you recover from gracefully. Treat secrets the way you’d treat a loaded weapon at the range: assume it’s live, point it nowhere dangerous.

C.4 — The Required agent-log.txt

Every Phase 2 project must include an agent-log.txt in its repo. It is graded. It is how your instructor sees the skill that’s actually being assessed: your direction of the agent and your judgment over it. A project with great code and no honest log scores lower than a humbler project with a clear one, because the log is the evidence that you were the architect.

The log records, for each task you delegated: what you asked, what the agent did, where it was wrong, where you intervened, and what you decided yourself. The “where it was wrong” and “what I decided” lines are the most important — they’re the proof of supervision. A log that says “asked the agent, it worked, done” for everything is a confession that you weren’t watching.

Template (copy this into your repo)

# Agent Log — Project N: <name>

## Architecture decisions I made myself (before any agent ran)
- Tool choice: <e.g. PostgreSQL, because ...the constraint that drove it...>
- Data model: <the key entities and relationships, and why>
- Component breakdown: <the modules I decided should exist>
- Concurrency / scaling stance: <if relevant>

## Delegation log

### Task 1 — <short title>
- **I asked:** <the instruction I gave the agent>
- **The agent did:** <files it created/edited, commands it ran>
- **Where it was wrong / risky:** <bug, bad assumption, unsafe command, hallucinated API — or "nothing, but I checked X, Y, Z">
- **Where I intervened:** <what I corrected, rejected, or rewrote myself>
- **I verified by:** <the test I ran / endpoint I hit / query I checked>

### Task 2 — <short title>
- **I asked:**
- **The agent did:**
- **Where it was wrong / risky:**
- **Where I intervened:**
- **I verified by:**

<...one block per delegated task...>

## What I would not let the agent decide, and why
- <the judgment calls I reserved — the architecture, the tool, the schema, a security choice>

Fill it as you go, not at the end. A log reconstructed from memory the night before the deadline reads exactly like what it is.

C.5 — Classroom & Academic-Integrity Policy

Read this slowly. It governs how Phase 2 is graded and where the line is.

Directing the agent is the skill being graded. Using an agent in Phase 2 is not cheating — it’s the assignment. We want you fluent at delegating well-specified work to a fast partner. That’s the working architect’s job in 2026 and after.

The failure is passing off the agent’s judgment as your own understanding. If the agent chose the database and you can’t explain why that database, under what constraint, you haven’t done the work — you’ve watched it being done. If your agent-log.txt claims you made an architecture decision you actually let the agent make, that’s an integrity violation, the same as claiming someone else’s reasoning as yours has always been.

So the bright line is:

• Allowed and expected: the agent writes code you specified, runs tests, scaffolds, refactors what you’ve read. You direct, read, verify, and decide.
• Not allowed: the agent makes the judgment calls (tool, architecture, schema, the constraint trade) and you submit them as your own understanding without the log telling the truth about it.

The live sessions are where fluency can’t be faked. Two checkpoints are deliberately structured so the agent can’t carry you:

• The midterm (Week 8) is closed-AI. Phase 1 is AI-OFF entirely, and the midterm is hand-built, in the room. It proves you own the cost model — Big-O, the structures, the speed/memory trade — in your own head.
• The final (Week 16) includes a live integration session. You’ll be asked to make and defend architecture and tool-choice decisions in real time, explain code in your own repo, and reason about a constraint you haven’t seen before. An agent built your modules during the term; the final checks that you were the architect over them.

If you direct the agent well, read everything, verify, and keep every real decision in your own hands — the live sessions are easy, because you actually know your system. If you let the agent think for you all term, they’re where it shows. That’s by design.

Coach’s Note — The most dangerous sentence in Phase 2 is “the agent handled it.” Sometimes that’s a fine thing to say about boilerplate. Said about an architecture decision, it’s the sound of the skill slipping through your fingers. Stay the architect. The agent is the fastest junior you’ll ever lead — and a junior who is never in charge.

Up next: Back to Chapter 9 to start Phase 2 — now that your agent is set up and you know the rules. Make sure your toolchain (Appendix A) and databases (Appendix B) are ready first.