Every repository has a ghost: code nobody on the team remembers writing. AI tools are adding to it faster than ever.
That is not a reason to stop using them. It is a reason to get better at the part they cannot do for you. Generating a function takes seconds. Knowing whether it belongs in your system takes understanding, and understanding comes from reading.
Writing was always the smaller share
Most of a developer's day is spent in code that already exists. You read to fix a bug, to add a feature without breaking three others, and to review a teammate's change. Now unfamiliar code arrives in every pull request, and it is fluent, confident, and sometimes wrong in ways that look right.
The developers who stay useful will be the ones who can open an unfamiliar file and, in a few minutes, say what it does, what it assumes, and where it will break.
Read with a question
Skimming does not stick. Before you open a file, decide what you want to learn. Where does this request get authorized? What happens when this list is empty? Which function actually writes to the database?
Then follow one path all the way through. Search for callers, jump to definitions, and add a temporary log line if you need to. One traced path teaches you more than ten files glanced at.
Code you can explain is code you own. Code you cannot explain owns you.
Practice on purpose
Pick a small open-source library you already use and read the function you call most. Write three sentences about how it works, then check them by running it with an odd input.
When an AI tool hands you code, do the same. Before you accept it, explain it in plain words. Where you get stuck is exactly the part to read again.
Reading feels slower than generating. It is also the reason generated code is safe to ship.
For structured practice, the free Debugging Is the Skill guide comes with the Haunted Repo: a small project with sixteen planted bugs waiting to be found.