One interesting trend to watch is how much vibe coding will be picked up by the engineering community.
I wholeheartedly agree with the following observation:
"Any engineering team that does code reviews and has multiple people working on the same project can’t sustain vibe coding practices."
At the same time, in our niche (a lot of early-stage product work), we use vibe coding for prototyping, sometimes even before we start actual collaboration with a client. As long as the basic assumption is that the code is entirely disposable, it's a fabulous tool.
Yet, any such experiments are necessarily isolated from the actual product code base.
That would suggest there's a hard limit to how much software developers could use vibe coding. And the reluctance to pick it up in the results shows that clearly.
The other cohort vibe coding tools try to target are non-technical people. In that case, we will have a technical limit. You can't vibe code a sustainable product without technical expertise. Even assuming a vibe coding tool could generate good enough code (which it reliably can't in the long run without supervision), one would have to explain enough technical context to make that happen. Thus, we get back to requiring technical expertise.
What follows is that the non-technical cohort will be limited as well. Ultimately, we can make all sorts of personal or pet projects, but not much commercial work in the long run.
So what does it mean to vibe coding in general and companies that bet their strategy on it (Lovable, Bolt, Replit, et al)?
Good observations! Right, it will be an interesting thing to see how the future of vibe coding will actually be. It made non-technical people closer to building products, but yet again, a lot of these people are contacting me and saying they need help with their product after some time.
I think the conclusion for now is: experiments, fun projects and MVPs. I don't see an actual scalable product being able to sustain that. As soon as you have more than 1 person working on the project, you need good practices in place.
Great insights and comparative analysis between 2024 and 2025. Thanks for sharing!
My pleasure Arvind! Glad they resonated.
One interesting trend to watch is how much vibe coding will be picked up by the engineering community.
I wholeheartedly agree with the following observation:
"Any engineering team that does code reviews and has multiple people working on the same project can’t sustain vibe coding practices."
At the same time, in our niche (a lot of early-stage product work), we use vibe coding for prototyping, sometimes even before we start actual collaboration with a client. As long as the basic assumption is that the code is entirely disposable, it's a fabulous tool.
Yet, any such experiments are necessarily isolated from the actual product code base.
That would suggest there's a hard limit to how much software developers could use vibe coding. And the reluctance to pick it up in the results shows that clearly.
The other cohort vibe coding tools try to target are non-technical people. In that case, we will have a technical limit. You can't vibe code a sustainable product without technical expertise. Even assuming a vibe coding tool could generate good enough code (which it reliably can't in the long run without supervision), one would have to explain enough technical context to make that happen. Thus, we get back to requiring technical expertise.
What follows is that the non-technical cohort will be limited as well. Ultimately, we can make all sorts of personal or pet projects, but not much commercial work in the long run.
So what does it mean to vibe coding in general and companies that bet their strategy on it (Lovable, Bolt, Replit, et al)?
Good observations! Right, it will be an interesting thing to see how the future of vibe coding will actually be. It made non-technical people closer to building products, but yet again, a lot of these people are contacting me and saying they need help with their product after some time.
I think the conclusion for now is: experiments, fun projects and MVPs. I don't see an actual scalable product being able to sustain that. As soon as you have more than 1 person working on the project, you need good practices in place.
Interesting data! Thanks for sharing!
Glad to hear that. My pleasure!