I do the same thing in a project I’ve worked on for 25 years. I’ve had mediocre at best results with AI. It’s useful to discuss concepts with, but the code never handles the nuances of the edge cases.

Then they quit or die.

I work on internal facing software and every rewrite I've seen in 20 years suffers from the same symptoms. The code/system is a mess because it has been exposed to reality for a decade. Reality is messy. That's why they pay us money, believe it or not.

Greenfield guy comes in, promises the world, and starts from some first principles white papered architecture. It's really lovely until they onboard the first user. Then they slowly commit all the "sins" (features that drive revenue) of the first system.

The firm is stuck supporting N systems indefinitely because the perfect new system takes so long to cover even 30% of the original system use cases, that management takes a flier on.. bear with me.. a second rewrite. Now they have 3 systems.

I've seen more 3rd systems than I've seen actual decommissioning of original systems into a single clean new system.

The answer is chipping away, modularizing, and replacing piecemeal Ship of Theseus style. But that does not drive big hires and big promotions.

The bolded quote "It’s harder to read code than to write it." is hilarious given todays context... it has only become more true :)

That kind of self-awareness and humility (and therefore intellectual honesty) is unfortunately really rare in tech for some reason. I don't think there's a way to proactively cultivate it in those who don't have it--if someone has made it to the workplace without having developed it, it's probably too late--but I do think there are ways to select for it by culling those who don't have it when we smoke them out. We ought to do a lot more of that.

Experts take the time to learn why the fence was there in the first place.

Wait if they can do that they’re not juniors anymore :P