I build software, data, and AI systems anchored to measurable product outcomes — applications, agent workflows, and simulations of how customers actually behave.

Gwern's proposal is useful because it asks a sharper question than "can agents write more code?" It asks what kind of software substrate would let code, proofs, docs, tests, and design intent scale together instead of drifting apart as the system grows.

That belongs near the agent-workflow links. If code generation keeps getting cheaper, the bottleneck moves toward specification, review, interfaces, invariants, and machine-checkable confidence. Lean is not a magic management layer, but this is the right direction of pressure: make the important claims in a codebase inspectable by tools, not merely implied by convention.

Steve Krouse makes the case I still buy: learning to code is less a guaranteed career coupon now and more a literacy for thinking precisely with computers. The strongest angle is educational, not nostalgic. Code teaches decomposition, feedback loops, debugging, abstraction, and the habit of turning a blurry desire into an executable system.

The Hacker News thread adds the necessary cold water. Most production programming is craft and maintenance, not pure art, and time spent learning code competes with every other skill. That actually sharpens the case in the AI era: if tools can generate more code than ever, the scarce skill is understanding enough to steer, inspect, repair, and refuse the output. You do not learn programming to beat the machine at typing; you learn it so the machine is not the only one in the room with a model of the work.

This is a useful designer's notebook on software quality because it pushes quality out of the narrow "does it work" box and back into the felt experience of using a product. Speed, clarity, reliability, craft, and the absence of papercuts all matter, even when they do not show up as a failing test.

The Hacker News pushback is worth keeping next to it: quality is not only the absence of visible problems. It is also resilience under harder conditions, maintainability, security, and the cost of change. The mature version combines both views: users feel polish at the surface, while teams feel quality in how safely the system can keep evolving.