Prompt engineering for developers: a guide that saves you hours every day

At my trainings, I start with one experiment. I give the entire team the same task — refactor a function using AI. The results vary dramatically. Not because some developers are better — but because they write better prompts.

Prompt engineering isn't a buzzword. For developers, it's a practical skill you can learn in an afternoon that immediately improves output quality. The difference between one iteration and five is often just how you phrase the question.

The three most common mistakes

1. Prompts that are too vague

The most common mistake. 'Fix this code' tells AI nothing — what's wrong? What's the expected output? What framework are you using? The more context you provide, the more precisely AI responds.

# Bad prompt:
Fix this code.

# Good prompt:
This function has a race condition on 
concurrent cache access. 
Add a mutex lock around cache operations 
and write a test that reproduces the issue 
with 10 simultaneous accesses.

The second prompt gets the right answer on the first try. The first prompt leads to guessing and 5 iterations of corrections.

2. Missing context

AI doesn't know your framework, your conventions, or the broader context of the change. The more context you provide, the fewer iterations you need. Attach relevant files, describe the existing architecture, mention constraints.

• What to include in context:
• Framework and language (Next.js 16, TypeScript, Prisma)
• Team conventions (naming, error handling, test patterns)
• Existing architecture (where auth lives, how routing works)
• Constraints (backward compatibility, performance requirements)
• What MUST NOT break (existing APIs, tests, integrations)

3. No verification in the prompt

'Do X' vs. 'Do X. Then run the tests and fix any failures.' The second approach gives AI a feedback loop — it can verify its own work and iterate. This is the simplest way to dramatically improve output quality.

A template for technical prompts

After hundreds of hours of experimentation, I developed a simple template for technical prompts. Four components:

• 1. WHAT I want to change — concrete task, not a vague request
• 2. WHY (context) — reason for the change, broader architecture
• 3. CONSTRAINTS — what must not break, backward compatibility
• 4. HOW TO VERIFY — tests, linter, expected output

# Template in practice:

# WHAT:
Rewrite the auth middleware from session-based 
to JWT.

# WHY:
We're moving to microservices and need 
stateless auth. Currently using 
express-session with Redis store.

# CONSTRAINTS:
- Existing API endpoints must work 
  without changes (backward compatible)
- Refresh token rotation (not single-use)
- httpOnly cookies for token storage

# VERIFICATION:
After completion, run the full test suite 
and fix failures. Verify all existing 
tests pass.

Advanced techniques

Chain of thought — breaking down into steps

For complex tasks, tell AI to break the problem into steps before implementing. 'First analyze the existing code. Then propose an approach. Then implement step by step. After each step run tests.'

# Chain of thought prompt:

1. Analyze src/auth/ — how does the 
   current auth work?
2. Propose a JWT migration plan 
   (what steps, in what order)
3. Implement step by step
4. After each step run tests
5. At the end verify everything works

Negative instructions — what NOT to do

AI tends to add things you didn't ask for. Explicitly tell it what NOT to do. 'Don't modify existing tests.' 'Don't add new dependencies.' 'Don't refactor parts of the code unrelated to the change.'

Example-based prompts

Show AI an example of existing code and say 'do the same for X.' AI understands your style, conventions, and patterns from the example and applies them consistently. This is especially powerful for code conventions.

# Example-based prompt:

Here's an existing endpoint in our style:

[attach existing endpoint code]

Write a new endpoint for /api/invoices
in the SAME style — same structure,
same error handling convention,
same logging pattern.

Common patterns that work

• 'Explain what you're doing before you do it' — forces AI to think
• 'Write tests BEFORE implementation' — TDD with AI
• 'Use a subagent to figure out how X works' — research without context loss
• 'Run tests after each step' — feedback loop
• 'Update CLAUDE.md so this doesn't happen again' — learning from mistakes

Why it's worth learning

A developer with good prompts finishes a task in one or two iterations. A developer with bad prompts spends five iterations fixing AI output and eventually writes it by hand. That difference is between 'AI saves me hours daily' and 'AI is useless.'

Prompt engineering isn't about writing longer prompts. It's about writing more precise ones. Four sentences with context, constraints, and verification beat two paragraphs of vague instructions.

Investment: an afternoon of learning. Return: hours every day. That's the best ROI you'll get in your dev workflow.