Two ways to use this prompt: Run it on your own code changes before you open a PR. Or paste it in before reviewing a teammate's diff, letting the AI do a first read before you do. Either way, you show up knowing exactly where to dig in.
This is the developer-focused companion to my second-pass prompt for professional work, rebuilt from the ground up for code: diffs, PRs, security surfaces, and everything that breaks after you ship.
For those of you already using AI in your development workflow (generating code, debugging, writing tests, cleaning up docs), let's not stop there.
Here is where things can go further, and where many developers stop short. This is the step that separates code that looks right from code that actually holds up in production, under load, and under review.
Challenging the output.
Why you may not be able to trust your AI's first pass
AI coding tools are fast. Fluent. They produce clean-looking, syntactically correct code that clears a linter and passes a basic test. They're built to get it semantically correct, not necessarily functionally right.
The challenge is not that AI writes bad code. It is that AI writes code that looks correct at the surface while carrying subtle logic errors, security gaps, and architectural decisions that made sense to no one in particular. The model does not understand your system. It will often pattern-match to what it has seen before.
One thing worth knowing: unless specifically instructed, AI coding tools do not reason across your codebase. They work from a fixed snapshot of the world that stops at a specific point in time, with no awareness of what has changed in your dependencies, your infrastructure, or the security advisory landscape since then. They carry context from your session, which is not the same as understanding your architecture. They generate code that fits the pattern of the prompt, not necessarily the intent behind it.
The first output is a starting point. A fast, often impressively capable starting point. But still a starting point, a first draft.
How significant is the AI code quality problem?
More significant than the productivity headlines suggest, and the data is starting to catch up with the hype.
CodeRabbit's analysis of 470 open-source repositories found that AI-generated code carries 1.7 times as many defects as code written by humans. That is not a small delta. Sonar's 2026 State of Code survey found that 96% of professional developers do not fully trust AI-generated code, and only 48% say they always check it before committing (which may account for the defect rate above). AI already accounts for 42% of committed code industry-wide. That can be millions of lines of 'first-draft' code in production.
It is not just correctness either.
"AI included bugs like improper password handling and insecure object references at a 1.5-2x greater rate than human coders. … If 2025 was the year of AI coding speed, 2026 is going to be the year of AI coding quality." — Stack Overflow Blog / CodeRabbit, January 2026
Stack Overflow's 2025 Developer Survey found that developer trust in AI tool accuracy has fallen to 33%, down from 43% the year before, while overall favorability toward AI tools has slid from 77% in 2023 to 60%. That is not developers becoming more skeptical for no reason. That is developers accumulating experience with what AI-generated code does after it ships.
The problem is not awareness. It is the gap between how much AI-generated code is going out and how rigorously it is being reviewed before it does.
This prompt is designed to close that gap.
What a deeper, second-pass prompt can do for your code
One way to think about it: the first prompt is like a fast junior engineer who knows a lot of patterns and can move quickly. Solid output, good intentions, and genuinely useful in the right context. But most experienced engineers would not promote a PR from a junior engineer without a senior taking a careful, independent look at it first.
This second-pass prompt works the same way. It resets context, strips out prior assumptions, and instructs the AI to approach the code as a skeptical senior engineer seeing it for the first time. Not a collaborator who helped write it, but more like a reviewer who has to defend it in a postmortem.
A well-structured second-pass prompt can:
- Catch what the first pass missed: logic errors, edge cases, off-by-one bugs, unhandled nulls
- Challenge the security posture: not just whether auth exists, but whether it is enforced in the right place, with the right model, against the right threat surface
- Find the DRY violations and reusability gaps: repeated logic, hardcoded values, inline behavior that should be extracted into shared utilities or components
- Verify library and API behavior: rather than assuming it knows how a dependency works, retrieve current documentation and advisories at review time
- Surface what a senior engineer would raise in review: an existing utility or dependency that already does what the new code reinvents, architectural inconsistencies, patterns superseded by better approaches, things that will cause pain in six months
This is not about slowing down. It is about catching the things that slow you down later, in production, at 2am, in a postmortem.
The AI echo chamber problem in code review
There is a subtler issue that does not get discussed much. When AI is used to generate code and then asked to review that same code, the result is often a feedback loop that mostly validates itself.
The model generated the code with a particular approach in mind. Asking it to review that code, without explicit instruction to break out of that frame, tends to produce agreement rather than challenge. It will check for the things it already checked for. It will miss what it missed the first time.
This is one way AI-assisted code that passes an AI review can still carry security vulnerabilities, architectural problems, and logic errors that only surface in production.
The prompt below is built to break that loop. It instructs the AI to treat every assumption as unverified, retrieve current library behavior and security advisories rather than rely on training-time knowledge, and approach the review the way a senior engineer who did not write the code would. Less pair programmer. More code reviewer with something to prove.
Why not just start with this prompt and skip the first pass?
The short answer is that this prompt works best when the code is far enough along to be meaningfully challenged. Think of it like submitting a PR for review. It should be ready, not still forming. Running a half-finished implementation through a structured adversarial audit produces a report on the wrong version of the code. The prompt works better when there is something settled to push against.
There is also a practical consideration. This prompt is thorough. It checks security, traces code paths, retrieves current dependency information, and produces a structured report. On throwaway scripts or early-stage prototypes, that level of depth is probably overkill and can burn tokens where you shouldn't. Save it for code that is heading toward review, production, or a security boundary.
One more thing: the two questions the AI asks before it starts require real answers. What is this change doing, and does it touch anything sensitive? If you cannot answer that clearly, the code may not be in the right shape for this yet.
Who this is for
This prompt tends to be most useful for developers and engineers whose output has real-world consequences:
- Frontend engineers: components, state management, accessibility, client-side security, browser API usage, third-party pixels
- Backend engineers: APIs, services, business logic, database queries, background jobs, third-party integrations, auth flows
- Full-stack developers: API contracts, data fetching layers, session handling, shared types, anything owned end-to-end
- DevOps and platform engineers: IaC, CI/CD pipelines, deployment configuration, secrets handling, IAM
- Engineering leads and senior engineers: reviewing PRs before merge, setting technical standards, owning the decisions that show up in postmortems
If the code is heading toward production, a security boundary, or a code review where someone is going to push back, this prompt is worth running first.
How to use it
- Get the code to a point where you would open a PR or send it for review
- Open a fresh session with your AI agent, or clearly signal a context reset
- Paste the prompt below, followed by the diff, link to PR, or relevant code sections
- Answer the two questions the AI asks before it starts
- Work through the findings: Critical first, then Significant, then Minor
- For anything flagged as assumed or requiring a live environment to confirm, verify independently before shipping
Those two questions matter. The more specific the answers, the sharper the audit.
The prompt: copy and paste this
(Edit it to fit your stack, your threat model, or your team's conventions. This should fit your needs.)
Role: Senior engineer running an independent second-pass audit of a diff / PR / change.
Ignore prior session context; treat the work as new and unverified. Review as a
skeptic, not a collaborator who already endorsed the approach.
Objective: Find defects, gaps, security exposures, and risks the first pass missed.
Categories below are focus areas, not a closed checklist. Measure the code against its
stated intent but judge it by what it actually does: a divergence from intent is itself
a finding, and good intent does not excuse a broken implementation.
Scope (default): Audit only the changed code plus what it directly touches, depends on,
or affects. Do not audit the whole codebase, refactor untouched code, or flag
pre-existing issues unless the change introduces, worsens, or relies on them (note
those briefly as out-of-scope context). Widen only if the author asks.
Ask before starting:
1. Why is this change being made (ticket / bug / requirement / goal), what does it
touch, and is any part internet-facing, handling auth, processing untrusted input,
or touching sensitive data (PII, credentials, payments, health)?
2. Any narrower focus (e.g. "security only," "just the auth changes"), or a request to
widen beyond the diff into surrounding files or a full-codebase audit?
Verification: Do not trust memory or training-time assumptions for API signatures,
library or framework behavior, version support, deprecations, browser compatibility,
or security advisories / CVEs — retrieve current sources at review time. Trace each
finding through the actual code path. Mark findings that need running code, a repro,
or a test to confirm; flag anything unverifiable as assumed, pending human
confirmation.
Audit — core (all code):
- Fitness for purpose: does it solve the stated problem? Is the approach proportionate
(not over- or under-engineered), complete, and free of scope creep? Simpler
alternatives?
- Correctness and logic: edge/boundary/off-by-one, null/empty/zero, type coercion,
inverted conditionals, wrong algorithm or data structure, arithmetic,
ordering/uniqueness assumptions.
- Error handling and resilience: unhandled exceptions/rejections, swallowed or
over-broad catches, missing validation, timeouts/retries/backoff, resource leaks,
partial-failure and rollback, graceful degradation.
- Security (priority — audit thoroughly):
Injection: SQL/NoSQL, command, path traversal, SSRF, XXE, deserialization,
template/log — is untrusted input validated, encoded, or parameterized at every
boundary?
AuthN/AuthZ: broken/missing access control, IDOR, privilege escalation,
session/token/JWT misuse, checks enforced only client-side.
Secrets and config: hardcoded creds/keys/tokens, secrets in source/logs/errors,
insecure defaults.
Web/browser: XSS (stored/reflected/DOM; innerHTML, dangerouslySetInnerHTML, v-html),
CSRF, CORS, CSP, clickjacking, cookie flags (HttpOnly/Secure/SameSite), open
redirects, postMessage, mixed content.
Crypto: weak algorithms, poor randomness, improper TLS/cert validation, unsalted or
fast password hashing, homegrown crypto.
Data exposure: PII handling, over-permissive responses, stack traces to clients,
sensitive data in logs.
Dependencies/supply chain: known-vulnerable or abandoned packages (check current
advisories), unpinned versions, lockfile integrity, risky transitives, typosquats.
Cite OWASP/CWE where it sharpens a finding.
- Code quality: readability, naming, complexity, duplication, dead code, unused
imports/vars, right level of abstraction, adherence to the project's
style/linter/conventions.
- DRY and reusability: repeated logic or duplicated code blocks that should be
consolidated; hardcoded values that should be constants or config; inline logic that
should be extracted into named functions, shared utilities, or reusable components
(UI, presentational, container, form, layout, or otherwise).
- Performance: algorithmic complexity, N+1 queries, redundant work, blocking I/O on
hot paths, unbounded memory, caching; for frontend, bundle size and re-render cost.
- Concurrency and state: races, deadlocks, unsafe shared state, missing
atomicity/locking, idempotency, cross-async ordering.
- Testing: coverage of new/changed paths, untested edge cases, brittle or
non-asserting tests, testability.
- Observability: log quality/levels, actionable errors, metrics/tracing on new
critical paths, production diagnosability.
- Interfaces and compatibility: contracts, breaking changes, versioning, backward
compatibility for callers, stored data, serialized formats.
- Data and persistence: migration safety/ordering/reversibility, transaction
boundaries, integrity constraints, rollout compatibility.
Audit — context-specific (only where relevant):
- Frontend/browser: accessibility, state correctness, cross-browser/responsive,
listener cleanup (leaks), SSR/hydration, loading/error states.
- Backend/service: request validation, rate limiting, auth middleware placement,
statelessness, connection pooling, pagination/payload limits.
- Deployment/infra: env and feature-flag handling, rollback/zero-downtime,
migration-vs-deploy ordering, IaC correctness, least-privilege IAM, resource
limits/health checks, pipeline secrets, CI/CD gates.
Cross-cutting:
- Consistency: internal contradictions, terminology/version drift, divergence from
surrounding architecture and conventions.
- Compliance and exposure: dependency license conflicts, regulatory obligations
(PII/GDPR, accessibility), legal/operational liability (flag only).
- Prior art: reinvented functionality that already exists as an internal utility, a
language standard-library feature, or an established third-party library; duplicated
or conflicting patterns; approaches superseded by a known standard/RFC or better
practice; what a panel of senior engineers would raise.
Output: Findings by severity — Critical / Significant / Minor. For each: location
(file, line/range, function), description, impact, resolution. Name the vulnerability
class (+ CWE/OWASP) for security findings.
- Critical: exploitable vulnerability, data loss/corruption, correctness bug on a core
path, likely outage.
- Significant: weakens robustness/security/performance/maintainability, or needs
mitigation before merge.
- Minor: style, naming, low-risk nits. State explicitly if a severity level has no
findings.
Constraint: When a fix needs a judgment call or depends on intent, threat model, or
unstated requirements, stop and ask — do not assume. Do not rewrite beyond what
demonstrates a fix unless asked. Stay in scope; if the change depends on a larger
problem outside the diff, flag it and ask before expanding.
What to expect back
The AI returns a structured report by severity level, with findings tied to specific files, line ranges, and functions.
Critical: exploitable vulnerabilities, data loss or corruption risk, correctness bugs on core paths, things likely to cause an outage.
Significant: findings that weaken robustness, security, performance, or maintainability, or that need addressing before the code merges.
Minor: naming, style, low-risk nits, things worth knowing but not blocking.
Each finding includes the location, the problem, the impact, and a suggested resolution. Security findings are named with their vulnerability class and CWE or OWASP reference where applicable. Where anything requires a judgment call or depends on intent or threat model, the AI is instructed to stop and ask rather than assume.
Push back on findings that do not fit your context. Ask for elaboration on anything unclear. Most engineers are surprised by what surfaces on code they thought was ready. Run it once and you will understand why this step exists.
What if it comes back with nothing critical?
That is a valid and useful result. A thorough second pass that confirms the code is solid before it goes to review is genuinely useful information. The goal is to feel more confident about the code changes, their blast radius, and even discover non-obvious impacts on the codebase.
Frequently asked questions
Should I trust AI-generated code without reviewing it? Most experienced engineers would say no, and the data backs that up. Sonar's 2026 survey found that 96% of professional developers do not fully trust AI-generated code, and only 48% say they always check it before committing. AI code introduces 1.7 times as many defects as human-written code on average. Review is not optional. It is the step that determines whether the speed gain was real.
What kinds of bugs does AI-generated code typically miss? The most common failure patterns are subtle logic errors and catches that pass basic tests but break on edge cases, security vulnerabilities introduced at input boundaries and auth checks, silent error handling that swallows failures rather than surfacing them, and DRY violations where the same logic gets copied rather than extracted. These are exactly the things a structured second-pass audit is designed to surface.
Why does AI write insecure code even when it looks correct? AI models generate code that fits the pattern of the prompt, not necessarily the threat model of the system. They do not know what is internet-facing, what data is sensitive, or what your auth architecture assumes. Security requires understanding context that the model does not have unless you provide it explicitly, which is exactly what the two pre-audit questions are designed to capture.
Is this the same as running an automated security scanner or linter? Not at all. Linters catch style and syntax. Static analysis catches known patterns. This prompt instructs the AI to reason about the code's behavior across real scenarios, trace logic through actual code paths, check current security advisories at review time, and surface architectural and design-level issues that an automated tool would miss. Think of it as a senior engineer review, not a scan.
Why not just start with this prompt instead of generating code first? This prompt is a review tool, not a generation tool. It works best when there is something settled to push against. Running it on a half-formed implementation produces a report on the wrong version of the code. Get the first pass to a point where you would open a PR, then run this.
Can I use this to review code I wrote myself without AI? Yes. The prompt does not care how the code was produced. It only evaluates whether it holds up under scrutiny. Some engineers run it on legacy code before touching it, to understand what they are working with before making changes.
Does this work with ChatGPT, Claude, Gemini, and other AI tools? Generally yes. The prompt is written in plain instruction language and works across capable frontier models. Results vary slightly by model, particularly on security depth, but the structure and intent carry across most of them. For security-sensitive code, models with web search enabled will produce better results on dependency and CVE checks.
What does "flag as assumed, pending human confirmation" mean? When the AI cannot verify a finding by tracing through the actual code or retrieving current documentation, it is instructed to flag it rather than assert it confidently. That is your cue to verify it yourself or run the code to confirm before shipping. It is the prompt's built-in honesty mechanism, and one of the most useful things it does.
The first pass is where your AI shows you what it can generate. The second pass is where you find out if it should ship.
