Skip to content

comment reply #999

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
qfilip wants to merge 1 commit into
base: master
Choose a base branch
from
Open

comment reply #999

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
240 changes: 177 additions & 63 deletions _posts/2026-08-13-why-use-orms-if-llms-write-code.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,39 +9,72 @@
{% include JB/setup %}

<div id="post">
<p>
<em>{{ page.description }}</em>
</p>
<p>
It's no secret that
<a href="/2023/09/18/do-orms-reduce-the-need-for-mapping"
>I'm no fan of ORMs</a
>. Most people, on the other hand, find them indispensable. As one reader
commented:
</p>
<blockquote>
<p>
<em>{{ page.description }}</em>
</p>
<p>
It's no secret that <a href="/2023/09/18/do-orms-reduce-the-need-for-mapping">I'm no fan of ORMs</a>. Most people, on the other hand, find them indispensable. As one reader commented:
</p>
<blockquote>
<p>
"I can work with raw SQL ofcourse... but the mapping... oh the mapping..."
</p>
<footer><cite><a href="/2023/07/17/works-on-most-machines#4012c2cddcb64a068c0b06b7989a676e">qfilip</a></cite></footer>
</blockquote>
<p>
This seems to capture something essential. When I discuss <a href="https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping">ORMs</a>, 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.
</p>
<p>
As I've argued, however, I'm <a href="/2023/09/18/do-orms-reduce-the-need-for-mapping">not convinced that ORMs solve that problem</a>.
</p>
<p>
But now that <a href="https://en.wikipedia.org/wiki/Large_language_model">LLMs</a> write code, does it even matter?
</p>
<p>
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.
</p>
<p>
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 <a href="https://en.wikipedia.org/wiki/SQL">SQL</a>?
</p>
<p>
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.
</p>
<p>
You should, of course, remind it to avoid <a href="https://en.wikipedia.org/wiki/SQL_injection">SQL injection</a> vulnerabilities.
"I can work with raw SQL ofcourse... but the mapping... oh the mapping..."
</p>
<footer>
<cite
><a
href="/2023/07/17/works-on-most-machines#4012c2cddcb64a068c0b06b7989a676e"
>qfilip</a
></cite
>
</footer>
</blockquote>
<p>
This seems to capture something essential. When I discuss
<a href="https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping"
>ORMs</a
>, 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.
</p>
<p>
As I've argued, however, I'm
<a href="/2023/09/18/do-orms-reduce-the-need-for-mapping"
>not convinced that ORMs solve that problem</a
>.
</p>
<p>
But now that
<a href="https://en.wikipedia.org/wiki/Large_language_model">LLMs</a> write
code, does it even matter?
</p>
<p>
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.
</p>
<p>
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
<a href="https://en.wikipedia.org/wiki/SQL">SQL</a>?
</p>
<p>
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.
</p>
<p>
You should, of course, remind it to avoid
<a href="https://en.wikipedia.org/wiki/SQL_injection">SQL injection</a>
vulnerabilities.
</p>
</div>
<div id="comments">
<hr />
Expand Down Expand Up @@ -134,16 +167,16 @@ <h2 id="comments-header">Comments</h2>
<p>
I've always been skeptical of ORMs because they're trying to make
seamless a translation between objects (graphs) and relational tables.
Those are two different designs, so the translation layer will always
be a leaky abstraction. SQL is designed around relations, and deriving
SQL from graph relationship is always going to have edge cases in
addition to complexity and performance issues.
Those are two different designs, so the translation layer will always be
a leaky abstraction. SQL is designed around relations, and deriving SQL
from graph relationship is always going to have edge cases in addition
to complexity and performance issues.
</p>
<p>
Indeed, modern ORM usage has focused more on simple CRUD operations,
abandoning object graphs in favor of DTOs, and even using multiple
DTOs for different queries over the same tables. We ended up writing
SQL indirectly in DTOs.
abandoning object graphs in favor of DTOs, and even using multiple DTOs
for different queries over the same tables. We ended up writing SQL
indirectly in DTOs.
</p>
<p>
This is why I prefer micro-ORMs like
Expand All @@ -156,32 +189,113 @@ <h2 id="comments-header">Comments</h2>
<div class="comment-date">2026-08-13 14:17 UTC</div>
</div>

<div class="comment" id="4d84baf78fef41c288b802df33a5895b">
<div class="comment-author"><a href="/">Mark Seemann</a> <a href="#4d84baf78fef41c288b802df33a5895b">#</a></div>
<div class="comment-content">
<p>
qfilip, thank you for writing. There's nothing inherently wrong with automated tests that involve a database, as long as the tests in question are deterministic, independent, and run fast. Some people have problems with the independence property, which may be one reason why you often run into the sentiment that integration tests aren't real unit tests.
</p>
<p>
Well, I wouldn't categorize them as <em>unit</em> tests either, but the name isn't that important. What matters is what value you get out of them, at what cost.
</p>
<p>
The cost of the test is typically the other issue associated with including a real database in automated tests: They tend to be slow. If the entire <a href="/2012/05/24/TDDtestsuitesshouldrunin10secondsorless">test suite runs for more than ten seconds, it tends to become a problem</a>. Even so, if this happens, you can always divide the test suite into a fast developer/TDD suite, and a slower, more complete QA suite, as described in <a href="/2021/06/14/new-book-code-that-fits-in-your-head">Code That Fits in Your Head</a>.
</p>
<p>
As to whether most SQL operations are basic CRUD, I suppose that depends on context and what kind of applications you are being asked to develop. I've worked on several projects that mostly involved a lot of complicated queries.
</p>
</div>
<div class="comment-date">2026-08-19 12:51 UTC</div>
<div class="comment" id="4d84baf78fef41c288b802df33a5895b">
<div class="comment-author">
<a href="/">Mark Seemann</a>
<a href="#4d84baf78fef41c288b802df33a5895b">#</a>
</div>
<div class="comment-content">
<p>
qfilip, thank you for writing. There's nothing inherently wrong with
automated tests that involve a database, as long as the tests in
question are deterministic, independent, and run fast. Some people have
problems with the independence property, which may be one reason why you
often run into the sentiment that integration tests aren't real unit
tests.
</p>
<p>
Well, I wouldn't categorize them as <em>unit</em> tests either, but the
name isn't that important. What matters is what value you get out of
them, at what cost.
</p>
<p>
The cost of the test is typically the other issue associated with
including a real database in automated tests: They tend to be slow. If
the entire
<a href="/2012/05/24/TDDtestsuitesshouldrunin10secondsorless"
>test suite runs for more than ten seconds, it tends to become a
problem</a
>. Even so, if this happens, you can always divide the test suite into a
fast developer/TDD suite, and a slower, more complete QA suite, as
described in
<a href="/2021/06/14/new-book-code-that-fits-in-your-head"
>Code That Fits in Your Head</a
>.
</p>
<p>
As to whether most SQL operations are basic CRUD, I suppose that depends
on context and what kind of applications you are being asked to develop.
I've worked on several projects that mostly involved a lot of
complicated queries.
</p>
</div>
<div class="comment-date">2026-08-19 12:51 UTC</div>
</div>

<div class="comment" id="6b38d244101042468d780db8e73d9616">
<div class="comment-author">
<a href="/">Mark Seemann</a>
<a href="#6b38d244101042468d780db8e73d9616">#</a>
</div>
<div class="comment-content">
<p>
Stephen Cleary, thank you for writing. I take it you are already
familiar with Ted Neward's article
<a
href="https://blogs.newardassociates.com/blog/2006/the-vietnam-of-computer-science.html"
>The Vietnam of Computer Science</a
>?
</p>
</div>
<div class="comment-date">2026-08-19 13:14 UTC</div>
</div>

<div class="comment" id="6b38d244101042468d780db8e73d9616">
<div class="comment-author"><a href="/">Mark Seemann</a> <a href="#6b38d244101042468d780db8e73d9616">#</a></div>
<div class="comment-content">
<p>
Stephen Cleary, thank you for writing. I take it you are already familiar with Ted Neward's article <a href="https://blogs.newardassociates.com/blog/2006/the-vietnam-of-computer-science.html">The Vietnam of Computer Science</a>?
</p>
</div>
<div class="comment-date">2026-08-19 13:14 UTC</div>
<div class="comment" id="7e5a83b4743d41809da4ea8bda4b0bc8">
<div class="comment-author">
qfilip <a href="#7e5a83b4743d41809da4ea8bda4b0bc8">#</a>
</div>
<div class="comment-content">
<blockquote>
<p>
As to whether most SQL operations are basic CRUD, I suppose that
depends on context and what kind of applications you are being asked
to develop. I've worked on several projects that mostly involved a lot
of complicated queries.
</p>
<footer>
<cite
><a
href="/2026/08/13/why-use-orms-if-llms-write-code#4d84baf78fef41c288b802df33a5895b"
>Mark Seemann</a
></cite
>
</footer>
</blockquote>
<p>
Just to clarify again, in order to have a complicated query, one needs
some data to query against. So the <i>reading</i> part can be complex.
Writing, in my humble experience, is usually straightforward and EF does
a great job there.
</p>
<p>
Maybe calling EF an ORM might be a misnomer, because it does much more
than just mapping. After all, it has a framework in its name.
</p>
<p>
I agree that for anything beyond basic joins, it absolutely cannot
compare to SQL, because SQL has a very specific purpose. But it still
automates a lot. I'm yet to hear a compelling reason to ditch that
automation.
</p>
<p>
Aside from mapping, (oh the mapping 😉), my other problem is the
maintenance of SQL as a magic string in F#/C#/whateverlang. LLMs can
generate code, but I don't trust them when something needs updating
(e.g. field name change). We can of course catch such errors with tests,
but why would I bother having them in the first place if I can relegate
it to the compiler and type checking?
</p>
</div>
<div class="comment-date">2026-08-20 14:20 UTC</div>
</div>
</div>