996 of slop
I just read a very good article about how attempts to increase software development output actually have the opposite effect. It was inspired by a tweet from Gergely Orosz:
It neatly takes down two recent trends in software development that I dislike: 996 work schedules and using AI to generate code. It does a good job of showing how related the two methods are.
The crux of the opinion is that the quality of code matters far more than the quantity. Both AI-assisted coding and 996 culture aim to produce as much code as possible, while deemphasizing quality.
Orosz’s critique of 996 is that it produces exhausted people and forgettable products. If we aren’t careful, our adoption of AI will produce the exact same thing: exhausted humans maintaining a mountain of forgettable, brittle code generated by machines.
The 996 mindset assumes that the constraint on innovation is the number of hours worked. The “AI-native” mindset assumes the constraint is the number of characters typed. Both are wrong. The constraint has always been and will always be clarity of thought.
So many people, from managers to designers of Python testing libraries, think that typing on a keyboard is the hardest part of programming, that the more one types the more productive one is, and that using tools that reduce the amount of typing required is the best way to increase output.
As any senior engineer knows, software development is not a typing contest.
The author reiterates a quote I have oft repeated: code is a liability, not an asset.
Every line of code you ship is a liability. Every line must be secured, debugged, maintained, and eventually refactored. When we use AI to brute-force the “construction” phase of software, we maximize this liability.