I think so. Recently a friend contacted me who vibe coded a CRM. He asked if I would be open to join their startup as a CTO, because their company is growing and he doesn't know anything that's going on in the app, technically.
How data is actually stored, how some reports are calculated. Everything works for them at the moment, but he is aware that he doesn't have the technical knowledge to know all that's going on.
They plan to scale, introduce more sensitive features to their clients, and they can't afford to rely on vibe coded features. There should be a person who is responsible for what's going on, and has the capacity to navigate these questions.
I imagine it would be easy for him to learn this profession, but doesn't look like that's one of his interests. Well, anyway, yeah, think the profession is not going anywhere.
Yeah agree with you. Another important aspect is that if I can build a product in, let's say, 2 to 3 weeks by vibe-coding, then I don't think this has any impact or any sort of value. Anyone can build the same thing, maybe in 3 to 4 weeks.
I think that's not an achievement for me as I have not spent any sort of effort on this. The products which used to take months are now possible in weeks and it's easier to replicate now.
What I am thinking is that the future might be that software will be free and the users will be paying for the infrastructure or pay-as-you-go stuff.
I think the architecture and structure of a code base, is just as important when using an LLM. A poorly structured code base will become technical debt, be difficult to further develop, and full of subtle bugs.
People are thinking "well it doesn't matter because the LLM will sort it out eventually" but someone with an LLM and good architecture will still be much faster and produce better software.
what I've found from working on vibe (https://github.com/fluffynuts/vibe) and using it as a daily driver for work, is that you can't reliably one-shot _anything_. Absolutely key is getting an agent to run a review, and then understanding the findings, and being able to decide on fixes, even if the agent does the actual fixes. On top of that, they're not so great at UX - there are plenty of paper-cuts I've had to point out manually, to get fixed - bots are missing the human interaction factor, and that really matters (I sound like claude, lol) when you have a product that's facing a real user.
In addition, I've found a good working agreement (supported in vibe via global agent instructions) and local working hints/agreement (supported in vibe via workspace agent instructions) really help - the global agreement lays out your expectations for the agent, the local one is for workspace-specific things, like instructions on how to test within the sandbox, or reminding the agent that if they need a tool they can get from apt, in the sandbox, they should just get it and carry on, not stop with text like "I don't have ffmpeg in this sandbox"
Some of the above may not impact users raw-dogging an agent as much - whatever is on the host system is up for grabs - which is exactly why I tell people not to raw-dog agents - the file and network "rules" they're given are basically just hints that the agent will work around if tasked to complete something - as all the cross-provider hacks have shown, as well as forensic analysis of agents working on a local machine (eg, caught reading all of /proc, so all those secrets you had on environments for other processes? not so secret any more).
Anyway, to come back again: yes, some kind of engineering is still required. I like to think of agents as proficient JUNIOR coders - they know the syntax, they understand what packages to use, etc, but they aren't great at designing architecture - just copying bits that they've seen. You need to be steering them if you don't want to end up with something full of holes. Most of the issues can be caught in review - agents are way better at spotting their own mistakes than humans are - but I think that's a crucial step people are missing - they tell the agent "BUILD X", and then they get something that looks like it works, and get excited enough to push to prod with glaring security holes.
I think so. Recently a friend contacted me who vibe coded a CRM. He asked if I would be open to join their startup as a CTO, because their company is growing and he doesn't know anything that's going on in the app, technically. How data is actually stored, how some reports are calculated. Everything works for them at the moment, but he is aware that he doesn't have the technical knowledge to know all that's going on. They plan to scale, introduce more sensitive features to their clients, and they can't afford to rely on vibe coded features. There should be a person who is responsible for what's going on, and has the capacity to navigate these questions. I imagine it would be easy for him to learn this profession, but doesn't look like that's one of his interests. Well, anyway, yeah, think the profession is not going anywhere.
Yeah agree with you. Another important aspect is that if I can build a product in, let's say, 2 to 3 weeks by vibe-coding, then I don't think this has any impact or any sort of value. Anyone can build the same thing, maybe in 3 to 4 weeks.
I think that's not an achievement for me as I have not spent any sort of effort on this. The products which used to take months are now possible in weeks and it's easier to replicate now.
What I am thinking is that the future might be that software will be free and the users will be paying for the infrastructure or pay-as-you-go stuff.
I think the architecture and structure of a code base, is just as important when using an LLM. A poorly structured code base will become technical debt, be difficult to further develop, and full of subtle bugs.
People are thinking "well it doesn't matter because the LLM will sort it out eventually" but someone with an LLM and good architecture will still be much faster and produce better software.
Yoda: "The Dark Side clouds everything. Impossible to see, the future is".
yes, totally
what I've found from working on vibe (https://github.com/fluffynuts/vibe) and using it as a daily driver for work, is that you can't reliably one-shot _anything_. Absolutely key is getting an agent to run a review, and then understanding the findings, and being able to decide on fixes, even if the agent does the actual fixes. On top of that, they're not so great at UX - there are plenty of paper-cuts I've had to point out manually, to get fixed - bots are missing the human interaction factor, and that really matters (I sound like claude, lol) when you have a product that's facing a real user.
In addition, I've found a good working agreement (supported in vibe via global agent instructions) and local working hints/agreement (supported in vibe via workspace agent instructions) really help - the global agreement lays out your expectations for the agent, the local one is for workspace-specific things, like instructions on how to test within the sandbox, or reminding the agent that if they need a tool they can get from apt, in the sandbox, they should just get it and carry on, not stop with text like "I don't have ffmpeg in this sandbox"
Some of the above may not impact users raw-dogging an agent as much - whatever is on the host system is up for grabs - which is exactly why I tell people not to raw-dog agents - the file and network "rules" they're given are basically just hints that the agent will work around if tasked to complete something - as all the cross-provider hacks have shown, as well as forensic analysis of agents working on a local machine (eg, caught reading all of /proc, so all those secrets you had on environments for other processes? not so secret any more).
Anyway, to come back again: yes, some kind of engineering is still required. I like to think of agents as proficient JUNIOR coders - they know the syntax, they understand what packages to use, etc, but they aren't great at designing architecture - just copying bits that they've seen. You need to be steering them if you don't want to end up with something full of holes. Most of the issues can be caught in review - agents are way better at spotting their own mistakes than humans are - but I think that's a crucial step people are missing - they tell the agent "BUILD X", and then they get something that looks like it works, and get excited enough to push to prod with glaring security holes.