I think both can be true. I practice and encourage “solving for a class of problem,” but typically where I see people generate technical debt is when attempting

I think both can be true. I practice and encourage “solving for a class of problem,” but typically where I see people generate technical debt is when attempting to apply that advice to domain/business logic that isn’t and shouldn’t be very abstract. Apply it to the things that make your app go, such as white-labeling or bulk inserts. Do not apply it to things like your new employee groups feature or payroll calculations. Applied to those you just add additional and arbitrary rules that have to be obeyed or else the abstraction begins to leak. And it always leaks.