AI Coding Weekly Review:
Three Months Later, Which JudgmentsStood the Test of Time

In April 2026, EP.81 recorded three signals at the time: the MirrorCode benchmark jointly released by Epoch AI and METR showed that Claude Opus 4.6 completely re-implemented a 16,905-line Go tool without source code, with four engineers estimating a human would need 2–17 weeks; GrandCode surpassed all human contestants in a Codeforces Div 1 live competition; App Store new app submissions surged 84%. Piecing these three signals together, the judgment given at the time was: "AI coding's time horizon has leaped from minutes to weeks," with a predicted window of 18–24 months.

Looking back three months later, this "week-level" scale holds up, but it is no longer the frontier coordinate. The concurrently published "Long-Horizon Task Frontiers" on this site recorded how benchmarks like FrontierSWE and SWE-Marathon re-cut the evaluation unit to "hours"; "Agent Engineering Evolution" recorded Kimi K2.6's 12-hour continuous autonomous operation and MiniMax M2.7's hundred-round self-modification with no human intervention. The "2–17 weeks" case that MirrorCode prided itself on, in the context three months later, looks more like an upper-bound case of "given an extremely long budget, single execution," rather than the norm of "continuous, multi-round, cross-session autonomous work"—the latter is the dimension the industry is truly competing on next. EP.81 wasn't entirely unaware of this at the time: it cited Epoch AI's statement that "larger-scale projects are not impossible, they just require larger inference budgets," but didn't anticipate that the window would narrow much faster than the "18–24 months" it had given.

EP.84 recorded two starkly different corporate AI-native strategies in the same week: Amazon chose the augmentation path—rolling out Claude Code and Codex to all employees, with no layoffs, putting every engineer in "Karpathy's意义上的 Iron Man exoskeleton," retaining human judgment while amplifying execution power; Coinbase chose the rebuild path—laying off 14% of staff, compressing the organizational structure to under 5 layers, rebuilding as "one-person multi-role AI-native squads," betting that AI could handle the workload of multiple people. It also recorded Simon Willison's unease about "the blurring boundary between vibe coding and agentic engineering," and Tom Tunguz's warning—a 3-person team driving 20 agents, where one departure means a 33% loss of institutional memory.

Three months later, there is no follow-up data in the vault to determine which organizational bet is better—that itself is an honest signal: the payoff cycle of organizational strategy is far longer than the window a single weekly note can verify. But the analytical framework proposed at the time still holds: the augmentation path assumes human judgment is scarce and AI is leverage; the rebuild path assumes workload is substitutable and labor cost is a variable. This fork has not disappeared over time; instead, it has become more prevalent in the second half of 2026—almost every company seriously investing in AI coding has to choose between these two paths, except no case has run long enough to prove itself right. The more隐蔽 question Robert Glaser raised at the time—"individual efficiency gains do not equal organizational capability accumulation"—currently remains unresolved, and may forever remain unresolved as a structural contradiction, rather than a technical problem that the next model upgrade will solve.

The signals recorded in EP.85 looked the most "technically trivial": the k10s project author used Claude over 30 weekends to build a Kubernetes dashboard, with efficiency once reaching 10x that of hand-written code, but after the Model layer ballooned to 1,690 lines no one could safely modify it anymore, and the author ultimately gave up and returned to hand-writing; software engineering expert James Shore concurrently proposed a framework—AI tools' advertised ROI usually only counts "generation speed," while ignoring that 60% of true software cost comes from maintenance; open-source projects like RPCS3 publicly complained about AI-generated "junk PRs" flooding in, with review costs skyrocketing while the proportion of genuinely valuable contributions declined. The three cases all point to one sentence: "We're using AI to produce code, but not using AI to manage code debt."

Looking back three months later, this is precisely the most time-tested judgment among the three weekly notes—because it is not describing an accelerating capability curve (which will be surpassed by the next release), but a structural trade-off (generation gets faster, but the review and maintenance bottleneck does not automatically get faster along with it). It can even be said to have pre-named a phenomenon that was only explicitly conceptualized later: in this site's "Loop Engineering" article, Google's Addy Osmani proposed comprehension debt—when an unattended loop modifies hundreds of lines of code in a repository, software generation speed exceeds the team's review capacity, and developers inherit a codebase where "underlying design decisions, structural dependencies, and edge cases are all blank." EP.85 told the same story through the collapse of a specific k10s project, just without this name at the time. This suggests a pattern: in weekly snapshots, the easiest thing to falsify is "how fast progress is," and the easiest thing to verify is "where problems will arise"—the former refreshes with every model release, the latter is engineering common sense and rarely expires.