I agree, good software engineering is largely about making good trade-offs.

However, I completely disagree with your characterization of LLM coding as saving you "typing in the code and sweating over every line of syntax".

Claude will happily architect complex layers of OOP, multithreading, SIMD (a "personal favorite" of both Claude and ChatGPT).

If you don't immerse yourself in the details, you will never know if you made the correct engineering trade-offs, let alone whether the various "optimizations" and clever solutions by the LLM actually work.

I think you're referring more to product strategy trade-offs than engineering trade-offs here; so yeah, getting something you don't understand out the door is often the fastest path to sales. This is also how we get so much low quality and unnecessary software out there (it was true before LLM coding, just amplified now).

I think a reasonable tradeoff, in theory, would be: use the LLM to help you explore the space of solution, then dive into the details and choose the path that feels right. However, I highly doubt most people do that. It's also easy to let the LLM's first solution influence your understanding of the problem, so that you will never truly explore novel solutions that fall outside of the most likely token sequence prediction.

Oh and LLMs when properly constrained can also do pretty good "auto-complete on steroids", which can definitely save you typing a lot of boilerplate. If that's how you use them, then your characterization is correct.