Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agentic AI systems violate the implicit assumptions of database design

arpitbhayani.me

Post reply on HN
Print view View original

81–90 of 115 posts

Re: Agentic AI systems violate the implicit assumptions of database design

#81

Post by angra_mainyu »

bloaf wrote: post #24

> The API failed silently because the database connection pool was exhausted downstream. I work with a team that does stuff like this, returning a 200 and a body containing "error: I didn't do what you said because _insert error here_" The problem is that you returned OK instead of ERROR when things were not OK and there was an ERROR. Its a design that smells of teams trying to hit some kind of internal metrics by sl…

>returning a 200 and a body containing "error: I didn't do what you said because _insert error here_"

I've seen this approach before, it mostly follows from using the code to signal application errors (200 + ok/error) from other kinds of errors that might arise.

Re: Agentic AI systems violate the implicit assumptions of database design

#82

Post by Pxtl »

sgarland wrote: post #64
dherls wrote: post #2

Giving 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…

I’m a DBRE. I spend a good portion of my day with a shell into one or more prod databases. The schema definitions in code are scattered between ORM model definitions, Alembic migrations, and Liquibase migrations, so the only reliable way I have of understanding a schema as it exists is to view it. Plus, I am very comfortable with SQL, and the various system catalogs of both MySQL and Postgres, so it’s a ton easier to…

So what do you do for "okay, we need to run this script that we've decided is a necessary operation". Special account? Everything go through the build server? I've been looking for tooling for "I need to do a production operation but I want it to have proper interlocks and reviews".

Re: Agentic AI systems violate the implicit assumptions of database design

#83

Post by Pxtl »

bloaf wrote: post #24

> The API failed silently because the database connection pool was exhausted downstream. I work with a team that does stuff like this, returning a 200 and a body containing "error: I didn't do what you said because _insert error here_" The problem is that you returned OK instead of ERROR when things were not OK and there was an ERROR. Its a design that smells of teams trying to hit some kind of internal metrics by sl…

I had to explain so many times to infrastructure guys why it was not okay that the software they use to manage outages still returns 200s.

Re: Agentic AI systems violate the implicit assumptions of database design

#84

Post by root_axis »

m463 wrote: post #72
dherls wrote: post #2

Giving 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…

> autonomous access to a real production databases remember that filesystems are just sophisticated databases rm -rf /

And the same logic applies.

Re: Agentic AI systems violate the implicit assumptions of database design

#85

Post by BrentOzar »

ripped_britches wrote: post #43

I’m all-in on agents but this is a “you’re holding it wrong” situation. If you want to give your agents a DB for their own work as a scratchpad or something that’s great. They can not only go to town, but also analyze their own work and iterate on it. If you are talking about a production base, agents should not be hitting it directly under any circumstances. There needs to be an API layer with defined usage patterns…

> This is basically the same as saying “databases weren’t designed for interns to run live inline migrations in prod”. Yeah of course they aren’t.

And the same as saying "databases weren't designed for non-technical people to connect with report-building tools like Power BI and Excel and run reports in the middle of peak customer checkouts."

As a DBA, I'm constantly surprised by what people think will be completely harmless to hook up to the database server - and then how much havoc it causes. Gonna be a rough decade.

Re: Agentic AI systems violate the implicit assumptions of database design

#86

Post by BrentOzar »

kgeist wrote: post #10
iambateman wrote: post #8

Giving 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?

> What if an executive makes a wrong business decision

I jokingly tell students, "We all know executives are gonna make bad decisions no matter what the data says. Might as well give them the random numbers more quickly."

Re: Agentic AI systems violate the implicit assumptions of database design

#87

Post by jmalicki »

cowlby wrote: post #78
2ndorderthought wrote: post #46

Earlier quoted context omitted.

You are thinking way too hard. This person is a hazard that needs to learn the hard way. If velocity means letting agents live edit a db, I'm fine being slow. Holy hell. Let these people crash and burn but definitely let me know the app name so I know never to use it first.

Not everything is a SaaS. I commented this elsewhere but I picture all the business running on spreadsheets/CSVs/MS Access databases on someone's desktop. People delete these all the time by accident. They have no security, no authentication, etc. An LLM agent (with RW access to a DB), a developer, and a few days these become proper apps that SMB business would pay well for. Sure don't give an LLM agent access to PII…

At the very least you should give it a non-prod copy of the database, not direct access to the DB actively powering production right now.

I've done work for a hedge fund where the DB ran directly on the manager's desktop. I worked with my local copy and sent an update script, and he had a second copy he ran on to verify.

Even with humans you shouldn't be working directly against the prod DB in these cases!

Re: Agentic AI systems violate the implicit assumptions of database design

#88

Post by sroussey »

cowlby wrote: post #76
steve_adams_86 wrote: post #36

Earlier quoted context omitted.

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 comple…

That's the issue that I feel misses the forest for the trees. Relatively simple applications or thin slices exist right now, in production, in critical paths, as spreadsheets/CSVs/files on someone's desktop. That's the pent up demand I picture out there for developers. Go to any SMB out there and there's a goldmine of processes that could be improved with LLM agents with full RW access to a database. Where backups ar…

I think the Venn diagram of people letting LLMs have complete control of their database AND having good backups, will have no overlap. The people that would benefit or not the people that have backups.

Re: Agentic AI systems violate the implicit assumptions of database design

#89

Post by jeremie_strand »

_bypa wrote: post #12
dherls wrote: post #2

Giving 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?

[dead]

Re: Agentic AI systems violate the implicit assumptions of database design

#90

Post by marcosdumay »

tremon wrote: post #45
nananana9 wrote: post #17

Earlier quoted context omitted.

The same way we've always done it - glance at it and see if the numbers look like they're within an order of magnitude of what looks reasonable.

So as long as the LLM only makes errors in the single-digit percentage range, everything is peachy. Make number go up, but not by too much.

If you already know the report's numbers, why are you asking an LLM to generate it?
Post reply on HN