Three new cards, two new operators. No cross-operator convergence today. Each card names a different version of the same underlying trap: professional intuition or tool design pulling practitioners toward a frame that made sense in an older context.
Steam algorithm does not care about the calendar
Chris Zukowski's September 8 analysis (October is the third-worst revenue month for indie horror games because Steam algorithm amplification is diluted by a 60 percent surge in competing horror releases) closes a loop on a question the horror game developer community returns to every year. Should you launch a horror game in October? The seasonal logic is compelling on its face. Horror is an October genre. Players are in the mood. Films exploit it every year.
The data does not support the conclusion for games. Zukowski tracked 7,019 horror games on Steam and found October ranks third-worst by median revenue for what he calls "serious" indie developers. June outperforms it. The mechanism is supply-demand asymmetry: October brings roughly 60 percent more horror game releases than June without a proportional increase in horror buyers. Steam's recommendation engine rewards sales velocity and wishlist conversion rate. When supply surges, each title's algorithmic amplification is diluted. June's lower competitive density means the same level of buyer interest spreads across fewer titles, and each gets a larger share of discovery surface.
The two strongest horror titles in his dataset, Lethal Company and No More Room in Hell, launched in October, which Zukowski addresses directly. They represent the top of a very long tail. The aggregate median tells the story for the typical indie team making a first or second game.
"The first rule of becoming a professional Steam developer is that you must realize your gut instinct is wrong"
The broader principle, which Zukowski has documented across multiple analyses, is that Steam's recommendation logic is not a mirror of cultural seasons. It responds to relative performance within a competitive set. A launch that would be strong in a quieter month can look average in an oversaturated one.
- Chris Zukowski, October is the third-worst revenue month for indie horror games because Steam algorithm amplification is diluted by a 60 percent surge in competing horror releases. October horror launches compete in a 60 percent denser release environment without a matching demand increase; June yields higher median revenue for most indie horror developers.
Two ways professional tools lead practitioners astray
Thorsten Ball and Hamel Husain published independently this week on adjacent problems. Ball is writing about how engineers review AI-generated code. Husain is writing about how teams build AI evaluation systems. The surface topics are different. The failure mode is the same: a framework designed for one context gets applied without adjustment to a new one, and the results look fine until you examine what the framework actually measured.
Ball's Engineers who dismiss AI-generated code as low-quality apply the same professional bias that causes domain experts to over-intervene within their specialty applies Taleb's naive interventionism concept to engineering culture. The original Taleb example is surgical: three cohorts of doctors recommended tonsillectomies at different rates for the same children (174, 99, and 52 of 389), each successive group reviewing children the previous one had cleared. The intervention rate tracked specialty identity, not clinical evidence.
Ball's question is whether engineers reviewing AI-generated code do the same thing. An agent delivers a feature end-to-end in 20 minutes: frontend, backend, documentation, tests. The engineer opens the PR and flags that the comments are dumb and the naming is inconsistent. Ball's point is not that code quality doesn't matter. It is that the review rubric was calibrated for human-authored code, where style and quality correlate with competence and maintainability. Agent-generated code has a different cost structure. Evaluating it by the same rubric makes the cheap production look expensive by mismeasurement. He states his own conclusion directly: "making Astra and Fable open PRs and then have two people review them line by line in September 2026? Nah."
Husain's Eval tooling anchors teams on generic automated metrics before they have examined enough outputs to know what actually fails identifies the equivalent pattern in evaluation tooling. Standard eval frameworks present teams with a configuration interface: pick metrics, set thresholds, connect a dataset. Teams fill in the form before they have built any grounded picture of what their system actually produces. The form creates anchoring bias toward the metrics the tool designer thought were relevant.
"Eval tools often get in the way. They nudge you toward generic off-the-shelf metrics and fully automated evals before you've looked at your data."
Husain's alternative, documented in the August 31 update to his evals-skills resource, is to reverse the sequence. Examine real outputs first. Let failure modes emerge from annotating a real sample. Then build evaluation logic that measures the things you have actually seen fail. The eval tool becomes an amplifier for judgment already grounded in data, not a substitute for forming that judgment. His error-discovery skill, new in the August update, gives coding agents a structured way to do the initial sampling and categorization work that most teams skip.
Ball and Husain do not reference each other and are working in different parts of the AI stack. The convergence is structural: two practitioners, from different lanes, pointing at the same error in how professional defaults transfer from human to AI contexts.
- Thorsten Ball, Engineers who dismiss AI-generated code as low-quality apply the same professional bias that causes domain experts to over-intervene within their specialty. Engineers apply code review rubrics trained on human-authored work to agent-generated code, overweighting stylistic quality and underweighting the cost-per-capability gain of fast agent delivery.
- Hamel Husain, Eval tooling anchors teams on generic automated metrics before they have examined enough outputs to know what actually fails. Eval tool configuration interfaces anchor teams on generic quality metrics before they have examined their own system's actual failure modes, producing automated evals that measure what the tool designer prioritized.