Comment by the_harpia_io
9 days ago
I mean in theory yes, good abstractions solve a lot - but in practice you're rarely starting from a clean slate. you're integrating with third-party APIs that have weird edge cases, working with legacy code that wasn't designed for what you're doing now, dealing with requirements that change mid-implementation. even with great abstractions the real world bleeds through. and AI doesn't know which abstractions are 'right' for your specific context, it just pattern-matches what looks reasonable. so you end up reviewing not just for bugs but to make sure it's not subtly incompatible with your architecture
Good abstractions only get you easy wins for some percent of the desirable tasks. They never guarantee 100% edge case unless trivial.
Choosing wrong means huge tech debt. Choosing righr just means most of your code will be happy path, and a few will need escape hatches. Not because of the abstract but because the target problem shifts uncontrollably. Because the problems you are solving typically require multiple abstractions and they are going to meet at the edges in the best case.
yeah the escape hatch accumulation is the real problem - starts as like 2 edge cases then just grows. I think the worst outcome is when you realize 6 months in that the abstraction was kind of wrong for your use case - now every new feature is fighting the grain of the code AND you've got a pile of special cases on top. at some point maintaining the abstraction layer itself becomes the work