The way I see this is that it's just another skill differentiator that you can take advantage of if you can get it right.
That is, if it's true that abstraction and architecture are useful for a given product, then people who know how to do those things will succeed in creating that product, and those who don't will fail. I think this is true for essentially all production software, but a lot of software never reaches production.
Transitioning or entirely recreating "vibecoded" proofs of concept to production software is another skill that will be valuable.
Having a good sense for when to do that transition, or when to start building production software from the start, and especially the ability to influence decision makers to agree with you, is another valuable skill.
I do worry about what the careers of entry level people will look like. It isn't obvious to me how they'll naturally develop any of these skills.
The fact that you called it out as a PoC is already many bars above what most vibe coders are doing. Which is considering a barely functioning web app as proof that vibe coding is a viable solution for coding in general.
> I do worry about what the careers of entry level people will look like. It isn't obvious to me how they'll naturally develop any of these skills.
Exactly. There isn't really a path forward from vibe coding to anything productizable without actual, deep CS knowledge. And LLMs are not providing that.
Yeah I think we largely agree. But I do know people, mostly experienced product managers, who are excited about "vibecoding" expressly as a prototyping / demo creation tool, which can be useful in conjunction with people who know how to turn the prototypes into real software.
I'm sure lots of people aren't seeing it this way, but the point I was trying to make about this being a skill differentiator is that I think understanding the advantages, limitations, and tradeoffs, and keeping that understanding up to date as capabilities expand, is already a valuable skillset, and will continue to be.
If you're really prototyping a product, a simple mockup with a tool like Balsamiq can get you quite far for communication and ideation. But more often, when people want a live prototype, it's because they plan to spin some lies as "sales and marketing".
What I've seen people use it for to, in my opinion, great effect is to demonstrate capabilities that exist, but for which there are many different possibilities for how to combine and present them to users.
Sure, you can just put together a clickable mock up like people have been doing for years, but putting together functional UIs that call out to existing APIs but cobble them together in different ways, that's actually less smoke and mirrors sales spin.
That is, if it's true that abstraction and architecture are useful for a given product, then people who know how to do those things will succeed in creating that product, and those who don't will fail. I think this is true for essentially all production software, but a lot of software never reaches production.
Transitioning or entirely recreating "vibecoded" proofs of concept to production software is another skill that will be valuable.
Having a good sense for when to do that transition, or when to start building production software from the start, and especially the ability to influence decision makers to agree with you, is another valuable skill.
I do worry about what the careers of entry level people will look like. It isn't obvious to me how they'll naturally develop any of these skills.