I find that depends a LOT on what you're asking the LLM to write, how well you're specifying it, etc. As for the code reviews, if it's code that matters: remember to open a new instance and ask the exact same question again on the code that has been reviewed and "fixed". Back a year ago, that could get you into a waffle-loop where the engine would change its mind back and forth about what's optimal and just oscillate between the two. These days they seem to record (and read) enough context to prevent that behavior, but I definitely get behavior of: "Are there any bugs?" "Yes, here are seven bugs." "Fix those bugs." "The bugs are fixed." (and they ususally really are...) "Are there any more bugs?" "No, we have fixed ALL the bugs." "Are you sure, look again." "Yes, I am sure we have found and fixed ALL the bugs."

new context window

"Are there any bugs?" "Yes, here are seven bugs." different bugs.

I did that on a bigger project and literally repeated 20 times, finding 140 real bugs - granted, the later bugs were getting pretty trivial / far out edge cases, but they were still real, still fixed, still denied there were any more bugs until opening a fresh context and asking again. This was on Google's Gemini 3.7 Flash High... Claude Opus 4.8+ seems quite a bit better about being able to continue in a context without becoming blind to issues "it has already solved."

Line completion is pretty damn handy, it's when you start asking for whole functions that things go downhill

There are already several large projects that have hundreds of thousands of users and those projects were almost completely vibe coded. It's almost the entire retro "recomp" scene now.

IMO: Specifically, they're bad at architecture and refactoring a small project into a large project. You have to jump through some hoops to make it craft something that needs more than 8m of context ram. If you can manage orchestration and multi-agents that don't need to know each others context, you can start to pull off bigger stuff, but it's not a forgone conclusion that it'll be fine. The worst output comes from it getting stuck on something and trying less likely answers successively until it works. You really have to watch for it to struggle and at the very least stop and start to try some new randoms.

Also, anything other than Claude-code with some really well-done project definitions is a waste of time.

At my company we are currently moving to implement AI for exactly that. A cost effective review buddy.

Various developers have tried to use it for coding and I think apart for one time scripts or getting an initial structure generated, noone is convinced of AI.

Opus-class and higher models are actually great at writing code, but maybe it's language dependent? I primarily work in TypeScript.

If we ever find a way to deal with the whole "burning the planet" issue, their best use case is to find and match patterns, not to imitate them.

The idea of using a language model to process search engine input isn't the dumbest part about Gemini and plenty of people report good results finding information easier and quicker with ChatGPT. In those cases, the deviation from rigid keywords is desirable because it can match results with related words rather than literal word-matching. Google Search already did a decent job at that (before the enshittification ran rampant), which more complex language models could improve even further.

The landmine is in their reproduction of those results, where the generated "summary" is the equivalent of a cunning bullshitter that convincingly sounds like he understood the topic but actually has no clue and just delivers a best guess. That's where the deviation becomes a risk of misinformation or introducing bugs.

They should narrow things down by finding the likely answers where that matters, not produce more stuff that humans will have to double-check.

LLMs suck at writing code,

So far.