JavaApp Review
Get Claude to tell you what’s actually wrong with your app.
Check your table assignment for today’s section.
Claude is helpful, fast, and—by default—a little too nice. Ask “what do you think of my app?” and you’ll get a hedged, encouraging answer that doesn’t help you ship a better project. Today you’ll practice the opposite: prompting Claude for the kind of pointed, specific critique that actually moves the work forward.
Today’s job is to interrogate your app from a user’s perspective, with Claude as the harshest reviewer you can get it to be. By the end of class you should walk out with a short, ranked list of things to fix as we near the end of the semester.
Set the StageSet the Stage
Generic prompts get generic feedback. Before you ask Claude anything, tell it what your app actually is: who it’s for, what problem it solves, and what “done” would look like. Without that context, every critique you get back will be safe and shallow.
Try it: Brief Claude on your app the way you’d brief a new TA.
I want you to review my app. First, let me describe it. <Describe your app, your target user, the core problem it solves, and what you’d consider a successful version.> Ask me one clarifying question before you start reviewing.
Who is the target user for my app, based on what it does? Tell me what you think, and I’ll correct you if you’re wrong.
In one sentence, what is the single most important thing my app needs to do well to be considered successful? Don’t hedge.
Once Claude has the context, it has something real to push against. That’s when critique gets useful.
Ask for Honest CritiqueAsk for Honest Critique
Now try a vague review request and notice what comes back. You’ll almost certainly get a polite list with one or two soft criticisms wrapped in praise. Read it carefully—not because the answer is good, but because seeing how empty it is is the whole point.
Try it: Ask the kind of generic question students usually ask.
How specific was the answer? How many of the points could apply to literally any app? That’s the baseline you’re going to push past for the rest of the activity.
Push Past FlatteryPush Past Flattery
This is the part of the activity that matters. Sharp prompts force Claude to commit to a specific opinion instead of hedging. Constraints help: a hostile persona, a forced ranking, a “name one thing” framing, a deadline. The more your prompt removes Claude’s escape hatches, the more useful the answer.
Try it: Pick a few of these and notice how the answers get sharper.
Pretend you’re a skeptical first-time user who has used much better apps before. You open mine and use it for sixty seconds. What’s the first thing that frustrates you?
If I had to cut one feature before the showcase to make the rest better, which one should it go and why?
You are a TA grading my app for the showcase. Where would you dock the most points, and what would you write in the feedback comment?
If an answer still feels generic, push back. “That’s vague—give me a specific example from my app.” “You’re hedging—commit to one answer.” A good critic doesn’t mind being pressed, and Claude will sharpen up if you don’t let it off the hook.
Argue Back, Then PrioritizeArgue Back, Then Prioritize
Critique you accept blindly is just as useless as critique you ignore. Pick one piece of feedback you disagree with and have Claude defend it. You’re the expert on your app—your job is to decide whether Claude has a point or whether it’s wrong.
Then turn the feedback you do accept into a ranked punch list. Showcase is one week away. The list is what you’ll work from.
Try it: Validate the critique, then prioritize.
I disagree with your point about <critique>. Defend it. Give me your strongest case for why I’m wrong to dismiss it.
Of all the issues you’ve raised today, rank the top three by how much they hurt the user experience. Be willing to say which ones I can ignore.
If I have one week and can only fix three things before the showcase, which three should I fix and in what order? Justify the order.
Write the punch list down somewhere you’ll actually look at it tomorrow. That’s the artifact this activity is supposed to produce.
Before You Leave: Commit and PushBefore You Leave: Commit and Push
Before getting your attendance scanned, make sure you commit and push your work. You can ask Claude to do this for you (try “please commit and push my work”), or use the Git integration in Android Studio.
Your Claude Code session transcripts are saved automatically with each commit. We use these logs to track your progress, so a push is required before you leave.
AttendanceAttendance
Once you’ve committed and pushed, show your progress to a staff member. They’ll scan your QR code for attendance.