AI Prompts for Node.js Development

Before: The Weak Prompt

Most Node.js development guides are wrong about one thing: they treat Node.js as "JavaScript on the server" and nothing more. But Node.js's event loop, non-blocking I/O model, and single-threaded concurrency create specific patterns that don't exist in browser JavaScript — and AI that doesn't know you're writing Node.js gives you code that misses all of them.

Here's the weak prompt that produces generic JavaScript masquerading as Node.js code:

Write a Node.js server that handles user authentication.

The AI writes an Express server. Sets up routes. Handles POST /login. Returns a JWT. It looks fine.

What it misses: no error handling middleware, no graceful shutdown on SIGTERM, no process-level uncaught exception handling, no async error propagation through Express 5 or explicit next(err) calls. It's a demo. In production, any unhandled promise rejection will either silently swallow the error or crash the process, depending on the Node.js version.

Why It Fails

"Write a Node.js server" is too broad and contains no Node.js-specific requirements. The AI interprets this as "write web server code in JavaScript" — and web server code in JavaScript looks a lot like web server code anywhere, minus the operational concerns that distinguish Node.js production systems from demos.

Three specific gaps in generic Node.js prompts:

No event loop awareness. Blocking the event loop with synchronous operations —

fs.readFileSync

No process lifecycle handling. Production Node.js needs to handle SIGTERM (for graceful shutdown in Kubernetes), uncaught exceptions, and unhandled promise rejections. Missing any of these causes silent failures or abrupt crashes.

No clustering or worker thread strategy. Node.js runs on a single thread by default. CPU-intensive operations block all requests. A production server that needs to do image processing or data transformation needs a strategy for offloading that work — which the prompt needs to specify.

⚠️ Common mistake: Accepting Express middleware in the wrong order. Error-handling middleware (four-argument function: err, req, res, next) must come after routes. If it's registered before, it never fires. AI doesn't always get this right without explicit instruction.

After: The Improved Prompt

You are a senior Node.js engineer. Write a production-ready Node.js service for the following requirement.

Node.js version: 20 LTS
Framework: Express 4.x (migrate to Express 5 error handling conventions)
Database: PostgreSQL via pg (connection pool, not single connection)

Requirement: User authentication service — POST /login returns JWT, POST /logout invalidates token, GET /me returns current user.

Production requirements:
1. Error handling: all async route handlers wrapped with a try/catch or asyncHandler wrapper — errors passed to next(err), not swallowed
2. Error middleware: Express error handler registered AFTER all routes, returns consistent JSON error format {error: string, code: string}
3. Process lifecycle: handle SIGTERM with graceful shutdown (finish in-flight requests, close DB pool, exit)
4. Uncaught exceptions and unhandled promise rejections: log and exit (never silent swallow)
5. Security headers: use helmet middleware
6. Rate limiting: rate-limit POST /login to prevent brute force
7. Logging: structured JSON logging (pino or winston) with request ID correlation
8. Database: pg connection pool, not a new connection per request

Do NOT use: synchronous file operations in request handlers, blocking operations on the main thread

After the code:
- Describe the graceful shutdown sequence step by step
- Flag any places where the event loop could be blocked
- Note the security assumptions this service makes

What this does: Specifies every Node.js-specific operational concern — event loop safety, process lifecycle, connection pooling, error propagation — rather than leaving them to chance. The "do NOT use" list prevents the specific patterns that cause production incidents.

⚡ Pro tip: Add "show the order of middleware registration and explain why this order matters" to any Express prompt. Middleware order is one of the most common sources of bugs in Node.js applications — authentication middleware before routes, error middleware after routes, body-parser before any middleware that reads the body. The explanation is as valuable as the code.

Breaking Down Each Element

"asyncHandler wrapper" — Express 4 doesn't automatically catch errors thrown in async route handlers. You need either a wrapper function or you handle the promise rejection manually. Express 5 (in beta) handles this automatically. Specifying this prevents the silent swallow pattern.

"registered AFTER all routes" — Express error middleware only fires if it's registered after the routes that might throw. It's a positional thing. Without specifying this, the AI sometimes registers it in the wrong place.

SIGTERM handling — Kubernetes sends SIGTERM before it terminates a Pod. Without a SIGTERM handler, requests in flight get dropped. With one, the server finishes what it's doing and shuts down cleanly. This is the difference between graceful deploys and intermittent 503s during rolling updates.

"pg connection pool, not a new connection per request" — creating a new database connection per request is one of the most common Node.js performance mistakes. A connection pool reuses connections. Without specifying this, AI often writes

new Client()

⚡ Pro tip: For any Node.js service that makes external HTTP calls, add: "Use http.Agent with keepAlive: true for connection reuse, and set a reasonable timeout (5–10 seconds). Document what happens when the external service is slow or unavailable." Connection keep-alive and timeout handling are almost never in AI-generated Node.js code by default.

Variations for Different Contexts

For Node.js CLI tools:

Write a Node.js CLI tool for [task]. Use Commander.js for argument parsing. Include: --help output with descriptions for each flag, --verbose mode that enables debug logging, proper exit codes (0 for success, non-zero for failure), and stderr for errors (not stdout). Handle SIGINT (Ctrl+C) gracefully.

What this does: CLI tools have their own conventions — exit codes, stdout vs stderr, signal handling — that are different from server code and that the AI skips without specification.

For Node.js streaming data processing:

Write a Node.js script that processes a large JSON file (potentially multi-GB) using streams. Use JSONStream or stream-json to parse without loading the full file into memory. Handle backpressure. Log progress every 10,000 records. Exit with code 1 if processing fails, 0 if successful.

What this does: Large file processing is a classic Node.js use case where the streaming API shines — but only if you use it correctly. The backpressure requirement prevents the stream equivalent of memory overflow.

Save and Reuse This

The improved prompt's structure — version + framework + production requirements + explicit exclusions — works for any Node.js task. The production requirements section is your Node.js-specific checklist: event loop safety, process lifecycle, error propagation, connection pooling.

Save your team's Node.js production requirements as a reusable template in PromptABCD. Every ai prompts nodejs development prompt you write starts from that baseline — which means every piece of code that comes out of it is production-ready by default, not by accident.

Node.js Security Prompts

Security in Node.js has specific concerns that generic security prompts miss. A targeted Node.js security prompt:

Review this Node.js/Express application for security vulnerabilities specific to Node.js. Check:
1. Dependency security: any use of known-vulnerable packages (reference current OWASP Node.js practices)
2. Path traversal: any file system operations using user-supplied paths
3. ReDoS (Regular Expression Denial of Service): any regex applied to user input that could have catastrophic backtracking
4. Prototype pollution: any use of Object.assign or merge functions with user-supplied objects
5. SSRF (Server-Side Request Forgery): any HTTP requests to user-supplied URLs
6. Environment variable exposure: any place where process.env values could leak to clients

Code: [paste]

What this does: Node.js-specific vulnerabilities — prototype pollution, ReDoS, SSRF — are underrepresented in general security reviews. This prompt covers the attack surface specific to the Node.js runtime and ecosystem.

⚡ Pro tip: For any Node.js service that accepts file uploads, add: "Review the file upload handling specifically. Check: file type validation (not just MIME type — check magic bytes), upload size limits, temporary file cleanup, and directory traversal prevention." File upload security is one of the most common Node.js vulnerability classes and one that AI won't flag without explicit prompting.

Node.js Observability

Production Node.js needs more than logs — it needs metrics and traces to understand performance at scale.

Add observability to this Node.js service. Include:
- Structured JSON logging with pino: request duration, response status, error details with stack traces
- Prometheus metrics endpoint (/metrics): request rate, error rate, latency percentiles (p50, p95, p99)
- OpenTelemetry trace instrumentation for the critical path (incoming request to database query)
- Health check endpoint (/health) that returns the status of all downstream dependencies

Framework: Express 4.x
Database: PostgreSQL via pg

What this does: Observability requirements in a prompt produce instrumented code from the start — instead of the typical pattern of adding instrumentation retrospectively during an incident. The three-signal approach (logs, metrics, traces) covers the observability bases that matter most in production Node.js.

⚡ Pro tip: For Node.js APIs that handle file uploads or process user-provided content, ask for a specific content safety review: 'Review the content processing code in this Node.js service for: MIME type validation that goes beyond the Content-Type header, file size limits enforced before reading the entire upload, path traversal prevention in any filename usage, and temporary file cleanup on error paths.' Content handling is one of the highest-risk Node.js code categories.

The combination of security and observability prompts alongside your core Node.js development prompts makes your ai prompts nodejs development library a full operational toolkit.