---
title: 'In the News: August 9, 2026 (Evening)'
description: "HumanLayer's Dex Horthy gives the first first-party account of a lights-off software factory that failed, and says the fix is putting code review back."
canonical_url: 'https://darkfactory.dev/news/2026-08-09-evening'
markdown_url: 'https://darkfactory.dev/news/2026-08-09-evening.md'
collection: news
date_published: '2026-08-09T20:15:00-04:00'
date_modified: '2026-08-09T20:15:00-04:00'
---

# In the News: August 9, 2026 (Evening)


HumanLayer went fully lights off on its own codebase in July 2025, hit a bug its coding agent could not solve even with its best prompting, and shut the experiment down. Dex Horthy told that story on stage for the first time this week and argued that the failure lives in how coding models are trained, not in the harness around them. Mario Zechner described stripping his coding agent down to four tools, while Command Code published internals for a read tool engineered to survive fifty million reads a month.

## 1. HumanLayer's Dex Horthy: we tried lights off in July 2025, and it failed

**[Harness Engineering Is Not Enough: Why Software Factories Fail](https://www.youtube.com/watch?v=Ib5GBkD555M)** · Dex Horthy, HumanLayer · AI Engineer, published 2026-07-23

Horthy told the room that HumanLayer ran its own codebase fully lights off, no human reading the code, starting in July 2025, and stopped after running into an issue its most advanced prompting could not resolve (8:18). His argument is that this is not a scale problem: no amount of additional harness or loop engineering can fix it, because the fault sits in how coding models are trained. He traces it to how benchmarks like SWE-bench score a training run, a binary pass or fail on whether tests pass, which gives a model no signal to penalize poor architecture along the way (12:43 to 13:08). He names three newer benchmarks trying to close that gap, SWE Marathon from Abundant AI, Deep Suite from Data Curve, and Frontier Code from Cognition, and says plainly that no good benchmark for a model's ability to maintain codebase quality exists yet (9:47). His prescription is to put code review back: a short upfront pass on product intent, system architecture, program design, and the order of implementation, which he says can turn hours of review into something closer to reading text you already agreed on (15:00 to 17:00). Auto-generated captions throughout; paraphrased rather than quoted per this lane's transcript rules.

**Why it matters:** This is the first first-party account in this lane of a real "lights off" factory that failed, from the company most associated here with pushing the idea. It gives a concrete reason to keep a human reading code beyond a general discomfort with autonomy.

## 2. Mario Zechner explains why he stripped his coding agent to four tools

**[I Hated Every Coding Agent, So I Built My Own](https://www.youtube.com/watch?v=Dli5slNaJu0)** · Mario Zechner, creator of Pi · conference talk, published 2026-03-31

Zechner's coding agent, Pi, ships four tools: read, write, edit, and bash. No MCP, no sub-agents, no built-in plan mode, no background bash, no built-in todo list; his standard answer for each is to write it as a file or spawn it in tmux instead (18:15 to 22:37). He grounds the minimalism in TerminalBench, where Terminus, an agent whose only interface is keystrokes into a tmux session, performs near the top of the leaderboard, which he reads as evidence that feature surface may not be what makes an agent perform well (16:07 to 17:36). He names a specific harness failure mode worth watching: OpenCode's per-turn session compaction prunes tool results before the last 40,000 tokens, which destroys the prompt cache, and he ties that directly to friction between Anthropic and OpenCode over infrastructure use (11:37 to 12:40). He also argues against approval dialogues as a safety mechanism on the grounds that they cause fatigue and get rubber-stamped, preferring containerization instead (21:01 to 21:15), and against feeding LSP errors back to the model mid-edit, since an unfinished edit is not a bug (12:52 to 14:08). Auto-generated captions throughout; paraphrased rather than quoted.

**Why it matters:** Pi is a working counterexample to the assumption that more tool surface makes a harness more capable. If you are deciding what to build into your own harness, Zechner argues for a smaller default.

## 3. Command Code's Ahmad Awais opens up a read tool built for 50 million reads a month

**[How our read tool saves billions of tokens vs Claude Code](https://x.com/MrAhmadAwais/status/2086521445694517404)** · Ahmad Awais, Command Code · X, August 9, 2026

Awais rebuilt Command Code's `read_file` tool for its v1 release and benchmarked it capability by capability against nine other harnesses, including Claude Code, OpenCode, and Pi. By his own count, Command Code handles roughly 50 million file reads a month; his estimate, which he calls "napkin math," puts wasted context from unneeded content at around 25 billion tokens a month if a read tool has no limits. He describes three stacked size limits, a line window, a byte budget, and a per-line character clamp, each catching a different shape of oversized file that the others miss. A "self-expiring" cache deletes its own cached record the moment it is used, because a stale cache hit pointing at content the model can no longer see is worse than a cache miss. The tool also refuses to let `write_file` overwrite a file the model has only partially read, a bug class Awais says no per-field input validation could have caught since it lives in the relationship between two tools. The whole piece doubles as marketing for Command Code, positioned by name against Claude Code throughout, and its comparison table and token figures are self-reported and unverified by anyone outside the company.

**Why it matters:** vendor framing aside, the specific failure modes here, a stale cache pointing at deleted content and a write blocked by an unseen partial read, are the kind of bug that shows up in any harness built around file tools, and are worth checking for in your own.