Can 100% confirm this from own experience! I've been the most productive (by far more than "10x") using my own set of tools, which have been created & refined by continuous praxis (dogfooding) and employed for hundreds of use cases over many years, and also partially followed me across different programming languages.

Unfortunately, many sectors of the software industry have succumbed to a formulaic paint-by-numbers approach to general "problem solving", which almost always exclusively relies on a handful of large frameworks, and with very little appetite remaining for any alternative approaches (maybe even more efficient and easier to maintain)... It's not just technology choices, but design processes/disciplines themselves too. Monopolies & monocultures everywhere, willingly adopted and encouraged, justified via more shallow learning curves, oversimplifications/mainstreaming, supposedly better hiring/career options and other self-selected network effects...

I noticed the software industry had already gotten into a rut ~10-15 years ago, way before the agentic vibe coding steamroller... Maybe due to overeager (and partially uninformed) adoption of design patterns, maybe due to the lack of caution understanding the impacts of introducing increasing amounts of complexity and dependencies, maybe because of the shortening attention spans caused by sprint-based work cultures (which only prioritize short-term goals) and the aforementioned unchallenged routine use of conceptual, architectural and code frameworks... Probably it's all of the above (and more)...

In short, had more industry players invested long-term into tailored tool building as part of their business, I think vibe coding would have had a lot less impact than it had so far. Defenders of LLM coding are frequently claiming the models are helping them to severely cut down on boilerplate and configuration tasks. This is unarguably a big win indeed! However, I also think the reason why so much boilerplate exists in the first place is exactly because of the points I listed above.

Using ye olde "hammer in need of nails" metaphor, so many orgs are attempting to solve all their tasks/projects via a handful of preexisting products/frameworks (and/or LLMs trained on materials which are statistically biased to produce better generated outcomes for these frameworks, a separate discussion).

The industry at large has been reduced to monolithic solutions, with layers and layers of customization via configuration piled on top. It's non-scalable & non-optimizable structurally and it's the wrong way to achieve/improve efficiency (or even proficiency) in your actual problem domains. It's also incomparable to the efficiency gains possible when designing & using a truly custom set of tools, including actually designing for bottom-up re-use & re-composition.

(Apologies for the wall of words)

#Software #Productivity #Architecture #Design #Frameworks #Monopoly