The 80% Problem: The Last 20% Is Where the Engineer Used to Live

chilipepperhott

Ironically, this post reeks of Claude. > Generative AI hasn’t repealed this rule. It’s relocated it

raychis

This is a good thesis but it does lean a bit too hard on a vague 80/20 metaphor. It kind of romanticises old-school engineering struggles while downplaying how much of past learning was just wrestling with crappy tooling or poor docs. Things are much better now, I wouldn't want to go back. The stronger argument would not just be the old way is better, but that we need a way to preserve judgment that used to be developed through the struggle.

senderista

Slop about slop.

sublinear

The answer is simple. Stop working for "big tech" and SV startups. They're the only ones leaning into AI this hard. Find a role maintaining services instead of scrambling to build shiny new products, and you'll have what you want. There is plenty to do. The last decade of "move fast and break things" broke a lot of things. The work is challenging and rewarding. You're not cleaning up slop. You're not being given so much rope to hang yourself. You will work with people that have been there for decades. They are not all backwards thinking corporate Java devs.

felix-the-cat

"They cluster around exactly the parts of engineering that take sustained operational experience, the idempotency key that keeps two racing requests from corrupting state, the backoff and jitter that keep a retry from turning into a stampede, the migration written to dodge a long table lock, the rate limiter, the circuit breaker, the structured log that makes the eventual failure diagnosable at 3am." But these are things that the AI actually knows how to do just about as well as regular developer would. I run into these problems all the time working on a trading platform and AI is quite good at solving these issues and discussing them if you have questions or providing a collection of strategies you can choose from.