The Fake Clock Is the Part of an AI-Written Rate Limiter Worth Reviewing

Start from the failure you want to catch, not from the model's confidence. A rate limiter has an annoying property: most of its behavior is invisible until the exact moment a client crosses a boundary, and once that boundary is crossed in production the damage is already a pile of 429s, retries, and support messages. The inexpensive way to review an AI-written token bucket is to give it a fake clock and replay a designed burst, because the common defects hide in boundary spacing, key isolation, and the difference between wall time and test time. Then, when the local harness passes, host the same generated limiter on a throwaway server and send the same sequence over real HTTP to catch status code, header, and timing mistakes that a unit test will never see.

You can do this with a very small amount of plumbing. MonkeyCode's free model access and free server option give you a place to generate the candidate limiter and a place to run it without touching your production environment. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The point is not to trust the generator; the point is to make the generated artifact prove a narrow property under conditions you control.

Start by asking the model for a token-bucket limiter for a small HTTP service, and add one requirement that shapes the entire review: the generated code must accept a clock as an argument rather than reading the system clock directly. That single requirement is more valuable than asking for production-grade code, because it makes timing deterministic and turns the hardest part of the limiter into a pure function you can test. A typical generated TokenBucket class will maintain a float representing the last refill time, and if it calls time.time() inside allow(key), you should push the model or edit the code until the timestamp arrives from outside.

The fake clock is not a mock in the mocking-library sense. It is a small object that knows the current virtual time and can move forward by exactly the amount you choose. In a test, you assemble a timeline of events, advance the clock to the next event, call the limiter, and record whether each request was allowed. The following harness is deliberately small enough to paste into a scratch file:

class FakeClock:
    def __init__(self):
        self.now = 0.0

    def sleep(self, seconds):
        self.now += seconds

    def time(self):
        return self.now

def send_burst(allow, timeline):
    clock = FakeClock()
    results = []
    for at, key in timeline:
        clock.sleep(at - clock.now)
        results.append((at, key, allow(key, clock.now)))
    return results

The allow function is whatever interface your generated limiter exposes, and the timeline is a list of virtual-time and key pairs. Because the clock advances in the order you specify, a passing or failing sequence is reproducible on every run, which means you can keep the failing case in your repository instead of trying to explain a flaky production incident from memory.

The burst that finds most mistakes is not a random load test. Use a short timeline that combines a full bucket, a boundary refill, two interleaved keys, and a long quiet period. For a limiter configured to allow two requests per second with a burst capacity of three, a useful sequence might be requests from key a at zero, fifty milliseconds, one hundred milliseconds, four hundred fifty milliseconds, nine hundred fifty milliseconds, and one thousand one hundred milliseconds. The expected pattern is to allow the first three and deny the next three, because the bucket drains faster than it refills. A model-generated version that allows the fourth request at four hundred fifty milliseconds has probably rounded clock arithmetic, while one that allows a request for key b because key a exhausted the bucket has mixed up per-key and global state. Those are exactly the bugs a quick read of the diff tends to miss.

Once the fake-clock harness is green, the free server earns its place. Run the generated limiter as a tiny HTTP service with an endpoint that accepts an API key and returns either 200 or 429, then point a small client at it and replay the same timeline with real sleeps. The goal here is not to measure capacity or prove it can survive production traffic; the goal is to observe the contract around the limiter, including the response body, the retry-after header, whether the server crashes when a key is missing, and whether the first request after a long pause behaves as the token bucket predicts. A one-file service on a free server is enough for that check, and it keeps the experiment away from your real API.

The full workflow, then, is four steps. Generate the limiter with an injectable clock. Drive the generated code through a deterministic burst locally and assert the allowed and denied sequence. Deploy the same file to a free server and replay the sequence over HTTP while recording status and headers. If any observed behavior differs from the local prediction, stop and fix the generated code before discussing it with someone else. This is not a let AI write your infrastructure and then test it slightly workflow; it is closer to treating generated code as an untrusted patch that must pass a tiny contract before you spend time reviewing the implementation.

There are clear limits to the approach. The fake clock proves the limiter's arithmetic and key-scoping logic, but it does not prove the generated service is thread-safe under real concurrency, nor does it tell you whether a free server has enough capacity for your actual traffic. It also will not rescue you from a limiter that uses a global variable in a way that only breaks when many users hit it at the same millisecond. If you are protecting a payment endpoint, a compliance boundary, or anything where a bad 429 or an accidental 200 is expensive, use a maintained rate-limiting library or a gateway feature and treat generated code as a study case, not a dependency. The workflow is most useful when the downside is a noisy endpoint and you want a quick, honest answer about a candidate implementation before you invite real users.

The failure budget is the mental shift. You do not ask the model to produce a limiter and then ask it to grade its own work; you ask it to produce a limiter that accepts a clock, and you use a fake clock plus a free server to spend the small failure budget where an error is cheap. That gives you a review you can repeat tomorrow with a different timeline, a different key layout, or a different generated implementation, without preserving the fragility of the first draft.

If you have access to MonkeyCode's free model and server options, the smallest useful change is to make the generated limiter accept a clock and run this replay before you read the diff for style. The review becomes a comparison between your predicted sequence and the observed sequence, which is a far more concrete thing to argue about than whether the code looks correct.