Every engineering team accumulates slop. Code that almost does the right thing. Network calls without retry logic. Files that grew to 600 lines because nobody stopped them. In a human-paced team, you handle slop the same way you handle weeds: the fast-moving engineers notice it, raise it in PR comments, and hope the pattern doesn’t repeat.
When agents are authoring three to five PRs per engineer per day [1], that hope strategy fails immediately. The PR velocity exposes every inconsistency. The cost of reviewing the same failure pattern for the fifteenth time becomes real and measurable. And the humans who are doing the reviewing become the bottleneck that prevents everything else from moving.
Ryan Lopopolo, Member of Technical Staff at OpenAI, designed a systematic answer to this problem. He called it Garbage Collection Day.
Figure 1 - Garbage Collection Day: Lopopolo’s Friday ritual converts each week’s PR slop observations into three types of durable artifacts, each of which catches the same mistake automatically on every future push. Once a lint, test, or reviewer-agent update exists, no human ever has to leave that comment again.
The Bottleneck That Killed Throughput
Before the ritual existed, the bottleneck was obvious in retrospect. Lopopolo’s team at OpenAI was running a three-engineer operation where agents did the implementation and humans reviewed the output [1]. That sounds like a staffing win until you look at the queue. As Lopopolo recounted, PRs were staying open for so long because the work needed code review, and the humans doing that review had become the blocker in the pipeline [1].
At “three to five PRs per engineer per day” [1], a three-person team is generating nine to fifteen PRs daily. Synchronous human review of that volume is not a review strategy, it is a bottleneck factory. And the feedback those reviewers were leaving was often the same feedback they had left on prior PRs. The fetch call needs a retry. The file is too long. The test coverage skipped the error path.
Each of those comments represented a context failure: the agent did not know the standard, so it did not apply it. The standard lived in the reviewer’s head. The reviewer had to externalize it, PR by PR, in perpetuity.
KEY INSIGHT: When agents are doing the work, every repeated PR comment is not a review note, it is evidence of a missing lint rule, a missing test, or a missing reviewer-agent instruction. The feedback loop only closes when you convert the comment into something the harness enforces automatically.
Figure 2 - The synchronous review bottleneck: Nine to fifteen PRs per day with three human reviewers creates a reliable queue. The compounding problem is that the feedback being given is often identical across PRs. The reviewer is not adding judgment on the second occurrence; they are paying a tax on missing automation.
The Wow Quote: What “Durably Solved” Means
Lopopolo named the anti-pattern with unusual precision. In his keynote at AI Engineer Europe 2026, he described what happens when a developer spots a non-functional requirement that the model keeps missing:
“I am not a reliable reviewer or author of code with respect to this non-functional requirement. However, taking the time to write some docs, write a lint that is bespoke to my codebase that is going to look at every time I call fetch to make sure that there’s a retry and a timeout wrapped around it means I’ve durably solved this problem” [1].
The phrase “durably solved” is doing a lot of work in that sentence. It is not “I left a comment.” It is not “I merged the fix.” It is a statement that the problem has been removed from the category of things that can recur. The lint runs on every push. The agent cannot author a fetch call without a retry and a timeout without the lint failing. The human no longer needs to remember to check.
The fetch-with-retry example is concrete for a reason. Non-functional requirements like retry logic, timeout behavior, file-length limits, and test coverage on error paths are precisely the things that experienced human reviewers enforce from pattern recognition. Agents do not carry that pattern recognition by default. They will skip the retry unless something in the harness enforces it.
Figure 3 - From comment to constraint: Before Garbage Collection Day, “fetch calls need retry and timeout” lives as a PR comment that the reviewer must re-type each time. After, a bespoke ESLint rule enforces the pattern on every push. The reviewer never types that comment again.
The Three Durable Artifact Types
The ritual has a specific output: not notes, not Slack messages, not “I’ll tell the team.” Lopopolo’s keynote enumerates exactly three types of durable artifacts that the day produces. Each one is harder to ignore than a comment and survives the context window.
Type 1: Bespoke Lints
Lints are the fastest artifact to ship and the most immediately enforceable. The fetch-with-retry example above is a lint: a custom rule wired into the codebase’s linting infrastructure that runs on every push. The OpenAI engineering blog describes the same ESLint-based approach, with the team building bespoke rules for patterns like retry and timeout enforcement [2].
The key word is “bespoke.” These are not generic ESLint rules from a shared config. They are rules specific to the codebase’s patterns, the team’s non-functional requirements, and the failure modes observed in that week’s PRs. The agent that runs in this codebase now has the linter as a closed-loop tutor. Every time it does the wrong thing, the lint catches it before a human does.
Type 2: File-Shape Tests
The second artifact type is source-code tests that assert structural properties separate from lints [1]. The distinction matters: lints run as static analysis at the rule layer, while these are tests written about the source code itself.
The illustrative example from the keynote is a file-length test: a test that asserts no source file in the codebase exceeds 350 lines [1]. That constraint would be impractical to enforce through review comments on a team generating fifteen PRs a day. As a failing test in CI, it becomes automatic. The agent cannot merge a 400-line file without breaking the test.
This category covers any structural invariant the team cares about: import graph constraints, naming conventions, module boundary rules, forbidden API calls. Anything that can be expressed as “this is true of the codebase as a whole” can be a file-shape test.
KEY INSIGHT: File-shape tests invert the enforcement model. Instead of “a reviewer must notice the violation,” the rule is “the CI pipeline must pass.” Agents respond well to clear failing feedback. A test failure is unambiguous. A code review comment is not.
Figure 4 - Three durable artifact types: Bespoke lints enforce coding patterns at the static analysis layer. File-shape tests enforce structural invariants at the CI layer. Reviewer-agent prompt updates enforce review standards at the automated review layer. All three share the same property: they run automatically on every future push without human intervention.
Type 3: Reviewer-Agent Prompt Updates
The third artifact type feeds directly into the reviewer agents that run on every push. Lopopolo’s harness at OpenAI runs persona-bucketed review agents: a front-end architect, a reliability engineer, and a scalability engineer, each reviewing the code through the lens of their domain expertise [1].
When a Garbage Collection Day review surfaces a recurring pattern, the fix is to add documentation to the relevant persona’s context. The reliability engineer agent gets a new instruction about retry patterns. The front-end architect agent gets a new note about component size limits. And from that point forward, every push gets reviewed against the updated standard.
The flywheel here is particularly interesting. The first time a human leaves a PR comment about missing retry logic, the agent that authored the code did not know the standard existed. After Garbage Collection Day, the reviewer agent knows. On the next push, the reviewer agent catches the pattern before the human ever sees the PR. On the push after that, if the implementation agent has been reading its reviewer-agent feedback, it may not make the mistake at all.
Figure 5 - The reviewer-agent update loop: A Friday Garbage Collection Day takes a PR comment that a human left during the week and converts it into a standing instruction for the reliability-engineer reviewer agent. On every subsequent push, the agent catches the pattern automatically. The human is out of the loop for that class of failure.
Running the Ritual
The cadence is explicit: every engineer on the team takes Fridays for this [1]. Not “when they get to it.” Not “someone should do this.” The entire team’s job on Fridays is to take the slop they observed that week and eliminate it categorically. Each engineer becomes the owner of the class of mistakes they personally spotted.
This design is important. It ties the person who noticed the pattern to the person responsible for building the artifact that prevents it. The engineer who left the retry comment on three separate PRs this week is the right person to write the retry lint. They understand the pattern, they have seen three examples of it, and they have the clearest intuition for what the edge cases are.
At a team of three, that is three lints, or three test additions, or three reviewer-agent updates per Friday minimum. Over a month, the harness has absorbed a month’s worth of observed failure modes. Over a quarter, the artifact set reflects the real failure pattern of agents working in this specific codebase on these specific problems.
The compounding effect is measurable in throughput. Lopopolo describes the before state plainly: PRs stayed open because they needed code review, and the humans performing that review were the blocker [1]. The after state is three to five PRs per engineer per day with humans no longer the synchronous gate [1]. The ritual is the operational mechanism that moved the throughput from bottleneck to flow.
Figure 6 - Compounding throughput from weekly slop elimination: Each Garbage Collection Day removes a class of failures from the human review queue. The throughput gain is not a one-time improvement; it compounds as the harness absorbs more of the review burden that humans previously handled synchronously. Lopopolo’s team reached “three to five PRs per engineer per day” [1] with this ritual as a core driver.
The Practitioner Connection: Our Own Slop-Elimination Loop
The Garbage Collection Day pattern resonates directly with how we run the dotzlaw.com article pipeline, and it is worth making that concrete rather than gestural.
The review-servoy-code skill lives at .claude/skills/review-servoy-code/SKILL.md. Every time the article-reviewer agent evaluates a Servoy tutorial draft and files a review at docs/kb/qa/reviews/, it is applying a standing set of criteria derived from prior reviews: ES6+ idioms, Hungarian notation, QBSelect over raw SQL, JSDoc on every function, try/catch in every event handler. Those criteria did not arrive from a style guide written in isolation. They were extracted from recurring patterns observed in actual drafts, codified once, and applied from that point forward automatically.
The dated review files under docs/kb/qa/reviews/ are the artifact trail. A file like 2026-05-16-claude-code-05-harness-evolution.md is the output of one pass of the loop: the reviewer observed something, the finding entered the record, and the skill criteria that govern future reviews were updated to catch the same class of problem without requiring a human to notice it again.
This is Garbage Collection Day applied to an article pipeline rather than a software codebase. The failure modes are different (voice inconsistencies instead of missing retries, wikilinks surviving to the body instead of file-length violations), but the loop is structurally identical: observe slop, build a durable artifact that catches it, never review that class manually again.
KEY INSIGHT: The Garbage Collection Day ritual is domain-agnostic. Any workflow where agents produce output and humans review it can run this loop. The weekly cadence and the “three durable artifact types” framing apply whether the output is code, prose, or data.
Figure 7 - The same loop in two domains: The Garbage Collection Day structure maps directly from software codebases to content pipelines. The artifact types have different names but the same function: encode a review standard once, enforce it automatically on every future pass, and remove the human from the loop for that class of failure.
What Changes When the Harness Has This
There is a flywheel property to this ritual that is easy to miss in the throughput numbers. The immediate benefit is that humans stop repeating themselves. The medium-term benefit is that the agents start absorbing feedback faster because the feedback arrives as a failing lint or a failing test rather than a suggestion in a comment thread.
An agent does not have to interpret a failing lint. The lint either passes or it does not. The fix is either in the diff or it is not. That clarity is qualitatively different from reading “I noticed you didn’t add a retry here” in a review comment and deciding how to respond. The lint leaves no room for interpretation and no room for the agent to deprioritize it.
This is what The Harness Evolution Principle describes from the pruning direction: as the agents improve, some of the scaffolding you built to compensate for their limitations expires. Garbage Collection Day works in the complementary direction. It is the weekly mechanism that loads new standards into the harness at the pace at which the team discovers that the agents need them. The two principles together define the maintenance loop: prune what the model no longer needs, add what the model has not yet learned.
The throughput numbers at OpenAI, “three to five PRs per engineer per day” [1] on a three-engineer team, are downstream of both. The model capability provides the ceiling; the harness maintenance practice determines whether the team reaches it.
Figure 8 - The Garbage Collection Day flywheel: Each cycle of the ritual adds enforcement artifacts to the harness. As the harness absorbs more review standards, the human review queue shortens. Shorter review queues mean faster merge cycles, which means faster iteration on the next round of observed slop. The flywheel compounds over months of consistent operation.
Conclusion
Garbage Collection Day is a simple ritual with a compounding return. Take one day per week. Convert each observed PR failure into one of three durable artifacts: a bespoke lint, a structural test, or a reviewer-agent prompt update. Let the harness enforce what you observed, so no human ever has to enforce it manually again.
The “wow” framing from Lopopolo’s keynote is the right lens: “durably solved” is the goal, and it is distinct from “fixed in this PR.” Fixed in this PR means the problem will recur. Durably solved means the harness closes the loop.
For teams running agents at scale, the math on this ritual is straightforward. Each durable artifact removes a recurring review cost and frees that human attention for judgment calls that actually require it. The three-to-five PRs-per-day throughput that Lopopolo’s team reached [1] is not just a model-capability number. It is what becomes possible when the humans on the team stop doing tasks that a lint rule can do better.
The next article in this sub-series examines the economics side of operating at that throughput: what it costs to run a billion output tokens a day, where those tokens actually go, and why the cost structure looks very different from what most teams expect.
The Series
This is Part 1 of the 3-part OpenAI Lopopolo sub-series:
- Garbage Collection Day: A Weekly Ritual for Reducing Agent Slop (this article). The Friday slop-elimination ritual, the three durable artifact types, and the throughput flywheel.
- Token Billionaire Economics: Where 1B Output Tokens Per Day Actually Go. The cost structure and token allocation of operating at extreme agent throughput.
- Code as Disposable Build Artifact: LLMs as Fuzzy Compilers. Treating generated code as ephemeral output and the architectural implications for harness design.
References
[1] R. Lopopolo, “Harness Engineering: How to Build Software When Humans Steer, Agents Execute,” AI Engineer Europe 2026 keynote, April 8-10, 2026, London. https://www.youtube.com/watch?v=am_oeAoUhew
[2] R. Lopopolo, “Harness engineering: leveraging Codex in an agent-first world,” OpenAI, February 11, 2026. https://openai.com/index/harness-engineering/
[3] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Harness Evolution Principle: Why Mature Harnesses Look Like Pruning,” dotzlaw.com, 2026. /insights/claude-code-05-harness-evolution/
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.