Skill.re
Prompt Patterns for Software Engineering
Patterns You'll Use Repeatedly
You've probably heard the phrase "prompt engineering" and dismissed it as marketing fluff. But here's the uncomfortable truth: there's a massive difference between how you ask the AI something and the quality of what you get back. Not in subtle ways. In "this works great versus this is garbage" ways.
After working with AI on hundreds of engineering tasks, patterns emerge. Certain structures produce consistently excellent results. Certain ways of framing problems yield deeper reasoning. The difference between a prompt that takes five minutes and one that solves your problem versus a prompt that produces a first draft you need to rewrite entirely.
Master these patterns and your AI productivity doesn't just improve. It multiplies. You stop fighting the tool and start having it think alongside you.
Pattern 1: The Implementation Pattern
This is your go-to for generating code. The structure matters because the AI needs to understand what you want, what constraints exist, and whether it should produce something safe or something performance-optimized.
Template:
Implement a [component/function] that [clear, specific goal].
Requirements:
- [functional requirement 1]
- [functional requirement 2]
- [functional requirement 3]
Constraints:
- [technical constraint: must use X, must not use Y]
- [performance constraint: must handle N requests/sec]
- [integration constraint: must work with existing Z]
Example Usage:
Input: [example]
Output: [expected output]
Use [language and framework version]. Follow [company/framework conventions].
Why each part matters: "Requirements" tells the AI what you need. "Constraints" prevents it from generating code that won't work in your environment. The example gives the AI a concrete target. Specifying the framework version and conventions saves you refactoring work.
Real example from a CTO: "Implement a rate limiting middleware for Express that tracks requests by IP address. Requirements: Track requests across all routes. Support per-route configuration. Log when limits are exceeded. Store state in Redis for distributed systems. Constraints: Must complete in Analyze this [code/system/architecture] for [specific concern].
Context:
[Background about the system, why it was built this way, what it does]
What I'm analyzing:
[Paste code or describe architecture]
Specific focus:
[What matters most: performance, maintainability, security, scalability?]
Look for:
- [Specific issue type 1]
- [Specific issue type 2]
- [Specific issue type 3]
Provide:
- Root cause analysis
- Severity and impact
- Actionable fixes
The key here is being specific about what you're analyzing. "Look at this code" produces surface-level feedback. "Analyze this code for performance bottlenecks given we're processing 100K records per minute" produces useful analysis.
Pattern 3: The Refactoring Pattern
When you know code needs improvement but aren't sure how to approach it, this pattern helps the AI make smart trade-offs.
Template:
Refactor this code to [specific improvement goal].
Current code:
[Paste code]
Constraints (must preserve):
- [Behavior that cannot change]
- [API that cannot change]
- [Integration point that cannot change]
Improvement goals (in priority order):
- [readability: remove nested callbacks]
- [performance: optimize database queries]
- [maintainability: reduce cyclomatic complexity]
Context:
[This code is used by X. It processes Y. It talks to Z system.]
Specifying constraints is crucial. The AI needs to know what's load-bearing versus what's negotiable. Otherwise it might refactor away something that has a hidden dependency you'll discover at 2am.
Pattern 4: The Documentation Pattern
Documentation is where most engineering teams fail. It's either nonexistent or outdated. The AI can't fix "nonexistent," but it can help you write comprehensive documentation fast.
Template:
Document this [code/system/process] for [audience].
What it does:
[High-level description]
Who uses it and why:
[Product team? Other engineers? Operators?]
Include sections on:
- [How it works at a high level]
- [How to use it with example]
- [Common issues and how to debug]
- [Performance characteristics and limits]
- [How to contribute or extend it]
Tone: [Technical but accessible / Deep technical / Quick reference]
Format: [Markdown for our wiki / Docstring / README]
Pattern 5: The Fix Pattern
When code is broken and you need help, give the AI everything you have. More context means better diagnosis.
Template:
Debug this [code/system/behavior] that is [broken in this way].
Error message or symptom:
[Paste exact error or describe behavior]
Context:
[How this is used, what triggers it, when it started failing]
Code:
[Paste relevant code]
What I've tried:
[What didn't work and why you think it didn't work]
What I suspect:
[Your hypothesis about root cause, even if you're not sure]
Debug goal:
[Find root cause, provide fix with explanation]
The "What I've tried" section is gold. It tells the AI what you've already eliminated, saving it from suggesting things you know won't work.
Pattern 6: The Architecture Pattern
For architectural decisions, the AI helps you think through trade-offs systematically.
Template:
We're considering [architectural decision: monolith to microservices, database change, etc.].
Current state:
- Scale: [users, requests/sec, data volume]
- Tech stack: [what we use]
- Team size: [how many engineers, skill levels]
What we're trying to solve:
[The actual problem: deployment bottleneck, scalability limit, team velocity]
Constraints:
- [Can't stop serving customers]
- [Budget is constrained]
- [Timeline pressure: yes/no]
Alternatives we're considering:
- [Option A]
- [Option B]
- [Option C]
For each option, analyze:
- Implementation effort and timeline
- Risk and failure modes
- Ongoing operational burden
- Cost (infrastructure and engineering time)
- Reversibility (easy to undo?)
Building Your Pattern Library
Here's what separates teams that use AI effectively from teams that are just dabbling: the winning teams build a library of patterns that work for their specific context. Not generic patterns from the internet. Patterns that work for their codebase, their architecture, their team's conventions.
Every time you use a prompt that produces excellent results, save it. Not to your notes. To a shared document. Make contributing patterns part of your code review culture. Someone writes a great prompt? Include it in the pattern library.
Over three to six months, your library grows from five patterns to fifty. New team members learn how to prompt effectively faster. Consistency improves because everyone uses the same templates. Your AI productivity compounds because each engineer is reusing patterns that already work in your context.
Team Pattern Library Structure: Create a shared document (Confluence, GitHub wiki, Notion, whatever you use). For each pattern, include: (1) Template with placeholders, (2) When to use it, (3) Real example from your codebase, (4) What to avoid, (5) Variations that work for different situations.
Start with five patterns. Your implementation pattern. Your analysis pattern. Your refactoring pattern. Your debug pattern. Your documentation pattern. Use them religiously for one sprint. Notice which ones save the most time. Add two more patterns you discover.
By month two, you have seven core patterns everyone uses. By month three, new patterns emerge that are specific to your challenges: "We always need to analyze database performance" becomes its own pattern. "We frequently refactor auth flows" becomes a pattern. "We document deployments for operators" becomes a pattern.
Making Patterns Stick: Include pattern templates in your PR template. When someone opens a PR, the template says "Used Pattern X for code generation?" This isn't bureaucracy. It's making the thing that works the path of least resistance.
Testing and Refining Your Patterns
Not all patterns work equally well. A pattern that works great for microservice APIs might not work for frontend code. A pattern that works with one LLM might not work perfectly with another.
When you use a pattern, think about what made it work. Did you need more detail? Less detail? Different structure? Keep notes. After two weeks using a pattern, refine it based on what you learned.
Some teams do monthly "pattern reviews": which patterns are actually getting used, which are gathering dust, what new patterns do we need? This keeps your library alive instead of letting it rot.
Patterns Work Better for Different Tools
Here's something people don't talk about much: patterns calibrated for one LLM don't always translate perfectly. Claude likes deep context. Some other models prefer brief instructions. Some LLMs do great on architectural reasoning. Others shine on code generation.
Once you pick your AI tool for the team, calibrate your patterns for it. Try variations. Document what works. For example, with Claude, providing very detailed context and asking for step-by-step reasoning produces exceptional results. With other models, verbose context sometimes reduces output quality.
This isn't huge, maybe 10-15% difference, but when patterns are the leverage point for your whole team's productivity, small improvements compound.
Anti-patterns to Avoid
Just as important as knowing good patterns: knowing what doesn't work. After watching dozens of teams use AI, certain patterns consistently produce bad results. Know what to avoid:
The "Dump and Hope" Pattern: Pasting a massive codebase and saying "fix this." The AI gets lost. Break it into smaller pieces. If you need the AI to understand the whole system, provide a summary first, then ask it to focus on a specific part.
The "No Context" Pattern: Asking the AI to generate something without any context about how it fits into your system. Results are generic and won't integrate well. Always provide context about architecture, constraints, and existing patterns.
The "Vague Goal" Pattern: "Make this better." Better how? Faster? More readable? More maintainable? The AI guesses. You get work you don't actually want. Be specific about what "better" means.
The "Assume the AI Knows" Pattern: Not explaining domain-specific knowledge or business logic. You understand why you made a certain architectural choice. The AI doesn't. Explain it.
Advanced: Combining Patterns
The most powerful prompts combine patterns. For example: "Analyze this code for performance issues (analysis pattern) and then refactor it (refactoring pattern) with these constraints (implementation pattern)."
Or: "I'm debugging this error (fix pattern). Before you fix it, step through what should happen (chain-of-thought pattern) to make sure we understand the root cause."
The more skilled you become, the more you mix and remix patterns for your specific situation. You develop a sense for what information the AI needs and in what order to ask for it.
Key Insight
Prompt patterns are your leverage. Good patterns save hours. Great patterns become institutional knowledge. Build a library. Refine it. Make it part of how your team works.
What to Do Monday Morning
- Identify the three tasks you use AI for most frequently. Code generation, analysis, debugging?
- For each task, write down what's currently working. What structure do you use? What context do you provide?
- Create a simple pattern template document. Start with just three patterns. One for your most common task. One for your second most common. One for something harder.
- Next week, test the patterns on real work. Refine them based on what actually worked.
- Share your patterns with one teammate. Ask if they'd find them useful. Iterate based on feedback.
Frequently Asked Questions
Q: Isn't creating prompt patterns just creating templates? How is that different from using AI normally?
Yes, they're templates. But templates matter more than you think. When everyone on your team uses the same structure for the same type of problem, you get consistency. Better results. Faster. New people learn faster because they follow established patterns instead of experimenting endlessly. It's the difference between "I'll figure out what works" and "we know what works."
Q: What if the patterns don't work for my team's specific context?
They won't, at first. The patterns here are starting points. Your job is to customize them for your specific tech stack, team structure, and problems. A team doing machine learning needs different patterns than a team building APIs. That's the whole point of building a team library instead of copying from the internet.
Q: Should we update patterns when new versions of AI tools come out?
Not frantically, but yes, periodically. Major updates to LLMs sometimes require pattern refinement. Every few months, review your patterns. Is one consistently underperforming? Try a variation. Test it on a few tasks before updating the library.
Q: Can we use these patterns with all AI tools?
The core concepts apply to all of them. Different models have different strengths and may require minor adjustments. But the fundamental idea, providing clear structure, specific constraints, and enough context, works across tools. Your mileage will vary slightly, which is why testing on your tool matters.
Q: How many patterns should a team actually maintain?
Start with five to seven. Too many patterns and nobody remembers them. Too few and you're forcing patterns to fit situations they don't. As your team grows and you discover patterns that are genuinely useful and different, add them. Most mature teams end up with 15-25 core patterns.