Advanced Strategies

You can ask for reviews through different lenses, such as performance, security, and usability. A persona changes the focus of the response; it does not give the model the qualifications, access, or accountability of a real specialist.

Step 1 — As a React performance expert:

Analyze this component for unnecessary re-renders and

expensive computations.



Step 2 — As a security auditor:

Review the same code for vulnerabilities and data exposure.



Step 3 — As a UX engineer:

Evaluate the user-facing behavior. Are there edge cases

that would confuse users?



Step 4 — Synthesize all three perspectives into a

prioritized list of improvements.

Each role label requests a different review lens: performance, security, or usability. The model does not acquire the qualifications or independent perspective of those specialists, so verify the combined findings with evidence and accountable reviewers.

For a decision with several trade-offs, ask for explicit options, assumptions, evidence to verify, and a concise rationale. This makes the response easier to inspect than a bare recommendation.

I need to add real-time collaboration to the family planner.



Before proposing a solution, think through these steps:



1. What are the technical options? (WebSocket, SSE, polling)

2. What are the trade-offs of each for my use case?

3. What's the simplest option that handles 10 concurrent users?

4. What changes to my current architecture are needed?

5. What are the main risks or failure modes?



For each step, list the assumptions, evidence to verify,
trade-offs, and a concise rationale. Then recommend an option.

A decision scaffold makes the response easier to inspect because options, assumptions, evidence, and trade-offs are explicit. It does not guarantee that the analysis is complete or correct.

After AI generates code, ask it to attack its own output. This technique consistently finds issues that a standard "review this code" prompt misses.

You just wrote this code. Now switch roles.



You are a hostile code reviewer whose job is to find

every possible issue. Be ruthless. Look for:



- Bugs that would only appear under unusual conditions

- Performance problems that emerge at scale

- Security vulnerabilities an attacker could exploit

- Assumptions that might not hold in production

- Race conditions or timing issues



Don't be diplomatic. List every problem you can find.

The instruction "don't be diplomatic" is important. AI has a tendency to be polite about its own output, hedging criticism with "this is mostly fine but..." Forcing a hostile stance produces far more thorough analysis.

Instead of asking for the final complex version immediately, build complexity incrementally. Each stage adds one layer of sophistication, and you verify correctness at each level.

Build a data table component. We'll add complexity in stages.



Stage 1: Static table that renders an array of objects.

         Just rows and columns, nothing else.



Stage 2: Add sorting (click column headers to sort).



Stage 3: Add filtering (search input that filters rows).



Stage 4: Add pagination (10 rows per page with controls).



Stage 5: Add row selection with checkboxes.



Start with Stage 1 only. I'll tell you when to proceed.

This strategy prevents the "complexity explosion" where AI tries to build everything at once and produces tangled code. Each stage is simple, testable, and builds cleanly on the previous one. By stage 5, you have a sophisticated component with a clean architecture.

Instead of asking "what's the best way to do X," compare credible approaches against explicit criteria. The structure improves inspectability; the facts and conclusions still require verification.

Compare these three state management approaches for my app:



1. React useState + context

2. Zustand

3. Redux Toolkit



Evaluate each on these dimensions:

- Learning curve (for a mid-level React developer)

- Bundle size impact

- Boilerplate required

- DevTools quality

- Suitability for my app size (~15 components, ~5 data entities)



Present as a comparison, then recommend one with reasoning.

The explicit evaluation dimensions prevent AI from defaulting to the most popular option. It forces genuine analysis across criteria that matter for your specific situation.

Traditional rubber duck debugging works by forcing you to explain the problem out loud. AI takes this further — it actually responds, asks clarifying questions, and proposes hypotheses.

I'm stuck on a problem and need to think it through.



Situation: My activity filter works for single-member

selection but breaks with multi-select. The filtered

list shows the right count but the wrong activities.



I've checked:

- The filter function logic (seems correct)

- The state updates (members array updates correctly)

- The component re-renders (it does)



Something is wrong but I can't see what.



Ask me questions to help me narrow down the issue.

Don't guess the answer — help me find it myself.

The instruction "help me find it myself" is key. It tells AI to ask diagnostic questions rather than jumping to solutions. This approach builds your own debugging skills while leveraging AI's ability to ask the right questions — questions you might not think to ask yourself.

Save prompts that worked for recurring tasks together with their inputs, expected outputs, and limitations. Re-test them when the model, tool, or task changes.

A prompt library can reduce repeated setup work and preserve lessons from earlier reviews. Version prompts against measured outcomes; reuse without re-testing can also preserve obsolete assumptions.