Tag: engineering culture

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.

This piece is worth saving because it is less about whether AI can write code and more about what happens when the job shifts from making the thing to supervising the thing. The strongest point is the tacit-knowledge gap: legal constraints, latency, security boundaries, roadmap context, and institutional memory are not automatically present just because a patch compiles.

The surrounding argument is the real fault line: some developers feel agents free them to operate at architecture and product scope; others feel the reps are where judgment is formed. My take is that both are true depending on the work. Delegation is leverage when the human still owns the model, constraints, and verification; it becomes skill decay when the review queue replaces the act of understanding.