I think there's a few more reasons that the author doesn't mention.

1) It's actually harder to design things that are simple than complex - to take complex requirements, present and anticipated future, and to see the simple design hiding within. This is where you want senior engineers who have built up this expertise over time. As Mark Twain (but originally Blaise Pascal) once said "If I Had More Time, I Would Have Written a Shorter Letter".

2) There is a big tendency nowadays, not entirely bad, to treat projects as systems integration of whatever pre-existing parts can be had, and these parts themselves may bring complexity since they are made for more general use, and also be "impedance mismatched" since they were never designed to work together, therefore requiring glue and adaptors to make them work. Sometimes it's just better to write something suited to the task at hand than try to force something pre-existing to do something it is over-engineerd for, or not entirely suited for.

3) Resume padding. Software engineers like to use the latest greatest packages and techniques that everyone is talking about, and hiring companies are asking for, even if they are not that well suited to the project at hand. Sure, with some effort and extra code you may be able to incorporate some sexy new tech into your project, but it may be to the detriment of the project.

▲

efitz 3 hours ago | parent | next [-]

It's actually harder to design things that are simple than complex

This. In fact it’s often harder to even figure out what simple is until you actually try a bunch of things, and current corporate software methodologies don’t allow for iteration and experimentation to figure it out; you get one shot before the software’s even exists yet.

At the risk of veering off topic, I think the super power that vibe coding gives you is the capability to experiment quickly, so you can figure out how to simplify something.

▲

vbezhenar 3 hours ago | parent | next [-]

> At the risk of veering off topic, I think the super power that vibe coding gives you is the capability to experiment quickly, so you can figure out how to simplify something.

"Quickly" is relative. If you can produce software quickly, that'll become the expected speed, so it's no longer treated as quickly and we will get back to the same situation.

	▲	efitz an hour ago \| parent [-]
		I’m not suggesting that you vibe code the solution; I’m saying you vibe code the prototype.

▲

sublinear 2 hours ago | parent | prev [-]

While I do think there is some value to vibe coding, spending more time thinking about the final product is just as necessary and often lets you gleefully cut away many gordian knots.

Quickly exploring the implementation details is nice, but it's rare if they ever get in the way. What really gets in the way is shitty planning.

▲

conception 2 hours ago | parent | prev [-]

I like this - Hubert Humphrey (VP US) was asked how long it would take him to prepare a 15 minute talk: "one week". Asked how long to prepare a two hour talk? "I am ready right now".