To me the biggest gotcha with AI code is that the bugs are not “normal”.

When reviewing human code I focus on specific parts because I know that there are parts where a person will just not make a bug (unless very junior).

AI on the other hand, will not do an off-by-one mistake, but it will happily just delete perfectly working code for no obvious reason. Or monkey patch a dependency because it missed a config flag. Or generally fail in a very novel and creative way.

The effort it takes to review AI code is much greater. And this is in a code base I am deeply familiar with.

Imo the future lies in a solid core programs with powerful plugin frameworks that expect all plugins to be code that was never read.

▲

aaron_m04 4 days ago | parent | next [-]

> Imo the future lies in a solid core programs with powerful plugin frameworks that expect all plugins to be code that was never read.

What makes you think that?

	▲	yoz-y 4 days ago \| parent [-]
		I think this is a good practice anyway. Putting as much code as possible into silos with guarded permissions. Historically plugins have been kind of crappy because they were constantly breaking with updates. However if they only live as a spec, and are regenerated when needed they can easily survive API changes. Bonus feature is that if all “installed” plugins are generated together, the llm can also find ways to avoid them being buggy due to weird interactions. All this while keeping the main program from crashing. Security wise the spec can also be inspected using a trusted LLM. It is trivial to hide exfiltration or malicious code in plugin/extension code (e.g.: honey). But it is much harder to hide it in a spec.

▲

witx 4 days ago | parent | prev [-]

Yup. I can expect an llm to write proper code to update an hashmap or update a db, but ffs the amount of race conditions, use after free and general concurrency issues I found on colleagues PRs developed fully with these things is disgusting.