What to Tell Claude When You Want a Real Security and Scale Review

The keywords are not "secure" and "scalable." Those words tell Claude almost nothing. What works is a role, your context, named checklists, and numbers it can test against. Below are the two prompts I use with clients, ready to copy.

Founders ask me this every month. They built something with Claude and want to know if it is safe and if it will hold up when users show up. They ask me what magic words to type. Be thorough. Think like a hacker.

Those words feel strong, but they do not change the output much. Claude will nod, list general advice, and wish you luck. I have watched this on shared screens many times. The founder pastes "check my security and make sure it scales," Claude returns general best practices, and nobody knows what to fix first.

The problem is the request, not Claude. If this pattern is new, read the shift from prompting to loop engineering first. Reviews are loops. You supply evidence and limits. Claude checks. You verify.

Why vague words fail

Words like "secure," "scalable," and "proper" have no observable meaning. Secure against what. Scalable to how many. Proper by whose standard. Claude fills the gaps with generic text.

Say "build a proper house" to a contractor and you get their assumption. Say "three bed, two bath, 1,400 square feet, on this lot, inspected to this code, finished by June" and you get a bid you can compare. Claude works the same way.

Vague prompts also let Claude skip your code. It answers from training data instead of your files. You get a lecture on password hashing instead of a finding that names your file and line. Correct in general, useless for you.

The fix comes straight from prompt engineering as software engineering. Treat the review like a spec. Name the role, the context, the checklist, the output format, and the numbers. Then require file and line evidence for every claim.

What Claude needs instead of keywords

Every review prompt I trust has five parts. Role sets the expertise. Context gives the app, users, and stack. Task lists the checks in order. Constraints block guessing. Format sets the report shape.

For security, the checklist matters most. I name OWASP Top 10 explicitly, plus auth, secrets, data protection, logging without PII, and dependencies. For mobile I add MASVS style checks (see my Capacitor mobile security checklist). Named checks force coverage.

For scale, the numbers matter most: current and target users, read/write mix, latency budget, availability and recovery goals. Without them, "will it scale" is unanswerable. With them, Claude can name the first bottleneck and what breaks at 10x.

Both prompts force evidence. Every finding cites file and line or says "not found in provided code." No citation means no credit. That one rule kills most hallucinations I see in AI reviews.

Security review prompt, copy ready

Paste this into Claude with your code attached. Fill in the brackets first and leave them visible so a teammate sees what you assumed.

Act as a senior application security reviewer. Review the attached codebase for security issues.

Context:
- App type: [web app / API / Capacitor mobile app / other]
- Stack: [for example: Node 20, Postgres, hosted on Render, auth via Supabase Auth]
- Users and data: [who uses it, what sensitive data it stores: emails, payments, health info, none]
- What is in scope: [list folders or files reviewed]
- What is out of scope: [third party services, infra you do not control]

Task, check in this order:
1. OWASP Top 10 coverage, one by one. For each, give PASS or FAIL with evidence.
2. Authentication: password policy, hashing, MFA support, session timeout, reset token expiry and single use.
3. Authorization: access checks on every route and object, IDOR risks, role enforcement, admin paths.
4. Secrets handling: hardcoded keys, keys in client bundle or logs, env handling, key rotation story.
5. Data protection: TLS in transit, encryption at rest, sensitive fields in URLs or logs, PII in analytics.
6. Input handling: validation, parameterized queries, output encoding, file upload limits and type checks.
7. Logging and monitoring: auth events logged, no passwords or tokens in logs, error messages that do not leak internals.
8. Dependencies: list risky packages you can see in package.json or lockfile, flag anything that needs an audit. Do not invent CVE numbers. If you are unsure, say "needs manual audit with npm audit."
9. If mobile: storage of tokens in secure storage vs plain localStorage, transport pinning status, deep link handling, WebView settings.

Constraints:
- Cite file and line for every finding. If you did not see the code, write "not verified in provided code."
- Do not invent files, functions, or configs you have not seen.
- Separate confirmed issues from risks that need runtime verification.
- No generic advice without tying it to this codebase.

Format, use exactly this:
1. Summary: top 5 risks in priority order, one sentence each.
2. Findings table, one row per issue:
Severity | File:Line | Issue | Evidence | Fix
Use severity values: Critical, High, Medium, Low.
3. OWASP checklist: each category with PASS/FAIL and one line of evidence.
4. Immediate fixes: the 3 fixes to ship this week, with exact file changes described.
5. Open questions: what you need from me to finish verification (logs, configs, infra access).

Scale review prompt, copy ready

Run this as a second pass after security, in a fresh thread or after the fixes land.

Act as a senior backend and reliability reviewer. Review the attached codebase and architecture for ability to scale.

Context:
- Current load: [for example: 200 daily active users, 20 concurrent at peak]
- Target load in 6 months: [for example: 5,000 daily active, 500 concurrent at peak]
- Read/write mix: [for example: 80 percent reads, 20 percent writes]
- Stack and hosting: [for example: Next.js on Vercel, Postgres on Neon, file uploads to S3]
- Latency budget: [for example: p95 under 500ms for API, under 2s for page load]
- Availability and recovery goals: [for example: 99.5 percent monthly, RPO 1 hour, RTO 4 hours]
- Known pain: [slow pages, timeouts, failing jobs, expensive queries]

Task, check in this order:
1. Data layer: N+1 queries, missing indexes, long transactions, connection limits, migration safety.
2. Caching: what is cached, TTLs, invalidation, what hammers the DB on every request.
3. Single points of failure: single DB, single region, single worker, cron on one box, local disk state.
4. Async work: what should move to a queue, retry policy, idempotency, dead letter handling.
5. Statelessness: can web tier scale horizontally, session handling, websocket stickiness, file storage locality.
6. Limits and backpressure: rate limits, payload limits, pagination, timeouts, circuit breakers.
7. Observability: request tracing, slow query logs, error budgets, alerts that page a human.

Constraints:
- Cite file and line for every claim. Write "not verified in provided code" when you cannot see it.
- Do the math. Show requests per second at current and target load. Show DB connections needed vs pool size.
- Name what breaks first at 10x load, and why.
- Do not recommend Kubernetes, sharding, or microservices unless the math requires it.

Format, use exactly this:
1. Summary: can it hit target load, yes or no, with the top 3 blockers.
2. Math box: current RPS, target RPS, peak concurrent, DB connections needed, cache hit assumption stated.
3. Findings table, one row per issue:
Severity | File:Line or Component | Bottleneck | Evidence | Fix
4. What breaks first at 10x: one paragraph, named component.
5. Load test plan: 5 k6 or locust scenarios with endpoints, virtual users, duration, and pass criteria tied to my p95 budget.
6. Open questions: metrics or access you need (APM, DB slow log, hosting limits).

How to force file by file evidence

The citation rule feels strict. It works because it turns Claude from essayist to inspector.

I attach the repo, then add one sentence at the top: "No finding counts without a file and line reference." When Claude returns a finding without one, I reply: "Give the file and line or mark it not verified."

I also split large codebases: one thread for auth routes, one for data layer, one for frontend storage.

Evidence tables also speed up human review later.

What good output looks like

Good output is boring in the best way. Three to five risks, each tied to a file and line, each with a concrete fix.

For example, a good security row reads: "High | api/reset.js:42 | Reset token valid 7 days, reusable | No single use flag | Set 1 hour expiry, single use, log redemption." Assignable today. A bad row reads: "Ensure robust authentication mechanisms are in place." You cannot assign that to anyone.

A good scale row reads: "High | db/queries.js:18 | Feed runs N+1 per page | Loop calls getLikes per post | Single join with index on post_id, paginate at 20." A bad row reads: "Consider optimizing database for scale."

If you get bad rows, reply: "Rewrite each finding with file, line, current behavior, and exact fix. Drop any finding you cannot tie to my code." That follow up cuts the fluff.

Common mistakes I see

The first mistake is asking for both reviews in one prompt. Security and scale pull in different directions. Run security first, fix the criticals, then run scale.

The second mistake is hiding context. Founders redact the stack "for privacy" and wonder why the advice is generic. Claude does not need your customer list. It needs your framework, DB, hosting, and auth provider.

The third mistake is accepting a clean bill of health. "No issues found" means the scope was too small or the evidence rule was missing. I have never reviewed an AI built MVP that passed everything on first look. That connects to the true cost of vibecoding and AI generated technical debt. Speed now means review later.

FAQ

What keywords make Claude do a real security check. No single keyword does it. Name a role, name OWASP Top 10, list auth and secrets checks, and require a findings table with severity, file, line, and fix for each issue.

How do I ask Claude about scaling to more users. Give current and target users, peak concurrency, read and write mix, and p95 latency budget. Ask what breaks first at 10x load and demand the math in requests per second.

Can Claude find vulnerabilities without seeing my code. No, not reliably. It can list general risks from a description, but real findings need the repo, routes, auth logic, and configs attached with file and line citations required.

Should security and scale be one prompt or two. Use two separate prompts. Security needs checklist coverage and evidence per file. Scale needs load math and failure analysis. Combined prompts produce shallow answers for both topics.

What do I do when Claude says everything looks good. Narrow the scope and rerun. Pick auth routes alone, require file citations, and ask for the top three risks that need runtime checks. Clean passes usually mean vague scope.

What I would do next

Run the security prompt on auth and user data paths first, ship the critical and high fixes, then run the scale prompt with real target numbers. Keep both outputs as versioned notes and rerun them when the next feature lands.

If you want a second set of eyes on what Claude flags, contact me here. Bring the Claude report and your repo. We will sort signal from noise fast.

About the Author: I am Brian Marvin, an AI native Fractional CTO. I help startups ship MVPs with AI speed and production discipline, including security reviews and scale plans that survive real users.