In some cases, I do not trust it to write code unchecked, and review everything it produces (which does not imply I catch all bugs, obviously).
In other cases, occasional failure is an option, and the speed you get by iterating fast is absolutely worth not even looking at the code.
So, do I trust this to write working code? Sometimes I do.
If I'm doing work for a client, it is not very common for me to simply vibe code something, because part of what clients expect of me is high quality (it's part of how we position ourselves), and I cannot simply assume the LLM will produce high quality (and indeed it does not without a lot of guidance). When I do vibecode in such cases, I make it clear that I did so and why (e.g. because it's a tool to be used in the project to help DX, not a core part of the product). Still, I haven't written 10 consecutive manual lines of code in almost a year.
If I'm working on something for myself, or on an internal product, then vibe coding is absolutely allowed and sometimes the norm. Here often we really do care about finding the right thing to build first.
You can clearly feel the tipping point where the LLM starts to crumble under the weight of the mess it has created, but that often doesn't matter when building an MVP for market validation or for small products that don't get particularly big. Plus, clearly the tipping point takes longer to reach with better and smarter models, and to me it is very clear that you need to learn how to iterate with LLMs right. The things I vibe-code now are much better than those I did before, even with similar models, because the tooling and approaches (the "real harness" and my "mental harness") are better. As with any tool: it takes practice to know how to use it, and if you're a good engineer and problem solver, you are miles ahead of the competition. Anyone can vibecode, but those with this kind of mind seem to be much more successful.
Nowadays I do produce a lot more than I used to, but I also have much more fun, perhaps only surpassed by when I learned how to code when I was a kid. A big chunk of this comes from my very privileged work position, where I get to call so many of the shots, and I'm aware of that.
I would really say the biggest downside to all of this, on a personal level, is exactly what I shared: what comes out of the LLM while discussing has become hard to grasp (especially on larger context windows), and it doesn't help that so many people now like to just throw me whatever ChatGPT/Claude wrote verbatim. I can't stand that, especially because most of the time they don't realize they're throwing me incomplete and poorly thought-out ideas.
Finally, naturally, like I said, this has to do with risk. I wouldn't trust Claude to give me legal advice, for example. I may check what it says and use it to brainstorm, but I wouldn't trust it with any meaningful informed decision like this.
In some cases, I do not trust it to write code unchecked, and review everything it produces (which does not imply I catch all bugs, obviously).
In other cases, occasional failure is an option, and the speed you get by iterating fast is absolutely worth not even looking at the code.
So, do I trust this to write working code? Sometimes I do.
If I'm doing work for a client, it is not very common for me to simply vibe code something, because part of what clients expect of me is high quality (it's part of how we position ourselves), and I cannot simply assume the LLM will produce high quality (and indeed it does not without a lot of guidance). When I do vibecode in such cases, I make it clear that I did so and why (e.g. because it's a tool to be used in the project to help DX, not a core part of the product). Still, I haven't written 10 consecutive manual lines of code in almost a year.
If I'm working on something for myself, or on an internal product, then vibe coding is absolutely allowed and sometimes the norm. Here often we really do care about finding the right thing to build first.
You can clearly feel the tipping point where the LLM starts to crumble under the weight of the mess it has created, but that often doesn't matter when building an MVP for market validation or for small products that don't get particularly big. Plus, clearly the tipping point takes longer to reach with better and smarter models, and to me it is very clear that you need to learn how to iterate with LLMs right. The things I vibe-code now are much better than those I did before, even with similar models, because the tooling and approaches (the "real harness" and my "mental harness") are better. As with any tool: it takes practice to know how to use it, and if you're a good engineer and problem solver, you are miles ahead of the competition. Anyone can vibecode, but those with this kind of mind seem to be much more successful.
Nowadays I do produce a lot more than I used to, but I also have much more fun, perhaps only surpassed by when I learned how to code when I was a kid. A big chunk of this comes from my very privileged work position, where I get to call so many of the shots, and I'm aware of that.
I would really say the biggest downside to all of this, on a personal level, is exactly what I shared: what comes out of the LLM while discussing has become hard to grasp (especially on larger context windows), and it doesn't help that so many people now like to just throw me whatever ChatGPT/Claude wrote verbatim. I can't stand that, especially because most of the time they don't realize they're throwing me incomplete and poorly thought-out ideas.
Finally, naturally, like I said, this has to do with risk. I wouldn't trust Claude to give me legal advice, for example. I may check what it says and use it to brainstorm, but I wouldn't trust it with any meaningful informed decision like this.