AI isn’t “bad.” It’s just bad at guessing. Treat it like a junior engineer: give a clear spec, constraints, and a definition of done. This article shows you exactly how to prompt—no fluff.

The One-Pager Prompt You Can Reuse

Copy, tweak, paste:

You are a {role}.
Do: {task}.
Context: {tech stack, versions, environment, audience}.
Constraints: {rules, limits, non-goals, budgets}.
Output: {format, length, sections or schema}.
Examples/Acceptance Criteria: {mini example or checklist}.
If info is missing, ask up to 3 clarifying questions; otherwise proceed and list assumptions at the end.

Tip: save a few variants of this in your notes: “coding,” “debugging,” “docs,” “analytics.”

RTCCOE: The 6 Parts That Make Prompts Work

• Role — who the AI is (e.g., “senior backend engineer”).
• Task — a verb + object (“build a REST controller for…”).
• Context — tech versions, repo shape, audience, domain.
• Constraints — limits, security rules, performance budgets.
• Output — exact format (file tree, JSON schema, sections, word/line caps).
• Examples — small good sample or acceptance checklist.

Bad vs Better (1-minute reality check)

❌ Vague: “Build me an app.”

✅ Better:

You are a senior Next.js engineer.
Do: scaffold a pricing dashboard with email/password auth.
Context: Next.js 14 (App Router), TypeScript, Tailwind, Prisma + Postgres, Node 20.
Constraints: accessible components, minimal deps, no server actions for auth.
Output: file tree + key files (single code blocks) + 5 bullet “how it works”.
Examples/Acceptance: passes Lighthouse ≥90 mobile; ESLint/Prettier clean.

Three Drop-in Prompt Templates

1) Code Generation

You are a senior {language}/{framework} engineer.
Do: implement {feature/component}.
Context: {versions}, {libraries}, target {browser/node}, data from {API/DB}.
Constraints: perf budget {X ms}, idiomatic style, include tests, no deprecated APIs.
Output: one code block per file with filename header + short rationale (≤5 bullets).
Examples/Acceptance: builds with {tool}, unit tests green, covers {N} edge cases.

2) Debugging

You are a staff-level debugger.
Do: identify root cause and propose a minimal fix.
Context: {stack}, {OS}, reproducible steps below.
Constraints: no public API changes; patch ≤ {N} lines; add failing test first.
Output: root cause summary → diff patch → minimal repro test (code).
Examples/Acceptance: issue reproduced, test fails before/green after, no perf regression.

3) Analytics/SQL

You are an analytics engineer.
Do: write SQL for {metric} with {time window}.
Context: {Snowflake/BigQuery/Postgres}; schema below.
Constraints: timezone {TZ}, exclude test data, no CTE nesting > 3, document assumptions.
Output: SQL + short explanation of joins/filters + 3 sanity checks.
Examples/Acceptance: matches dashboard {X} within ±1% for last 7 days.

Prompt Patterns That 10× Quality

• Rubric first, answer second — “List acceptance criteria, then produce the solution and self-check against the list.”
• Constrain the shape — ask for JSON/schema, headings, or a table to avoid rambling.
• Few-shot clarity — include one small good example; the model will mirror style.
• Critique loop — “Give 3 options + a trade-off table; recommend one.”
• Safety valves — “If unsure, say ‘unknown’; cite only official docs.”

Security & Quality Guardrails (paste these in “Constraints”)

• Use parameterized queries; never string-concat SQL.
• Hash passwords with password_hash(...) / bcrypt / Argon2.
• Target Node 20 / Python 3.11 / {versions} explicitly.
• Budget: ≤150 lines, ≤8 bullets, ≤200 words (pick what fits).
• Accessibility: keyboard focus, ARIA labels, color contrast ≥ 4.5:1.

From Idea to Output: One Worked Example

Prompt

You are a senior React engineer.
Do: build a responsive pricing table with monthly/annual toggle.
Context: React 18 + TypeScript + Tailwind; no external UI libs; SaaS landing page.
Constraints: accessible controls; keyboard navigable; ≤120 lines; mobile-first; no inline styles.
Output: single .tsx file (one code block) + 5 bullets on accessibility choices.
Examples/Acceptance: toggling updates prices; Lighthouse mobile ≥90; aria-pressed used correctly.

Why it works: Role sets the voice; task is concrete; context pins versions; constraints avoid bloat; output shape prevents rambling; acceptance criteria define “done.”

Troubleshooting Fast

• Hallucinated APIs? Add: “If unsure, say unknown; cite official docs only.”
• Too long? Add a word/line budget and numbered sections.
• Security misses? Add explicit do/don’t rules in Constraints.
• Edge cases ignored? Ask to list 5 edge cases first, then incorporate.

Grab-and-Go Checklist

• Did you set a Role and concrete Task?
• Is the Context explicit (versions, audience, domain)?
• Are Constraints strict enough (security, performance, size)?
• Is the Output shape nailed (sections/schema/length)?
• Do you have Examples/Acceptance to define “done”?