All projects · Chapter 13: Iterative Refinement
Project 13

Drive AI to Green

Apologetic question: "What is patience in correction?"

Project 13 — Drive AI to Green

“My son, do not despise the LORD’s discipline or be weary of his reproof.” — Proverbs 3:11

“The first draft of anything is shit.” — Ernest Hemingway, who never used an AI assistant but understood iterative refinement

Chapter: 13 — Iterative Refinement Due: End of Week 13 Submit: A link to your code — an OnlineGDB Java project URL or a public GitHub repo URL — containing your final (green) Java source, the original (red) source for diff reference, the JUnit test file, and a complete prompts.txt log. See Coding 1’s online-coding workflow appendix for the OnlineGDB workflow and Appendix A for AI assistant setup.

Allowed during this project:

  • The course-default AI assistant (any code-capable model — see Appendix A).
  • The Java standard library and JUnit 5.
  • Your textbook and prior project notes.
  • The compiler and the test runner.

NOT allowed:

  • Editing the implementation file directly by hand at the Normal tier (this is the entire point of the exercise — every change goes through the AI).
  • Editing the test suite. Ever.
  • A second person’s help on the prompts.

The Setup

You are handed a working-ish Java project. It compiles. It runs. But out of its JUnit test suite, five tests fail.

Your job is to drive the test suite to all-green. Your constraint: you cannot edit the implementation file directly. You can only prompt an AI assistant, accept its edits, and re-run the tests.

This is a deliberately artificial constraint. In real software you would absolutely edit the code by hand when it’s faster. The constraint exists to force you to practice the prompting discipline that Chapter 13 spent 16 sections teaching. By the end of the project, prompts that you previously would have written casually should be written tightly, with explicit scope, with embedded tests, with diagnostic-first patterns.

Phase 2 is partnership. This project is a stress test of the partnership.

Learning Targets

By completing this project, you will demonstrate that you can:

  • Read failing JUnit test output, form a hypothesis about the bug, and articulate the hypothesis in a prompt.
  • Use diagnostic prompting (§13.2) to surface a bug rather than guess one.
  • Scope a fix prompt to a single method (§13.3).
  • Embed a failing test in a prompt as the spec (§13.4).
  • Recognize and break an oscillating correction loop (§13.6).
  • Decide when to stop iterating and write code yourself (§13.7) — for the Medium and Hard tiers, this is allowed.
  • Keep a complete, timestamped prompt log that another engineer could audit.

Normal Tier

Goal: Drive 5 failing tests to green using only prompts. Log everything.

Required features

  1. Starting code. Your instructor provides a worked instance of this project — a StudyStreakTracker that records daily Scripture-study check-ins. Download all three files:

    • StudyStreakTracker.java — the implementation with bugs (the red <Module>.java). Five planted logic bugs; it compiles and runs.
    • StudyStreakTrackerTest.java — a JUnit 5 test suite with 12 tests, of which 5 fail and 7 pass (the <Module>Test.java).
    • StudyStreakTracker-original.java — an untouched copy of the red implementation, kept for the diff the grader runs (the <Module>-original.java). Don’t compile this alongside the others — it’s a reference artifact.
    • Standard JUnit 5 imports work; in OnlineGDB use the “Java” project type and the bundled JUnit, or add org.junit.jupiter:junit-jupiter:5.10.0 if you’re on local Maven (see Appendix B).

  2. The constraint. You may not edit <Module>.java directly. Every change is produced by an AI assistant and pasted in by you. You may not change <Module>Test.java ever — not formatting, not imports, not whitespace.

  3. The deliverable. A final <Module>.java where all 12 tests pass.

  4. The prompt log. A prompts.txt file in your submission, with this structure:

    # Project 13 — Prompt Log

**Student:** <your name>
**AI assistant used:** <name + model version>
**Start time:** <timestamp>
**End time:** <timestamp>
**Total prompts sent:** <count>
**Tests failing at start:** 5
**Tests failing at end:** 0

## Prompt 1
**Timestamp:** <time>
**Hypothesis I was testing:** <one sentence>

    <full prompt text, exactly as you sent it>

    
**AI response (summary):** <one paragraph — you don't need to paste the full response, but summarize what changed>

**Test result after applying:** <e.g., "4 fail, 8 pass — fixed test X">

## Prompt 2
...

  5. The reflection. At the bottom of prompts.txt, a 200–400 word reflection answering: (a) which prompt template helped most? (b) where did you get stuck? (c) did you ever feel the urge to break the no-direct-edit rule, and if so, why?

Normal-tier rubric (out of 100)

CriterionPoints
All 12 tests pass in the final code30
prompts.txt is complete (every prompt logged with timestamps)15
Each prompt entry includes a stated hypothesis10
Prompts demonstrate scoping (Template 3 from §13.11) at least twice10
At least one prompt is purely diagnostic (no fix requested) (Template 1)10
At least one prompt embeds a failing test verbatim (Template 4)10
Total prompt count ≤ 15 for the 5 bugs10
Reflection is specific (not generic)5

Note on the prompt-count grade: 15 prompts for 5 bugs is generous — about 3 prompts per bug. If you exceed 15 prompts but still reach green, you get partial credit (drops to 5 points). If you reach green in 5 prompts or fewer, you get a +5 bonus on the total. Quality over quantity.

Medium Tier (+up to 25% extra credit)

Goal: Catch a planted regression and redirect.

Required features

The Medium-tier starting code has the same 5 starting bugs plus a hidden regression trap: one of the most common AI fixes will accidentally break a previously-passing test. You won’t know which fix triggers it until it happens.

M1. Catch the regression. When a previously-passing test starts failing, your next prompt must explicitly address it. Your prompts.txt should have a clearly labeled section:

## Regression caught at Prompt N

**Previously passing test that now fails:** `<test name>`
**Hypothesis about what the AI broke:** <one sentence>
**Redirect prompt:**
```

Result: <e.g., “all 12 tests passing”>


**M2. Joint-constraint prompt.** Your redirect must use the joint-constraint pattern (§13.6) — paste both tests, ask the AI to satisfy both simultaneously, and constrain the output scope.

**M3. Add a regression test.** *After* reaching green, add one new JUnit test to a *separate* file `RegressionTest.java` (it's OK to write this file by hand — it's a test file, and you wrote the regression scenario yourself, so you're the spec author). The new test should specifically guard against the regression you encountered. Run the full suite again to confirm the regression test also passes.

### Medium-tier additional points (+up to +25)

- Regression caught and documented: +10
- Joint-constraint prompt used to fix the regression cleanly: +10
- New `RegressionTest.java` written by hand and passing: +5

---

## Hard Tier (+up to 25% additional extra credit)

**Goal:** Run the exercise twice with two different AI assistants. Compare and analyze.

### Required features

**H1. Second assistant.** Repeat the entire Normal-tier exercise with a *different* AI model. Use the same starting code. Use the same test suite. Submit a second `prompts-assistant-2.txt` log alongside the first.

The course-default assistant (Appendix A) is your first. Your second can be any other code-capable assistant available to you — your school's licensed assistant, a different free-tier offering, the same vendor's smaller or larger model, etc. Name both clearly in each log's header.

**H2. Comparison document.** Submit a `comparison.docx` (400–600 words) that compares the two runs along these axes:

1. **Prompt count to green.** Which assistant needed more? Why?
2. **Failure modes.** Did each assistant tend to make the same kind of wrong fix, or different kinds? Specific examples.
3. **Scoping behavior.** Did either assistant respect "modify only this method" better than the other?
4. **Hallucination rate.** Did either invent more nonexistent APIs?
5. **Where you would use each.** A one-paragraph recommendation: in what kind of task is each assistant's behavior an advantage?

The comparison is not a vendor war. It is a calibration exercise — you are learning the *shape* of each assistant's behavior so you can route work intelligently in the future.

**H3. Save your prompt library.** Append your three best prompts from this project (the ones that produced the cleanest, most efficient fix) to your personal `prompts/library.txt` (start the file if you don't have one). Each entry: the template, the situation it suited, the result. This file is yours to keep across the rest of the course.

### Hard-tier additional points (+up to +25)

- Second-assistant log complete and credible: +10
- Comparison document with specific examples (not generic "Assistant A was better"): +10
- Prompt library updated with 3 well-annotated templates: +5

---

## Submission

**Submit one URL** via the course portal:

- **OnlineGDB project link** (recommended). Create your project at [onlinegdb.com](https://www.onlinegdb.com/), choose **Java** as the project language, add your `<Module>.java`, `<Module>Test.java`, and (for Medium) `RegressionTest.java`, then attach `prompts.txt` (and `prompts-assistant-2.txt` + `comparison.docx` for Hard) as additional text files. Share the project link.
- **GitHub repo link** (alternative). Push everything to a public repo. The grader will compile with `javac *.java` against bundled JUnit 5 and run the test suite.

### What the submission must contain

1. **`<Module>.java`** — your final, green implementation. Filename matches the public class name.
2. **`<Module>Test.java`** — unchanged from the starting code. The grader will diff this against the original; any modification fails the project.
3. **`<Module>-original.java`** — the starting (red) version, untouched. Provided so the grader can see the diff.
4. **`prompts.txt`** — the prompt log (see Normal-tier section 4 for the required shape).
5. **(Medium)** `RegressionTest.java` — your regression-guarding test.
6. **(Hard)** `prompts-assistant-2.txt` and `comparison.docx`.
7. **A reflection comment block** at the very top of `<Module>.java`:

/* * Project 13 — Drive AI to Green * * Tier targeted: Normal / Medium / Hard * AI assistant used: <name + version> * Total prompts sent: * Tests green at end: / * What I learned: one short paragraph * Where I struggled: one sentence */


The grader will: open the project, read the comment block, read `prompts.txt`, run the test suite, and grade against the rubric. The prompt log is graded almost as heavily as the code.

> **Coach's Note —** Coding 1 and Coding 2 focus on writing code, not managing development environments. If something behaves oddly, you and the grader are looking at the exact same browser-hosted environment — there are no "works on my machine" defenses by design. Coding 3 will introduce a local toolchain properly.

---

## Hints (Read Before You Start)

- **Read the test names first.** Test names are usually `methodName_scenario_expectedBehavior`. The names tell you what the bugs cluster around. Sort the failures by which method they target — fix one method at a time.
- **Always paste the failing test verbatim into the prompt.** §13.4. The single biggest prompt-quality improvement available to you.
- **Always scope to one method.** §13.3. "Modify only `parseDate`. Output only the new method body." Saves regressions.
- **The first prompt is rarely a fix prompt.** It is usually a *trace* prompt or a *find-the-bug* prompt. §13.11 templates 1 and 2.
- **Don't accept a refactor.** If the AI returns a "fix" that rewrites three methods, reject it and re-prompt with stricter scope. The grader can tell from your `prompts.txt` whether you accepted broad rewrites.
- **Run the full test suite after every accepted change.** Not just the test you were working on. A regression is invisible until you run the full suite.
- **If you've spent 10 prompts on one bug, stop and re-read the chapter.** Specifically §13.6 and §13.7. You're probably in a loop, and the answer might be to take the keyboard (Medium and Hard tier only — Normal tier holds the constraint).
- **Estimated time:** Normal: 3–5 hours. Medium: 5–8 hours. Hard: 9–14 hours (because you do the whole exercise twice plus the comparison).

---

## What Mastery Looks Like

A great Project 13 has a **prompt log a senior could audit and respect.** Every prompt has a stated hypothesis. Every prompt is scoped. Diagnostic prompts come before directive prompts. No prompt is longer than it has to be.

A great Project 13 reaches green in **5–8 prompts for the 5 bugs.** Not 1. (1 means you were directive without diagnosing, which is luck.) Not 20. (20 means you were thrashing.) The sweet spot is small.

A great Project 13's reflection identifies a **specific moment** when a diagnostic prompt saved a wrong directive guess. Generic reflections — "I learned that prompts matter" — are worth almost no credit. Specific reflections — "On bug #3 I assumed the date format was wrong, but the diagnostic prompt revealed the assignment ordering was reversed in the constructor — saved at least two prompts" — are the work.

A great Hard-tier Project 13's `comparison.docx` reads like a working engineer's calibration notes, not like a marketing review. The grader has seen both assistants; insincere praise is obvious.

---

## When You're Done

1. Re-read your `prompts.txt` aloud. Does each prompt sound like *you*, or does it sound like a copy-paste from the chapter? Both are fine — but if every prompt is a template, you missed the variation that real debugging requires.
2. Confirm the test suite passes on a fresh run (close, reopen, run). Some IDEs cache test results misleadingly.
3. Confirm `<Module>-original.java` was preserved untouched.
4. Submit.
5. Read [Chapter 14](Chapter 14) — the honesty question. It is heavier on prose than any other chapter in the book. Treat it that way.

> **Coach's Note —** The most expensive part of senior engineering is not writing code. It is correcting code that almost works — yours, your team's, the AI's. The discipline you built this week is the discipline you will use for the next thirty years of your career, whatever tools come and go. Time spent on `prompts.txt` is time spent on your future self's working notebook.

See you on Monday.