AI has changed how we work. I've built a lot of AI and ML projects, and AI coding assistants now handle much of the boring work for me: boilerplate, refactors, test scaffolding, the first draft of a tricky function. On a good day it feels like having a fast, tireless pair programmer.
Those projects also taught me something the hype skips over: AI is a boon only when you know how to use it properly. Trust it blindly and the tool that was supposed to save you hours can quietly undo days of work.
The two-minute change that took thirty
Here's the moment it clicked for me.
I was deep in a project and needed a tiny change, literally two lines. I could have typed it myself, but it felt faster to just tell the AI what I wanted and move on.
It made my two-line change. It also "helpfully" changed other things I never asked about: it renamed a variable, reworked a function nearby and adjusted logic in another part of the file. None of that was in my request.
Then things started breaking. What should have been a two-minute task became thirty minutes of tracking down what had changed, working out why and putting back the code that had been working fine.
The AI hadn't done what I asked. It had done what it thought would help, and those are not the same thing.
Why this happens
AI coding tools are built to be helpful, and that's exactly the problem. Give a model a small task and it often reads it as a chance to "improve" whatever it sees nearby. It doesn't know which parts of your code are fragile, which strange-looking line is there on purpose or which function three other modules quietly depend on.
You have that context. The AI usually doesn't. When you hand over control without checking the output, you're betting that its guesses match your intent. On a real project, sometimes they won't.
How I work with AI now
I didn't stop using AI. I changed how I use it.
1. Keep the scope tight and say so
I don't just say "fix this." I say "change only these two lines, don't modify anything else." Stating the limit up front cuts down a lot on surprise edits.
2. Ask for the plan before the change
For anything beyond a trivial edit, I ask the AI to explain what it's going to change before it changes it. If the plan touches files or functions I didn't expect, I catch it before it lands.
3. Read every diff
This is the big one. I treat AI-generated code like a pull request from a new teammate: helpful and fast, but not merged without review. If a two-line request comes back as a forty-line diff, that's a red flag.
4. Commit before you prompt
I commit before I let AI touch anything. If it goes sideways, rolling back takes one command instead of thirty minutes of archaeology.
git add -A && git commit -m "checkpoint before AI edit"
# ...let the AI make its change, then review exactly what it touched:
git diff
# not what you asked for? throw it away:
git restore .5. Know when to just type it yourself
For a two-line change you already understand, writing it by hand is often faster than prompting, waiting and reviewing. AI pays off on the work that's actually tedious, not on every keystroke.
The real lesson
AI isn't the problem. Blind trust is. AI is an amplifier: in the hands of someone who reviews, questions and stays in control, it multiplies productivity. In the hands of someone who accepts every suggestion, it multiplies mistakes just as fast.
The developers who'll get the most out of AI aren't the ones who use it the most. They're the ones who know when to rely on it, when to check it and when to tell it no.
Use AI. Just don't hand it the steering wheel.
