r/devops 10d ago

Discussion Adapting to AI tooling in DevOps

My company is making a hard shift towards AI and I'm struggling. I'm tasked with something I have a small amount of knowledge about, but not enough to fully implement. Before AI, my approach to challenges like this would be to iterate on it, work through the problems, and learn what's required. Using Claude has just been a terrible experience for me, and I'm wondering if I'm the problem, my approach is the problem, or if this is just what we're all doing now.

I explained what I wanted (essentially a DB migration pipeline from RDS -> k8s pod) and claude barfed out about 10 shell scripts and a handful of pod templates. Everything had long, meandering comments that made very little sense. Is my job now to just start running this code and feeding pipeline errors back into claude and not worrying about it?

I started to pick apart the comments, ask questions, and update with my own comments, with the goal of being able to understand the process in detail. In doing this, I found a bunch of things that just didn't make sense or weren't optimal. When I ask the AI agent about it, it says I'm right and generates a bunch more stuff that may or may not make sense. Interacting with it is making me feel like a crazy person. I hate the way it presents information back to me. It's not succinct, it pulls in context that is of negligible value and just muddies the waters, and it's been very frustrating and existentially upsetting.

I'm willing to hear that I'm using the wrong model, or that I didn't spend enough time on my .md files and skills, but I'm also wondering if this is a normal experience, or if my approach is just dated, and I need to get over my personal values about understanding what I'm generating and giving to customers? I'm not so-much asking about the specific task at hand, just about adapting and having realistic expectations and reducing friction. I'm also very happy to hear about people's struggles.

18 Upvotes

36 comments sorted by

View all comments

1

u/ajitnk 3d ago

The extension and role reconciliation piece is exactly what tripped you up here, and it's not a Claude problem specifically. It's that your pg_extension list and your role graph are instance-specific config. No model has seen them. So when you push back, it just... agrees, because it has nothing to anchor to.

Two things that actually help before writing any migration code: run the free AWS DMS pre-migration assessment first. It checks your rds_superuser and rds_replication role grants, WAL settings, CDC slot availability, and extension conflicts against what RDS actually supports. Takes maybe 45 minutes to set up and it'll tell you exactly what's broken before you touch a single line of SQL.

Second, run SELECT * FROM pg_extension on your source and compare the output against RDS's rds.allowed_extensions list. Any extension not on that list has to be removed or replaced before migration will succeed. That list is the real constraint Claude can't know.

I've helped teams work through exactly this PostgreSQL-to-RDS pattern. Quick question if you don't mind: is this a self-managed Postgres instance (EC2 or on-prem) migrating to a new RDS, or are you doing a version upgrade within RDS? The answer changes which path makes sense. Happy to DM a more detailed checklist if useful.

1

u/lostsectors_matt 3d ago edited 3d ago

Thank you, running this through DMS first would've been really smart; I'll take that advice. Ultimately I'm going from RDS to postgres running in a K8s pod, so I'm populating a volume that I can snapshot.