Comment by early_exit
1 day ago
for me it basically all boils down to:
1. I dont want to have to accept every time Claude touches our DB
2. I'm scared out of my mind it might do something bad to the DB
Plan mode gives me enough confidence that it wont do (2) --> allowing me to give it enough permissions to do (1)
Oh gods, I don't give it write access to my actual DB.
For my small-scale sqlite dB, it gets read access, and I encourage it to test modifications by copying it somewhere and writing into that.
Scale-dependent, but I hope to not have to work at a scale where it gets write access to the production DB. That just seems like asking for trouble.
FYI I had Clod attempt to corrupt a prod db the other day. (Opus 5)
I was experimenting with a rather complicated backfill operation, were I had a validation script I understand and have Clod come up with the backfill script. I was running against a local prod copy, and it proposed running the actual (unfinished) backfill script against prod.
It didn't have access to the secrets and I also caught the command, but a good reminder that this stuff needs guardrails.
yeah that's crazy. its so good 99% of the time but I've seen it have some insane hallucinations before (as late as Fable... cant remember if it was Fable 5 or Fable 5.1).
Hallucination not a big deal when it's on the surface layer. But I can't imagine the damage it could do if it hallucinated while building/validating a "load-bearing" component and then continued down that path
Make a db replica or just a db user account with readonly permissions, and have only those in your env, or docs accessible to agent. It's liberating.
Do you mean when you're making changes to a production DB?
yeah (at an early stage data-focused startup). I think when our product is a bit more mature we'd probably have a staging tier with full access and then manually promote builds / DB changes to prod. So many things to build lol
we DO daily snapshotting, so the risk is limited... but still spooks me
> data-focused startup
What could possibly go wrong with building a data-focused company on a foundation of violating the most fundamental precepts of data management
Write schema/data migration files [with agents] in version control and deploy those deterministically (after review).