Why Claude's First Answer Is Never Good Enough
Never, ever accept the first pass from Claude Code
When you ask Claude to build something, it defaults to one question: does it run? That’s the bar. Not is it secure, not will it cause problems later. Just: does it execute.
I discovered this by accident in the middle of a project when I said “Evaluate what you’ve done so far.” Claude found 25 gaps and critical issues in the code it had created. That’s when I realized the first response is nothing more than “Here you go. It runs.”
The fix is counterintuitive: ask Claude to evaluate its own work as the next step in the session.
Name the personas
I call them personas, simple prompts that evaluate the work completed up to that point from the perspective of various angles of evaluation. The first one, the self-evaluator, is mandatory. The rest are based upon your specific project.
The Self-Evaluator
“Evaluate the work you just completed.”
The Self-Evaluator persona is the one I never skip. The value provided by this simple request when building a project can’t be overstated.
When Claude gives you the initial response to a request, all it’s looking for is “Did I provide something that runs?” That’s it; no quality check, no self reflection, no security check, no conflict resolution. Does it run. That’s all the original response uses to determine if it’s provided an adequate answer.
By activating an evaluation context immediately following Claude’s output, a different type of analysis takes place in the Claude brain. It switches contextually from “Does it run” to “Is this any good.”
The first time I ran this persona, Claude found 25 gaps and issues in the code it had created.
Other Personas
Once you have the self-evaluation habit, you can add targeted personas for specific risks. You don't need all of these. I wouldn’t ask a security analyst to evaluate the design quality of the presentation I’m putting together. Pick what matches your project.
Program manager: “Are there any gaps in the project plan?” Ask this at the end of your planning phase.
Security analyst: “Review this as a senior security analyst. Assume the system will be attacked.”
Adversary: “Review the code as an adversary would see it. What are the attack vectors?”
Project conflict evaluator: ”Evaluate the context of where we are in the project. What works now but will become a problem later?”
Senior programmer: “Looking in retrospect, evaluate this as a senior programmer.”
The Skeptic: ”Review this as a paranoid, skeptic code quality tester.”
Be selective when you use that last one. I speak from experience. A true skeptic is going to see every single granular issues as a high priority. You’ll be caught in analysis paralysis for hours.
Two Closing Prompts: The Sanity Checks
I build my projects in multiple sessions. Closing prompts are two questions I ask at the end of each session. They aren’t personas, they’re a final sanity check on the project as a whole at that phase.
Closing Prompt 1 — Retrospective
“In retrospect, would you change anything done so far in this project?”
At the end of a each session, the project “knows” about itself in the full context of what has been done so far. “Are there earlier decisions you’d reverse?” Claude will not only respond with what would be changed, also why it would be change, what’s the risk of that change, and what’s the value of the change. It’s your decision on whether to implement those changes, but I find that in most cases, it makes more logical sense than the original plan.
Closing Prompt 2 — Forward conflicts
“Knowing the entire project plan, what issues in the current build will conflict with future phases?”
Looking forward in the project plan catches path-dependency or potential conflicts before they even occur.
I was running a multi-phase project, nine phases. In Phase Three I asked the “forward thinking” question, and discovered that something we had planned in Phase Six would require a large refactor if we stayed with the current infrastructure choices. Finding that out in Phase Three, made for an easy fix within a matter of minutes, while waiting until Phase Six would have caused a massive rebuild.
How to Use Your Personas
Personas are not a part of your original prompt. Let your build prompt run to completion, then ask for evaluation as the next step in the session. The separation eliminates defensive bias. Claude switches from builder to critic.
This pattern, build then evaluate separately, is the foundation for building quality into your projects. Everything else is an extension of that.
Build Your Own Personas
Your projects will have different risks than mine. Create personas that match your context. What failures would be expensive in your work? What blind spots do you typically have? Build personas that check for those.
The pattern stays the same: build something, evaluate it separately, fix what needs fixing, move forward. Each phase of your project gets its own evaluation sequence.
What personas will you create for your projects? Leave your insights in the comments. I’ll let you know if I use one of them.
- Senior Storyteller