40 AI Prompts for Software Development

Act as a senior engineer. I'll describe a feature request in plain language: [paste the request].
Turn it into a short written spec with: functional requirements, non-functional requirements
(performance, security, scale), explicit edge cases, and what's out of scope. Flag anything
in my description that's ambiguous instead of guessing at it.

I need to choose between these approaches for [problem]: [list 2-3 options].
Write an ADR: context, the options considered, the decision drivers (cost, latency, team
familiarity, operational burden), a recommendation, and the consequences of that choice,
including what we're giving up.

Here's my design for [system/feature]: [paste description or diagram in text form].
Before I build this, stress-test it against these constraints: [expected load], [latency
budget], [failure modes we need to survive]. Tell me where it breaks first and why.

Break this feature into an ordered implementation plan: [feature description].
Sequence the steps by dependency (what has to exist before the next step can start), flag
the riskiest step, and note where a step could be built behind a feature flag instead of
shipped all at once.

Design a REST API for this feature: [feature description]. Specify resources, HTTP verbs,
status codes, request/response shapes, pagination, and a versioning approach. Call out any
endpoint that mixes concerns and should probably be split.

Here are the user stories this system needs to support: [paste stories].
Design a normalized relational schema: tables, columns, types, foreign keys, and the indexes
you'd add and why. Flag anywhere you chose denormalization on purpose and what it costs us.

Design a GraphQL schema (types, queries, mutations) for this domain: [domain description].
Flag any resolver that's likely to cause an N+1 query problem at scale, and suggest a
batching or dataloader pattern for it.

We need to make this breaking change to our API: [describe the change].
Propose a versioning and deprecation strategy that gives existing consumers a migration
path: how we version, how long we support the old shape, and what we communicate to
integrators and when.

Here's how our codebase structures a feature ([describe folder layout, naming conventions,
patterns used]). Scaffold a new [feature type] following the same conventions: [feature
description]. Don't introduce a new pattern unless the existing one genuinely doesn't fit.

Implement this function in [language/framework]: [paste spec/signature]. Include input
validation, and handle these error cases explicitly rather than letting them throw
unhandled: [list error cases]. Add a one-line comment explaining any non-obvious choice.

Implement [algorithm/problem description] in [language]. State the time and space
complexity of your solution, and mention if a different approach would trade one for
the other in a way that matters for [expected input size].

This service calls [downstream dependency] over [protocol]. Design an error-handling
strategy: what to retry and with what backoff, what timeout to set and why, whether a
circuit breaker makes sense here, and what error types callers should expect to handle.

I need to [describe the concurrent/async operation, e.g., "process items from a queue
with a max of N in flight"]. Write this in [language], explain the synchronization or
concurrency-control choice you made, and call out the failure mode it's guarding against.

Here's the spec for a feature: [paste spec]. Generate a test plan covering unit,
integration, and end-to-end levels. For each level, list what it should cover and, just
as importantly, what it should NOT try to cover (to avoid duplicate coverage).

Write unit tests in [test framework] for this function: [paste function]. Prioritize
boundary conditions, empty/null input, and the edge cases a happy-path-only test suite
would miss, over repeating the same successful case three different ways.

Generate test fixtures for this schema: [paste schema/type definitions]. Include realistic
valid data, boundary values, and a few adversarial cases (oversized strings, unexpected
unicode, null-where-required) that a naive fixture generator would skip.

Here's a user flow that spans multiple services: [describe the flow, e.g., signup, then
payment, then provisioning]. Design an integration/E2E test for it, and specify what
should be mocked versus run against a real (test) instance at each step, and why.

Here's a bug report from a user: [paste report, however vague]. Turn it into a concrete,
minimal reproduction case: the exact steps, expected vs. actual behavior, and the
information still missing that would help confirm it (environment, input, timing).

This fails intermittently, roughly [frequency/pattern]: [paste error/logs]. Here's what's
changed recently: [recent deploys/config changes]. Here's what I've already ruled out:
[list]. Suggest the most likely root causes ranked by probability, and how to confirm each.

Memory usage on [service] climbs over [time period] under [load pattern] and doesn't
recover. Here's what I'm seeing in heap snapshots/metrics: [paste description or data].
Suggest likely culprits (unclosed handles, growing caches, retained closures) and how to
confirm which one it actually is before I start "fixing" the wrong thing.

I'm seeing [symptom, e.g., duplicate records / lost updates] under concurrent load in this
code path: [paste code]. Walk through where the race is likely occurring, propose a fix,
and explain why your fix actually closes the window instead of just narrowing it.

Here's profiler output for [service/function]: [paste output]. Identify the top 3
optimization targets by likely impact, explain why each is a target, and note which one
is the safest to attempt first given [risk tolerance/deadline].

This query is slow in production: [paste query and, if available, EXPLAIN output].
Table sizes are roughly [row counts]. Suggest an optimization (index, rewrite, or both),
explain the tradeoff (write cost, storage, staleness) it introduces, and how to verify
the fix actually helped before shipping it.

Here's a function that's become a bottleneck at our current scale: [paste function, note
input size]. Analyze its time/space complexity, propose a faster approach if one exists,
and be explicit about what it costs (memory, code complexity, readability) in return.

I need a load test plan for [endpoint/service]. Expected traffic shape is [describe:
steady, spiky, seasonal]. Propose a realistic test (ramp pattern, duration, concurrency)
and define pass/fail criteria (latency percentiles, error rate) before we run it, not after.

I need to make this schema change without downtime: [describe the breaking change, e.g.,
renaming/splitting a column]. Propose an expand-contract migration plan: what ships first
so old and new code both work, what the cutover step is, and what ships last to clean up.

I need to migrate data from [old shape] to [new shape]: [describe transformation].
Draft a script with a dry-run mode that reports what it would change without changing
anything, plus validation that confirms row counts and a sample of transformed records
match expectations before the real run.

Here's the migration I'm about to run in production: [paste migration]. Before I run it,
write the rollback plan: what to run to reverse it, what state it assumes existed
beforehand, and what would make the rollback itself unsafe (e.g., writes that happened
in between).

We need to move off [deprecated library/API version] across the codebase. Usage is spread
across roughly [scope, e.g., number of files/services]. Propose a phased plan: what to
migrate first (lowest risk, highest value), how to run old and new in parallel safely,
and a way to track what's left.

Design a CI pipeline for this project: stack is [language/framework], test suite takes
roughly [duration], and we deploy to [target]. Specify stages, what runs in parallel,
what gets cached, and where you'd add a manual approval gate versus fully automating it.

Write a multi-stage Dockerfile for this service: [language/framework, brief description].
Optimize for small final image size and fast rebuilds (layer/cache ordering). Explain
what each stage is responsible for and why it's separated from the others.

I need Infrastructure-as-Code (e.g., Terraform) for these resources: [list resources,
e.g., a VPC, a managed database, an autoscaling group]. Draft the configuration, and note
how state should be managed and what would count as risky drift to watch for.

We're deploying changes to [service, brief risk profile]. Propose a deployment strategy
(blue-green, canary, or rolling) matched to that risk profile, including what metric
would trigger an automatic rollback and how fast that rollback needs to be to matter.

Here's the code and package manifest for this project: [paste or summarize key files].
Write a README: what it does, how to install and run it locally, required environment
variables, and a minimal usage example. Don't invent features that aren't in the code.

Here are the route/handler definitions for this API: [paste]. Generate reference
documentation: endpoint, method, parameters, request/response examples, and error
responses. Flag any endpoint whose behavior isn't fully clear from the code alone.

Write an on-call runbook for [service]. Include: the most common failure modes we've
seen, the first three checks to run when paged, escalation contacts/thresholds, and
links to the dashboards/logs a responder would need. Keep each step actionable, not just
descriptive.

Write an onboarding doc that gets a new engineer to their first merged PR: local setup,
how our branching/review process works, where the "gotchas" are that aren't obvious from
the code, and a suggested small first task.

We have an active incident: [describe symptom, start time, affected systems, current
status]. Draft a status update for [stakeholders/status page] in plain language: what's
affected, what we know, what we don't yet, and when the next update will come.

Here's the raw timeline of an incident: [paste timestamps/events/Slack log]. Write a
blameless postmortem: summary, timeline, contributing factors (not "who"), impact, and
proposed follow-ups. Focus on what let the failure happen, not who triggered it.

This alert has fired [N] times in the last [period], and [M] of those were false
positives: [describe the underlying condition and recent trigger history]. Suggest a
tuning change (threshold, duration, additional condition) that would have caught the
real incidents while suppressing the noise, and what it might miss as a tradeoff.