Exercise:
Next time you’re stuck, instead of “write this whole feature,” ask: “Which artifact is missing here (requirements/design/code/tests/docs)?” Then ask the model for that artifact only.
Several prompt patterns are particularly useful for software engineering.
Give the model a role, constraints, and an output format.
Pattern
You are a senior {language/framework} engineer in a {domain} team.
Goal: {one clear goal}.
Constraints: {standards, stack, limits}.
Output: {bullet list, code block, checklist, etc.}.
**Example (backend)**
You are a senior TypeScript engineer on a fintech backend.
Goal: suggest a safe design for retrying failed payments.
Constraints: Node 20, PostgreSQL, no external queues.
Output: brief architecture description, then pseudocode for the retry logic.
Exercise:
Take a current task and rewrite your next AI question into this pattern. Compare output quality with your usual “casual” prompt.
Break work into tiny steps: one prompt per sub‑task.
Instead of:
Build a full auth system with JWTs in NestJS and write tests.
Use a chain like: This is “task decomposition” or “decomposed prompting.”
Exercise:
Pick one real task you have this week. Write a list of 5-8 prompts that would get you from problem → working, tested code. Use them sequentially instead of one mega‑prompt.
Ask the model to attack or review something, not to create from scratch.
Patterns
Code review:
Act as a strict code reviewer. Given this code and these standards, list specific issues and suggested changes.
Design critique:
Act as a system architect. Here is my design. Identify scaling risks, failure scenarios, and unclear responsibilities.
GitHub’s Copilot guidance is essentially this: have AI review snippets and propose improvements; you still decide what to accept.
Exercise:
Paste one of your recent PRs (or a simplified version) and ask:
“Act as a strict reviewer. What are the top 5 issues (correctness, readability, performance, security)?”
Then decide which comments you’d actually address.## d) Self‑check / reflection prompts
Use the model on its own output: Re‑read your last answer. Identify at least 3 potential errors, missing edge cases, or unsafe assumptions. Propose concrete fixes.
This leverages “introspective” prompt patterns shown to improve quality.
Exercise:
After a long answer you like, always follow with a self‑check prompt like above and compare.
Trying to have an LLM build a whole feature usually produces fragile, untestable code. Instead, decompose tasks along artifacts and complexity.
A blog on task decomposition shows exactly this: instead of “fix this whole feature,” it breaks debugging into focused questions like “What causes this error message?” and “What needs to change in auth.js?”
Example sequence (bugfix) Exercise:
Take a real bug. Before you touch it, use those four prompts. Compare your own diagnosis to the model’s; note where it helped or confused things.
You can treat different models as tools in a belt, picking per task.
Common usage patterns reported by practitioners:
A typical “toolbelt” approach is to start with the fastest model to brainstorm or generate ideas, then move to a slower, more deliberate one to structure and refine.
Practitioner example:
One architect uses Gemini wired into Claude so Claude can work over a large codebase, then uses Claude itself for heavier coding tasks and iterative refinement-but still doesn’t ask it to “design the complete product.”
Exercise:
Write a small “LLM playbook” for yourself like:
Then force yourself to follow it for a week and adjust based on what actually worked.
Think of AI as a junior dev who can type very fast but is overconfident. Your job is to review.
GitHub suggests validating that AI code compiles, runs tests, and matches your requirements and patterns. A broader “reviewer‑mode” checklist adds alignment, accuracy, completeness, and risk.
Ask yourself:
Exercise:
Take one AI‑generated file. For each of the four dimensions above, write 1-2 concrete comments (like you would in a PR). Only then decide what to keep.
The risk with heavy AI use is “outsourcing thinking.” You can avoid that by explicitly practising evaluation.
A 2026 article on “reviewer‑mode” suggests: strip away tone and just inspect the logic and assumptions. Ask:
Concrete habits
Exercise:
Pick one AI answer this week and spend 10 minutes writing a short “review” of it in a markdown file: what’s good, what’s wrong, what you’d change, what you learned. That’s how you turn AI usage into deliberate practice.
Real‑world reports show successful patterns like:
Mini‑project exercise:
Take a small feature (e.g., “add rate limiting to this API”) and intentionally use AI in each phase:
At each step, you review and edit as if a junior wrote it.
Here’s a compact set you can cycle through:
Decomposition drill:
Prompt‑pattern drill:
Model‑choice drill:
Red‑team drill:
If you tell me your main stack (e.g., “TypeScript/React”, “Java/Spring”, “Python/data”), I can turn this into a short, concrete “training plan” with stack‑specific example prompts and exercises. What tech stack and kind of work (feature dev, backend APIs, data, DevOps, etc.) are you mostly using LLMs for right now?
Rizwan Saleem — https://rizwansaleem.co