Distributed rate limiter limits
A teammate proposes letting an AI agent write the core of a new Go distributed rate limiter — a token-bucket implementation shared across many goroutines and backed by Redis for cross-instance coordination, with a local fallback when Redis is unreachable. When would you NOT lean on the agent for this, and what failure modes make it the wrong tool for the load-bearing parts?
Implement
simulate_token_bucket(capacity: int, refill_per_second: int, request_times_ms: list[int], request_costs: list[int], backend_up: list[bool]) → list[bool]Examples
in
[5,1,[0,0,0,0,0,0],[1,1,1,1,1,1],[true,true,true,true,true,true]]out[true,true,true,true,true,false]in
[2,1,[0,0,500,1000],[1,1,1,1],[true,true,true,true]]out[true,true,false,true]in
[3,0,[0,10,20],[1,1,1],[true,false,true]]out[true,false,true]What a strong answer looks like
Treat the AI’s output as a draft to verify, not an answer to trust. Name the specific flaw and the input that triggers it, say how you’d catch it (tests, edge cases, reading critically), and how you’d re-prompt or decompose to get it right.
0:00 of about 22 min
Vibe & agentic: describe the solution in plain language (or narrate it) and the coach grades your approach.
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.