A view I have which feels controversial these days is that GenAI code tools are a net asset to code being held by entities that "should" hold them (ie workloads where code is a profit center not a cost center) and a net liability to the opposite. SaaS is a very squishy word and includes a lot things which are more accurate to call tech enabled services; Salesforce being one of the best examples (but you could say the same about many ERPs).
Maybe my biggest disagreement with your view is I think it is simultaneously far too conservative and far too aggressive at the same time. Where there was previously a decision about buy vs build, I disagree with the belief that many tech oriented companies will pull SaaS capabilities inside as GenAI developer tools improve because the cost of "build" is actually not going to get comparatively cheaper compared to the risk of "buying" - if anything, the risk of "building" internally with GenAI tooling that you were considering "buying" is significantly higher unless you are prepared to truly own it, that is go head to head with the entire rest of the market focuses on building and selling that tool as their full-time corporate focus. The actual risk of owning a tool internally making allowances for GenAI tooling is a lot higher than folks realize because GenAI tooling has a lot more risk of creating vibeslop and the only way to avoid that is to be dedicated to producing that tool as one's full time job and serving the needs of the entire market that needs it in that process. This is impossible to do with an internal tool.
The flip side of that same realization is why I also believe that your view is too conservative. The company that might be more empowered to consider building Salesforce internally with better tooling is not competing with Salesforce -- they are competing with the market that is going to /takedown/ Salesforce and a future version of themselves that would've used the future successor to Salesforce. Such a company is probably not in the business of building and selling CRMs although they are likely in the business of using such a CRM. The risk of making that conflation would be to stretch existing resources thin and turn the high interest credit card of tech debt and turn it into a payday loan with GenAI vibeslop.
I do not view GenAI as a democratizer. I view it as an accelerator with the capabilities to accelerate not just "winners take all" dynamics for the top companies that invest enough to avoid vibeslop, but "losers lose all" dynamics in the supply chain for everyone else who tries to wing it to capitalize before inevitably losing against future incumbents, or try in vain to turn a legacy firm into an innovator before inevitably losing against tech debt.
Everyone likes to believe they'll be able to use these great tools to become a future incumbent. But becoming a future incumbent is something that is very hard to do unless your org + book of business + funding + tools is better than someone else's org + book of business + funding + tools. That is why I don't think it actually changes the buy vs build decision that much; the decision should probably still be to buy, it's just changing the question of what exactly should be bought.
Excellent response. I think my position is that I don’t vibe code and most senior/deeply experienced dev/arch’s are doing something else.
We’re not coding. We’re orchestrating well constructed applications that follow proven principles (DDD, behavior focused, packaged business capabilities, behavior unit testing).
We’re extracting high value from GenAI.