Comment by locknitpicker
1 day ago
> You not only stumble upon a weird bug in your hacky solution that takes engineering weeks to debug, but your interfaces are fragile so feature velocity drops (bugs reproduce and unless you address reproduction rate you end up fixing bugs only) and things are so tightly coupled that every two line change is now multi-week rewrite.
I don't think you fully grasp the issue you're discussing. 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.
The calling card of junior developers is looking at a project and complaining it's shit. Competent engineers understand tradeoffs and the importance of creating and managing technical debt.
This has always been true. I just don’t see how AI makes accumulating tech debt more attractive, as the original poster seems to be implying. If anything it seems to make things worse. At least when you write shit code by hand you know it so you can remember to go back to it, keep it in mind as a potential source of bugs. But YOLO from AI and you probably have no idea.
> 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.