> Less dependency management, less glue, less accidental complexity from adapting your problem to someone else’s abstraction.
Less maintenance and flexibility. You're not really "designing software" until you have a 20+ year old product.
Vibe coders really embody the "temporarily embarrassed billionaire" mindset so perfectly.
We are maintaining and extending a bunch (15 around) large ERP/data type projects which are over 20 years old with vibe coding. We have a very strict system to keep the LLMs in bounds, keeping to standard etc and we are feeling we are close to not having to read the code; we have over 2 months of not having to touch anything after review. I designed most of those projects 20-30 years ago; all have the same design principles which are well documented (by me) so the LLM just knows what to find where and what to do with it. These are large 'living' projects (many updates over decades).
This seems like an uncharitable take. Personally I would refrain from putting a 20 year barrier around the qualification, that seems a little harsh.
TFA's take makes sense in a certain context. Getting a high-quality design which is flexible in desirable ways is now easier than ever. As the human asking an LLM for the design, maybe you shouldn't be claiming to have "designed" it, though.
I was specific to the age of the product not of the age of the developer on that project. The point is that "high quality design" is such a fleeting thing that perhaps "longevity of design" is more worth having. It's also probably the case that the latter is much harder to come by which makes it a perfect barrier of qualification.
This is ridiculous. There are numerous multi billion dollar software companies with customers less than half that age.
Is there some reason to think that poorly designed software cannot be profitable? Perhaps we shouldn't use revenue as a proxy for quality?
More to the point how much of that profit is generated from selling those customers data rather than earning those customers payments?