Chapter 09 · Reps

Pair Programming With AI — Reps

← Back to Chapter 9

Chapter 9 — Reps

Conditioning, not grading. Type every line — except where the rep explicitly tells you to prompt the AI. Phase 2 reps mix solo work with AI work; pay attention to which is which.

You need:

  • A working Java 17 environment (Appendix B or OnlineGDB with Java selected).
  • JUnit 5 available (OnlineGDB has it; locally, see Appendix B).
  • An AI assistant available in a separate window — Claude, GPT, Gemini, or whatever the course is using (Appendix A).

For every rep that involves prompting the AI, keep a running log in a single file reps-prompts.txt. Same format you will use for prompts.txt in projects: timestamp, prompt, response (or a link), and one sentence on what you learned.

Reps 1–3: First Pair-Programming Cycle

Rep 1 — Tiny spec, AI implementation

Write a short spec (5–10 lines) for this method:

secondLargest(int[] nums) → int
  Returns the second-largest element of nums.
  If nums has fewer than 2 elements, throws IllegalArgumentException.
  If all elements are equal, throws IllegalArgumentException.
  Otherwise returns the second-largest *distinct* value.

Hand the spec to your AI assistant with a prompt like:

Implement this Java 17 static method to the spec below. Use only the standard library. No comments needed in the code, but include a Javadoc on the method.

Save the AI’s response. Now read it line by line. Find:

  1. At least one thing the AI did well (good name, idiomatic use of Arrays.stream, anything).
  2. At least one thing you would change (extra cruft, weak name, edge case not handled).

Write both findings in your log.

Rep 2 — Write the tests yourself

For your spec from Rep 1, write at least 5 JUnit tests by hand — no AI. Cover:

  • Normal case (two distinct values).
  • Three or more values.
  • Duplicates — {3, 3, 1} should return 1.
  • Fewer than two elements — should throw.
  • All elements equal — should throw.

Run the tests against the AI’s implementation. Report passing/failing.

If any fail, the bug is in the AI’s code (or, occasionally, in your test). Determine which.

Rep 3 — Fix the code, not the tests

For any failing test in Rep 2, fix the AI’s code so the test passes — without changing the test. Do the fix yourself; do not re-prompt for a fix. The point is the senior’s experience of reading wrong code and seeing the fix.

Log what was wrong and what you changed.

Reps 4–6: The Hallucination Hunt

Rep 4 — Prompt for the impossible

Ask your AI assistant:

In Java 17, what’s the standard library method for parsing a CSV row into a String[]?

There is no such standard library method. There is no String.splitCsv(), no Arrays.parseCsv(), no Files.readCsvLines(). (There are third-party libraries — OpenCSV, Apache Commons CSV — but the AI was asked about the standard library.)

Observe the response. One of three things will happen:

  1. The AI honestly says “there isn’t one; you’d need to write it yourself or use a third-party library.”
  2. The AI invents a method name like String.splitCsv() or CsvUtils.parse().
  3. The AI shows you a real method like String.split(",") and quietly warns that it doesn’t handle quoted fields.

Log which one happened. If your AI invented something, that is your hallucination case study — paste it.

Rep 5 — Verify with the compiler

Take whatever Java code the AI produced in Rep 4. Paste it into a Java 17 file. Try to compile.

If it compiles: the AI used real methods. Note this in your log.

If it does not: read the compiler error. The error tells you exactly which symbol the AI invented. Save the error message in your log.

This is the test you should run on every piece of AI code: does it compile? If not, the AI lied (cheerfully and confidently), and the compiler told you so.

Rep 6 — Find the API in the docs

Pick one method from the AI’s output in Rep 4 or Rep 5 that you weren’t already familiar with. Look it up in the official Java 17 docs at docs.oracle.com/en/java/javase/17/docs/api/.

Confirm it exists. Confirm the signature matches what the AI wrote. Confirm the behavior matches what the AI claimed.

Log whether the AI was accurate on all three counts.

Reps 7–8: Review Discipline

Rep 7 — Five tests on someone else’s code

Take the EventLog implementation from §9.7 of the chapter (download EventLog.java) — you can also re-prompt the AI for it, or copy from the chapter. Without looking at the chapter’s test suite, write five tests of your own. Try to cover:

  • One test for a feature that obviously works.
  • One test for a feature you think might be subtly broken.
  • One test for a boundary case (n = 0, empty input, etc.).
  • One test for an error case (bad input that should throw).
  • One test for the invariant (e.g., events are stored in insertion order, internal collections aren’t exposed).

Run them. Note which pass, which fail. For any failure, decide: is the code wrong, or is your test wrong?

Rep 8 — Find the bug the AI didn’t see

Here is a real-shaped piece of AI output. It compiles. It works on most inputs. There are at least two bugs.

public static int countWords(String s) {
    return s.split(" ").length;
}

Find both bugs (hint: consider null, the empty string, and leading/trailing/multiple spaces). Fix them in a corrected version. Document the bugs and your fixes.

Reps 9–10: Specifying Tightly

Rep 9 — Two prompts, same problem

Pick this small problem: a method that returns the most-frequent character in a string, breaking ties by alphabetical order.

Write two prompts:

  1. Vague: “Write Java code that finds the most common character in a string.”
  2. Precise: “Write a Java 17 method with signature public static char mostFrequent(String s). If multiple characters tie for highest frequency, return the alphabetically smallest. If s is null or empty, throw IllegalArgumentException. Use only java.util and java.lang. Include Javadoc.”

Send both. Save both responses. Compare:

  • Does the vague prompt’s output handle nulls? Empties? Ties?
  • Does the precise prompt’s output do something visibly different in those edge cases?

Log the comparison in one paragraph.

(This is a preview of Chapter 10 and Project 10. The point of running it now is to feel the difference between vague and precise before the next chapter formalizes it.)

Rep 10 — Specify what the AI should NOT do

Pick this problem: count the number of vowels in a string.

Write a prompt that includes at least three negative constraints:

  • Do not use any third-party libraries.
  • Do not use regular expressions.
  • Do not create any helper methods; everything goes in one method.

Send. Observe whether the AI honored all three constraints. (Spoiler: it usually does, because constraints in the prompt land.)

Log the result.

Reps 11–12: Signing Your Work

Rep 11 — Write a one-line accountability statement

For one of the prior reps that involved AI, write a single sentence you could honestly sign your name to. Format:

“I wrote the spec, prompted the AI for an implementation, reviewed every line, made [N] changes, wrote [M] tests, and stand behind the result.”

Fill in real numbers. If you can’t honestly say that sentence, redo the rep.

This sentence is the thing the rest of Phase 2 is training you to be able to say truthfully. Get used to writing it.

Rep 12 — Break It On Purpose

Six Phase 2 mistakes. Apply each, observe, learn:

  1. Accept the first answer. Take any prior rep’s AI output and ship it unread. Then read it. Find a bug. (There will be one.)
  2. Skip the spec. Ask the AI for “a class that tracks user activity” with no further detail. Compare the output’s shape to what you’d actually want.
  3. Don’t log a prompt. Try, for one rep, to recall exactly what you typed yesterday. Notice you can’t. This is why you log.
  4. Compile-only check. Take AI code that compiles but is wrong (Rep 8’s countWords, for example). Ship it without tests. Then write a test that catches the bug. Notice how cheap the test was relative to the bug.
  5. Skip review on “obvious” code. Take a 5-line AI output and assume it’s correct. Then read it carefully. Was it?
  6. Hand-author every line for a class the AI could have written. Time yourself. Notice how much slower it is, and notice which parts of the slowness were valuable (you thought about edge cases) and which weren’t (you typed boilerplate).

Each of these mistakes is one a real engineer makes regularly. Make them on purpose now, in low-stakes reps, so you recognize them later.

Done? One Last Thing.

Open a fresh file. Write down, in your own words, what each of these phrases means:

  • “Senior/junior model”
  • “Hallucinated API”
  • “Plausible but wrong”
  • “Spec → AI → review”
  • “Secondary causes”

If any phrase comes out muddy, reread the chapter section. The vocabulary is part of the move.

Up next: Project 9 — Project 9: Spec → AI → Review.