Imagine: You are in a meeting with a vendor. It is going fine. Then they ask a completely normal question:
"So, how exactly does X work?"
And you stall. Not because it is a hard question. Because you shipped X, you own X, and you did not actually write X. Your A.I. did, and you skimmed it, and it worked, and you moved on.
I had this happen to me. It was no big deal, I explained myself and found the answer, but I did not like the feeling of not knowing.
The worry is real, and it is not new
One of the big fears about A.I. is what it does to how much we learn, and how well.
We are already leaning on it hard. People get their news explained to them. Kids get their homework answered. We get our custom software written. These are genuinely great use cases.
The problems start when:
- We read the A.I. summary and never look at the actual source.
- We get the answer instead of doing the work, so we never actually learn much.
- We accept the code without understanding it, and then something breaks and we have no idea where to even start looking.
For a developer or IT professional, the bill comes due in three ways. You learn less about how your own system works. Your troubleshooting gets slower and shallower. And your codebase quietly turns into a liability, because you are responsible for something you cannot explain.
None of that shows up on day one.
The Manager Parallel
I have kinda lived a version of this transition, and so has every manager reading this.
When you move from writing code all day to managing people who write code all day, you produce less. Way less. And you do lose a little of your edge. That is real.
But something else happens. You start exercising different skills, and they turn out to matter a lot: reading a system at the architecture level, asking the question that unblocks somebody, knowing which risk is actually the risk. You stop being the person who types the most and you become the person who understands more.
And honestly, your "old" skills become a foundation for those new skills. For non-technical folks, your expertise in your domain becomes incredibly useful for directing the output and checking the quality.
So the goal is not "use less A.I." The goal is to make sure the thing you traded away is the typing, and not the understanding and awareness.
How I Avoid This Issue
I let A.I. do nearly all of my coding, and I have not felt myself getting dull. Here is what that actually looks like for me:
General Tips
Make it explain itself, on purpose. I ask a lot of "why" out loud. Some prompts I use constantly:
- "Explain this like I have to defend it in a design review tomorrow."
- "What approaches did you consider and reject here, and why?"
- "What is the riskiest part of this change?"
- "What would break if traffic went up 10x?"
Any of those will teach you something or even catch real problems.
Stop on the words you do not know. A term goes by that you cannot define: so stop and ask, or go look it up. Small but fundamental and very powerful.
Recite it back before you ship it. For anything meaningful, I close my agent and try to explain the change or work to myself in my head. If I cannot get through it cleanly, I should review the work and plan again.
Keep building things that challenge you. Do it on your own time or as time allows, on something you actually care about. Run into the wall, get stuck, try again. Nobody is watching, there is no deadline, and it is still a quick way to learn anything.
Watch how other people use theirs. Everyone has worked out some workflow trick. Ask them.
Tips Particularly For Developers
Read the logs yourself, especially when the agent is circling. Let the A.I. read them first, absolutely. But the moment your agent takes its third swing at the same bug, that is your cue to open the logs personally. Nine times out of ten there is a line in there that it skipped right past, and you spotting it is what breaks the loop.
Use the design phase as your learning budget. Before anything gets built, I will have it lay out two or three approaches with real tradeoffs, and tell me who else does it that way. That is the requirements and design part of the SDLC. This is where most of my exposure to new frameworks and patterns comes from now.
Read the diff instead of the file. Telling yourself you will "skim the whole file later" can end up a daunting task. Reading the diff is easier and it is the difference between approving code and reading code. If something looks weird in there, stop and ask the bot about it before it merges.
So…
Like I said, I let A.I. write most of my code. But my role remains involved, I am just not doing the actual writing anymore. I'm still testing, still designing, still exploring and asking questions.
Next time you finish something, try asking this to yourself.
"If someone stopped you in a meeting and asked how it works, could you tell them?"
Not line by line. Just the shape of it, out loud, without opening your laptop or asking your agent.
If yes, you are fine. Go faster, fam!
If not, there is likely something new for you to learn.
Top comments (0)