# Can the Codebase Afford to Remember It?

Every patch asks the codebase to remember something.

Sometimes the memory is clean: a new behavior, a clearer abstraction, a regression test, a convention applied where future readers expect it. Sometimes the memory is expensive: a helper bypassed in one place, a broad diff hiding several decisions, a test that locks in an implementation, a local shortcut that future maintainers have to rediscover.

Mergeability is the question of whether that memory is worth accepting.

A hidden test can inspect current behavior. It cannot fully inspect what the codebase will have to remember after the patch becomes ordinary. That is why "does it pass?" and "would you merge it?" are different questions. The first asks whether the answer works. The second asks whether the system can live with the answer.

Cognition's FrontierCode is valuable because it points the benchmark at the second question. The public post says its tasks come from 36 open-source repositories and were built with maintainers who define mergeability in their own projects. The benchmark grades correctness, test quality, style, scope discipline, and codebase standards using tests, rubrics, custom verifiers, and LLM grading. Cognition reports that its hardest 50-task Diamond set is still mostly unsolved, with the leading model at 13.4 percent.

Those numbers are source-reported until the private benchmark earns independent trust. The important shift is the evaluation object. Production code is being measured at the point where an output becomes part of a maintained system.

The `LOG_WARNING()` example makes the shift concrete. A task asks for warnings to go through a helper. The model writes one line through `LOG_WARNING()` and continuation lines directly through `std::cerr`. The warning appears either way. A behavior check can pass.

The codebase has acquired a bad memory. It now remembers that warning behavior goes through the helper except where this patch decided the helper was only decoration. If the helper changes later, the abstraction fails exactly where the benchmark's behavioral surface looked fine.

The maintainer rejects the patch because she can see the memory forming.

This is what review taste is. A maintainer has learned which memories become costly. She has seen the helper bypass that blocked a logging change, the sprawling patch that made a rollback impossible, the missing test that turned ownership into archaeology. Her review comment compresses that history into a small local demand.

FrontierCode's rubrics and review process are attempts to capture that compressed history. They are trying to make maintainer judgment repeatable enough to benchmark against. That is hard because any proxy for judgment can fail two ways: loose enough for agents to game, rigid enough to reject good code that differs from the expected solution.

The benchmark also cannot be the whole production object. A raw model diff, a repository-aware agent, and a loop that can revise after review are different systems. Real engineering includes context acquisition and feedback. The right workflow may learn the codebase's memory well enough to produce mergeable changes more reliably than a one-shot score suggests.

Still, the standard is right. Generated code should be judged by whether the maintained system can carry it without special pleading. A patch is production-grade when future maintainers can reason from the codebase itself instead of remembering the agent's path through it.

The code does not merely have to work. The codebase has to be able to remember it.