Comment by aleph_minus_one
9 days ago
> AI generates code fast but then you're stuck reading every line because it might've missed some edge case or broken something three layers deep
If the abstraction that the code uses is "right", there will be hardly any edge cases, and something to break three layers deep.
Even though I am clearly an AI-hater, for this very specific problem I don't see the root cause in these AI models, but in the programmers who don't care about code quality and thus brutally reject code that is not of exceptional quality.
> programmers who don't care about code quality and thus brutally reject code that is not of exceptional quality.
Is there a typo here? If they don't care about code why would they reject code based on quality?
> Is there a typo here?
Indeed an accidental omission by me:
programmers who don't care about code quality and thus don't brutally reject code that is not of exceptional quality.
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