Project 10 — Two Prompts, Two Outcomes

“Let what you say be simply ‘Yes’ or ‘No’; anything more than this comes from evil.” — Matthew 5:37

Chapter: 10 — Prompts as Specifications Due: End of Week 10 Submit: A link to your code — OnlineGDB or GitHub — containing comparison.docx, vague-prompt-output.java, precise-prompt-output.java, both test files, and prompts.txt. See Coding 1’s online-coding workflow appendix. Allowed tools: Java 17, JUnit 5, your AI assistant. Required artifacts: two prompts, two code files, two test files, one comparison, one prompts log.

The Setup

Last week you ran one spec-AI-review cycle and learned the workflow. This week you run two on the same problem — once with a deliberately vague prompt, once with a precise one. The point is to feel, in your own hands, how much of the AI’s output quality is downstream of your prompt’s quality.

You are not being graded on whether one of your two implementations is better than the other. You are being graded on the comparison — your written analysis of what changed, why it changed, and which specific elements of your precise prompt produced which specific improvements in the output. The code is evidence. The comparison is the work.

A grader reading your submission should see: two prompts (one vague, one precise), two code files (each generated by the corresponding prompt with minimal touch-up), two test files (yours, written by hand, identical for both implementations), and a comparison document that names — with quotes and line numbers — the specific differences and the prompt sentence responsible for each.

This project is short to ship and instructive to write. Do not rush the comparison.

Learning Targets

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

• Write a deliberately vague prompt and a deliberately precise prompt for the same problem.
• Recognize, in AI output, the specific features that result from specific prompt sentences.
• Apply the four-part prompt structure (role / signature / behavior / constraints) under your own analysis.
• Write JUnit tests that can fairly evaluate two implementations against the same spec.
• Articulate, in writing, why precise prompting produces better code — not just that it does.

Normal Tier

Goal: A working comparison of vague vs precise prompting on one problem of moderate complexity.

Pick a problem

Pick one of these (or, with permission, propose your own equivalent-difficulty problem):

1. Luhn checksum — validate a string of digits as a credit card number. See §10.8 for spec sketch.
2. Roman numerals — convert between integers (1–3999) and Roman numeral strings, both directions.
3. Date parser — parse a date string in any of YYYY-MM-DD, MM/DD/YYYY, DD.MM.YYYY formats into a LocalDate, throwing on ambiguity.
4. Tag normalizer — given a string like " Lutheran;Reformed; Anglican , Lutheran ", return a sorted unique list of tags: ["Anglican", "Lutheran", "Reformed"].
5. Diff — given two List<String>, produce a unified diff showing added, removed, and unchanged lines.

The problem must be small enough that one prompt → one method (or one small class) is reasonable, and complex enough that several edge cases exist.

Required deliverables

1. vague-prompt.txt — your vague prompt. One or two sentences. The kind a non-engineer might write. Save the exact text you sent.

2. precise-prompt.txt — your precise prompt. Uses the four-part structure (§10.1). Includes at least one signature, three examples, and three negative constraints.

3. vague-prompt-output.java — the AI’s output for the vague prompt. Save it as the AI gave it to you, minus only what’s needed to make it compile (rename the class if needed, add a package statement). Do not clean it up further.

4. precise-prompt-output.java — the AI’s output for the precise prompt. Same rule: save it as the AI gave it, minus only what’s needed to compile.

5. SpecTest.java — a single JUnit 5 test class with at least 10 tests that fairly evaluate the spec. The same tests must be runnable against both implementations. Tests should cover:

   • Happy paths (at least 3).
   • Edge cases (at least 3 — empty, null, boundary).
   • Error cases (at least 2 — invalid inputs).
   • At least 2 cases that the AI specifically might miss.

   You may need to rename classes or methods slightly to run the same tests against both implementations. Document any such renames in comparison.docx.

6. comparison.docx — a one-page (300–500 word) written comparison. Required sections:

   • Test results. How many of your 10 tests passed against each implementation? Show the numbers.
   • Five differences I can name. List at least five specific differences between the two outputs. For each: (a) what the vague version did, (b) what the precise version did, (c) which sentence in the precise prompt caused the precise version’s behavior.
   • What surprised me. One paragraph on something the AI did that you didn’t expect (good or bad).
   • Verdict. One paragraph: would you ship the vague-prompt output as-is? The precise-prompt output? If no to either, what would you have to change?

7. prompts.txt — chronological log of every prompt you sent for this project. Same format as Project 9: timestamp, prompt, response summary, what you did with it.

Grading rubric — Normal (out of 100)

The bulk of points lives in the comparison. That is intentional. Generating two outputs is mechanical. The reading and the analysis is the senior work.

Medium Tier (+up to 25% extra credit)

Pick one of:

M1. Three prompts, not two

Add a third prompt: a test-first prompt. Send your SpecTest.java itself, with a one-line instruction: “Here are failing JUnit tests. Produce code that passes them all. Use only the standard library.”

Save the response as test-first-prompt-output.java. Run your tests against it.

Add a fourth section to comparison.docx: Three-way comparison. Did the test-first output score better, worse, or comparably to the precise-prompt output? Did it pass tests but introduce features you didn’t want? Did it pass all tests, or did it find a way to satisfy the assertions while violating the spec’s spirit?

This rep is the canonical test-first prompting experience. Most students find that the test-first output passes all 10 tests and is cleanest, because the AI had a closed-form target to hit. Some find that the AI minimally-satisfied the tests and produced code with subtler bugs in the un-tested gaps. Either finding is publishable.

M2. The “in-prompt example” experiment

Take your precise prompt. Make a variant that adds an in-prompt code example — a partial implementation showing the style you want. For instance, for the Luhn problem, you might include in the prompt:

Style guide — the loop should look like this:

for (int i = number.length() - 1; i >= 0; i--) {
    char c = number.charAt(i);
    // ...
}

Send this enhanced prompt. Save the output. Compare to your standard precise-prompt output. Did the AI follow the style? Did it produce more idiomatic code? Did it copy the example verbatim and not add the rest?

Document the experiment as an additional section in comparison.docx.

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

Pick one of:

H1. Build a prompt library

Build a small reusable prompt-template library. At minimum five templates, each in its own file in a prompt-library/ directory:

• 01-implement-to-signature.txt
• 02-test-first.txt
• 03-refactor.txt
• 04-explain.txt
• 05-find-the-bug.txt

Each template file must contain:

• The template itself, with [placeholders] for the variable parts.
• An example filled-in version using a real problem.
• A “when to use” section (3–5 sentences).
• A “common failures and how to head them off” section (2–4 sentences).

Then use at least three of your templates somewhere in the project (Normal or Medium) and reference the use in comparison.docx.

This is your senior’s toolkit, packaged for reuse. The first time you build one, it takes hours. The hundredth time, it saves you hours. Build it now.

H2. The cross-model prompt audit

Send your precise prompt to two different AI assistants — e.g., Claude and GPT, or whichever pair you have access to. Save both responses as precise-prompt-output-modelA.java and precise-prompt-output-modelB.java.

Run your tests against both. Add a section to comparison.docx: Cross-model audit. Did the same prompt produce comparable code across models? Where did they differ? Which differences were taste (idiomatic preferences) and which were correctness?

This is the rep that proves to you that the prompt is the leverage, not the model. The exact same prompt to two different models produces broadly comparable outputs when the prompt is sharp, and broadly comparable mediocre outputs when the prompt is dull.

Submission

Submit one URL via the course portal. The submission must contain all files listed under Normal (and Medium/Hard as applicable).

Reflection block at top of comparison.docx

<!--
Project 10 — Two Prompts, Two Outcomes

Tier targeted:    Normal / Medium / Hard
Problem chosen:   [Luhn / Roman / DateParser / TagNormalizer / Diff / other]
AI assistant(s):  [name, version if known]

Honest accounting:
  - I wrote both prompts deliberately. The vague one was not lazy; it
    was an honest "first attempt that doesn't take prompting seriously."
  - I wrote SpecTest.java by hand before generating either implementation.
  - I did not edit the AI's outputs except [what specifically].
  - I ran the tests against both implementations and reported real numbers.

What I'd change if I had another hour:
  [one sentence]
-->

What the grader will do

1. Open prompts.txt and read the chronology.
2. Open vague-prompt.txt and precise-prompt.txt. Note the difference.
3. Open both *-output.java files. Note the difference visually before reading any analysis.
4. Open SpecTest.java. Run it against both implementations. Verify the numbers in your comparison.docx.
5. Read comparison.docx carefully. The five named differences are the heart of the grade.
6. Score against the rubric.

Hints (Read These If You’re Stuck)

• “My vague prompt produced output that was actually decent.” Sometimes the problem is easy enough that even a vague prompt lands. If so, pick a harder problem, or rewrite your vague prompt to be vaguer. The point of the project is the contrast; if there is none, you don’t have a project.

• “My precise prompt produced output that was barely better.” Either (a) your “precise” prompt was actually pretty vague — re-read §10.1–§10.4 and tighten, or (b) the AI is having a bad day. Send the same precise prompt in a fresh thread; sometimes the variance is real.

• “My tests pass on both implementations.” Good — write more tests, especially in the edge-case category. The point is to find a discriminating test, not to prove both work. If all 15 tests pass on both: the vague prompt didn’t fail, and that itself is a comparison finding (write it up).

• “My tests don’t run against both implementations because the class names are different.” Rename one (or both) so a single test file can target them. Document the rename in comparison.docx. Or use a wrapper class. The tests must be the same tests to be a fair comparison.

• “My comparison.docx feels short.” 300–500 words is a real word count. Most students undershoot the first time. Specific quotes from the AI’s output, with the prompt sentence that caused them, are how you get to 500 words honestly. Vague generalities (“the precise version was more robust”) are not.

• “How long should this project take?” Normal: 3–5 hours including the comparison. Medium: 5–7 hours. Hard: 7–10 hours.

What Mastery Looks Like (Beyond the Rubric)

The rubric tells you what to do. Here’s what to aim for:

A great Project 10’s comparison.docx is a document a next-week’s student would learn from. It names specific patterns (“when the prompt didn’t mention null behavior, the AI returned false; when the prompt did, the AI threw”). It links specific output behaviors to specific prompt sentences. It tells the truth even when the truth is “the AI’s first answer was already pretty good on this problem.”

A great Project 10’s SpecTest.java includes at least one test that neither AI implementation passes on the first try — because you wrote a test for an edge case neither AI thought of. That test, more than anything else, proves you are thinking like the senior.

A great Project 10’s prompts.txt shows iteration. You sent the vague prompt, looked at it, and didn’t re-prompt — that’s the discipline. You sent the precise prompt, possibly tweaked it, and re-sent — that’s also discipline. The log shows your thinking. Show your thinking.

A great Project 10 leaves you with a personal prompt-library file (Hard H1, even if you only attempt Normal) that you’ll actually use in Project 11, Project 12, Project 13, and the final. The artifact compounds.

When You’re Done

1. Re-read comparison.docx out loud. Does it tell a story a reviewer could follow?
2. Make sure your test counts in comparison.docx match the test counts a grader would see when running your code.
3. Make sure vague-prompt.txt is honestly vague — not strategically vague to make the precise prompt look better. The integrity of the comparison depends on a real vague prompt.
4. Submit.
5. Read Chapter 11. Now we get serious about reading the code that comes back.

Coach’s Note — The students who do Project 10 well find that their Project 11 takes half as long. The students who half-ship Project 10 find that Project 11 is a slog. The reason is direct: code review is what you do when your prompt didn’t catch everything, and if you don’t yet have the prompt discipline, the review work is much harder. Get the prompts right this week. Next week’s chapter rewards you for it.

Sharp prompts. See you Monday.