Prompt Engineering for Production Safety

According to GitHub's 2025 developer survey, 92% of developers now use AI coding tools regularly. A separate analysis by GitClear found that 60% of new code committed to production codebases in 2025 was AI-generated or substantially AI-assisted.

Think about that for a moment. The majority of new production code is being written by systems that, as we've covered, have a 2.74x higher vulnerability rate than experienced developers. And most of the prompts driving that code generation look like this:

"Build a user authentication system with login and signup forms"

No constraints. No safety requirements. No specification of what "done" means in production terms. The AI generates something that works. The developer ships it. Three months later, someone finds the SQL injection vulnerability in the login form.

Prompt engineering for production safety isn't about using magic words. It's about treating your prompt as a specification — one that explicitly includes security constraints, not just functional requirements.

The Security Review First Pattern

Before you ask AI to build anything, ask it to identify what could go wrong. This is not about being cautious — it's about getting better output. An AI that has been primed to think about security will generate more secure code.

WRONG:
"Build a user profile page that lets users update their bio and avatar URL."

RIGHT:
"I'm building a user profile page. Before writing any code, identify the top 3 security
risks in this feature — specifically around user input, file storage, and URL handling.
Then build the feature with those risks addressed."

This prompt pattern consistently produces code that handles XSS, open redirect vulnerabilities in avatar URLs, and input length validation — three things the naive prompt will miss.

Constraint-Based Prompting

Security constraints belong in the prompt, not in your post-review. When you know what patterns are dangerous, ban them explicitly:

"Build a comment form. Constraints:
- Never assign untrusted content to innerHTML. Use textContent for all user-generated content.
- Always parameterize database queries. No string concatenation in SQL.
- Validate and sanitize all inputs server-side, not just client-side.
- Rate-limit the submission endpoint at 10 requests per minute per IP."

These constraints cost you 30 extra words. They eliminate the four most common vulnerabilities in comment forms.

The constraints that matter most for each domain:

SQL and database operations:

• "Always use parameterized queries / prepared statements"
• "Never concatenate user input into SQL strings"
• "Require pagination on all list queries — no unbounded SELECT *"

Authentication and authorization:

• "Implement server-side session validation on every protected route"
• "Hash passwords with bcrypt (cost factor 12+). Never store plaintext."
• "Check authorization before returning any resource — never trust client-provided IDs alone"

File and URL handling:

• "Validate file types by MIME type and magic bytes, not just extension"
• "Never pass user-controlled values directly to filesystem operations"
• "Sanitize and validate redirect URLs to prevent open redirects"

APIs:

• "Include rate limiting on all public endpoints"
• "Return generic error messages to clients — never expose stack traces or internal paths"
• "Validate request body schema before processing"

The Diff Review Habit

Every AI-generated code change should be reviewed as a diff, not as a complete file. This sounds obvious, but many vibe coders accept AI output by reviewing the final file state — which makes it easy to miss what changed and what the AI removed.

When an AI refactors a function, it may also silently remove a security check that was in the original. When it adds a feature, it may modify an existing validation routine in a way that widens an attack surface. These changes are invisible if you're reading the file; they're obvious in the diff.

# Always review AI changes as a diff
git diff HEAD

# Or review staged changes before committing
git diff --staged

# For larger changes, use a structured diff tool
git difftool HEAD

Make this a reflex. Before you commit anything AI-generated, look at the diff.

Structuring Prompts for Code You Can Ship

A production-ready prompt has four parts:

1. Context: What is this component? What's the security context? (Public API? Admin-only? Handles PII?)
2. Functional requirements: What should it do?
3. Explicit constraints: What patterns are prohibited? What standards must it meet?
4. Verification requirement: Ask the AI to explain how it handled the top risks.

Example:

"This is a public-facing API endpoint that handles password reset requests for an
authentication system. Security context: it processes user-submitted email addresses
and sends password reset tokens.

Build a POST /auth/reset-password endpoint that:
- Accepts an email address
- Looks up the user in the database
- Generates a cryptographically random reset token (expires in 15 minutes)
- Stores the token hash (not the token itself) in the database
- Sends a reset email

Constraints:
- Always use parameterized queries
- Return the same response whether the email exists or not (prevent email enumeration)
- Rate-limit to 3 requests per email address per hour
- Token must be 32+ bytes of CSPRNG output, URL-safe encoded

After writing the code, explain specifically how you prevented email enumeration and
how the token storage protects against database theft."

This prompt is longer. The code it produces is significantly safer and will survive a security review.

What to Do Next

1. Review your last five AI prompts. Did any of them include explicit security constraints? If not, identify the top vulnerability class for each feature and add constraints before your next session.
2. Build a personal constraint library. A text file with your standard constraints for SQL, auth, file handling, and APIs. Paste the relevant section into every prompt for that domain.
3. Adopt the diff review habit starting today. Before committing any AI-generated change, run git diff --staged and read it completely.

The 92% adoption rate means AI tools are standard infrastructure now. What isn't standard yet is using them with production-grade discipline. That gap is exactly what this guild exists to close.

---

🤖 Ghostwritten by Claude Opus 4.6 · Curated by Tom Hundley