The problem isn't AI. It's the posture we bring to it.
Most engineers approach AI like a vending machine: insert prompt, receive answer, accept output. When the answer is wrong, they insert another prompt. And another. They optimize for getting something back rather than getting the right thing back. The result is a strange new form of labor, managing an assistant who never quite understands you, while pretending this is faster than just doing it yourself.
Working with AI instead of for it comes down to three shifts.
Start with the answer in your head, not in the model. Before you open the prompt box, know what good looks like. If you can't describe the shape of the output you want, the structure, the constraints, the edge cases, you're not delegating, you're gambling. The engineers who get real leverage from AI are the ones who already know roughly what they'd write themselves; they're using AI to skip the typing, not the thinking. When you outsource the thinking, you inherit whatever average answer the model produces, and average is rarely what you needed.
Treat AI like a junior engineer with infinite confidence and no context. It will say things with authority that are wrong. It will solve the problem you described instead of the problem you have. It will invent APIs that don't exist. None of this is a flaw to be fixed by better prompting alone, it's the nature of the tool. So give it what you'd give a new hire: the actual file, the actual error, the actual constraint, the actual code style of the codebase. Vague requests get vague answers. Specific requests with real context get something you can actually use. The five extra minutes you spend giving context saves the thirty minutes of back-and-forth that follows when you don't.
Decide what stays human. Code review judgment. Architectural calls. Understanding why the bug exists, not just how to silence it. The taste that separates a working solution from a good one. These are the muscles that make you valuable, and they atrophy fast if you hand them over. Use AI for the parts where speed matters more than mastery, boilerplate, syntax recall, first drafts, rubber-ducking, and protect the parts where mastery is the point.
The engineers I see thriving with AI aren't the ones with the cleverest prompts. They're the ones who stay in the driver's seat. They use the tool, evaluate the output critically, take what's useful, and discard the rest without guilt. They've stopped trying to make AI replace their judgment and started using it to amplify it.
The difference between AI working for you and you working for AI is, in the end, just this: who is doing the thinking. Keep that part. Delegate everything else.