[mikeckennedy]

Author here. I've been building data-driven apps for many years. I've long thought that ORMs are the right abstraction level for developers (still do). But it turns out Claude and friends are better with native query langages (e.g. SQL) than with relatively niche ORMs. Happy to discuss the tradeoffs. I know this pattern isn't for every project, and I'm genuinely curious where others draw the line.

A bit of feedback I've already gotten since this is a Python-leaning article is:

1. What are you crazy: Why not Pydantic? Pydantic is great for many things. I'm a bit fan. I'm just not convinced it needs to be the access layer for my DB. Most apps do many more reads than writes. You pay the cost of validation on every read, not just writes. Alternatives include using dataclass-wizard (https://github.com/rnag/dataclass-wizard) and cattrs (https://catt.rs) for validation on the way in for dataclasses without revalidating on every read.

2. Data classes don't provide runtime type checking. No they don't. If that is paramount for you, choose Pydantic (see #1for why I chose data classes ;) ). But data classes do provide type-checking time type safety. When paired with tools like cattrs and dataclass-wizard, inbound data can be type safe too.

3. This uses MongoDB examples. Fair. The pattern applies to SQL too (psycopg3 + parameterized queries + dataclasses). The core argument, that AI handles vanilla SQL better than SQLAlchemy ORM code, holds even more strongly there given how universal SQL is.

Benchmarks and runnable code are in the repo if you want to check it out.