Which is fine, don't get me wrong. But that would be like if someone wants to work as an automotive engineer, but they only enjoy driving a car. It doesn't work that way. You should enjoy the entire process of manufacturing a car if you want to drive a good one. Sure, you may enjoy some tasks more than others, and this is fine, but you can't ignore the ones you don't. Otherwise you're only doing a disservice to yourself, your team, and the users of what you build.
> Doesn't mean I don't care about code quality, or good abstractions and having a reasonable design/architecture. But I'm focused on the end goal, having a particular problem solved, and coding is just the way there (sometimes).
But coding is just the mechanical part of building software. It's the last step of the process after everything you mentioned is taken into consideration. Everything else is how you ensure that you reach the end goal successfully. So saying that the end goal is your main focus doesn't make sense if you want to actually reach it.
This is why I think that people who enjoy vibe coding today, are not, and will never become software engineers. They want to fast track to the end goal by jumping over the parts that are actually important. Blindly accepting whatever a code generation tool spits out if it passes a quick manual happy path test is not engineering. It's something else that produces much inferior results. At least until these tools get much, much better at it, which still seems far away, and unlikely with the current tech.