AI Prompts for Software Engineers (2026)

You are a senior application security engineer. Audit the following [Node.js / Python / Go / Java] code for OWASP Top 10 vulnerabilities. For each finding: (1) assign a severity rating of critical, high, medium, or low, (2) describe the attack vector and what an attacker could do if it were exploited, (3) provide a corrected version of the affected lines. Also flag any secrets, credentials, or sensitive configuration that should not be in source code. Assume this code is deployed in a production environment accessible from the public internet.

You are a backend performance engineer specializing in high-throughput systems. Analyze this [SQL query / API handler / algorithm / data pipeline] for performance bottlenecks. Include: (1) Big-O complexity analysis of the current implementation, (2) identification of any N+1 query patterns or unnecessary database round trips, (3) memory allocation hotspots, (4) specific optimizations ranked by expected impact. For each optimization, estimate the improvement (e.g., "reduces p99 latency by ~40% at 1k req/s") and flag any trade-offs introduced.

You are a principal engineer at a high-growth startup. Design the system architecture for [feature or system name] given these constraints: scale requirements of [X requests/second, Y daily active users, Z GB of data]; latency target of [<Xms p99]; team size of [N engineers]; existing stack of [languages, databases, cloud provider, messaging]; and a budget constraint of [describe]. Provide: (1) a component diagram described in text, (2) the proposed data model for core entities, (3) the API contract for the three most important endpoints, (4) key failure modes and how the design handles them, (5) the three biggest trade-offs you made and what you would change at 10x scale. Be explicit about where you are making assumptions.

You are an expert in concurrent and distributed systems programming. Analyze the following [Go / Rust / Python asyncio / Java / Node.js] code for race conditions, deadlocks, and non-atomic operations that could cause incorrect behavior under concurrent execution. For each issue: describe the exact scenario in which it manifests, explain why it is non-deterministic and therefore hard to reproduce locally, and provide a corrected version using the appropriate synchronization primitive or pattern for this language and runtime.

You are a developer advocate who writes documentation that engineers actually want to read. Write a comprehensive README for [service / library / tool name]. Target audience: [senior engineers / junior engineers / external API consumers]. The service does [one-sentence description]. Include: (1) a one-paragraph pitch that explains the problem it solves and why it exists, (2) prerequisites and installation, (3) a quickstart example using a real-world scenario (not a toy "hello world"), (4) a full API reference table with method signatures, parameter types, and return values, (5) known limitations and gotchas, (6) a contributing guide. Tone: clear, direct, and technical — modeled on Stripe's or Linear's documentation style. Avoid padding and marketing language.

Write a formal Architecture Decision Record for the following decision: we chose [technology / approach / pattern X] over [alternatives Y and Z] for [system or feature]. Context: [describe the problem being solved and the constraints we were operating under]. Format: standard ADR structure including Status, Context, Decision, Consequences (positive and negative), Alternatives Considered (with a brief reason each was rejected), and a Related Decisions section. Tone: precise and technically rigorous. This document will be stored in the repository and read by engineers who join the team 12 months from now.

You are a senior engineer writing a pull request description that will be read by two audiences: (1) reviewers who need to understand what changed and why so they can give meaningful feedback, and (2) future engineers reading git history to understand the codebase. Here is a summary of the changes: [describe the changes or paste the diff summary]. Write a PR description that includes: (1) a one-sentence summary of what this PR does and why, (2) a "What changed" section with specific bullets per logical change, (3) a "Why" section explaining the motivation and any alternatives you considered, (4) a "How to test" section with concrete steps a reviewer can follow, (5) any follow-up work that is explicitly out of scope. Flag any areas where you made a deliberate trade-off that reviewers should weigh in on. Keep the tone direct. No buzzwords or filler sentences.

You are a staff engineer and technical advisor. I am deciding between the following architectural approaches for [specific problem]: Option A is [describe]. Option B is [describe]. Option C is [describe]. My context: [team size, expected traffic, current stack, timeline, biggest constraints]. I am currently leaning toward Option A. Your job is to: (1) steelman Options B and C as strongly as possible, surfacing every reason they might outperform my preferred option, (2) identify the two or three conditions under which Option A would fail or need to be replaced, (3) list the questions I should answer before committing, and (4) suggest how to structure a short spike or proof-of-concept that would de-risk the decision in one week.

You are a senior software engineer specializing in clean code and maintainable architectures. Refactor the following [language] code to improve [readability / testability / adherence to [specific pattern: repository pattern / CQRS / hexagonal architecture]]. Hard constraints: (1) do not change the external interface or method signatures that other modules depend on, (2) do not introduce new dependencies beyond what is already in the project's dependency file, (3) preserve all existing behavior — this is a behavior-preserving refactor. For each change you make, add a brief inline comment explaining the design principle it applies. After the refactored version, provide a summary of the patterns applied and why each improves the code.

You are a backend engineer writing integration tests for a production API. Write integration tests for the [endpoint or feature] that: (1) test the full request-response cycle against a real database (use [PostgreSQL / MySQL / MongoDB] with a test fixture strategy you define), (2) verify correct HTTP status codes and response body shapes for both success and error paths, (3) test authentication and authorization boundaries — what an unauthenticated user, a user with insufficient permissions, and an authorized user each receive, (4) verify that side effects (emails sent, events published, records created) occur exactly as expected. Use [test framework and language]. Include setup and teardown logic. Explain your fixture seeding strategy.

You are a staff engineer creating an onboarding guide for a new engineer joining our team. They are a [senior / mid-level / junior] engineer with experience in [their background] but no familiarity with our system. The guide should cover: (1) an architecture overview — the three to five most important services and how they relate, (2) local development environment setup with exact commands (I will provide the commands; structure them clearly), (3) the three most common development workflows with step-by-step instructions, (4) the five most important gotchas or non-obvious facts about our system that trip up new engineers, (5) a "first week" task list that progressively builds familiarity, and (6) a glossary of internal terminology and abbreviations. Tone: direct and precise, not corporate. Write for someone who is technically competent but has zero context about our specific system.

You are a senior SRE writing a blameless incident postmortem in the style of Google's SRE handbook. The incident was: [one-sentence description]. I will provide the raw timeline and contributing facts. Structure the postmortem as follows: (1) Incident Summary — severity, duration, customer impact in concrete terms, (2) Timeline — chronological events from first signal to full resolution in UTC, (3) Root Cause Analysis — apply the 5 Whys method to identify the systemic root cause, not just the proximate trigger, (4) Contributing Factors — systems, processes, or knowledge gaps that made the incident worse or harder to detect, (5) Detection & Response Assessment — how long it took to detect, to page, to mitigate, and where those times could be improved, (6) Action Items — each with an owner, a completion date, and a category of prevent / detect / mitigate. Tone: factual, constructive, and blameless. Never attribute the incident to human error without also identifying the systemic condition that made that error possible.