We help teams review, prioritize, understand, and secure agent outputs.
Free plan includes 10 AI reviews a month. No card required.
Add per-key rate limiting to the public API
acme/payments-api · #412 · round 2 of review
Acceptance criteria coverage
2 of 4 satisfied
- Rate limit returns 429 with Retry-AfterSatisfied
- Limits are per-API-key, not per-IPSatisfied
- Burst allowance of 20 requestsPartial
- Counters survive a process restartUnmet
Rate limit counters are held in process memory
Why: The PRD requires limits to survive a restart and to hold across instances. A module-level Map resets on deploy and is not shared between the three API pods, so a client can get 3× the intended quota and reset it by timing a deploy.
src/middleware/rate-limit.ts:24
No test covers the burst allowance boundary
Why: Requests 20 and 21 are the exact edge the PRD calls out. Nothing currently fails if that off-by-one regresses.
Every feature follows a process.
Most tools help you write code faster. CODE_KING runs the process around it.
Fixes and Re-Review loop until the implementation actually satisfies the PRD.
It asks the questions a good PM would.
A request arrives as a support ticket, an email, or notes from a customer call. Before anything gets written, the agent scores how answerable it actually is and asks only for what’s genuinely missing — with the reason it needs each answer.
And it pushes back. If the capability already exists, it says so and educates the requester instead of building a duplicate. Not every request should become a feature.
Incoming request · support ticket
“Customers keep hammering our API and taking the whole thing down. Can we add rate limiting?”
Before we write a PRD
45% completeShould limits apply per API key, per IP, or per customer account?
This changes the storage key and whether a shared NAT breaks legitimate traffic.
What should happen when a client exceeds the limit — reject, queue, or degrade?
Rejecting is a breaking change for existing integrations.
PRD · Per-key API rate limiting
ApprovedProblem
A single misbehaving integration can exhaust API capacity for every other customer. Support has escalated this four times this quarter.
Goals
Cap request volume per API key. Return a standards-compliant 429. Keep limits accurate across all instances.
Non-goals
Per-endpoint quotas. Billing-tier-aware limits. Anything touching the dashboard UI.
Acceptance criteria
- Rate limit returns 429 with Retry-After
- Limits are per-API-key, not per-IP
- Burst allowance of 20 requests
- Counters survive a process restart
A PRD you’d actually sign off on.
Problem statement, goals, non-goals, user stories, acceptance criteria, edge cases, and success metrics. Every section is editable and versioned, because the first draft is a starting point, not a verdict.
The acceptance criteria are the important part — they become the contract the AI reviewer later checks the code against.
From requirements to a board your team can work.
Tasks are generated from the approved PRD, and each one traces back to the criterion it exists to satisfy.
Todo
2Add Redis-backed counter store
INFRAWire Retry-After header
FEATUREIn progress
1Rate limit middleware
FEATUREIn review
1Burst allowance window
FEATUREDone
2Define limit config schema
CHOREContract tests for 429
TESTA reviewer, not a linter.
It reads the diff against the PRD, the acceptance criteria, and the tasks — then tells you whether the feature is actually built.
Blocking vs non-blocking
Issues are categorised by whether they should stop a release. A missing test is not the same as an auth bypass, and the review says so.
Always explains why
Every issue carries its reasoning and the requirement it violates. Actionable feedback, not a severity label.
Posted to your PR
Summary and inline comments go back to GitHub through the app, so the conversation stays where your team already works.
Then it sends the issues back for fixes, and reviews the new code again. The loop continues until the feature is genuinely ready — not until someone gets tired of looking at it.
Nothing ships without a person saying so.
The approval screen puts the PRD, the tasks, the pull request, every round of AI review, and every outstanding issue on one page. A blocking issue that is still open prevents approval outright.
AI does the reading. A human makes the call. That order is the whole point.
Blocked by 1 open blocking issue
Built like a product, not a demo.
Multi-tenant workspaces, real GitHub integration, and durable background workflows you can watch run.
Durable workflows
PRD generation, reviews, and readiness checks run as Inngest steps with progress visible in the app.
Real GitHub data
A GitHub App, installation tokens, webhooks, and live diffs. Nothing about a pull request is faked.
Traceable requirements
Tasks reference criteria; reviews report coverage per criterion. You can always answer “is it done?”
Typed end to end
A tRPC monorepo over Prisma and PostgreSQL, so the contract between UI and API cannot drift.
Ship your next feature the way you’d want it reviewed.
Create a workspace, connect a repository, and run the loop end‑to‑end.