Three Stooges — Vibe Code Results
Four prompts • Four responses • Four critiques & grades
TechToolsGuru vibe-coding the Stooges driver with Raina in Magic School’s
Code Craft Studio. Prompt by prompt, from a crash to a clean ArrayList with
case-insensitive duplicate guarding — then a post-session analysis with Stage 4 improvements.
This page documents TechToolsGuru’s complete vibe-coding session using Raina in Magic School’s Code Craft Studio.
The goal: take the original Three Stooges Java driver — which crashes with an ArrayIndexOutOfBoundsException if no command-line arguments are supplied — and iteratively improve it through four prompts into a fully defensive, ArrayList-backed, Scanner-driven program with case-insensitive duplicate guarding.
Each prompt below includes: the original text as sent to the AI, a C.R.A.F.T. critique with a grade, and the complete Java code Raina produced in response. After all four prompts, a post-session analysis offers TTG’s perspective on the process and a set of concrete improvements to the final Stage 4 code.
This page is accessible only via the link in the Entry Chatlog. It is intentionally not indexed or linked from the main site.
I am a student in an APCS-A Java course with about 3 months of training. You are a patient APCS-A teacher and professional programmer. I have received some code that works when a user provides command line input in JDoodle but fails if they forget to do so. I’d like the code to work regardless. The code’s purpose is to list the various characters that appeared in the series ‘The Three Stooges.’ There are 3 primary stooges (Moe, Larry and Curly) and some stooges that came into the team later, Shemp and Joe. The default values should be Moe, Larry and Curly. Regardless, the first phase of the program should print out their names. Future versions will allow us to add additional stooges to the ‘cast’ disallowing duplicates. I should be able to copy and paste this code into JDoodle and have it work.
Here is the code snippet: [original ThreeStoogesDriver.java attached]
A textbook opening vibe-code prompt. The role framing is creative and specific: a student assigns both their own experience level and the AI’s teaching persona in a single sentence. The domain context (Three Stooges, Moe/Larry/Curly defaults, future stages) is well-placed and gives the AI meaningful constraints to scaffold toward. The code is attached. The JDoodle target platform is named. This is a strong first move.
✅ Strengths
⚠️ Growth Areas
System. out.println has a space that’s technically legal in Java but poor style. A deliberate prompt would note: “preserve the spacing as written” or “fix the style on line 6.” Raina fixed it silently, which was correct — but the student didn’t control that decision."Insufficent" (misspelled). Raina corrected it in the response — which is helpful but again uncontrolled. Explicitly noting known issues gives you authority over which ones get fixed.Grade rationale: B+ — Excellent dual-role framing and precise failure description. The missing F (format constraint) and unaddressed style issue keep it off the A tier, but this is a strong first prompt for a three-month student. Raina’s response was clean and directly targeted the problem.
Raina’s Response — Prompt 1
The code you supplied worked well: I wanted to alert a user if default values were used. Here is my modified code:
[Prompt 1 response code, unmodified, attached]
There were additional stooges through the years that were part of the team. I’d like to be able to add them via keyboard input into the program and have them printed out. I’ll need to use an ArrayList to host the final collections of players. Refactor this code for user input and create an ArrayList to hold the final data. Assume I can enter as many stooges as I want until I indicate I want to stop.
A good iterative prompt that does the most important thing correctly: it provides the working code as the new baseline before asking for changes. The three goals are clear — keyboard input, ArrayList, open-ended entry. The acknowledgment that the prior response “worked well” is a natural conversation signal that helps the AI understand it’s building on a solid foundation rather than correcting a failure.
✅ Strengths
ArrayList is named, not just “a collection.” This prevents the AI from choosing a LinkedList or array.⚠️ Growth Areas
'x' — a programmer convention, not a user-friendly one. Specifying 'done' or 'quit' would have produced a more student-friendly interface.Grade rationale: B — Solid iterative move; providing the working code is the right call. The dropped role, unspecified sentinel, and missing F/T constraints cost it the B+. The duplicate-guard omission is intentional iterative discipline, not a flaw.
Raina’s Response — Prompt 2
The code you supplied worked well. I like how you disallowed duplicates, but there was a flaw: If ‘Moe’ is in the ArrayList, the software allowed ‘moe’ to be entered since casing was not checked. We should ensure entries are disallowed if their only differences are in casing. It was very good that you trimmed the user input to disallow trailing spaces.
The most surgical prompt in this set. Three sentences, one precise bug, one specific fix requested, one positive acknowledgment. This is textbook iterative prompting: say what worked, name the single thing that didn’t, be exact about the failure mode, then stop. Raina had everything she needed and produced a focused, clean response with two new helper methods.
✅ Strengths
.trim() behavior at the end reinforces the prior response’s quality before pointing out the flaw. This keeps the conversation constructive and signals “don’t remove the trim logic.”⚠️ Growth Areas
capitalizeName()), but the prompt left that open. Specifying “normalize to title case before storing” would have been tighter.Grade rationale: A− — The most precise prompt in the session. Short, specific, example-driven, and respectful of what already works. The session-dependency and under-specified normalization strategy prevent a full A. This is the model for all single-issue follow-up prompts.
Raina’s Response — Prompt 3
Danger Will Robinson! Magic School times you out if you leave it unattended. The active session was lost before Prompt 4 could be sent. Context had to be re-established from scratch.
Lesson: AI session context does not persist indefinitely. When picking back up after a timeout, treat it as a cold start — re-establish role, re-provide the current code, and describe the problem as if the AI has never seen it. Prompt 4 demonstrates exactly how to do this well. Notice how it re-introduces "I am a Java student" and "you are a professional Java programmer and APCS-A teacher", and includes the full code. This is the correct recovery pattern.
hasDuplicates() UtilityI am a Java student and you are a professional Java programmer and APCS-A teacher. I have some code that requests information at a command line level about the cast of characters in ‘The Three Stooges.’ It works well except if a user provides duplicate entries during the input phase, those duplicates stay in the final ArrayList and we shouldn’t have duplicates. We need a utility method that sends a true or false signal as to whether there are duplicates in the args array. We can wire it as a compound conditional in the check for the array size.
Here is the code: [Prompt 3 response code attached]
A strong cold-start recovery prompt. The two most important things are done correctly: the role frame is re-established immediately, and the full current code is provided. The problem statement is clear and the proposed solution architecture — a boolean utility method wired as a compound conditional — demonstrates genuine APCS design thinking. This is not just “fix it for me”; it’s “I know the shape of the solution, execute this design.”
✅ Strengths
boolean utility method + compound conditional. The student is not just asking for a fix — they’re demonstrating understanding of the design pattern. This shows APCS-level thinking about method decomposition.if statement the new method belongs.⚠️ Growth Areas
Moe Moe Curly). The prompt says “during the input phase” which could be interpreted as either context. Raina correctly understood it to mean args, but the phrasing could have been more precise: “if someone passes duplicate names via command-line args.”Grade rationale: B+ — Excellent session recovery. The role re-establishment + full code provision is the right model. The HOW-prescription is intentional APCS pedagogy but limits flexibility; the “input phase” ambiguity is a small clarity gap. Overall a strong, purposeful prompt from someone who clearly understands what they want the program to do.
Raina’s Response — Prompt 4
Session Analysis
📈 The Arc: From Crash to Clean
The four-prompt sequence traces a clean learning arc. Prompt 1 solved the critical ArrayIndexOutOfBoundsException and added the default fallback. Prompt 2 introduced the ArrayList pattern and Scanner-driven input — the architectural leap of the session. Prompt 3 tightened the duplicate guard with case normalization, the most sophisticated code change for the fewest words of prompt. Prompt 4 hardened the command-line input path against duplicates at the source. Each stage produced genuinely better software; nothing was thrown away.
🎯 Prompt Quality Summary
The session improves as it goes. Prompt 3 is the standout: three sentences, one bug, one test case, one fix, done. Prompt 1 is the strongest structurally (full C.R.A.F.T. with dual role), Prompt 2 is the weakest (drops the role, leaves the sentinel vague), and Prompt 4 is the best cold-start recovery in the set. The consistent strength across all four is the practice of providing working code as the baseline before describing the next change — this is the single most important iterative prompting discipline.
⚠️ The Session Timeout: A Real-World Lesson
The Magic School timeout between Prompts 3 and 4 is not a failure — it’s a lesson embedded in the process. AI sessions are stateful but mortal. When context is lost, the correct move is exactly what was done here: re-establish roles, re-provide the code, state the problem fresh. Students who learn this recovery pattern early will spend less time confused about why the AI “forgot” what they were working on.
✨ What Raina Did Well
Raina’s responses were consistently complete (full class, never fragments), added helpful comments without being asked, chose sensible defaults (title-case normalization, 'x' as sentinel), and preserved prior logic through each iteration. The capitalizeName() and containsIgnoreCase() helper methods in Response 3 were creative additions beyond what the prompt explicitly required.
The Stage 4 code is solid and correct. These are not bugs — they are the next layer of craftsmanship. Here are four targeted improvements a co-creator would make:
Improvement 1 — try-with-resources for Scanner
The current code calls input.close() at the end of main. This works in the happy path but leaves the Scanner open if an exception is thrown before that line. Java 7+ introduced try-with-resources specifically for this:
// Before — closes only in the happy path:
Scanner input = new Scanner(System.in);
// ... all the code ...
input.close();
// After — auto-closed even on exception:
try (Scanner input = new Scanner(System.in)) {
// ... all the code ...
} // Scanner auto-closed here
Improvement 2 — Consolidated error message
The inner if / else inside the outer else block produces two different messages for two sub-cases. For an APCS program, a single message is cleaner and easier to read:
// Before — two branches, two messages:
} else {
if (args.length < 3) {
System.out.println("Insufficient command-line argument data! Defaults used!");
} else {
System.out.println("Duplicate names in command-line arguments! Defaults used!");
}
// ...
}
// After — one message, one branch:
} else {
System.out.println("Invalid command-line input. Defaults used!");
// ...
}
Improvement 3 — "done" as the sentinel value
The sentinel 'x' is a programmer shorthand. For a program students or real users will interact with, "done" is more self-explanatory and feels natural as an exit command. The change is a one-line swap in the while condition and two println calls.
Improvement 4 — String.join() in printStooges()
The manual comma loop in printStooges() is a classic APCS pattern worth knowing — but once students are familiar with it, String.join() is more idiomatic and eliminates the index-boundary check entirely:
// Before — manual comma with boundary check:
public static void printStooges(ArrayList<String> stoogeList) {
for (int i = 0; i < stoogeList.size(); i++) {
System.out.print(stoogeList.get(i));
if (i < stoogeList.size() - 1) {
System.out.print(", ");
}
}
System.out.println();
}
// After — String.join() does the comma logic:
public static void printStooges(ArrayList<String> stoogeList) {
System.out.println(String.join(", ", stoogeList));
}
Bonus — The capitalizeName() limitation
Worth noting but not changing at this stage: capitalizeName() lowercases everything after the first character, so "McHugh" becomes "Mchugh" and "O'Brien" becomes "O'brien". For a Stooges roster this is fine. For a real-world program, a more robust name-normalization strategy would be needed. This is a good “Stage 6” discussion prompt.
Improved Stage 4 — All Four Changes Applied