DEV Community: NongdyZ

The SaaS Metrics Every Founder Should Track (MRR, CAC, LTV, Runway)

NongdyZ — Sun, 12 Jul 2026 01:10:28 +0000

Most early SaaS dashboards I see track the wrong things. Page views. Signups. Total revenue this quarter. Those numbers feel good and tell you almost nothing about whether the business is actually healthy.

The metrics that matter are the ones that answer four questions: Is recurring revenue growing? Can I afford to acquire customers? Are those customers worth more than they cost? How long until I run out of money? That's MRR, CAC, LTV, and runway. Get these four right and you can make almost every early-stage decision with confidence.

Here's how to calculate each one correctly — including the mistakes that quietly inflate them — with the actual formulas.

1. MRR — and the four movements inside it

MRR (Monthly Recurring Revenue) is the predictable revenue you can expect every month. The number itself is easy. What founders miss is that a flat MRR can hide a business that's bleeding.

Normalize everything to monthly first. An annual plan at $1,200 is $100 MRR, not $1,200 — never book the full annual amount as one month's MRR.

MRR = sum of each customer's monthly subscription value

Annual plan? MRR = annual price / 12

Then break the change in MRR into four movements — this is the part that reveals the truth:

Net New MRR = New + Expansion + Reactivation − Contraction − Churned

  New           = MRR from brand-new customers
  Expansion     = upgrades / seats added by existing customers
  Reactivation  = previously-churned customers who came back
  Contraction   = downgrades by existing customers
  Churned       = MRR lost from customers who cancelled

Two companies can both show "+$5k MRR this month." One did it with $5k of new sales and zero churn. The other added $15k of new sales while losing $10k to churn — a leaky bucket that will stall the moment sales slows. Only the breakdown tells them apart.

2. Churn — the metric that caps your growth

Churn is the single most important early signal. High churn means you're filling a bucket with a hole; no amount of marketing fixes it.

Customer churn rate = customers lost in period / customers at start of period

Revenue churn rate  = MRR lost (churn + contraction) in period / MRR at start

Track revenue churn alongside customer churn. If you lose small accounts but keep big ones, revenue churn looks great even when logo churn is ugly — and vice versa. When expansion revenue exceeds churned revenue, you have negative net revenue churn: the holy grail, where your existing customer base grows even if you add zero new customers.

Net Revenue Retention (NRR) = (starting MRR + expansion − contraction − churn) / starting MRR

NRR > 100% means the existing base is growing on its own.

3. CAC — what a customer actually costs

CAC (Customer Acquisition Cost) is the fully-loaded cost to win one customer. The common mistake is counting only ad spend.

CAC = (total sales + marketing spend in period) / new customers acquired in period

"Fully-loaded" means everything: ad spend, salaries of sales and marketing people, tooling, agency fees, content costs. If you only count the ad bill, your CAC looks half what it really is, and you'll overspend into a loss.

A useful companion is CAC payback period — how many months of gross margin it takes to earn back the cost of acquiring a customer:

CAC Payback (months) = CAC / (ARPA × gross margin %)

ARPA = average revenue per account per month

Under ~12 months is healthy for most B2B SaaS; under 6 is excellent. Long payback means your growth is financed by cash you don't get back for a year — dangerous when runway is short.

4. LTV and the ratio that decides if you have a business

LTV (Lifetime Value) is the total gross profit you expect from a customer before they churn.

Average customer lifetime (months) = 1 / monthly customer churn rate

LTV = ARPA × gross margin % × average customer lifetime

Always multiply by gross margin. Revenue isn't value — if it costs you 40 cents in hosting and support to deliver a dollar, only 60 cents is real. Skipping margin is the most common way founders fool themselves with a beautiful LTV.

Now the ratio that ties CAC and LTV together — the one a serious investor checks first:

LTV : CAC ratio = LTV / CAC

< 1   : you lose money on every customer. Stop and fix the model.
~ 3:1 : healthy. The standard target for sustainable SaaS.
> 5:1 : often means you're UNDER-investing in growth — spend more.

A 3:1 ratio means each customer returns three dollars of lifetime gross profit for every dollar spent acquiring them. Below 1:1, scaling just loses money faster.

5. Runway — how long the clock runs

Everything above is academic if you run out of cash. Runway is the number of months until you hit zero.

Net burn = monthly cash out − monthly cash in
Runway (months) = current cash balance / net burn

If you're burning $40k a month with $480k in the bank, that's 12 months of runway. Watch the trend, not just the snapshot: rising MRR shrinks net burn and extends runway every month — that's the whole game pre-profitability. Once cash in exceeds cash out, net burn goes negative and runway is effectively infinite. That's the finish line.

A worked example

Say you're at: 200 customers, $50 ARPA, 80% gross margin, 4% monthly customer churn, $600 CAC, $300k cash, $30k net burn.

MRR              = 200 × $50            = $10,000
Avg lifetime     = 1 / 0.04             = 25 months
LTV              = $50 × 0.80 × 25      = $1,000
LTV : CAC        = $1,000 / $600        = 1.67  → below target, fix churn or CAC
CAC payback      = $600 / ($50 × 0.80)  = 15 months → a bit long
Runway           = $300,000 / $30,000   = 10 months

The story those five numbers tell: revenue is real but churn is high (4%/month is steep), which drags LTV down so the unit economics are thin (1.67:1), and you have 10 months to fix it. That's a far more useful picture than "MRR is $10k and growing." The priority is obvious — attack churn first, because it improves LTV, the ratio, and payback all at once.

Put it in a model, not a memory

The mistake isn't not knowing these formulas — it's not having them wired into one live model where changing churn instantly updates LTV, the ratio, payback, and runway. When they're connected, you can ask "what if I cut churn to 2%?" and watch every downstream number move. That's when metrics become a decision tool instead of a report card.

If you want it pre-built

Wiring a clean, investor-ready model with all of these linked — MRR movements, cohort churn, LTV:CAC, payback, and a runway forecast that updates as you change assumptions — is a weekend of spreadsheet work if you start from scratch. I built one so you don't have to: the SaaS Metrics & Financial Model is a ready-to-use spreadsheet with every formula in this post connected, scenario toggles, and a START HERE guide that walks you through plugging in your own numbers in about ten minutes.

But you don't need it to start — the formulas above are the whole framework. Calculate your LTV:CAC and runway today; those two numbers alone will sharpen your next decision.

Which of these five do you actually track today, and which one have you been avoiding? Be honest in the comments — I suspect churn is the one most of us look away from.

Multi-Agent Code Review with Claude Code Subagents

NongdyZ — Thu, 09 Jul 2026 13:00:03 +0000

A single AI reviewing your code is like asking one person to be your security auditor, your test engineer, and your style nitpicker at the same time. They'll do all three jobs at 60%. You get a review that mentions a missing semicolon and misses the SQL injection.

Claude Code's subagents fix this by splitting one generalist into a panel of specialists, each with its own focused instructions and — importantly — its own context window. One agent thinks only about security. Another thinks only about test coverage. A third synthesizes their findings into a verdict. The result reviews more like a real team than a single chatbot.

Here's a multi-agent code review workflow you can build today, with the actual subagent files.

How subagents work in Claude Code

A subagent is just a Markdown file in .claude/agents/ with frontmatter and a system prompt. The frontmatter declares its name, when to use it, and which tools it's allowed. Claude Code can invoke them by name or delegate to them automatically based on the description.

The magic is the separate context window. The security agent isn't distracted by the test agent's reasoning. Each one stays sharp on its single job, and you can run them in parallel.

Agent 1: The reviewer (correctness)

---
name: code-reviewer
description: "Reviews a diff for bugs, correctness, and convention violations. Use after writing or changing code."
tools: Read, Grep, Bash
---

You are a senior code reviewer. Review ONLY the changed lines plus immediate context.

Output exactly three sections:
1. Blocking — bugs, data-loss risks, broken logic. Each with file:line and a concrete fix.
2. Should fix — correctness/clarity issues that aren't blocking.
3. Nits — naming/style. Keep short.

Rules:
- If there are no blocking issues, say so on line one. Do not invent problems to look thorough.
- Check: unhandled null, off-by-one, error paths, N+1 queries, wrong async/await, edge cases.
- Quote the exact line you flag. No vague "consider improving error handling".

Agent 2: The security auditor

This one thinks in vulnerability categories, not vibes. Giving it OWASP as a checklist is what stops it from rubber-stamping.

---
name: security-auditor
description: Audits changed code for security vulnerabilities. Use on any diff touching input handling, auth, queries, or file/network IO.
tools: Read, Grep, Bash
---

You are an application security auditor. Review ONLY the diff and its immediate context.

Walk these categories explicitly and report findings per category:
- Injection (SQL, command, template, NoSQL)
- AuthN/AuthZ (missing checks, broken object-level access, privilege escalation)
- Input validation & output encoding (XSS, SSRF, path traversal)
- Secrets & data exposure (hardcoded keys, logging PII/tokens)
- Unsafe deserialization, insecure defaults, missing rate limits

For each finding: severity (Critical/High/Medium/Low), file:line, the exploit in one sentence, and the fix.
If a category is clean, write "OK" — do not pad. Do not flag theoretical issues the code can't actually hit.

Agent 3: The test engineer

---
name: test-reviewer
description: Evaluates whether a change is adequately tested and writes the missing tests. Use after code-reviewer.
tools: Read, Grep, Bash, Write

---

You are a test engineer. Given a diff, assess test coverage of the *behavior that changed*.

Output:
1. Coverage gaps — for each changed behavior, list the cases NOT tested: edge values, null/empty,
   error path, boundary, concurrency. Be specific to this code.
2. Missing tests — write the actual test code for the highest-value gaps, matching the repo's existing test style.

Rules:
- Don't praise existing happy-path tests. Find what's missing.
- Test the public contract, not private internals, so refactors don't break the tests.
- If coverage is genuinely sufficient, say so — don't manufacture busywork tests.

The orchestration: a `/review` command

Tie them together with a slash command in .claude/commands/review.md so one keystroke runs the whole panel:

---
description: Run the full multi-agent review on the current diff
---

Run a complete review of the staged/unstaged changes:

1. Get the diff with `git diff HEAD`.
2. Invoke @code-reviewer on the diff.
3. Invoke @security-auditor on the diff.
4. Invoke @test-reviewer on the diff.
5. Synthesize all three into a single verdict:
   - VERDICT: SHIP / FIX FIRST / NEEDS DISCUSSION
   - Blocking items (from any agent), deduplicated, sorted by severity.
   - A short ordered to-do list to get to SHIP.

Keep the synthesis tight. Don't repeat every agent's full output — surface what blocks the merge.

When you run /review, Claude Code dispatches the three specialists, collects their reports, and the orchestrator boils it down to a decision. You read one verdict instead of three walls of text.

What this looks like in practice

On a recent endpoint change, the three agents split the work cleanly:

code-reviewer caught an unhandled null when the user had no orders — a 500 waiting to happen.
security-auditor flagged that the userId came from the query string with no authorization check: any logged-in user could read anyone's orders (broken object-level access — the #1 item on the OWASP API Top 10).
test-reviewer noticed there was no test for the empty-orders case or the unauthorized case, and wrote both.

A single generalist agent, in my experience, finds the null and stops — it feels "done" after one solid catch. The panel keeps going because each specialist is measured against its own job, not the overall vibe of "did I find something."

Build it incrementally

You don't need all three on day one. Start with code-reviewer plus the /review command that calls just that one. Add security-auditor the first time a security bug slips through. Add test-reviewer when you notice untested changes shipping. Each agent is one small file — the cost of adding one is minutes, and a bad agent is just a file you delete.

If you want the whole panel pre-built

Tuning the output formats so the agents are actionable instead of fluffy is the real time sink — getting "quote the exact line" and "don't invent problems" dialed in took me weeks. If you'd rather drop a finished setup into any repo, I packaged my full configuration as Claude Code Agent OS: 26 specialized subagents (reviewer, security, tests, refactor, and more), 12 slash commands including /review and /ship, ready-to-edit CLAUDE.md templates, MCP configs, and safety hooks — with a START HERE quickstart that has you running in about five minutes.

But the three agents above are enough to feel the difference right now. Copy code-reviewer and the /review command into your repo and run it on your next diff.

If you build your own review panel, which specialist earns its keep the most for you? I'd like to know in the comments.

AI Debugging Prompts That Actually Find the Bug

NongdyZ — Mon, 06 Jul 2026 13:00:03 +0000

The default way most people debug with AI is to paste a stack trace and type "fix this." Sometimes it works. More often the model invents a plausible-sounding cause, "fixes" it, and the bug is still there — now hidden under a layer of confident wrong code.

The problem is the same one that ruins human debugging: jumping to a fix before understanding the cause. A good debugging prompt forces the model to do what a senior engineer does — reproduce, isolate, form a hypothesis, then test it — instead of pattern-matching the error string to the nearest Stack Overflow answer.

Here are the prompts I actually use, organized by the kind of bug. They work in Cursor, Claude, ChatGPT, or any assistant. Copy them, paste your context, and notice how the output stops being a guess.

Why "fix this" fails

"Fix this" gives the model no role, no method, and no constraint against guessing. So it does the easy thing: it finds the most common cause of that error message and assumes that's yours. For generic errors (undefined is not a function, connection refused) the most common cause is rarely your cause.

The fix is to make the model show its reasoning before it writes a single line of code — and to forbid it from changing anything until you've agreed on the cause.

Prompt 1: Root-cause analysis (no fix yet)

This is my default. The key constraint is the last line — it stops the model from skipping to a patch.

You are a senior engineer debugging a problem. Do NOT write a fix yet.

Here is the symptom: <what you observe>
Here is the error / log: <paste>
Here is the relevant code: <paste>
What I've already ruled out: <list, or "nothing yet">

Work through this in order:
1. State exactly what the symptom tells us — and what it does NOT tell us.
2. List the 3-4 most likely causes, ranked by probability for THIS code (not in general).
3. For each cause, give the single cheapest check that would confirm or eliminate it.
4. Tell me which check to run first and what result would point where.

Do not propose a code change until I report back what the checks showed.

You run the checks, paste the results, and then it fixes — now with evidence instead of a guess. This one prompt has saved me from more wrong "fixes" than anything else.

Prompt 2: Regression hunt ("it worked yesterday")

When something broke and you have version control, the bug is almost always in the diff. Point the model at the change, not the whole file.

This worked before and now it doesn't. The behavior change is: <before vs after>.

Here is the diff of recent changes: <paste git diff, or the commit range>
Here is the failing case: <input → expected → actual>

Analyze the diff specifically:
1. Which changed lines could plausibly cause this exact symptom? Quote them.
2. For the top suspect, trace how the new code produces the wrong result, step by step with the failing input.
3. Confirm it's the cause before fixing: what value would I see at <line> if you're right?

Ignore unchanged code unless the diff broke an assumption it relied on.

The last line matters. Without it, the model wanders off into unrelated parts of the file. A regression lives in what changed — anchor it there.

Prompt 3: Race conditions and intermittent failures

Intermittent bugs are where AI guessing is most dangerous, because the "fix" appears to work (the bug just didn't happen to fire). Force the model to reason about interleaving and ordering, not just the code path.

This bug is intermittent — it fails maybe 1 in 20 runs. Assume it's a timing/ordering issue.

Here is the code: <paste async/concurrent code>
Here is what's shared between the concurrent paths: <state, files, DB rows, caches>

Reason about it as a concurrency problem:
1. Identify every piece of shared mutable state and who reads/writes it.
2. Find an interleaving of operations that produces the bad result. Write it as a numbered timeline (Thread A line X, then Thread B line Y...).
3. Name the category: race, deadlock, lost update, stale read, missing await, or unhandled rejection.
4. Propose a fix that removes the race (lock, atomic op, await, idempotency key) — not one that just makes it rarer.

If you can't construct a failing timeline, say so — don't invent one.

The "write it as a numbered timeline" instruction is what turns hand-waving into something you can verify. If the timeline is real, the bug is real. If the model can't build one, it admits it instead of fabricating a fix.

Prompt 4: The "explain it back to me" sanity check

Before you accept any AI fix, run this. It catches the cases where the model fixed the symptom but misunderstood the cause.

Before I apply your fix, explain it back to me:
1. In one sentence, what was the actual root cause?
2. Why did the bug appear only under <the conditions I described> and not always?
3. What does your fix change, and why does that address the cause (not just the symptom)?
4. What input would still break this code after your fix? Is there an edge case left?

If any answer is "I'm not sure," tell me what to check instead of guessing.

If the model can't cleanly answer #2 — why these conditions and not others — it didn't understand the bug, and its fix is a coincidence. That single question has caught more bad patches for me than any test.

The pattern behind all of these

Every prompt here does the same four things: assigns a role, demands a method (reproduce → hypothesize → verify), forbids guessing, and delays the fix until there's evidence. That's not an AI trick — it's just disciplined debugging, written down so the model can't skip steps.

You can build these yourself from the templates above. The only real work is keeping a tuned library so you grab the right one instantly instead of rewriting it at 2 a.m. during an incident.

If you want the full library ready to go

I keep a much larger set than fits in one post — prompts for root-cause, performance profiling, flaky tests, memory leaks, log analysis, and writing the minimal repro. I cleaned them up and packaged them as the Developer's AI Prompt Arsenal: 140 copy-paste prompts across debugging, code review, refactoring, testing, and architecture, organized so you find the right one in seconds, with a START HERE guide on how to fill in the variables.

That said, the four prompts above cost nothing and will change your very next debugging session. Start with Prompt 1 — paste your current bug into it before you let any AI touch the code.

What's the most stubborn bug an AI prompt ever helped you crack — or the one it kept getting wrong? Tell me in the comments; I'm collecting the patterns.

10 Cursor Rules Every Developer Should Steal (.mdc)

NongdyZ — Fri, 03 Jul 2026 13:00:03 +0000

I used to think AI coding assistants plateaued because the models weren't good enough. Then I watched a teammate's Cursor produce cleaner code than mine on the same task, with the same model. The difference was his .cursor/rules/ folder. His assistant had a contract; mine was improvising.

A good Cursor rule isn't a motivational poster ("write clean code"). It's a specific, enforceable check scoped to when it matters. Below are ten rules I've stolen, refined, and now copy into every repo. Steal the ones that fit your stack. Each is a real .mdc file you can paste into .cursor/rules/.

Quick refresher on `.mdc` frontmatter

Cursor's Project Rules live in .cursor/rules/*.mdc. Three frontmatter fields decide when a rule loads:

alwaysApply: true — in context on every request. Keep these short and universal.
globs: "**/*.tsx" — auto-attaches only when a matching file is touched.
Neither set — Cursor pulls it in when the description looks relevant.

Scoping is the whole point. Ten rules loaded on every request dilute the context until the model ignores all of them. Ten scoped rules stay sharp because only the relevant two or three are ever present at once.

1. The non-negotiable global rule

This is the only one I set to alwaysApply: true. Everything in it is a check the model can apply to a diff, not an aspiration.

---
description: "Global engineering guardrails — always apply"
globs:
alwaysApply: true
---

- Validate and type all external input (request bodies, query params, env) at the boundary.
- No secrets in code. Read from env. Never log tokens, passwords, or full PII.
- Functions that can fail return a typed error or throw — never return null silently.
- When you change a signature, update every caller in the same edit.
- Prefer deleting code over adding a flag. The best fix removes complexity.

2. Kill `any` before it spreads (TypeScript)

Left alone, Cursor reaches for any constantly — it's the path of least resistance. This glob-scoped rule forces it to think about the real type.

---
description: TypeScript type-safety rules
globs: "**/*.ts, **/*.tsx"
alwaysApply: false
---

- No `any`. Use `unknown` + a narrow, or define the type. If truly stuck, add `// TODO: type` with a reason.
- Components are typed function components with an explicit props interface. No `React.FC`.
- Exported functions have explicit return types. No relying on inference at module boundaries.
- Prefer discriminated unions over optional-everything objects.

3. SQL safety, loaded on demand

No alwaysApply — it eats no context on your CSS work, but the description makes Cursor pull it in the moment you write a query.

---
description: Database and SQL safety — apply when writing queries or migrations
globs:
alwaysApply: false
---

- Always use parameterized queries / prepared statements. Never interpolate input into SQL.
- Any query that can return many rows is paginated or bounded with LIMIT.
- Watch for N+1: fetching a list then querying per item is a bug, not a style choice.
- Migrations are reversible and never run automatically — generate the file, let a human apply it.
- Select named columns, not `SELECT *`, in application queries.

4. Tests that target edges, not happy paths

---
description: Test-writing conventions — apply when adding or editing tests
globs: "**/*.test.*, **/*.spec.*"
alwaysApply: false
---

- Cover the edge cases first: empty input, null, boundary values, duplicate, and the error path.
- One behavior per test. The test name states the expected behavior, not the function name.
- No tests against private internals — test the public contract so refactors don't break them.
- Don't mock what you don't own without a thin wrapper around it.

The "edge cases first" line is what changes the output. Without it, Cursor writes the one test that proves the function runs and stops.

5. Commit messages a human can scan

---
description: Git commit message format
globs:
alwaysApply: false
---

- Use Conventional Commits: type(scope): subject. Types: feat, fix, refactor, test, docs, chore.
- Subject is imperative and under 60 chars: "fix: handle empty cart on checkout".
- Body explains *why*, not *what* — the diff already shows what.
- One logical change per commit. Don't bundle a refactor with a feature.

6. Accessibility, scoped to the frontend

---
description: Accessibility rules for UI
globs: "**/*.tsx, **/*.jsx, **/*.vue"
alwaysApply: false
---

- Every interactive element is keyboard-reachable and has an accessible name (label, aria-label, or text).
- Images have alt text; decorative images use alt="".
- Don't rely on color alone to convey state — pair it with text or an icon.
- Focus is visible and never trapped. Modals return focus to the trigger on close.

7. Error handling that surfaces, not swallows

---
description: Error handling
globs:
alwaysApply: false
---

- Never catch an error just to log it and continue — either handle it meaningfully or rethrow.
- Error messages include enough context to debug without a repro (id, operation, input shape).
- User-facing errors are friendly; internal errors keep the stack. Never leak internals to the client.
- No empty catch blocks. Ever.

8. Comments that explain "why"

---
description: Comment discipline
globs:
alwaysApply: false
---

- Comment *why*, not *what*. If a comment restates the code, delete it and rename instead.
- Flag non-obvious decisions, workarounds, and "do not change this because…" with a reason.
- No commented-out code in commits. That's what git history is for.

9. Dependency restraint

---
description: Dependency policy
globs:
alwaysApply: false
---

- Don't add a dependency to solve what 15 lines of code can. State the tradeoff if you do add one.
- Prefer the platform/standard library before reaching for a package.
- No new dependency without checking it's maintained (recent commits) and has no known critical CVEs.

10. The "stay in scope" rule

The one that saves the most cleanup time. Cursor loves to "helpfully" refactor three files you didn't ask about.

---
description: Scope discipline — always apply
globs:
alwaysApply: true
---

- Change only what the task requires. Don't reformat or refactor unrelated code in the same edit.
- If you spot an unrelated bug, mention it — don't fix it without asking.
- Keep diffs reviewable. A 400-line diff for a 2-line fix is a failure.

How to actually adopt these

Don't paste all ten today — you'll dilute the context and burn out maintaining them. Start with three: rule #1 (global guardrails), one stack rule (#2 if you're on TypeScript), and rule #10 (scope discipline). Live with those for a week. Add another only when you catch Cursor making the same mistake twice. A rule earns its place by preventing a real, repeated error — not by sounding good in a blog post.

If you'd rather start from a tuned set

Curating and maintaining a rule library is its own small project. If you want a head start, I packaged my full tuned collection as the Cursor AI Power Pack — a set of ready-to-drop .mdc rules organized by stack and concern, plus prompt recipes and a START HERE guide so you know which rule to enable when. It's the same scoped, anti-fluff philosophy as the ten above, just done for you.

But you don't need it to get value here. Copy rules #1 and #10 into your repo right now — those two alone will make your next Cursor session noticeably tighter.

Which rule does your team enforce that I left off this list? Drop it in the comments — I'm always hunting for ones worth stealing.

10 AI Prompts That Make Code Review Actually Useful

NongdyZ — Tue, 30 Jun 2026 13:01:51 +0000

"Review my code." You paste a function, and the AI replies with a tidy paragraph: "This code looks good! You might consider adding error handling and improving variable names." Thanks. You knew that. You wanted it to find the off-by-one in the loop and the unhandled null on line 14.

The problem isn't the model. It's the prompt. "Review my code" gives the AI no role, no priorities, and no output format, so it defaults to vague praise. The fix is to prompt it the way a senior engineer would brief a reviewer: who you are, what to look for, what to ignore, and how to report it.

Below are the principles plus a few of the exact prompts I use. Copy them, swap in your code, and watch the quality of the feedback change.

Why structure beats length

A good review prompt has four parts:

Role + context — "You are a senior backend reviewer. This runs in production handling payments."
What to check — a concrete list, in priority order.
Constraints — what not to do. This is the part everyone skips, and it's the part that kills the fluff.
Output format — so you get a triaged list, not an essay.

The constraint "Do not suggest improvements you cannot point to a specific line for" alone removes about half the generic noise. The model can no longer say "consider improving error handling" — it has to find the line where error handling is actually missing, or stay quiet.

Prompt 1: The triaged review

This is my default. The priority ordering and the "blocking first" rule mean the important stuff isn't buried under nitpicks.

You are a senior engineer reviewing a diff for production code.

Review the code I provide. Check, in this order:
1. Correctness — logic errors, off-by-one, wrong conditionals, edge cases (empty, null, very large input).
2. Security — injection, missing authz checks, unsafe deserialization, secrets in code.
3. Reliability — unhandled errors, resource leaks, race conditions, missing timeouts.
4. Clarity — naming and structure that will confuse the next reader.

Output three sections: BLOCKING, SHOULD-FIX, NITS.
For every item, quote the exact line and give the fix as a code snippet.

Constraints:
- If a category has no issues, write "none". Do not invent problems to seem thorough.
- Do not comment on style covered by a formatter.
- No general advice. Every point must reference a specific line.

Here is the code:
[PASTE CODE]

Prompt 2: The adversarial "break it" review

Sometimes you don't want a polite review — you want the AI to actively try to break your code. This catches edge cases a normal review glides past.

You are a hostile QA engineer. Your goal is to find inputs and conditions
that make this function behave incorrectly, crash, or produce wrong output.

For each issue, give:
- The exact input or condition that triggers it.
- What goes wrong and why.
- A minimal test that reproduces it.

Focus on: empty/null/undefined, boundary values, unexpected types, concurrent
calls, and extremely large input. Do not suggest stylistic changes.

Code:
[PASTE CODE]

The "give me a test that reproduces it" line is what makes this prompt pay off — you don't just hear about the bug, you get the failing test to confirm it.

Prompt 3: The security-only pass

When the code touches auth, payments, or user input, run a dedicated security pass instead of relying on the general review to catch it.

You are a security auditor. Review this code ONLY for security issues.
Map each finding to a category: injection, broken auth/authz, sensitive data
exposure, SSRF, insecure deserialization, or missing input validation.

For each finding: severity (high/med/low), the vulnerable line, an example
exploit, and the fix. If you find nothing exploitable, say so plainly —
do not pad the report.

Code:
[PASTE CODE]

Running security as its own pass works better than folding it into a general review, because a focused prompt keeps the model in one mode instead of splitting attention across naming, structure, and security all at once.

The pattern you can reuse for anything

Look at what those three share: a role, a prioritized checklist, a hard constraint against fluff, and a fixed output format. That same skeleton works for debugging ("you are a debugger, reproduce before theorizing"), for refactoring ("preserve behavior, change one thing at a time"), for test writing ("target edge cases, not the happy path"), and for SQL review ("check for N+1, missing indexes, full scans").

Once you internalize the skeleton, you stop typing "review my code" forever. You write prompts that tell the AI exactly what job it's doing — and it stops guessing.

A small homework

Take the triaged-review prompt above, run it on a function you wrote this week, then run plain "review my code" on the same function. The difference is the whole point of this post — and it's free to try right now.

Want these prompts wired into a real workflow?

Prompts get even better when they're not floating in a chat box but baked into named, repeatable steps. That's what I built with Claude Code Agent OS: it turns reviewer, debugger, test-writer, security-auditor and more into focused subagents you invoke with one command — each with the same five-part, anti-fluff structure (role, checklist, output format, constraints) as the prompts above, plus 12 slash commands and ready-to-edit CLAUDE.md templates. Works with Claude Code today, and the prompts themselves drop into ChatGPT, Cursor, or Copilot.

But the three prompts in this post are yours to keep and will sharpen your reviews today. Steal them, adapt them to your stack, and ship better code.

Which review constraint made the biggest difference for you? I'm always collecting the lines that kill AI fluff — share yours below.

Cursor Rules That Actually Improve AI Output (.mdc Project Rules)

NongdyZ — Sat, 27 Jun 2026 19:06:17 +0000

Most Cursor rules I see online are wish lists. "Write clean code." "Follow best practices." "Be concise." Cursor reads them, nods politely, and ships exactly the same code it would have without them.

The reason is simple: vague rules give the model nothing to act on. A rule only changes output if it's specific, enforceable, and scoped to when it matters. After rewriting my rules around those three properties, Cursor went from "code that works but I'd reject in review" to "code that passes review the first time" on most requests.

Here's what actually moved the needle, with real .mdc rules you can paste in.

The format: `.cursor/rules/*.mdc`, not `.cursorrules`

Cursor has moved to Project Rules stored as .mdc files in .cursor/rules/. The big advantage over the old single .cursorrules file is scoping: each rule has frontmatter that controls when it loads.

---
description: "Security rules for all code"
globs:
alwaysApply: true
---

Three frontmatter fields decide everything:

alwaysApply: true — the rule is in context on every request. Use for short, universal rules (security, error handling).
globs: "**/*.tsx" — the rule auto-attaches only when a matching file is in play. Use for stack-specific rules so your React rules don't pollute your Python context.
Neither set — the agent pulls the rule in when it judges it relevant, based on the description. Use for situational best-practice rules.

This scoping is the whole game. Loading every rule on every request dilutes the context and the model starts ignoring all of them. Scoped rules stay sharp because only the relevant ones are present.

Rule 1: A global rule the model can actually enforce

Keep your always-on rule short and written as concrete checks, not aspirations:

---
description: Global engineering rules — always apply
globs:
alwaysApply: true
---

- Validate and type all external input (API bodies, query params, env vars) at the boundary.
- Every function that can fail returns a typed error or throws — never returns null silently.
- No secrets in code. Read from env. Never log tokens, passwords, or full PII.
- When you change a function's signature, update every caller in the same change.
- Prefer deleting code over adding flags. The best fix removes complexity.

Notice there's no "write clean code." Every line is a check the model can apply to a specific diff. "Validate input at the boundary" produces a zod schema; "write clean code" produces nothing.

Rule 2: A stack rule scoped by glob

This one only loads when a TypeScript/React file is involved, so it never interferes with your backend or scripts:

---
description: React + TypeScript conventions
globs: "**/*.tsx, **/*.ts"
alwaysApply: false
---

- Components are typed function components. No `React.FC`. Props via an explicit interface.
- No `any`. Use `unknown` + a narrow, or define the type. If you truly can't, add a `// TODO: type` and explain.
- Follow the Rules of Hooks: no hooks in conditions or loops. Effects list every dependency they read.
- Data fetching goes through the existing query layer, not raw `fetch` inside components.
- Every interactive element is keyboard-accessible and has an accessible name (label, aria-label, or text).

The no any rule is the one people underrate. Left alone, Cursor reaches for any constantly because it's the path of least resistance. One scoped line removes most of it and forces it to think about the actual type.

Rule 3: A best-practice rule the agent loads on demand

Some rules only matter sometimes — like database access. Leave alwaysApply off and write a clear description so the agent pulls it in when it touches SQL:

---
description: Database and SQL safety — apply when writing queries or migrations
globs:
alwaysApply: false
---

- Always use parameterized queries / prepared statements. Never interpolate user input into SQL.
- Every query that can return many rows is paginated or explicitly bounded with LIMIT.
- Add an index before shipping a query that filters or joins on a non-indexed column — call it out.
- Migrations are reversible and never run automatically. Generate the file; let the human apply it.
- Watch for N+1: fetching a list then querying per item is a bug, not a style choice.

Because this rule isn't always loaded, it doesn't eat context on your CSS work. But the moment you ask Cursor to write a query, its description makes it relevant and it gets pulled in.

The before/after that convinced me

Same request — "add an endpoint to fetch a user's orders" — with and without the rules above.

Without rules:

app.get("/orders", async (req, res) => {
  const userId = req.query.userId;
  const orders = await db.query(`SELECT * FROM orders WHERE user_id = ${userId}`);
  res.json(orders);
});

SQL injection, no input validation, no pagination, SELECT *.

With the rules:

const Query = z.object({ userId: z.string().uuid(), page: z.coerce.number().min(1).default(1) });

app.get("/orders", async (req, res) => {
  const parsed = Query.safeParse(req.query);
  if (!parsed.success) return res.status(400).json({ error: parsed.error.flatten() });
  const { userId, page } = parsed.data;
  const limit = 50;
  const orders = await db.query(
    "SELECT id, total, status, created_at FROM orders WHERE user_id = $1 ORDER BY created_at DESC LIMIT $2 OFFSET $3",
    [userId, limit, (page - 1) * limit]
  );
  res.json({ orders, page });
});

Parameterized, validated, paginated, explicit columns. Same model, same prompt. The rules did that.

How to start without overdoing it

Don't write twenty rules on day one — you'll dilute the context and burn out maintaining them. Start with exactly three:

One short alwaysApply global rule (security + error handling).
One glob-scoped rule for your main stack.
One on-demand rule for whatever bites you most (SQL, accessibility, tests).

Live with those for a week, then add a rule only when you catch Cursor making the same mistake twice. Rules earn their place by preventing a real, repeated error.

If you want a full, tuned AI-coding setup

Rules are one half of the picture. The other half is giving your AI assistant a real workflow — focused review/test/refactor steps instead of one generalist doing everything. I packaged my complete setup as Claude Code Agent OS: 26 specialized subagents, 12 slash commands, ready-to-edit CLAUDE.md templates, MCP configs, and safety hooks — the same scoped, anti-fluff philosophy as the rules above, applied to the whole coding loop. It works alongside Cursor and any editor.

That said, the three-rule starter in this post costs nothing and will improve your very next Cursor session. Build those first, then decide if you want the full setup.

What's the one mistake Cursor keeps making in your codebase? Tell me in the comments and I'll suggest a rule for it.

How I Set Up Claude Code with 26 Production Subagents (CLAUDE.md, MCP, Hooks)

NongdyZ — Sat, 27 Jun 2026 13:54:39 +0000

When I first opened Claude Code on a real project, it felt like hiring a brilliant junior who had read every book but never shipped anything. It could write code fast, but it would forget my conventions halfway through a session, run a migration without asking, and "fix" a bug by deleting the failing test.

After a few weeks of tuning, it now behaves like a small senior team: it plans before it codes, reviews its own work, writes tests, and refuses to run anything destructive. The difference wasn't a better model. It was a better setup — a CLAUDE.md, a set of focused subagents, a couple of MCP servers, and two small hooks.

Here is exactly how that setup works, so you can build your own.

1. CLAUDE.md is the contract, not a wishlist

CLAUDE.md is the file Claude Code reads automatically at the start of every session. Most people treat it like a README. It works far better as a contract: short, specific, and written in always/never terms the agent can't misread.

The two rules that gave me the biggest jump in quality:

## Build & test (run these, do not guess)
- Install:  pnpm install
- Dev:      pnpm dev
- Test:     pnpm test -- --run
- Lint:     pnpm lint
- Typecheck: pnpm typecheck

## Always
- Run `pnpm typecheck && pnpm test -- --run` before saying a task is done.
- Use parameterized queries. Never build SQL with string concatenation.
- When you change a public function, update its tests in the same edit.

## Never
- Never run `git push`, `git reset --hard`, or any DB migration without me confirming.
- Never add a dependency to fix something a few lines of code can solve.
- Never disable a failing test to make the suite pass.

The reason the "Build & test" block matters: without the exact commands, the agent guesses them (npm test, yarn test, make test) and wastes turns failing. Give it the real commands once and it stops guessing.

Keep this file under ~50 lines. A long CLAUDE.md gets diluted in the context and the agent starts ignoring the middle of it. Be ruthless.

2. Subagents: split one generalist into many specialists

A single agent juggling "review this, also write tests, also refactor" produces mediocre output at every task. Subagents fix this by giving each job its own focused instructions and its own context window. In Claude Code these live in .claude/agents/*.md and you invoke them by name.

A subagent is just a Markdown file with frontmatter and a system prompt. Here's a real one — my code-reviewer:

---
name: code-reviewer
description: "Reviews a diff for bugs, security issues, and convention violations. Use after writing or changing code."
tools: Read, Grep, Bash
---

You are a senior code reviewer. Review ONLY the changed lines plus their immediate context.

Output exactly three sections:
1. **Blocking** — bugs, security holes, data loss risks. Each with file:line and a fix.
2. **Should fix** — correctness or clarity issues that aren't blocking.
3. **Nits** — style/naming. Keep this short.

Rules:
- If there are no blocking issues, say so on line one. Do not invent problems to look thorough.
- Check: injection, missing error handling, N+1 queries, unhandled null, race conditions.
- Quote the exact line you're flagging. No vague "consider improving error handling".

The two lines that make it useful are "Do not invent problems to look thorough" and "Quote the exact line." Without them, reviewers either rubber-stamp everything or generate a wall of generic advice. With them, you get actionable output.

I run a roster of focused specialists this way — a debugger that reproduces before it theorizes, a test-writer that targets edge cases instead of happy paths, a security-auditor that thinks in OWASP categories, an api-designer, a refactor-architect, and so on. Each one is a small file with a tight output format. The pattern is always the same: one job, one output format, one anti-fluff constraint.

3. MCP: give the agent eyes and memory

MCP (Model Context Protocol) servers are how Claude Code reaches outside the chat — the filesystem, a browser, a persistent memory store. You configure them in .mcp.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"]
    },
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

The one I'd add first is sequential-thinking. It gives the agent a scratchpad to break a problem into steps before acting, which noticeably reduces the "confidently wrong" answers on multi-step tasks. A browser MCP (Playwright) is the second I reach for, because it lets the agent actually load the page and read the console instead of guessing why the UI broke.

One caution: MCP servers move fast and some get abandoned. Pin to maintained ones and check they still install before you rely on them.

4. Hooks: the safety net that runs without asking

Hooks are shell commands Claude Code runs on events you choose. Two are worth setting up on day one.

Auto-format on save — so you never review a diff full of whitespace noise:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "pnpm prettier --write \"$CLAUDE_FILE_PATHS\"" }]
      }
    ]
  }
}

Block dangerous commands — a pre-execution guard that refuses destructive shell calls even if the agent tries them:

#!/usr/bin/env bash
# .claude/hooks/guard.sh — exit non-zero to block the command
if echo "$CLAUDE_TOOL_INPUT" | grep -qE 'rm -rf /|git reset --hard|DROP TABLE'; then
  echo "Blocked: destructive command refused by guard hook." >&2
  exit 1
fi

This is the difference between trusting an autonomous agent and babysitting it. The model can be wrong; the hook is deterministic.

Putting it together: a feature, start to finish

With the setup above, my actual workflow on a new feature is short:

Ask the agent to plan — it writes the steps before touching code.
It scaffolds and implements, formatting on save via the hook.
I invoke code-reviewer on the diff, then test-writer for the gaps it found.
pnpm typecheck && pnpm test runs because CLAUDE.md says it must.
It drafts the commit and PR description.

The agent does the typing. I do the deciding. That's the whole point.

Want the whole thing as a drop-in?

Building all of this from scratch is a real time sink — the 26 subagents alone took me weeks of tuning to get the output formats right. If you'd rather skip that and drop a finished setup into any repo, I packaged my exact configuration as Claude Code Agent OS: 26 specialized subagents, 12 slash commands (/plan, /review, /test, /ship...), 5 ready-to-edit CLAUDE.md templates, the MCP configs, and the safety + format hooks (bash and PowerShell) — with a START HERE quickstart that gets you running in about 5 minutes.

But you don't need it to get value from this post. Start with a tight CLAUDE.md and one code-reviewer subagent today; that pair alone will change how your next commit feels.

If you build your own subagent roster, I'd genuinely like to see which specialists you find most useful — drop them in the comments.