Reading code still gets treated like homework even though it is most of the job.
My normal weeks disappear into code I didn't write and systems I didn't design because the failure usually isn't in the spec. The evidence is in the logs, a stale migration, a suspicious test, or the one Slack thread that finally says what the edge case is.
Commits get counted and attached to a name, though most of the work happened before the commit while somebody built a model of the system accurate enough to change it without guessing. AI has made that imbalance harder to ignore by increasing the volume of code that still needs review.
Output got cheap
Writing code by hand comes with friction, and the friction does something useful. Each line forces a small decision, and by the time the thing runs you've had several chances to notice what you're actually doing.
Generated code isn't inherently unsafe, but it removes most of that friction and looks familiar enough to feel understood even when it isn't, especially when we skim the signatures and move on once CI is green.
It works a little like a corporate drug, in that the output feels like progress before anyone really owns it. A ticket closes, the Jira count moves, and a few hundred lines become production's problem. Nobody has to be lazy for this to happen, since the careful path is just more expensive than the fast one.
Read it like you own the failure
I start with what the code assumes, look for the input that breaks those assumptions, and trace what has to stay true three services away. A suspicious test might protect real behavior or be a historical accident that picked up coverage, and knowing which one you're looking at is most of the skill.
CI can tell you the tests pass without telling you they're the right tests or that the change belongs in this system at all. If you still need the model's explanation open beside you to follow the control flow, you're not finished.
This should change interviews
Typing every line used to give you a weak check on comprehension almost for free. If a model writes the lines, that check has to go back deliberately, by tracing the data and predicting where it fails before you trust the output.
That's harder to schedule and score than a blank-file exercise, but so is the production it's meant to prepare people for.
Prevention is hard to count
Senior engineers spend more time stopping bad changes before they become incidents or a quarter of cleanup. Much of that work is making the risky part visible while there is still time to fix it.
Companies still reward what they can count, and commits and merged pull requests are easy to count. Understanding leaves no trace, so AI can make the visible numbers climb faster without making the system any easier to understand.
I read far more code than I write now, including code I would never have chosen to open, and I try to read it slowly enough to notice where it surprises me before I start writing.
Where this stands
I don't trust a generated change until somebody understands it, because a tool that can't own the failure gives us more code to read, not less.
- A tool that can verify a change is safe without a person first reconstructing the system.
- Teams delivering generated code at volume with no rise in incidents or review load.