Comment by egorfine
5 hours ago
vibecoding != AI.
For example: I'm a senior dev, I use AI extensively but I fully understand and vet every single line of code I push. No exceptions. Not even in tests.
5 hours ago
vibecoding != AI.
For example: I'm a senior dev, I use AI extensively but I fully understand and vet every single line of code I push. No exceptions. Not even in tests.
Whilst I agree with your point, I think what sometimes gets lost in these conversations is that reviewing code thoroughly is harder than writing code.
Personally, and I’m not trying to speak for everyone here, I found it took me just as long to review AI output as it would have taken to write that code myself.
There have been some exceptions to that rule. But those exceptions have generally been in domains I’m unfamiliar with. So we are back to trusting AI as a research assistant, if not a “vibe coding” assistant.
I think the point is in a banking context, every line of code gets reviewed thoroughly anyway.
Would you consider Knight Capital Group[1] a banking context?
[1]: https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stoc...
I’d expect every line of code to get reviewed in any organisation.
The difference with AI is that the “prompt engineer” reviews the output, and then the code gets peer reviewed like usual from someone else too.
You'd be surprised...
> as long to review AI output as it would have taken to write that code myself
That is often the case.
What immensely helps though is that AI gets me past writer's block. Then I have to rewrite all the slop, but hey, it's rewrite and that's much easier to get in that zone and streamline the work. Sometimes I produce more code per day rewriting AI slop than writing it from scratch myself.
Unfortunately, the people who are "pro-AI" are so often because it lets them skip the understanding part with less scrutiny
The good news here is that their code is of such a poor quality it doesn't properly work anyway.
I have recently tried to blindly create a small .dylib consolidation tool in JS using Claude Code, Opus 4.5 and AskUserTool to create a detailed spec. My god how awful and broken the code was. Unusable. But it faked* working just good enough to pass someone who's got no clue.
> The good news here is that their code is of such a poor quality it doesn't properly work anyway.
This is just wishful thinking. In reality it works just well enough to be dangerous. Just look at the latest RCE in OpenCode. The AI it was vibe-coded with allowed any website with origin * to execute code, and the Prompt Engineer™ didn't understand the implications.
3 replies →
That is my preferred way to use it also, though I see many folks seemingly pushing for pure vibe coding, apparently striving for maximum throughput as a high-priority goal. Which goal would be hindered by careful review of the output.
It's unclear to me why most software projects would need to grow by tens (or hundreds) of thousands of lines of code each day, but I guess that's a thing?
And I do a lot of top level design when I use it. AIs are terrible at abstraction and functional decomposition.
Aye. AI is also great for learning specifics of poorly documented APIs, e.g. COM-based brainrot from Microsoft.
Hey now, that COM based rot paid for my house and kid’s college expenses.
Not anymore. AI actually does this part much better.
> Not even in tests.
This should be "especially in tests". It's more important that they work than the actual code, because their purpose is to catch when the rest of the code breaks.