I use AI every day. I ask it to explore approaches, trace unfamiliar code, suggest test cases, take a first pass at repetitive work, and push back on decisions I'm not fully convinced about.
It's made me faster. It hasn't made the job automatic.
The code can arrive in seconds now. I still have to decide whether it belongs in the system.
The first draft is no longer the hard part
When a first draft was expensive, producing it took up much of the work. AI changes that balance. It can turn a rough idea into something clickable before I would have finished writing a detailed implementation plan.
That creates a new temptation: because the output looks complete, it feels as if the thinking must be complete too.
It isn't. I still need to ask who the feature is for, what must remain true when the happy path ends, and which tradeoff the customer or the next engineer will inherit. AI can help me work through those questions, but it can't answer them without the context I provide.
More output means more to review
AI-generated code is often most dangerous when it looks ordinary. The names are reasonable. The tests pass. The patch is close enough to the surrounding code that nothing immediately feels wrong.
But it may have put a responsibility in the wrong layer, missed an existing invariant, duplicated a helper, or handled the success path without understanding what production does when a dependency fails.
I review AI-produced changes the same way I review an unfamiliar patch from a capable engineer. I trace the request through its boundaries. I identify what must remain true. I look at failure paths and data changes. Then I run the behavior in the real system instead of treating a green test suite as the end of the conversation.
Passing tests is evidence. It is not permission to stop thinking.
Where AI earns its keep for me
AI is especially useful when the work has a wide surface area: learning how an unfamiliar part of a repository fits together, comparing implementation options, building a test matrix, or checking a change for cases I may have missed. It is also very good at the repetitive work that is necessary but does not need to consume the best part of my attention.
I use the time it saves on the parts that need more context: sharpening the requirement, checking the architecture, talking through a tradeoff, and testing what happens outside the happy path.
I also ask AI to challenge me. Agreement is cheap. A useful review should try to show me where my assumption breaks.
I keep the final decision
AI doesn't know which customer promise is hidden behind a strange piece of code. It wasn't there for the outage caused by a similar shortcut. It won't be the person answering when the release causes a problem.
That doesn't make it a toy. It makes it a powerful tool with no stake in the outcome.
My responsibility is still the same: understand the problem, make the tradeoffs visible, verify the work, and own what reaches production. I want the speed. I just don't want it to become an excuse for lowering the bar.