I think the spirit of this post has merit, but the premise is flawed. ORMs have been causing this same class of problem for decades. Furthermore, It's not at all uncommon for humans to create different queries for the same result and for them to follow different review paths for the same underlying database.
Agentic AI systems violate the implicit assumptions of database design
31–40 of 115 posts
Re: Agentic AI systems violate the implicit assumptions of database design
#32> Connections are Brief
This doesn't make sense, in the context of the author's chosen example (postgres). Postgres connections are very heavy and there is a huge performance penalty for cycling them quickly, and a whole range of silly workarounds for this fact (pgbouncer). Maybe the author meant to say that sessions are brief.
Re: Agentic AI systems violate the implicit assumptions of database design
#33I totally agree on investing in a sane data model upfront. So many production systems have schemas that only made sense to the engineer that created them. I would be delighted if I can read a schema and understand what a column means without having to dig through a bunch of migration PRs. I recently encountered `is_as BOOL` in an important table. After way too much invested time we found out it meant "is active servi…
I think the best db schema I had the displeasure of working with was one where it was a requirement that every table and column name NOT have vowels, except for the few that could, and "the few that could" were governed entirely by a spreadsheet owned by the DB admin. And so you got tables like LANDMRK and columns like RCR_RCRDR.
Oh my. What could possibly be the justification for this?
Re: Agentic AI systems violate the implicit assumptions of database design
#34Giving an LLM write access is insane but I gave LLM’s read-only access to our database and it’s been a huge productivity win. Executives who wouldn’t take the time to build a report are happy to ask an AI agent to do so.
How do you validate that the reports are correct? What if an executive makes a wrong business decision because the LLM wrote a wrong SQL query?
Re: Agentic AI systems violate the implicit assumptions of database design
#35Agree across the board.
Re: Agentic AI systems violate the implicit assumptions of database design
#36Earlier quoted context omitted.
LLM agents are unlocking demand and supply for applications that wouldn't have been possible before due to time constraints though. There's a growing demand for single user or smaller scoped apps where giving LLM agents direct access means velocity. The failure/rollback model is much easier with these as long as we have good backup hygiene.
> There's a growing demand for single user or smaller scoped apps where giving LLM agents direct access means velocity. The failure/rollback model is much easier with these as long as we have good backup hygiene. This makes no sense to me. For anything that has sensitive payment or personally identifieable data, direct access to DB is potentially illegal. > The failure/rollback model is much easier with these as long…
This narrative seems to come from people who haven't worked on meaningfully complex software systems. They're more like script kiddies than software developers. I don't mean that in a derogatory manner. They're right that LLMs are unlocking new possibilities in the realm of their work. They just don't realize that these new possibilities are constrained to relatively simple applications, or very thin slices of complex systems.
I use an LLM to access my database occasionally, but never in production and never with write access. It is genuinely useful. It would never be useful in a production setting, though.
It's worth noting too that people should be wary of what a read only user means in database land. There are plenty of foot guns where writes can occur with read-like statements, and depending on the schema, maybe this would be a rollback-worthy situation. You really need to understand your database and schema before allowing an LLM anywhere near it, and you should be reviewing every query.
Re: Agentic AI systems violate the implicit assumptions of database design
#37Giving LLM agents direct, autonomous access to a real production databases with write access seems insane to me. NO ONE, agent or human, should have direct write access to production databases outside of emergency break glass scenarios. This is why we have stored routines and API layers to pre-define what writes are allowed. The facts that agents CAN autonomously write to a database does not imply that they should. F…
How does that even work in compliance-relevant scenarios where the audit trail shows some LLM messed with the data? Who, if anyone, is on the hook?
The dev who ran it. The manager who allowed it. The director/VP/CTO who enabled the culture. They all have some responsibility for it.
Re: Agentic AI systems violate the implicit assumptions of database design
#38> Never let an agent hard-delete anything. Use soft deletes as a baseline for any table an agent can write to
How you even enforce it ?
And why you are even giving agent access to live DB in the first place ?
Re: Agentic AI systems violate the implicit assumptions of database design
#39I think the spirit of this post has merit, but the premise is flawed. ORMs have been causing this same class of problem for decades. Furthermore, It's not at all uncommon for humans to create different queries for the same result and for them to follow different review paths for the same underlying database.
A query created by a human and reviewed by at least 1 other human becomes static after it's merged. But the query from an LLM is dynamic, it can change between two calls in the same session if the LLm sees a reason to change it, and there is no review pipeline and QA stage.
Re: Agentic AI systems violate the implicit assumptions of database design
#40think of a flat database table as a projection (of all previous SQL queries), should you give access to it to agents?
probably not, maybe only for analytical (OLAP) purposes in read-only mode.
for transactional OLTP loads, it is better to use Kafka style durable queues, have agents create a change record to mutate the state, but not the projection itself, which could be recomputed at arbitrary point in time via time-travel mechanism, could be branched out into different versions, etc