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.

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...

Would you consider Knight Capital Group[1] a banking context?

[1]: https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stoc...

> 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.

The worst is reviewing the code and realizing it stinks and should be done another way

So you re-roll the slot machine and pay the reviewing cost twice

I don't think AI's biggest strength is in writing code

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.

> it works just well enough to be dangerous

Excellent. I for one fully welcome Prompt Engineers™ into the world of software development.

I assume you don't understand some of the words in the rest of my comment. Or you're a nihilist and enjoy watching everything burn to the ground.

It's all fun and games until actual lives are at stake.

I'm watching the voters around the world electing charismatic leaders and then cheering the consequences.

Thus companies electing to replace software developers with AI slop are not of a much surprise to me.

It doesn't matter whether people will die because of AI slop. What matters is keeping Microsoft shareholders happy and they are only happy when there is a growing demand for slop.

> 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.

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.