1) Writing code the "old fashioned" way (i.e., a Python program that does X, Y, Z) allows you to arrive at a battle tested solution that will not change over time. From a risk assessment perspective, the behavior is essentially immutable, allowing a business to guarantee consistent behavior over long periods of time.

2) Just because something hasn't happened to you do, does not mean that it will not happen. LLM are opaque. If you stay on the "happy path", you may see consistent behavior for long periods of time, but there's always potential for an edge case where something goes catastrophically wrong. This is without even opening the can of worms regarding prompt injection and intentional sabotage of a working system.

3) There are plenty of real world examples of an LLM spontaneously deleting data from a DB (or the entire DB) or otherwise going completely off the rails. These might seem hyperbolic, but it happened at our company (to a test DB, not production). The severity of errors that occur can be existential to a business' survival without the proper guard rails.

4) There's no concrete way to truly confirm understanding between an LLM and a human. It can tell you that it completely understands what you want, and then it can do exactly the opposite. Followed by, "my bad" (Claude's new favorite catch phrase). Code can be audited and even proven to be correct given the appropriate level of time and energy.

My best results have been gleaned in using LLM to produce deterministic systems. I recognize everyone has different use cases and needs, but this seems to be the best use of the technology in my experience.

LLMs are probabilistic by design so running the same prompt multiple times will give you different results.

Otherwise, we wouldn’t needed LLMs and could replace it all with Postgres