I think the claims non-tech companies are going to be vibe-coding their own enterprise software are overblown.
The economies of scale and the diversion of focus away from their differentiators mean it won't make sense outside of marginal cases (it will of course add pricing pressure to software solutions though).
But what I think will happen is software is going to drift more towards a consulting arrangement.
The reduced cost of fresh builds is going to make it timely and economical enough for companies to hire consultants specialised in their niche, which maintain their own suite of custom software which they then integrate into those companies themselves.
I think we're seeing initial signals of this with the surging of the (goofy named) "forward deployed engineer" role.
Of course this is not as scalable as the classic SaaS play, and those multiples are going to be harder to get. One hopes this will in turn redirect more VC funding into hard tech.
I've spent most of my career working to simplify systems and processes, and the thing that's surprised me the most is how cool the reception usually is.
I think this is because professionally speaking it acts as a moat. By making something as complex as you are able you raise the participation costs of others.
The example I like to use is: it would never be in a lawyer's interest that the law be simple.
I think one factor is AI is encouraging people to turn off their brains.
It sometimes feels like AI chatbot use is like the doomscrolling of work - it's always easier just to dump something into the chatbot than think about it.
The real question is: what's the fallout going to be after the dust settles? My guess is that the explosion of codebase entropy now underway from this is going to make for an interesting future - once it reaches the point where AI agents are spinning constantly despite progress grinding to a halt.
And they're be no veterans who know the codebase deeply to step in and fix things because it was all vibecoded - and then what are companies going to do?
I think that's the point where they turn back to the thinkers for help.
Exactly. There's little gap between a spec that's been written to the level of detail needed and just code. There's some, but it's not a big gap after decades of umpteen new frameworks and languages and new forms of abstraction.
The core of the misunderstanding is between new builds and making changes to existing builds (where most software dev work actually happens). Yes, you'll get a great headstart with a detailed spec for a new build. The issue is in the hundreds of changes that'll follow that.
Do people think that the desire to make shortcuts and do minimum effort changes is going to stop just because you've got a bit-more-natural-language-looking spec? And then with an AI underneath making probabilistic changes to code that's now basically a compile target - they really think the dev pace isn't going to collapse, but just faster and with a big ongoing inference bill?
The LLM's do not form mental models. You are not going to get a better results from an LLM vibe coding against spec diffs vs a dev prompting it from a position of understanding the codebase and the requested change.
This ultimately converges on what source code is though.
The most common form of what you'd call a "spec" is the acceptance criteria on a work ticket, which is an accretive spec i.e. a description of desired change -- "given what already exists, change it as follows". I.e. if you somehow layered and summarized and condensed all tickets that have been made since product started, you'd have your "spec".
But it's the devs who were doing that condensing via understanding each desired spec addition vs reality of existing codebase.
So the gap between what people are currently calling "specs" what the code was already doing is not big and will not stay big, but for the fact you're effectively adding another (quasi) compile step underneath - and in this case its a non-deterministic one.
But I think even if it were purely leetcode-like, devs would actually be quite happy with this, since at least you'd only have to do it once and then it's re-usable for every application.
At the end of the day it doesn't really matter what our opinions of good screening are, but what the salary-payers are. Personally I just rely on live (& conversational) task-based coding tests.
Its purpose isn't really to test practical skills though, more just to screen for intelligence and conscientiousness (like a tournament who can take the most mental punishment), which are extremely useful in software development.
I think resumes will eventually (or have already) become obsolete in tech. The SNR is so low, they offer very thin filtering value.
Even taking the tiny bits of the resume that are "hard signal", like GPA, certifications, prior roles, etc, it doesn't translate into their performance in the initial screening interview.
This is why what I think the industry sorely needs is examination consortia.
Rather than trying to guess capability from the name of the university they went to, leading tech companies creating standardized tests in various fields, and your test scores form your "resume", so that developers can just focus on improving their scores rather than wasting time on resume/application/repetitive-screening toil.
It's more whether one allows oneself to be taken advantage of or not. Only a vocal minority take that stance, others would just be disappointed if it went away.
I like the approach ngrok took - made a v1 that remained open source, but once realized it had high demand, built v2 closed as a paid service.
Another approach is to offer professional services around it.
Basically it's very optional to accept the attitude of others that you should provide them value for free.
The economies of scale and the diversion of focus away from their differentiators mean it won't make sense outside of marginal cases (it will of course add pricing pressure to software solutions though).
But what I think will happen is software is going to drift more towards a consulting arrangement.
The reduced cost of fresh builds is going to make it timely and economical enough for companies to hire consultants specialised in their niche, which maintain their own suite of custom software which they then integrate into those companies themselves.
I think we're seeing initial signals of this with the surging of the (goofy named) "forward deployed engineer" role.
Of course this is not as scalable as the classic SaaS play, and those multiples are going to be harder to get. One hopes this will in turn redirect more VC funding into hard tech.