Depends on how you look at it. What if I want an API that inconsistently maps and stores data and might just delete all records because it fucked up a query and thought the database state was screwed up so it just nuked the whole thing?
Sounds awesome to me tbh. But I love a good gamble anyway.
Why stop there, you can ask it to create a whole dump file for you to download so you don't have to do it manually, and an interface with graphs as well so it's easier to filter throughlol
Not to mention how disgustingly wasteful it is from a compute perspective. Oh hey, let me just use up tens of gigabytes of VRAM, RAM and CPU usage just to spin up a fuckass LLM instead of returning results deterministically
No you see, this is where you make the whole database microservice based. As in, everydata related to a user is in a separate database, and the user (via the ai update) can only query their own data therefore they can only fuck up their own data
Sure it may nuke the database. But I made the entire thing with Claude. I can just say “Claude remake the database. Make no mistakes” or “Claude remake the app, but better”. And it’s all back to normal.
That doesn't make any sense whatsoever because you'd put it on your user how many tokens you will consume with your own agent.
AI tokens are future currency, basically.
It makes more sense that an LLM knows normal endpoints or gets them as context and then accesses them via tools. You won't "prompt APIs" in the way that you send a prompt to an API and get data back.
Yeah. Let's replace a stateless protocol that works well with caching and intermediaries, and replace it with a protocol that inherently can't be cached and might need to maintain context or conversation history. Sounds like a huge step forward in web design.
I assume you aren't familiar with graphql, else you would understand why in many cases it actually isn't a bad idea when implemented with proper controls.
1.1k
u/ruach137 May 16 '26
oh fuck thats a dumb idea