All appendices
Appendix A

AI Pair-Programming Toolkit

Which AI, ethical use, classroom guidelines

Appendix A — AI Pair-Programming Toolkit

“Iron sharpens iron, and one man sharpens another.” — Proverbs 27:17

The AI is the second piece of iron. It only sharpens you if you keep hold of the first piece — and the first piece is you.

This appendix does two jobs.

  1. It tells you which AI assistant to use for Phase 2 of this course — a free, browser-based option you can run on a locked-down school laptop with no admin rights — and how to set it up.
  2. It states the rules of the partnership: the prompts log every Phase 2 project requires, the honesty standard, and the classroom policy. These are not optional. The grader checks them, and Chapters 9 and 14 explain why they matter.

If you have not yet read Chapter 9, read it first. This appendix is the tool; Chapter 9 is the discipline. The tool without the discipline is how people ship code they don’t understand.

A note on the submission workflow. Phase 2 still submits the same way Phase 1 did — an OnlineGDB link or a public GitHub repo. That workflow lives in Appendix D of Coding 1 and hasn’t changed. This appendix is only about the AI half of the work.

A.1 — The course position on which AI to use

This book is deliberately vendor-neutral. The senior/junior skills you’re building — spec, review, test, honest disclosure — transfer across every competent code-capable model. We are not training you on a product; we are training you on a way of working. A student who learns to direct one assistant well can direct the next one, and the one after that, because the skill lives in you, not in the tool.

So the rule is simple: use any competent, browser-based AI assistant you can access for free, and use it the way Chapters 9–14 teach. The reps work the same regardless of which one you pick.

That said, “pick any” is not helpful advice to a student staring at a school laptop on the first day of Week 9. So below is a concrete recommendation, hedged as of 2026, because this is the most fast-moving corner of the whole course. Names, free-tier limits, and default models change every few months. Treat the specifics as a starting point, not gospel; trust the category, verify the current details yourself.

A.2 — The no-admin-rights path (start here)

Most of you are working on a school-managed laptop, a library computer, or a Chromebook where you cannot install software. Good news: you don’t need to. Every assistant we recommend runs entirely in a web browser. There is nothing to install, no admin password to enter, no PATH variable to fix. If you can open a browser and reach the internet, you can do every Phase 2 project.

This is the same philosophy as the rest of Coding 1 and 2: the instrument is the browser. You write code in OnlineGDB in one browser tab, and you keep your AI assistant open in a second tab. You move between them by switching tabs. That’s the whole setup.

Coach’s Note — If a tool ever asks you to “install an extension,” “download a desktop app,” or “run this command in a terminal” — stop. You do not need any of that for this course, and on a managed machine you probably can’t do it anyway. The plain website is enough. Browser extensions and CLI tools are real things professionals use, but they are Coding 3 material. For now, two browser tabs is the entire toolkit.

A.3 — Three concrete options (as of 2026)

As of 2026, the three most widely used code-capable assistants each offer a free tier that runs in the browser and is more than enough for this course. In alphabetical order, so you don’t read a ranking into the list:

  • Claude — at claude.ai. Create a free account; you get a capable default model with a daily usage limit. Strong at the spec-driven, “read this and explain it” work Chapter 9 leans on.
  • ChatGPT — at chatgpt.com. Create a free account; you get a capable default model with rate limits. The one most of your classmates will already have used.
  • Gemini — at gemini.google.com. Sign in with a Google account (you very likely already have one from school). Capable default model, generous free tier.

Any one of these is a valid course assistant. Pick one and stick with it for at least a project or two so you learn its quirks rather than chasing the newest thing every week.

A few honest caveats, all hedged as of 2026 because they will drift:

  • The free tier is enough; the best models usually aren’t free. Each vendor reserves its strongest model for a paid plan. You do not need the paid plan for this course. The free default models are entirely capable of the Phase 2 projects — and frankly, a weaker model that forces you to write a sharper spec (Chapter 10) is better training than a stronger one that lets you get lazy.
  • Free tiers have daily limits. You may hit a cap if you prompt carelessly all afternoon. That is itself a lesson: a senior who prompts precisely (Chapter 10) burns far fewer messages than one who prompts vaguely and re-rolls. Treat the limit as a forcing function for good prompting, not an obstacle.
  • “No account at all” options exist but are limited. There are sites that let you chat with these models without signing in. They tend to strip out the features you’ll want (saved history, file context) and you can’t trust where your text goes. For coursework, make a free account with one of the three above. It’s a one-minute step and it gives you a history of your sessions, which makes the prompts log (A.5) far easier to assemble.
  • Student offers come and go. As of 2026, at least one vendor has offered students extended free access through a verification program. If your school provides or endorses an AI account, use the one your instructor approves — it sidesteps the free-tier limits entirely and keeps everyone on the same footing. Check your syllabus first.

Coach’s Note — Chapter 9 says it plainly and so will I: the book never tells you which AI to use, because it doesn’t matter to the skill. The three names above are a convenience so you can start today, not a verdict on which is “best.” All three hallucinate APIs sometimes (Chapter 9.4). All three produce plausible-but-wrong code sometimes (Chapter 9.5). All three are vulnerable to the same review discipline. The skill transfers. That’s the whole point of Phase 2.

A.4 — Setting it up and using it

The setup is short on purpose.

Step 1 — Open two browser tabs

  • Tab 1: your code editor — OnlineGDB (or whichever web IDE you’ve been using). See Appendix D of Coding 1.
  • Tab 2: your AI assistant — one of the three from A.3.

You will spend Phase 2 moving between these two tabs. That is the workspace.

Step 2 — Create a free account

On the assistant’s site, sign up (email or a school Google account). An account gives you saved conversation history, which you’ll need when you build the prompts log. Without an account, your prompts vanish when you close the tab, and reconstructing them later is miserable.

Step 3 — Use it as the junior, not the oracle

This is the part that matters, and it’s the part Chapters 9–13 train. A quick reference for how to drive it:

For pair-programming a single class or method (the Project 9 / Chapter 9 workflow):

  1. Write the spec yourself first — signature, inputs, outputs, error behavior, examples (Chapter 2, Chapter 10).
  2. Paste the spec into the assistant with explicit constraints: language version (Java 17), allowed libraries, internal data structures, “do not add features I didn’t ask for.”
  3. Read every line it returns. Hunt for hallucinated APIs and plausible-but-wrong edge cases.
  4. Make your fixes. Write the tests yourself, or prompt for them and then review them hard.

For spec-writing and sharpening a prompt (Chapter 10):

  • Lead with the signature, not a prose description. “Implement this exact method:” beats “write a method that…”
  • Specify by example. Concrete input→output pairs remove ambiguity a sentence can’t.
  • Add negative constraints — what it must not do. Half of bad AI output is unrequested extra stuff.

For refactoring and driving to green (Chapters 11 and 13):

  • Give it the failing test output and the relevant code, then form a hypothesis and ask a targeted question — “Walk through parseDate("2026-05-24") line by line and tell me where the year becomes 26.” Diagnostic prompts first, directive fixes once you know the cause.
  • If you’ve been stuck thirty minutes with no progress, stop prompting and fix it yourself. That information is also useful, and a senior knows when to take the keyboard.

Coach’s Note — A practical habit that pays off all semester: keep the assistant in a tab you can see while you read its code in the editor. The temptation in Phase 2 is to copy-paste the AI’s answer and move on. Resist it. Read the answer in place, out loud if you have to. The moment after the AI hands you code is the moment most Phase 2 mistakes are made — see Chapter 9.10.

A.5 — The prompts log: the non-negotiable artifact

Every Phase 2 project deliverable includes a prompts log — a chronological record of every prompt you sent the assistant, with rough timestamps, in the order you sent them. The grader reads it. It is not busywork; it is the evidence that you directed the work.

Why it exists

Three reasons, all from Chapter 9:

  1. It proves you were the senior. “I directed the AI” is one of the three honest statements from Chapter 14. The log is what makes that statement checkable instead of a faith claim.
  2. It teaches you to see your own process. Reading back your prompts shows you where a bad idea entered, where a vague prompt produced bad code, where a sharp prompt fixed it. That reflection is where the growth is.
  3. It’s honest disclosure. Not because using AI is shameful — Chapter 9.8 is clear that AI-assisted work is genuinely yours — but because the discipline of saying plainly what the tool did and where you directed it is itself part of the work.

What goes in it

Keep it simple. For each meaningful exchange:

  • A rough timestamp (you don’t need seconds — “Tue ~3:10 PM” is fine).
  • The prompt you sent, verbatim or close to it.
  • One line on what you did with the response — accepted it, rejected it, fixed two lines, found a hallucinated method, wrote five tests against it. The grader cares more about your moves than the AI’s text.

Log everything, including the small stuff. Especially the small stuff. “It was just a quick question” is exactly the prompt students skip, and skipping it leaves a hole in the record. The discipline is the point.

Coach’s Note — You don’t need any special tool for this. Keep a running text note as you work and paste prompts into it as you send them. Saved conversation history (the reason you made an account in A.3) means you can reconstruct it at the end if you fall behind — but reconstructing is harder than logging as you go. Build the habit of logging in the moment.

The other half: “you must understand every line”

The prompts log proves you directed the work. This rule proves you own it:

You are accountable for every line you ship. If a bug ships, “the AI wrote it” is not a defense — you reviewed it, you approved it, your name is on it (Chapter 9.8, Chapter 14). Before you submit, you should be able to open your own file and walk a stranger through every architectural decision, every test, every place you redirected the assistant, every line of the code. If you can’t — if you stammer because you’ve never actually read your own submission — then you didn’t do the senior work, and pretending you did would be the lie Chapter 14 is about.

A useful gut-check, straight from Chapter 14: imagine an interviewer a year from now with this project open, asking “walk me through this.” If you can talk for ten minutes about it, you wrote it. If you can’t, go read it until you can.

A.6 — Ethical use and the honesty standard

The Eighth Commandment — “You shall not bear false witness against your neighbor” (Exodus 20:16) — is the most relevant of the ten for the work we do in Phase 2. Chapter 14 unpacks it at length. Here is the short, binding version.

Three things are almost always honestly available to you, and together they describe what a senior engineer actually does:

  1. “I wrote the spec.” — you decided what the program should do.
  2. “I directed the AI.” — you wrote the prompts, read the responses, caught the bugs. (The prompts log proves it.)
  3. “I tested it.” — you wrote and ran the tests; the result is verified, not just typed.

If you can honestly say all three about a project, you wrote the project. The AI helped. The author is you. This is the doctrine of secondary causes and the Lutheran doctrine of vocation applied to engineering: the tool doing real work does not erase your authorship, any more than a sharp pencil erases the writer’s — but the pencil is not nothing, so you say honestly what it did (Chapter 9.8).

What you must always do:

  • Follow the rules where they’re stated. This course requires a prompts log on every Phase 2 project. Log every prompt. If a future class, contest, or employer forbids AI, don’t use it; if they require attribution, attribute.
  • Answer directly when asked. “Did you use AI on this?” gets a true, specific answer — what it did, which parts, what you did by hand (Chapter 14.4, Scenario B).
  • Disclose when the work would be misread without it. Submitting AI-generated code where the reader assumes you typed every line, without correcting that assumption, is dishonest by omission. When in doubt, add the disclosure — one extra comment line costs nothing; being caught omitting it costs your reputation.

What does not require a flag (Chapter 14.2): using an IDE, searching the web for syntax, asking the AI to explain a piece of code you then read yourself (that’s reading, not writing), or autocomplete of a variable name. The boundary isn’t “did a tool touch this,” it’s “would my reader form a wrong impression of my contribution if I didn’t say something.”

The line that holds it all together: the reps are the point. AI can shortcut the output. Nothing can shortcut the formation. Don’t use the assistant to skip the rep that builds the skill — that’s not cheating the grade so much as cheating yourself, and it’s the one form of “winning” this whole course is built to prevent.

A.7 — Classroom policy (read your syllabus, then this)

Your instructor’s syllabus is the final word. Where this appendix and the syllabus disagree, follow the syllabus. With that said, the course’s default Phase 2 policy is:

  1. AI is on, and expected. Phase 1 (Weeks 1–8) was AI-off by rule; you earned the right to use it by proving you don’t need it. Phase 2 (Weeks 9–16) expects AI on every project. Not using it is not “playing it safe” — the projects are sized for a senior with a fast junior.
  2. Any competent browser-based assistant is allowed. Use one of A.3, or whichever one your instructor approves. If your school provides an AI account, prefer it.
  3. A prompts log is required on every Phase 2 project. No log, or an obviously incomplete one, is a failed deliverable. See A.5.
  4. You sign your work, and you own every line. Your name on the project means you reviewed, tested, and stand behind all of it. “The AI wrote it” is never a defense for a bug you shipped.
  5. Honest disclosure, every time. Follow A.6. The reflection on your final project is a graded honesty component, not a formality.
  6. Don’t use AI to skip the reps. The exercises and reflective drills (especially Chapter 14’s) are meant to be done by you. Channeling them straight through an AI defeats the only purpose they have.

Coach’s Note — Notice that none of these rules are about catching you. They’re about making you the kind of engineer a team can trust — one who knows what’s in their code and can say so honestly. In the hands of a senior, AI makes good code faster. In the hands of someone who isn’t a senior, AI makes bad code faster. You did the eight weeks of Phase 1 to earn a place in the first group. These rules are how you stay there.

A.8 — When things go wrong

“The assistant won’t load / I hit the daily limit.” Free tiers cap usage. If you’re capped, you were probably prompting loosely — re-read Chapter 10 and prompt sharper next session. In the meantime, you can switch to one of the other two options in A.3 (a fine reason to have an account on more than one). If a school-provided account exists, it usually has higher limits.

“It gave me code that doesn’t compile.” Good — the compiler caught a hallucinated API (Chapter 9.4). Look up the unfamiliar method in the Java 17 docs; if it isn’t there, it doesn’t exist. This is a feature of the workflow, not a failure of it.

“It keeps confidently giving me the wrong answer.” Your prompt isn’t narrowing the problem. Give it the error message, the test output, the relevant code, and a hypothesis (Chapter 13). If thirty minutes pass with no progress, stop prompting and fix it yourself.

“I forgot to log a bunch of prompts.” Open your saved conversation history (the reason you made an account) and reconstruct the log as best you can, in order, with rough timestamps. Then log in real time going forward. An honestly-reconstructed log beats a fabricated tidy one — and a fabricated one is exactly the false witness A.6 forbids.

“Which one should I actually pick?” Any of the three in A.3. Stop agonizing and start the rep. The skill is in how you use it, and that skill is identical across all three.

Up next: You have the tool and the rules. Open Chapter 9 if you haven’t, then start Project 9 — your first formal spec → AI → review cycle. For the submission workflow (the OnlineGDB / GitHub link), see Appendix D of Coding 1.