Developers ChatGPT Prompts
Debug faster, write cleaner code, and learn new languages with your AI pair programmer.
Python Code Review
Review the following Python code for {purpose}. Work in priority order and say why each finding matters rather than only naming it: first correctness and security — injection, authentication and authorisation gaps, unsafe input handling, secrets in source; then reliability — error handling, resource cleanup, and behaviour under partial failure; then performance where it is measurably relevant rather than speculative; then readability and structure. Check for mutable default arguments, bare except clauses swallowing errors, missing context managers around resources, type hints on public interfaces, and the GIL implications of any threading used for CPU-bound work. For every issue give the location, the concrete failure it causes, a corrected snippet, and a severity. Separate defects that will bite in production from stylistic preferences, and state explicitly what you could not assess without seeing tests, configuration or the calling code.
JavaScript Code Review
Review the following JavaScript code for {purpose}. Work in priority order and say why each finding matters rather than only naming it: first correctness and security — injection, authentication and authorisation gaps, unsafe input handling, secrets in source; then reliability — error handling, resource cleanup, and behaviour under partial failure; then performance where it is measurably relevant rather than speculative; then readability and structure. Check for unhandled promise rejections, missing await, accidental floating promises, closure captures inside loops, prototype pollution on merges, and equality and coercion bugs from ==. For every issue give the location, the concrete failure it causes, a corrected snippet, and a severity. Separate defects that will bite in production from stylistic preferences, and state explicitly what you could not assess without seeing tests, configuration or the calling code.
TypeScript Code Review
Review the following TypeScript code for {purpose}. Work in priority order and say why each finding matters rather than only naming it: first correctness and security — injection, authentication and authorisation gaps, unsafe input handling, secrets in source; then reliability — error handling, resource cleanup, and behaviour under partial failure; then performance where it is measurably relevant rather than speculative; then readability and structure. Check for `any` escaping through public APIs, unsafe type assertions hiding real mismatches, non-null assertions used instead of narrowing, discriminated unions that are not exhaustively handled, and whether types actually encode the invariants or merely decorate them. For every issue give the location, the concrete failure it causes, a corrected snippet, and a severity. Separate defects that will bite in production from stylistic preferences, and state explicitly what you could not assess without seeing tests, configuration or the calling code.
Java Code Review
Review the following Java code for {purpose}. Work in priority order and say why each finding matters rather than only naming it: first correctness and security — injection, authentication and authorisation gaps, unsafe input handling, secrets in source; then reliability — error handling, resource cleanup, and behaviour under partial failure; then performance where it is measurably relevant rather than speculative; then readability and structure. Check for resource leaks outside try-with-resources, mutable state shared across threads without synchronisation, equals and hashCode contract violations, overly broad exception catching, and N+1 queries behind an ORM. For every issue give the location, the concrete failure it causes, a corrected snippet, and a severity. Separate defects that will bite in production from stylistic preferences, and state explicitly what you could not assess without seeing tests, configuration or the calling code.
C++ Code Review
Review the following C++ code for {purpose}. Work in priority order and say why each finding matters rather than only naming it: first correctness and security — injection, authentication and authorisation gaps, unsafe input handling, secrets in source; then reliability — error handling, resource cleanup, and behaviour under partial failure; then performance where it is measurably relevant rather than speculative; then readability and structure. Check for ownership ambiguity and raw pointers where a smart pointer belongs, rule-of-five violations, iterator and reference invalidation after container mutation, undefined behaviour from signed overflow or aliasing, and exception safety across resource acquisition. For every issue give the location, the concrete failure it causes, a corrected snippet, and a severity. Separate defects that will bite in production from stylistic preferences, and state explicitly what you could not assess without seeing tests, configuration or the calling code.
REST API Design for Task Management
Design a RESTful API for Task Management. Define the resource model and the relationships between resources, then the endpoints with methods, path structure, request and response schemas, and status codes for success and every failure. Model the hierarchy carefully — projects, tasks, subtasks, assignees, comments — and decide whether subtasks are a separate resource or a self-referential relation. Handle bulk operations, since clients will always need to move many tasks at once. Cover authentication and authorisation including how object-level permissions are enforced, pagination (state whether cursor or offset and why), filtering and sorting conventions, rate limiting with the headers returned, and a consistent error envelope carrying a machine-readable code. Address versioning strategy and what constitutes a breaking change. Provide an OpenAPI fragment for two representative endpoints, and list the three design decisions most likely to be regretted later with the alternative for each.
REST API Design for Social Media Scheduling
Design a RESTful API for Social Media Scheduling. Define the resource model and the relationships between resources, then the endpoints with methods, path structure, request and response schemas, and status codes for success and every failure. Timezone correctness is the core difficulty: store instants in UTC with the originating timezone retained separately, and be explicit about DST behaviour for recurring schedules. Model per-platform constraints and partial failure when one network rejects a post. Cover authentication and authorisation including how object-level permissions are enforced, pagination (state whether cursor or offset and why), filtering and sorting conventions, rate limiting with the headers returned, and a consistent error envelope carrying a machine-readable code. Address versioning strategy and what constitutes a breaking change. Provide an OpenAPI fragment for two representative endpoints, and list the three design decisions most likely to be regretted later with the alternative for each.
REST API Design for E-commerce
Design a RESTful API for E-commerce. Define the resource model and the relationships between resources, then the endpoints with methods, path structure, request and response schemas, and status codes for success and every failure. Cart and order need different consistency guarantees. Make checkout idempotent with an idempotency key, model inventory reservation with expiry, and never let a price be supplied by the client. Cover authentication and authorisation including how object-level permissions are enforced, pagination (state whether cursor or offset and why), filtering and sorting conventions, rate limiting with the headers returned, and a consistent error envelope carrying a machine-readable code. Address versioning strategy and what constitutes a breaking change. Provide an OpenAPI fragment for two representative endpoints, and list the three design decisions most likely to be regretted later with the alternative for each.
REST API Design for Booking
Design a RESTful API for Booking. Define the resource model and the relationships between resources, then the endpoints with methods, path structure, request and response schemas, and status codes for success and every failure. Availability and double-booking are the whole problem: define the locking or reservation-hold strategy, the conflict response, cancellation and modification semantics, and how timezone differences between provider and customer are represented. Cover authentication and authorisation including how object-level permissions are enforced, pagination (state whether cursor or offset and why), filtering and sorting conventions, rate limiting with the headers returned, and a consistent error envelope carrying a machine-readable code. Address versioning strategy and what constitutes a breaking change. Provide an OpenAPI fragment for two representative endpoints, and list the three design decisions most likely to be regretted later with the alternative for each.
REST API Design for File Sharing
Design a RESTful API for File Sharing. Define the resource model and the relationships between resources, then the endpoints with methods, path structure, request and response schemas, and status codes for success and every failure. Design for large files: pre-signed direct uploads rather than proxying bytes, resumable and chunked uploads, virus scanning as an async state, and a permission model covering owner, shared-link and expiry semantics. Cover authentication and authorisation including how object-level permissions are enforced, pagination (state whether cursor or offset and why), filtering and sorting conventions, rate limiting with the headers returned, and a consistent error envelope carrying a machine-readable code. Address versioning strategy and what constitutes a breaking change. Provide an OpenAPI fragment for two representative endpoints, and list the three design decisions most likely to be regretted later with the alternative for each.
Database Schema for E-commerce
Design a normalised relational schema for E-commerce supporting {scale}. Give tables with columns, types, nullability, primary and foreign keys, and unique constraints. Price and product data must be historised: an order line stores the price paid, never a foreign key to a mutable price. Model variants and options without an attribute-value sprawl, and treat inventory movements as an append-only ledger. Normalise to 3NF, then state explicitly where and why you denormalise, since unexplained denormalisation is how schemas rot. Add indexes justified by the specific queries they serve, not speculatively, and note the write cost each one adds. Cover soft deletes versus hard deletes, created/updated timestamps, and the audit trail. Provide DDL for the core tables, three representative queries with their expected access path, and name the two decisions that would be most expensive to change once there is production data.
Database Schema for Social Networking
Design a normalised relational schema for Social Networking supporting {scale}. Give tables with columns, types, nullability, primary and foreign keys, and unique constraints. The follower graph and the feed are the hard parts. Decide fan-out on write versus read and justify it against expected follower distribution, and plan for the power-user case that breaks whichever you choose. Normalise to 3NF, then state explicitly where and why you denormalise, since unexplained denormalisation is how schemas rot. Add indexes justified by the specific queries they serve, not speculatively, and note the write cost each one adds. Cover soft deletes versus hard deletes, created/updated timestamps, and the audit trail. Provide DDL for the core tables, three representative queries with their expected access path, and name the two decisions that would be most expensive to change once there is production data.
Database Schema for Project Management
Design a normalised relational schema for Project Management supporting {scale}. Give tables with columns, types, nullability, primary and foreign keys, and unique constraints. Model hierarchical tasks explicitly — adjacency list, materialised path or closure table — and justify the choice against the queries actually run. Handle custom fields without an unbounded EAV table. Normalise to 3NF, then state explicitly where and why you denormalise, since unexplained denormalisation is how schemas rot. Add indexes justified by the specific queries they serve, not speculatively, and note the write cost each one adds. Cover soft deletes versus hard deletes, created/updated timestamps, and the audit trail. Provide DDL for the core tables, three representative queries with their expected access path, and name the two decisions that would be most expensive to change once there is production data.
Database Schema for CRM
Design a normalised relational schema for CRM supporting {scale}. Give tables with columns, types, nullability, primary and foreign keys, and unique constraints. Contacts, accounts and deals need a flexible relationship model including many-to-many with roles. Activity history is high-volume and append-only, so separate it from the entity tables and plan its retention. Normalise to 3NF, then state explicitly where and why you denormalise, since unexplained denormalisation is how schemas rot. Add indexes justified by the specific queries they serve, not speculatively, and note the write cost each one adds. Cover soft deletes versus hard deletes, created/updated timestamps, and the audit trail. Provide DDL for the core tables, three representative queries with their expected access path, and name the two decisions that would be most expensive to change once there is production data.
Database Schema for Inventory Management
Design a normalised relational schema for Inventory Management supporting {scale}. Give tables with columns, types, nullability, primary and foreign keys, and unique constraints. Stock level should be derived from an immutable movement ledger rather than stored as a mutable counter, which is the classic source of drift. Model multi-location stock, reservations and reconciliation adjustments. Normalise to 3NF, then state explicitly where and why you denormalise, since unexplained denormalisation is how schemas rot. Add indexes justified by the specific queries they serve, not speculatively, and note the write cost each one adds. Cover soft deletes versus hard deletes, created/updated timestamps, and the audit trail. Provide DDL for the core tables, three representative queries with their expected access path, and name the two decisions that would be most expensive to change once there is production data.
Unit Tests for a Python Function
Write unit tests for the following Python function. Cover, in order: the normal path with representative inputs, boundary values at every limit including zero, one, empty and maximum, invalid input and the exact error expected, and any state or concurrency interaction. Use pytest with parametrize for the case table and fixtures for setup. Mock at the boundary with unittest.mock, and prefer freezing time over sleeping. Name each test for the behaviour it asserts, so a failure report reads as a sentence. Assert on observable behaviour rather than internal implementation, or the tests will break on every refactor. Identify which branches remain uncovered and whether that is acceptable. Finally, list any case where the test revealed the function's contract is ambiguous — that is usually a design bug worth fixing before the test is written around it.
Unit Tests for a JavaScript Function
Write unit tests for the following JavaScript function. Cover, in order: the normal path with representative inputs, boundary values at every limit including zero, one, empty and maximum, invalid input and the exact error expected, and any state or concurrency interaction. Use Jest or Vitest with test.each for the case table. Test async behaviour explicitly, including rejection paths, and use fake timers rather than real delays. Name each test for the behaviour it asserts, so a failure report reads as a sentence. Assert on observable behaviour rather than internal implementation, or the tests will break on every refactor. Identify which branches remain uncovered and whether that is acceptable. Finally, list any case where the test revealed the function's contract is ambiguous — that is usually a design bug worth fixing before the test is written around it.
Unit Tests for a TypeScript Function
Write unit tests for the following TypeScript function. Cover, in order: the normal path with representative inputs, boundary values at every limit including zero, one, empty and maximum, invalid input and the exact error expected, and any state or concurrency interaction. Use Vitest with typed fixtures. Test the runtime behaviour the types cannot guarantee — parsed external input, narrowing at boundaries — rather than re-asserting what the compiler already proves. Name each test for the behaviour it asserts, so a failure report reads as a sentence. Assert on observable behaviour rather than internal implementation, or the tests will break on every refactor. Identify which branches remain uncovered and whether that is acceptable. Finally, list any case where the test revealed the function's contract is ambiguous — that is usually a design bug worth fixing before the test is written around it.
Unit Tests for a Java Function
Write unit tests for the following Java function. Cover, in order: the normal path with representative inputs, boundary values at every limit including zero, one, empty and maximum, invalid input and the exact error expected, and any state or concurrency interaction. Use JUnit 5 with @ParameterizedTest for the case table, Mockito at collaborator boundaries, and AssertJ for readable assertions. Test exception type and message, not just that something threw. Name each test for the behaviour it asserts, so a failure report reads as a sentence. Assert on observable behaviour rather than internal implementation, or the tests will break on every refactor. Identify which branches remain uncovered and whether that is acceptable. Finally, list any case where the test revealed the function's contract is ambiguous — that is usually a design bug worth fixing before the test is written around it.
Unit Tests for a C++ Function
Write unit tests for the following C++ function. Cover, in order: the normal path with representative inputs, boundary values at every limit including zero, one, empty and maximum, invalid input and the exact error expected, and any state or concurrency interaction. Use GoogleTest with TEST_P for the case table. Cover ownership and lifetime explicitly, run under sanitizers for memory and UB, and test exception safety where resources are acquired. Name each test for the behaviour it asserts, so a failure report reads as a sentence. Assert on observable behaviour rather than internal implementation, or the tests will break on every refactor. Identify which branches remain uncovered and whether that is acceptable. Finally, list any case where the test revealed the function's contract is ambiguous — that is usually a design bug worth fixing before the test is written around it.
Algorithm Optimization for Sorting Large Datasets
Optimise an approach to Sorting Large Datasets for {constraints}. Start by establishing the baseline: current time and space complexity, and — more importantly — where the measured time actually goes, since the asymptotic bottleneck and the real one frequently differ. Distinguish in-memory from external sorting. If the data does not fit in memory, the problem is I/O-bound and the answer is a merge strategy, not a faster comparison. Consider whether the data is partially ordered or has bounded keys, which admits linear-time approaches. Propose two or three approaches with their complexity, the assumptions each requires about the input, and the conditions under which each wins. Give the recommended implementation with the key steps explained, then be explicit about the trade-off accepted: memory, preprocessing cost, code complexity or accuracy. Add how to benchmark this honestly with representative data rather than a synthetic best case, and state the input size below which the simpler approach is the correct choice.
Algorithm Optimization for Finding Shortest Paths
Optimise an approach to Finding Shortest Paths for {constraints}. Start by establishing the baseline: current time and space complexity, and — more importantly — where the measured time actually goes, since the asymptotic bottleneck and the real one frequently differ. Choose against the graph's properties: BFS for unweighted, Dijkstra for non-negative weights, Bellman-Ford where negatives exist, A* where an admissible heuristic is available. For repeated queries on a static graph, precomputation changes the calculus entirely. Propose two or three approaches with their complexity, the assumptions each requires about the input, and the conditions under which each wins. Give the recommended implementation with the key steps explained, then be explicit about the trade-off accepted: memory, preprocessing cost, code complexity or accuracy. Add how to benchmark this honestly with representative data rather than a synthetic best case, and state the input size below which the simpler approach is the correct choice.
Algorithm Optimization for String Matching
Optimise an approach to String Matching for {constraints}. Start by establishing the baseline: current time and space complexity, and — more importantly — where the measured time actually goes, since the asymptotic bottleneck and the real one frequently differ. Distinguish single-pattern from multi-pattern and one-off from repeated search. KMP and Boyer-Moore suit single patterns; Aho-Corasick suits many; a suffix structure pays off only when the text is searched repeatedly. Propose two or three approaches with their complexity, the assumptions each requires about the input, and the conditions under which each wins. Give the recommended implementation with the key steps explained, then be explicit about the trade-off accepted: memory, preprocessing cost, code complexity or accuracy. Add how to benchmark this honestly with representative data rather than a synthetic best case, and state the input size below which the simpler approach is the correct choice.
Algorithm Optimization for Data Compression
Optimise an approach to Data Compression for {constraints}. Start by establishing the baseline: current time and space complexity, and — more importantly — where the measured time actually goes, since the asymptotic bottleneck and the real one frequently differ. State the trade-off explicitly between ratio, compression speed and decompression speed, and which matters for this workload. Note whether the data has exploitable structure, and that already-compressed input will not compress again. Propose two or three approaches with their complexity, the assumptions each requires about the input, and the conditions under which each wins. Give the recommended implementation with the key steps explained, then be explicit about the trade-off accepted: memory, preprocessing cost, code complexity or accuracy. Add how to benchmark this honestly with representative data rather than a synthetic best case, and state the input size below which the simpler approach is the correct choice.
Algorithm Optimization for Load Balancing
Optimise an approach to Load Balancing for {constraints}. Start by establishing the baseline: current time and space complexity, and — more importantly — where the measured time actually goes, since the asymptotic bottleneck and the real one frequently differ. Compare round-robin, least-connections and consistent hashing against the actual request profile. Where cache locality matters, consistent hashing with bounded loads usually wins; handle the heterogeneous-backend and hot-key cases explicitly. Propose two or three approaches with their complexity, the assumptions each requires about the input, and the conditions under which each wins. Give the recommended implementation with the key steps explained, then be explicit about the trade-off accepted: memory, preprocessing cost, code complexity or accuracy. Add how to benchmark this honestly with representative data rather than a synthetic best case, and state the input size below which the simpler approach is the correct choice.
Microservices Architecture Design
Design a microservices architecture for {system} at {scale}. Begin with the question most designs skip: whether this should be microservices at all, given team size and operational maturity — a distributed monolith is worse than either option. Define service boundaries from business capabilities and data ownership, with each service owning its data exclusively. Specify synchronous versus asynchronous communication per interaction and why, the event schema and its evolution rules, and how you handle transactions spanning services (saga, outbox, or accepting eventual consistency). Cover service discovery, resilience through timeouts, retries with backoff and circuit breakers, idempotency for retried operations, distributed tracing, and the deployment and versioning story. Name the three failure modes this design is most exposed to.
Application Security Audit Checklist
Build a security audit checklist for a {application_type} handling {data_sensitivity}. Organise by the OWASP Top 10 plus the categories it underweights: authentication and session handling, authorisation and object-level access control, input validation and injection, cryptography and secrets management, dependency and supply-chain risk, logging and monitoring, and infrastructure configuration. For each item give the specific check, how to test it (manual step or tool), what a pass looks like, the severity if it fails, and the remediation. Weight broken object-level authorisation highly — it is the most commonly missed and most exploited. Add the checks that belong in CI rather than a periodic audit, and note where a specialist penetration test is required rather than a checklist.
Code Refactoring Plan
Write a refactoring plan for {codebase_area} with {pain_points}. Start with the rule that makes refactoring safe: characterisation tests before any change, so behaviour is pinned before it is moved. Inventory the problems — duplication, long functions, unclear boundaries, leaked abstractions, missing tests — and rank them by the cost they impose on current work rather than by how ugly they look. Sequence the work into independently shippable steps, each behaviour-preserving and each leaving the codebase working, because a long-lived refactoring branch is how these fail. For each step give scope, risk, verification and a rollback. State explicitly what you are choosing NOT to refactor and why, and the measurable signal that tells you the effort paid off.
CI/CD Pipeline Setup
Design a CI/CD pipeline for {stack} deploying to {target}. Define the stages and what fails the build at each: lint and type checks, unit tests, build, integration tests, security and dependency scanning, then deploy. Keep the feedback loop fast — state the target time to first failure signal and what runs in parallel or only on the main branch to protect it. Cover artefact immutability and promotion across environments rather than rebuilding per environment, secrets handling that never exposes values in logs, database migrations and their ordering relative to deploys, and the deployment strategy (rolling, blue-green or canary) with automated rollback triggers. Add branch protection rules, the flaky-test policy, and the three pipeline failures most likely to be worked around rather than fixed.
Technical Documentation Template
Create a technical documentation template for {project_type}. Structure it for someone arriving via search who will read exactly one page, not the whole site. Cover: what this is and what problem it solves in two sentences, when to use it and when not to, a quickstart that works end to end in under five minutes, core concepts with the vocabulary defined once, task-based how-to guides, an API or configuration reference, troubleshooting organised by the symptom the user observes rather than the underlying cause, and an architecture section for contributors. Specify which sections are mandatory, how code examples are kept runnable and tested, the review trigger that catches documentation drifting from behaviour, and the ownership model that stops it rotting.