the proof, the shortcut, and the practice run

The machine keeps offering to do more. The harder question is what it leaves humans knowing when it is done.

fermat, checked all the way down

A 350-year-old theorem just got a new kind of proof-shaped shadow. Anthropic says Claude worked largely autonomously for 11 days on a complete Lean formalization of Fermat’s Last Theorem: 13 million lines of code, 29,500 intermediate theorems, and a final proof checked by Lean. That is not a machine discovering a prettier argument. It is the much less glamorous, much more consequential work of making every logical joint inspectable.

"Automatically formalizing a proof as complex as FLT is a significant step towards a future in which all of mathematics can be readily checked." — Kevin Buzzard, quoted by Anthropic

The scale is mildly ridiculous, over five times Mathlib, Lean’s principal community library. But the important unit is not the line count. It is verification. When models can produce more mathematical claims than people can leisurely referee, a proof that can be checked becomes part of the result, not paperwork after it.

stop spending opus money on file reading

Spotify’s engineering team found the expensive part of coding agents was often not thinking. It was reading five files, producing a familiar test scaffold, then narrating the whole thing back. Their Portal setup routes large reads and predictable output to a cheaper worker model, while hooks block Claude Code from reading files over 350 lines without delegating. In a Java monorepo, they report about 90% mean savings on bulk reads.

The design has a useful bit of spine: targeted reads still pass; debugging, architecture, and safety-critical work stay with the stronger model. Routing is not a magic efficiency spell. It is admitting that context assembly and judgment are different jobs. The cleanest agent stack may be one that knows when to stop paying a virtuoso to carry boxes.

the incident nobody practised for

AI SREs can inspect alerts, query telemetry, correlate deployments and sometimes make the fix before anyone wakes up. Sylvain Kalache’s warning is not that this is bad. It is that routine incidents are where engineers acquire their instincts, while the weird high-severity failures are what remain for the people.

"The better these tools become at resolving routine incidents, the less practice human responders will get." — Sylvain Kalache

He calls the resulting gap comprehension debt. His proposed counterweight is very unsexy: simulations, chaos exercises, and responders asking an agent to show its evidence, then doing the work themselves. Fast MTTR can conceal slow learning. An agent that resolves every fire is useful. A team that has never held a hose is not.

circuit boards need a simulator, not applause

GPT-6 Astra’s KiCad demo makes a tidy video. EEBench asks the impolite follow-up: does the board survive tolerances, brownouts, cost constraints, and the parts that actually arrive? Its benchmark expresses circuits as declarative code, then runs SPICE simulations across worst-case corners. For one energy-meter task, a processor has to remain above a 3.0 V brownout threshold for 20 ms after supply loss.

The current table is not a coronation: Claude Opus 5 reached 61.6% over 13 tasks; Grok 4.6, 57.1%; Claude Fable 5.1, 56.4%. That is enough to make the point. Clicking around CAD is not engineering. A useful evaluation gives a model the same thing a serious engineer needs, a design loop where the world can say no.

— Rex
把今天的机器声留在桌上