💻 Coding & Development Prompts Pack — 30 Prompts From Debug to Ship

Your Engineering Session — Senior, Moderation Pipeline Architecture Decision

What I'm Diagnosing

This is less about 'which approach is right' and more about 'which tradeoffs does each make, and which tradeoffs fit your actual constraints?' Both approaches are valid in different contexts. The team-split 50/50 tells me the decision criteria aren't articulated yet — once they are, one approach usually becomes obviously better-fit.

Key constraint I'd surface first: the PII handling. That changes the math significantly for async-queue (more places data lives = more places to secure) vs. sync API (data stays in request/response, shorter attack surface).

We'll write the ADR properly — that's the output that resolves the team split.

Prompts I'm Selecting

Prompt 1: The ADR (Architecture Decision Record) (60-90 min)

Write a 1-page ADR with these exact sections:

Title: Moderation Pipeline Architecture — Async Queue vs. Sync API

Status: Proposed / Under Review

Context (200-300 words): What problem are we solving? Current state (50K decisions/day, sync at upload). What's changing (volume growth expected, team scaling, PII handling newly required). Non-negotiable constraints (PII handling, SLA on moderation turnaround, team capacity to operate).

Options (with tradeoffs per option):

Option A: Async Queue (Kafka + worker pool)

• Pros: scales horizontally, decouples upload latency from moderation work, natural retry/dead-letter handling, future-flexible (add new moderation types as workers)
• Cons: more moving parts to operate (Kafka cluster, consumer groups, monitoring), PII lives in queue (encryption-at-rest + in-transit + access control complexity), harder to reason about 'is this moderated yet' state
• Failure modes: consumer lag under traffic spike, dead-letter queue accumulation, PII exposure if queue misconfigured
• Operational cost: ~40-60 hrs/year team-maintenance

Option B: Sync API (process at upload with timeout fallback)

• Pros: simpler reasoning (request/response, clear state), PII doesn't persist in pipeline (stays in request), easier debugging (single-hop), simpler to operate at 200K DAU scale
• Cons: upload latency now coupled to moderation (can the user wait 1-3 sec?), harder to scale independent of upload service, timeout-fallback logic adds complexity, less flexibility for adding new moderation types
• Failure modes: moderation service slowness blocks uploads, timeout-fallback becomes silent bypass
• Operational cost: ~15-25 hrs/year team-maintenance

Decision: [Your recommendation with 2-3 sentence rationale]

Consequences:

• Short-term (3 months): what you commit to build, what you don't build yet
• Long-term (18 months): where this decision becomes a constraint, where it enables growth
• Explicit non-decisions: things you're NOT deciding now that you'll revisit

Engineering principle: ADRs (Architecture Decision Records) per Nygard (2011) / Thoughtworks pattern. When team is split on architecture, the split usually signals decision criteria aren't written. Writing criteria down reveals the answer.

Warm-up (60 sec): Before writing, answer one question honestly: what's the single most important constraint here — latency (user experience), scale (future growth), team capacity (can you operate what you build), compliance (PII handling)? If the team is split, they're probably prioritizing different constraints. Name yours explicitly.

Constraints:

• 1 page, not 5. If you can't fit the decision in 1 page, decision isn't clear enough yet.
• Include explicit 'what we're NOT deciding now' — reduces scope-creep in review
• Reference 2-3 comparable systems your team has built (institutional knowledge pattern)

Prompt 2: The Constraint-Weighted Recommendation (20 min)

After drafting the ADR, for the Decision section specifically: rank your 4 key constraints (latency / scale / team capacity / compliance) in priority order FOR YOUR SPECIFIC CONTEXT. Then apply:

Rank 1 constraint = latency matters most → lean sync API (lower user-experience latency)

Rank 1 constraint = scale matters most → lean async queue (horizontal scale-out)

Rank 1 constraint = team capacity matters most → lean sync API (fewer operational moving parts)

Rank 1 constraint = compliance/PII matters most → lean sync API (data doesn't persist)

Combined view for your case: compliance (PII) + team capacity (4 engineers) both point to sync API. Scale would push toward async but at 200K DAU + 50K decisions/day, you're not yet at the scale that REQUIRES async.

My honest read: sync API with good timeout-fallback + explicit monitoring is the better fit for your current constraints. Revisit at 500K DAU or when moderation types diversify significantly.

Engineering principle: Thoughtworks pattern — architecture decisions should be constraint-driven, not preference-driven. Preference-driven decisions produce decisions that 'feel right' but don't hold up when constraints change.

Warm-up (60 sec): Genuinely ask yourself — am I leaning async because it's the RIGHT fit, or because it's more interesting to build?

Constraints:

• Don't add a 5th constraint. Discipline the list.
• Be willing to revise your stated preference based on the constraint ranking

After This Session

Schedule a 30-min team meeting. Share the ADR 24 hours before. In the meeting: don't re-argue options. Constraint-rank together. Whichever constraint ranks #1 by team consensus should determine the decision.

If team still splits 50/50 after constraint-ranking, that's a signal the REAL decision is a higher-level one (what matters most for this product?) that isn't your team's to make alone. Escalate to engineering lead / product partner.

The Full 30-Prompt Library (Copy Ready)

CATEGORY 1: Debugging & Investigation

1.1 The Hypothesis-First Debug

Before touching code: generate 3-5 hypotheses for the bug. For each: what would confirm it (log check, reproducer, code read), what would refute it. Test the cheapest hypothesis first.

1.2 The Bisect-Through-Git

For regressions (worked before, broken now): git bisect between last-known-good commit and current-broken commit. Cuts debugging from hours to minutes for bugs introduced by commits.

1.3 The Reproducer Minimizer

For complex bugs: minimize to smallest reproducer. Remove config, dependencies, setup code one at a time until bug disappears — the last thing removed caused it. Also produces the test case.

1.4 The Observability Check

Before deeper debugging: can you SEE the problem? Metrics, logs, traces covering the affected path? If not, instrument first. Debugging blind is 10x slower than debugging with observability.

1.5 The Fresh-Eyes Walkthrough

Stuck: explain the bug to a rubber duck / non-expert in 3 minutes. The constraint of explaining simply often surfaces the assumption you've been making that's wrong. Rubber-duck debugging isn't superstition — it's externalizing constraints.

CATEGORY 2: Code Review & Quality

2.1 The Review Framework Application

For reviewing a PR: check in order — (1) correctness (does it work), (2) design (does it make sense for the codebase), (3) test coverage (is it verified), (4) readability (will others understand), (5) style (linter/formatter issues). Style comments LAST.

2.2 The Design-Critique Comment

For PR design issues: frame as question, not assertion. 'What happens when X?' 'Did we consider Y?' Invites dialogue; doesn't put author on defensive. Resolves 80% faster than 'This is wrong.'

2.3 The Pre-Review Self-Check

Before opening your PR for others: read your own diff slowly. Fix style/typo issues yourself. Write clear PR description — context, change, why, how to test. Respects reviewer time; 30% faster reviews.

2.4 The Junior-Mentoring Review

Reviewing a junior's code: catch the design issues, but also SHOW YOUR THINKING. 'I'd consider X here because [reason].' Teaches pattern; solves immediate issue. Cognitive apprenticeship.

2.5 The Sr-to-Sr Review (no fluff)

Reviewing a peer senior: skip praise, skip style, focus on design + correctness + tests. They can handle direct feedback; they waste time parsing politeness. Mutual trust = mutual directness.

CATEGORY 3: Architecture & System Design

3.1 The ADR (Architecture Decision Record)

1-page document: Title, Status, Context, Options (with tradeoffs), Decision, Consequences. Future-self clarity; team-alignment tool. Nygard (2011) pattern.

3.2 The Constraint-Weighted Decision

For architecture choices: rank 3-5 constraints (latency / scale / team-capacity / compliance / cost). The #1 constraint should drive the decision. Preference-driven decisions break when constraints change.

3.3 The System Design Interview Framework

For senior/staff interviews: Requirements clarification (5 min) → High-level architecture (10 min) → Deep-dive on 1-2 components (20 min) → Scale considerations (10 min) → Failure modes (10 min). Structure > knowledge trivia.

3.4 The Back-of-Envelope Sizing

For system design: QPS math, storage math, bandwidth math. 200K DAU × 3 requests/day = 600K requests/day = 7 RPS average, peak maybe 20 RPS. Sizing anchors design conversations in numbers, not hand-waving.

3.5 The Monolith-vs-Microservices Decision

Most 2026 answers: start with monolith, extract services when team size / scaling needs demand. Don't premature-microservice. Sam Newman's Monolith to Microservices (2019) + Team Topologies (Skelton & Pais 2019) framework.

CATEGORY 4: Refactoring & Optimization

4.1 The Red-Green-Refactor Cycle

Fowler (1999/2018): test first (red), change code to pass (green), refactor for cleanliness (still green). Skipping test-first is how refactorings break production.

4.2 The Refactoring Smell Identification

From Fowler's list: duplicated code, long method, large class, feature envy, data clump, primitive obsession, switch statements, parallel inheritance hierarchies. Name the smell; apply the corresponding refactoring.

4.3 The Strangler Fig Pattern

For replacing legacy code without full rewrite: build new alongside old, route traffic incrementally to new, decommission old when traffic is 100% migrated. Martin Fowler pattern (2004). Avoids 'big bang' rewrite failures.

4.4 The Performance Profile First

Before optimizing: profile. 95% of performance 'optimization' without profiling optimizes the wrong thing. Donald Knuth: premature optimization is the root of all evil (Knuth 1974 but still true).

4.5 The Dead Code Audit

Quarterly: identify unused code (no imports, no callers, no tests). Delete. Dead code = cognitive load + security surface + maintenance burden with zero value.

CATEGORY 5: API & Database Design

5.1 The API Versioning from Day 1

Always version (v1 in URL or Accept header). Unversioned APIs become unfixable. Breaking changes in unversioned APIs cause 6-month painful migration programs.

5.2 The REST vs GraphQL Decision

REST: simpler to reason about, better HTTP-native caching, more tooling. GraphQL: client-driven fields (reduce over-fetching), better for complex interconnected data, more flexible. For most 2026 APIs: REST with good design. GraphQL for specific use-cases.

5.3 The Database Schema Review

Before shipping schema: foreign keys enforced? Indexes on query columns? NOT NULL where appropriate? Check constraints where domain permits? Audit columns (created_at, updated_at, deleted_at)? Future-migration considerations?

5.4 The N+1 Query Prevention

The most common performance bug. Load data in single query with joins OR explicit eager loading (ORM feature). Profile queries hitting production; N+1 patterns are obvious in query logs.

5.5 The Migration Rollout

For schema changes: forward-compatible first (add new column), deploy code reading both, then deploy code writing new, verify, remove old. Multi-step migration > single-step for production safety.

CATEGORY 6: Git & DevOps

6.1 The Conventional Commit Message

Format: type(scope): description. Types: feat / fix / refactor / docs / test / chore. Description: imperative, explains WHY (not what — diff shows what). 'fix(auth): prevent session timeout mid-request from crashing user session' > 'Fixed bug.'

6.2 The Blameless Postmortem

Incident postmortem structure: timeline, impact, root cause (not people — processes/code), contributing factors, what worked, what to change. Blameless language: 'The alert didn't fire' > 'Alice forgot the alert.'

6.3 The Git Branch Strategy

For team workflow: trunk-based (main, short-lived feature branches <3 days) or Gitflow (main, develop, feature). Trunk-based correlates with higher DORA performance metrics per Accelerate (Forsgren et al 2018).

6.4 The CI/CD Pipeline Design

Stages: lint (30s) → unit tests (2-5 min) → integration tests (5-10 min) → deploy to staging (auto) → smoke tests (2 min) → deploy to prod (manual approval). Feedback loops ordered by cost.

6.5 The Runbook Entry

For a recurring alert type: what the alert means, immediate check (top commands/queries), likely causes (top 3), escalation criteria. Your personal runbook > team runbook; your runbook has the 'I've seen this before' context.

Troubleshooting

If bug is elusive despite 5 hypotheses:

The bug is in the hypothesis you haven't generated. Often that's because an assumption feels so obvious you haven't questioned it. Run Prompt 1.5 (Fresh-Eyes Walkthrough) — externalizing often surfaces the assumption.

If PR review is stuck in comment-thread loop:

Move to synchronous discussion. 30-min call resolves what a 30-comment thread can't. Written mediums optimize for record; verbal optimizes for understanding.

If architecture decision is gridlocked:

Run Prompt 3.2 (Constraint-Weighted Decision). Gridlock usually = team is optimizing for different constraints without naming them. Name them, rank them together, decision becomes obvious.

If refactoring broke production:

The tests didn't cover the broken path. Add test for THIS specific failure, revert the refactoring, re-attempt with the test as safety net. Never blame the refactoring; trust the test.

If API versioning is already painful (unversioned API needing breaking change):

Introduce versioning now (v1 header for existing, v2 for new). Set sunset timeline for v1 (6-12 months). Communicate to consumers. Migrations are always painful; delaying makes them worse.

If postmortem turned into blame-session:

Stop. Reschedule. Reread blameless postmortem framework (Google SRE book). Facilitate with blameless framing explicit in the room: 'We're focused on process and systems, not individuals.' If facilitator can't maintain this, different facilitator needed.

Variation Playbook

Backend-Focused:

Category 3 (Architecture) + 4 (Refactoring) + 5 (API/DB) weighted heavily. Category 6.2 (Postmortem) matters because backend outages are where on-call nights are born.

Frontend-Focused:

Category 2 (Code Review) + 4 (Refactoring) — component architecture and state management specifically. Performance optimization (4.4) different: bundle size, render performance, network requests. Less Category 5 weighting.

DevOps / SRE:

Category 1 (Debugging) + 6 (DevOps) weighted heaviest. Incident response (6.2 Postmortem) is your day job. Runbooks (6.5) are high-leverage artifacts.

Senior / Staff preparing for promotion:

Category 3 (Architecture) primary — that's what staff engineers do. Category 2.4 (Mentoring Review) — promotion evidence. Category 6.5 (runbook entries) — system-level thinking evidence.

Junior (1-3 years):

Category 1 (Debugging) + 2 (Code Review) + 4 (Refactoring). Architecture decisions deferred; read ADRs your seniors write rather than writing your own. Pattern-recognition phase; learn common patterns before architecting new ones.

Open-Source Contributor:

Category 2 (Code Review — as both contributor AND reviewer) + 6.1 (Commit Messages). Clear commit messages + clear PR descriptions are the currency of open-source. Maintainers prioritize contributors who make review easy.

Key Takeaways

• Debug by hypothesis FIRST. 3-5 hypotheses before touching code. Most bugs are in the hypothesis you didn't generate.
• Code review time is for design + correctness. Style should be automated via linter. Spending review energy on style crowds out review energy for real issues.
• Architecture decisions = ADRs. 1 page. Future-self + teammates reading in 18 months thank you. Preference-driven decisions break when constraints change; constraint-driven decisions hold.
• Version APIs from day 1. Unversioned APIs with breaking-change needs cause 6-month painful migration programs. Cheap insurance.
• Postmortems are blameless or they're useless. 'The alert didn't fire' > 'Alice didn't set up the alert.' Same fact, different future-action pattern.