Code that works, and that I can’t explain
A while back I was changing a module. The implementation AI handed me passed first try, tests all green, and I merged it without thinking. Two weeks later that part broke. I spent ten minutes staring at code I had “written”. It runs, but I couldn’t say why it was written that way, or what one of the boundary checks was guarding against.
That felt bad. My name is on it, but it never really went through my head.
Output and understanding are coming apart
These two used to be tied together. If you didn’t understand it, you couldn’t write it. Not being able to write it was an honest signal that forced you to go and understand.
That signal is gone. You can ship without understanding, and ship fast and polished. The gap is still there, just covered by a layer of output that looks professional. It stays covered until the day something breaks.
The worse part is that it fools you. The thing got built, so you assume you can do it. Next time something similar comes up you think you have experience, when what you have is the memory of one time AI got it right.
The one check I keep for myself
Not using AI less. I still use it where it helps. It’s one extra step after finishing: close the screen and ask myself, “if it weren’t here right now, could I explain this from scratch?”
If I can, move on. If I can’t, go back and read that part until I get it. Not to avoid depending on AI, but so that piece actually counts as mine instead of borrowed.
Honestly I don’t manage it every time. When I’m in a rush I swallow it whole like anyone else. But at least I can tell which is which: what I really understand, and what I’ll have to pay back later.
Two sentences worth keeping apart
“I built it” and “I understand it” used to be near synonyms. They aren’t anymore.
AI makes the first one easy. Whether it’s worth the effort to hold on to the second is a personal call. Mine is that it is: on the day something actually breaks, the second one is what saves you.