Why use ORMs if LLMs write code? by Mark Seemann
The return of SQL?
It's no secret that I'm no fan of ORMs. Most people, on the other hand, find them indispensable. As one reader commented:
"I can work with raw SQL ofcourse... but the mapping... oh the mapping..."
This seems to capture something essential. When I discuss ORMs, the most common argument in favour seems to revolve around the amount of boilerplate code required to communicate with a relational database. And indeed, it's significant.
As I've argued, however, I'm not convinced that ORMs solve that problem.
But now that LLMs write code, does it even matter?
In addition to my individual reservations, it strikes me that ORMs come with many issues related to query efficiency. The vibe I'm getting from ORM experts is that if you really know a particular ORM, you can fine-tune the queries it makes. There are, however, various pitfalls to avoid: Anti-patterns to eschew, idioms to follow, particular APIs to keep clear of, certain parameter values to explicitly pass, etc.
Which strikes me as ironic, because wasn't the whole promise of ORMs that you could read from and write to a relational database without getting bogged down in the details of SQL?
So instead of fiddling with a temperamental and implicit ORM API, why not write fine-tuned parametrized SQL queries? Or rather, ask an LLM to do that for you, as well as all the boilerplate code.
You should, of course, remind it to avoid SQL injection vulnerabilities.
