The 12 AI Prompts I Actually Use Every Week as an Indie Engineer
Not 50, not 100. Twelve specific prompts I reach for weekly building real production software solo — with the actual prompt text, when to use each, and the failure mode it prevents.
Raju H
AI Builder · Dhaka
TL;DR
Most "AI prompts for engineers" lists collect 50+ prompts the author has never personally used. Research backs the smaller number: most experienced people reuse only 10–15 prompts repeatedly. Below are the 12 I reach for weekly building this bootcamp platform solo. Each one is copy-paste ready, with the situation that triggers it and the mistake it prevents. They're ordered by how often I use them, not by importance.
How to read this list
Every prompt has three parts:
- When I reach for it — the specific trigger
- The prompt — copy-paste ready;
[brackets]mark the variable parts - Why it works — the failure mode it prevents
The throughline: every good prompt is a small spec. It names the artifact, the constraints, and what to avoid. Vague prompts produce vague output.
1. The codebase boot-up prompt
When I reach for it: Returning to a part of the code I haven't touched in two-plus weeks.
The prompt:
Read the files in [path/]. In your reply give me exactly:
1. What this module does, in 2 sentences.
2. The 3 most important functions and why they matter.
3. Any non-obvious constraints, gotchas, or comments I should know
before editing — especially anything that looks load-bearing.
Don't suggest changes. Just orient me.
Why it works: The "don't suggest changes, just orient me" line stops the model from immediately proposing a refactor I didn't ask for. I want a map, not a renovation.
2. The spec-first feature prompt
When I reach for it: Before implementing any feature with real logic.
The prompt:
I want to build [feature]. Before writing code, write a short spec:
- The artifact and where it lives (file paths in this repo).
- 3-6 named constraints it must satisfy.
- The failure modes to prevent (what wrong-but-plausible output
would look like).
- The boundary: which existing files/types it touches.
Then stop. I'll review the spec before you implement.
Why it works: Forcing the spec out of the model first, then pausing, catches misunderstandings before they become code. Half the time the spec reveals I described the feature wrong. Cheaper to fix a paragraph than a diff. This is spec-driven AI in a single prompt — and if you'd rather structure it in a form, the free Spec Builder does exactly this.
3. The "write the failing test first" prompt
When I reach for it: Any feature where correctness matters more than speed (payments, auth, refund math).
The prompt:
Before implementing [feature], write the test that would fail today
and pass once it's built. Cover: the happy path, [specific edge case],
and the failure case where [bad input]. Use [test framework]. Show me
the test; don't implement the feature yet.
Why it works: Writing the test first turns a fuzzy "make it work" into a concrete target. When I built the seat-count logic — pending rows expire after 15 minutes — the test forced me to pin down exactly what "expired" meant before any code existed.
4. The senior-reviewer prompt
When I reach for it: Before committing anything non-trivial.
The prompt:
Review this diff like a skeptical senior staff engineer. Rank issues
by severity. For each: what's wrong, why it matters, and the smallest
fix. Check specifically: edge cases, error handling, N+1 queries,
anything that leaks PII to the client, and anything that contradicts
the conventions in CLAUDE.md. Be blunt. If it's fine, say so in one line.
Why it works: "Be blunt. If it's fine, say so in one line" prevents the model from inventing nitpicks to seem useful. I want real problems or a clean bill, not manufactured busywork. This caught a query that was about to ship user emails to a client bundle.
5. The "explain this error" prompt
When I reach for it: Cryptic compiler or framework errors I don't immediately recognize.
The prompt:
Here's the full error: [paste]. And here's the code that triggered it:
[paste]. Tell me: (1) what the error actually means in plain English,
(2) the most likely root cause given this code, (3) the fix. Rank
causes by likelihood if there's more than one.
Why it works: Pasting the full error plus the triggering code, and asking for ranked causes, beats the instinct to paste just the last line. The framework's real complaint is often three lines up.
6. The "is there a library for this" prompt
When I reach for it: Right before I start building anything that feels like it should already exist.
The prompt:
I'm about to build [thing] in [stack]. Is there a well-maintained,
widely-used library that already does this? If yes, name the top 1-2,
note their tradeoffs, and tell me when rolling my own is still the
right call. If there's no good library, say so plainly.
Why it works: The "if there's no good library, say so plainly" guard stops the model from recommending an abandoned package just to have an answer. Saves me from both reinventing wheels and from adopting dead dependencies.
7. The conventional-commit prompt
When I reach for it: Every commit. This repo enforces Conventional Commits with a phase scope.
The prompt:
Write a Conventional Commit message for this diff. Format:
<type>(<scope>): <subject under 72 chars>, blank line, then a body
explaining the WHY not the WHAT. Types: feat/fix/chore/docs/refactor/
test. No tool attribution of any kind in the message.
Why it works: Naming the format and the 72-char limit produces a usable message on the first try. The "no tool attribution" line matters because this repo has a commit hook that rejects AI/tool credits — the prompt respects the constraint instead of fighting it.
8. The targeted-audit prompt
When I reach for it: Per phase, before a release gate.
The prompt:
Audit [path/ or this slice] for one dimension at a time. Start with
[security | performance | accessibility]. List concrete findings with
file:line, severity, and a one-line fix each. No general advice —
only issues you can point at in this code. If a dimension is clean,
say so and move to the next.
Why it works: "One dimension at a time" and "no general advice — only issues you can point at" keeps the output actionable. A scattershot "review everything" prompt returns a wall of generic best-practices; this returns a punch list.
9. The design-doc draft prompt
When I reach for it: Before a substantial change that I'll want a record of.
The prompt:
Draft a short design doc for [change]. Sections: Problem (3 sentences),
Options considered (2-3, each with one tradeoff), Decision + rationale,
Risks (top 2 with mitigations). Keep each section under 100 words.
Active voice. No hedging — state the decision.
Why it works: This produces the bones of an ADR-style record I can drop straight into the project's decisions log. The word caps prevent the model's tendency to pad design docs into unreadable essays.
10. The "convert this" prompt
When I reach for it: Porting a pattern between languages or framework idioms.
The prompt:
Convert this [source] to [target], preserving behaviour exactly. Keep
the same function/variable names where they still make sense. Flag any
spot where the conversion isn't 1:1 and a behavioural difference could
sneak in. Don't "improve" the logic — just convert it.
Why it works: "Don't improve the logic — just convert it" is the key constraint. Without it, the model silently refactors while translating, and now you're debugging two changes at once instead of one.
11. The rubber-duck prompt
When I reach for it: A bug I've stared at for 20 minutes with no theory.
The prompt:
I'm debugging [symptom]. Here's what I expect: [X]. Here's what
actually happens: [Y]. Here's what I've already ruled out: [list].
Here's the relevant code: [paste]. Don't fix it yet — first give me
your 3 most likely hypotheses, ranked, and a one-step way to test each.
Why it works: "Don't fix it yet — give me hypotheses and a way to test each" turns the model into a debugging partner instead of a patch generator. Half the time, articulating "what I've already ruled out" surfaces the answer before the model even replies — classic rubber-ducking, with a model that talks back.
12. The end-of-week TIL prompt
When I reach for it: Friday, reviewing the week's commits.
The prompt:
Here's my git log for the week: [paste git log --oneline]. Write a
3-bullet "what I learned / shipped this week" summary I could post or
keep as a note. Focus on the non-obvious decisions, not the routine
commits. Keep it honest — if it was a slow week, say so.
Why it works: This turns a commit log into a reflection artifact. The "if it was a slow week, say so" keeps it from inflating routine work into fake accomplishments. Over months these summaries become the raw material for posts like this one.
What's NOT on this list (and why)
- "Write me a function that…" — Too vague. Give it a spec (prompt #2) or don't bother.
- "Make it more efficient" — Efficient on which axis? Memory, latency, lines of code? Name it or the model optimizes the dimension you didn't want.
- "Refactor this" — "Better" how? Same problem.
- "Add comments" — You'll get 50 comments explaining trivia. Better: "Add a header comment explaining this module's responsibility and the 2–3 non-obvious decisions."
The pattern: every prompt that earns a permanent spot names the artifact, the constraints, and what to avoid. The ones that don't, get deleted.
How I keep the list at 12
These live in one pinned note. New prompts I'm trying go in a _drafts section at the bottom. After 30 days each one either earns promotion to the main list or gets deleted. Most get deleted. The list stays around 12 because that's how many distinct problems I actually solve in a typical week — and a prompt I reach for less than monthly isn't a habit, it's a bookmark.