Comment by friendzis

> Competent engineers understand tradeoffs and the importance of creating and managing technical debt.

I would disagree on the engineering point, as this ultimately falls on project management. Yes, engineers should provide professional expertise, but if management decides to yolo then engineers do not have the capacity to remove tech debt, regardless of their competence. Management of technical debt is, at the end of the day, managing short term versus long term velocity.

> Things don't happen in a vacuum, and your hypothetical "fragile interfaces" that you frame as being a problem are more often than not a lauded solution to quickly deliver a major feature.

Nothing I said disagrees with this, however that quick delivery of a major feature has downstream effect: anything that touches said feature is harder / slower / error-prone to implement. The more the team embraces "move fast and break things" the harder the wall it hits. Slower teams tend to be consistently average. Neither is better and this competence in managing technical debt is more often than not coupling/decoupling over fragile/robust interfaces.

This shows in LLM coding assistant use. Drop them in a well structured codebase and they implement features relatively well. Drop them in a bowl of spaghetti and they hurt themselves over confusion. With LLM coding assistants becoming more prevalent this managing of tech debt becomes even more important topic. You just cannot tell the LLM "pls implement well, no tech debt bro" or "yolo this, move fast, make it work 80% of the time".

If my career has taught me anything is that it takes competent engineering to push back against management pushing for every possible shortcut. A worry here is that detachment from the final output will reduce buy-in and produce "bad" code that will eventually grind feature velocity to a halt.