Generic AI answers are a you problem, not a model problem.
That’s the uncomfortable premise behind a Reddit post from a software engineer who tested 40 different prompts on Claude. The setup was simple: generic questions get generic answers. “Review my code” gets style feedback, not the JWT auth bypass hiding in layer two. “Design this system” gets a textbook answer, not the specific bottleneck that breaks at 50,000 requests per day. And the more complex the engineering problem, the wider the gap between what Claude returns and what you actually needed in the first place.
The engineer’s conclusion after all that testing? The issue isn’t the AI. It’s that most prompts are questions. What actually works is building a system around the prompt. Not just better phrasing. A behavioral contract that tells Claude how to think before it answers.
The Old Way vs. the One That Works
“You are a senior engineer” is technically a persona prompt. It’s also weak. It hands Claude a job title with no operating principles, which means Claude defaults to the most generic version of that role it’s ever seen in training data. The result looks reasonable on the surface: coherent sentences, plausible structure, the appearance of expertise. But it’s averaging across every senior engineer archetype it was ever trained on, which means it’s no specific senior engineer at all.
Compare that to: “You are a principal engineer. If you are uncertain, say so explicitly. Do not speculate as fact. Think step by step before giving any verdict.”
Same general intent. Completely different behavioral contract. The second version doesn’t just describe a role, it defines how the role thinks. It pre-empts the failure modes before they happen: confident speculation, vague recommendations, single-paragraph answers that collapse five separate concerns into one. You’re not describing a person. You’re describing a decision-making process.
The gap shows up clearly when you test it. A role-only prompt on a distributed system design question returns a reasonable architecture with three tiers and a load balancer. A behavioral-spec prompt on the same question returns an architecture plus explicit uncertainty flags on the parts Claude can’t assess without more context, plus a breakdown of where the assumptions live. One of those is useful for engineering decisions. The other one just looks useful.
🛠️ Five Changes That Actually Improve Claude’s Output
- Persona plus grounding beats role-only prompts. Give Claude operating principles, not just a title. Specify how it should handle uncertainty before uncertainty arrives. Think of it less like hiring for a job title and more like writing a job spec that includes the decision criteria you want applied to every answer.
- Force output format contracts. Without explicit section headers, Claude collapses multiple concerns into one vague paragraph. Name the sections you expect and Claude will actually check each one separately. If you want a security review broken into authentication, authorization, and input validation, say exactly that. “Review the security” leaves the structure entirely up to Claude. “Review authentication, then authorization, then input validation in separate sections” forces it to treat each as a distinct lens, and you catch the gaps it skipped.
- Add uncertainty flags explicitly. “If you cannot assess something without more information, ask rather than guessing.” One line. Meaningfully reduces confident wrong answers on technical questions. This matters more on architecture decisions than code review because the blast radius of a wrong architecture recommendation is much larger than a misplaced comment about variable naming.
- Use chain-of-thought triggers. “Think through this step by step before giving your recommendation” doesn’t just produce longer answers, it produces more accurate ones. The difference shows up most on architecture-level decisions where Claude needs to reason through tradeoffs rather than pattern-match to the most common answer in its training data. The intermediate reasoning it surfaces also lets you catch exactly where it went wrong, which is harder to do when you’re only evaluating a final recommendation.
- Build skill personas, not role names. A full system prompt with operating principles changes output quality at the root level. One engineer built eight of these: Principal Architect, Security Auditor, TypeScript Craftsman, AWS Solutions Architect, Performance Engineer, Staff Engineer, SRE, and API Designer. Each one is a behavioral spec, not a label. The Security Auditor persona doesn’t just “think like a security engineer.” It follows a specific checklist sequence, flags anything touching auth or input handling with explicit severity levels, and asks for more context before assessing anything that touches external integrations.
Why This Matters for Real Engineering Work
When you’re using AI for actual engineering decisions, a confident wrong answer is worse than an uncertain one. The system described here is designed to surface uncertainty, force structured reasoning, and prevent the generic pattern-matching that makes AI feel useless for serious work. Most AI disappointment comes from a mismatch between what the model was asked and what the engineer actually needed. The prompt was a question. The need was a specification.
The practical reframe: treat the prompt like an API contract. Define inputs, expected behavior, output format, and how edge cases should be handled. That’s how engineers think about interfaces. Turns out it’s also how you get AI to behave like one. Once you have a few solid behavioral specs built out, the actual prompting gets faster, not slower. You’re not drafting from scratch every time. You’re calling a defined interface with the right parameters already set.
Stop writing prompts. Start writing specs.
Frequently Asked Questions
Q: Do I need all 40 prompts, or can I start smaller?
Start small. Pick 2, 3 problems you solve repeatedly (code review, system design, security analysis) and build persona-based prompts just for those. The comment shows a modular framework you can scale incrementally, you don’t need the full system on day one.
Q: Does this approach work with other AI tools, or just Claude?
The core principles, grounding instructions, output format contracts, and chain-of-thought, apply across Claude, Gemini, and Cursor. The underlying mechanics are model-agnostic, though you may tweak wording based on each tool’s strengths.
Q: How do I measure if better prompts are actually working?
Test on scenarios where you know the right answer. Run your old prompts and new structured ones on the same problems (code reviews, architecture critiques, security audits) and track results: fewer follow-ups, faster decisions, or fewer missed issues. The difference becomes obvious quickly.
Q: What if I don’t have time to write detailed prompts?
Layer in one principle at a time. Start with grounding instructions, then add format contracts, then uncertainty flags. The comment’s modular structure (system rules, thinking patterns, pattern library) lets you build once and reuse across scenarios, cutting your total effort.
Q: How should I organize my prompts so I actually use them?
Use a modular structure: system-level rules, role-specific thinking patterns, and a pattern library. This prevents rewriting and lets you mix rules across different use cases. It’s the difference between 40 scattered notes and one coherent system you’ll actually reach for.
I engineered 40 prompts that make Claude think like a principal engineer — here’s the system behind them
by u/Abdulus in PromptEngineering