My company is making a major shift toward AI-assisted development, and I'm struggling to find a productive way to use it. I was asked to build something outside my strongest area: essentially a database migration pipeline from an RDS PostgreSQL instance into a Kubernetes-based environment. Normally I would break the problem down, research what I needed, implement it incrementally, and learn through the process.
Instead, I gave Claude a broad description of the task and received around ten shell scripts plus several Kubernetes manifests. The output was full of long, confusing comments and included far more complexity than I expected: database role and extension reconciliation, RDS-specific behavior, failed-dump recovery, extra pods, listener rules, and other pieces I hadn't requested. When I questioned parts that seemed wrong, the model agreed with me and produced even more code, which made it difficult to tell whether I was making progress or just accumulating plausible-looking changes.
I'm not asking for a solution to the migration itself. I'm trying to understand what realistic AI-assisted workflows look like. Am I using the wrong model or prompting it poorly? Should I be doing more work on planning documents, project skills, and context files? Is it normal to review and challenge nearly everything the model generates, or is the expectation now to run the code, report pipeline errors, and let the model iterate without fully understanding the implementation?
I still believe I need to understand and take responsibility for anything I ship, but the pressure at work is toward doing these tasks in hours rather than days. I'd appreciate hearing how others have adapted, including struggles and reasonable expectations for AI tooling in infrastructure work.
4 Answers
Understanding what you ship is not an outdated value. The model can help write code, but it cannot take responsibility for the postmortem when something fails at three in the morning. I’ve had better results treating AI-generated code as a proposal to verify, not as an answer to iterate on blindly. It should be easy to explain every action, permission, resource, and destructive behavior before deployment. For unattended infrastructure, prefer simple and deterministic solutions over elaborate “smart” workflows you cannot reconstruct later.
Your instinct to inspect and understand the output is correct. The model is useful for drafting, research, and finding gaps, but it is not a substitute for a design or an acceptance test. Don’t start with “build the whole migration.” Define the phases, inputs, outputs, safety conditions, and rollback behavior first. Then have the model work on one small, reviewable piece at a time. You are not expected to run generated infrastructure code blindly and feed the resulting failures back into the model.
That’s reassuring. I gave the tool far too much scope because I underestimated how many database-specific details were involved. I’m going to go back to defining the process myself and use the model to review each step instead of generating the entire workflow.
Database migrations are a particularly bad place to trust broad, generic generation. The model cannot know all the important details of your actual instance: PostgreSQL version, extensions, roles, parameter groups, permissions, storage behavior, backup requirements, or the exact failure and rollback scenarios. For work like this, write the migration plan and invariants yourself, then ask the model to challenge the plan, explain unfamiliar concepts, or produce narrowly scoped implementation pieces. Keep anything that can affect data or production state behind explicit review and testing.
Exactly. The Kubernetes pieces were mostly understandable to me, but the database-related sections expanded into hundreds of lines of assumptions about roles, extensions, and recovery behavior. That was the point where the generated solution stopped helping.
A lot of the frustration comes from asking for a solution before establishing a working contract. I usually put the tool in planning mode, make it state its assumptions, and require a short plan before it writes code. I provide the expected directory structure, resource names, interfaces, and constraints, then approve one phase at a time. Ask for concise output—short explanations, tables, or diagrams—and tell it to stop when it encounters an unknown rather than inventing a solution. It can be very productive, but only when you act as the technical lead rather than treating it like an autonomous implementer.
My plans were hundreds of lines long and much of that was noise, so I clearly need to tighten the format. I also started this project without the project-specific guidance and skills I normally use, which probably made the interaction worse.
I’ve also found that the model tends to agree with every criticism and then add more complexity. That agreement isn’t proof that the revised design is correct; it’s a reason to return to the requirements and test the specific claim.