It always was.
The industry just had a flattering story that made the job sound more like invention and less like reading comprehension with consequences.
The story went like this: software development is the act of producing code. Blank file, focused engineer, working system. Nice little myth. Easy to sell. Easy to turn into interview loops, productivity metrics, and manager-friendly diagrams where the arrows are all pointed in the direction of output.
The story was never quite true. It is now obviously not true.
The hard part was always reading.
The Job Was Always Reading
Look at a normal engineering week when the calendar has not been cleaned up for a performance review.
You are debugging code you did not write. You are reviewing a pull request from another team. You are trying to understand why a service only fails when the customer is large, the payload is ugly, and the clock is somehow involved. You are reading logs, stack traces, stale documentation, migration notes, generated clients, half-remembered Slack threads, and a test that is either protecting behavior or preserving a historical accident.
The writing is the visible part. It is often the receipt. The work happened before that, while you were building the mental model that made the change small enough to trust.
Senior engineers have always known this, even if we do not always say it clearly. The useful ones can walk into an unfamiliar codebase and orient quickly. They notice where the abstractions are doing real work and where they are just decorative fencing around a mess. They can tell the difference between code that works and code that works because nothing interesting has happened yet.
That skill is not syntax. It is not framework trivia. It is not the ability to produce a function from memory while someone watches through a video call.
It is comprehension. It is judgment. It is reading.
AI Took Away the Cover Story
Generative AI did not turn software development into code review. It made it harder to pretend it was anything else.
When a model can produce a plausible implementation in thirty seconds, the important question changes immediately. It is no longer, can you type the code? It is, should this code exist?
Is it right? Does it do what it appears to do? What assumption is hiding in the helper function with the cheerful name? What happens when the input is malformed, the caller is wrong, the data is old, the service is slow, or the person using it does the thing the docs politely implied they would not do?
Those are review questions. That is the new default interface between developers and shipped code.
The uncomfortable part is that this exposed a gap that was already there. Some engineers were strong producers and weak readers. They knew the shapes. They knew the frameworks. They could generate output that looked right at a glance. But when AI handed them a firehose of plausible code, they did not have the review muscles to tell what was solid, what was merely familiar, and what was going to wander into production wearing a fake mustache.
That is not a moral failure. It is a training failure. For years, the industry rewarded visible production more than accurate understanding. AI made that bargain expensive.
Review Is Active Work
Reading code is not passive. It is not sitting quietly while syntax enters your eyes.
Good review is interrogation. Why is this here? What did the author believe when they wrote it? What does the call site assume? Which failure mode is being handled, and which one has been sent to live in the bushes? Is this abstraction reducing complexity, or just moving it to a place where fewer people will look?
You are reconstructing a system from artifacts. Sometimes the artifacts are kind. Often they are code, tests, names, comments, migrations, and the occasional TODO that has survived long enough to qualify for benefits.
This is the same skill a good editor brings to prose. Not copyediting. Judgment. The ability to see what the work is trying to do, what it actually does, where it is brittle, and what it is asking the reader to trust without evidence.
That is engineering.
How to Build Better Engineers
If reading is the core skill, then we should train it on purpose.
Code review should not be treated as a gate with vibes. It should be where judgment gets taught. A senior engineer should be able to explain why a change is risky, not just declare that it feels wrong. A junior engineer should leave a review with a better model of the system than they had when they opened the diff.
Pairing should include reading unfamiliar code, not just co-authoring new code. Onboarding should ask engineers to explain existing systems, including the weird parts everyone has learned to step around. Architecture review should include actual failure prediction, not just box alignment.
The curriculum is not mysterious. Read pull requests deeply. Read code you did not write. Read incident reports and then go find the line where reality disagreed with the diagram. Read open source to understand tradeoffs, not to collect patterns like refrigerator magnets.
The hard part is making space for it. Reading looks slower than typing until the typing creates a month of cleanup.
Hiring for the Actual Job
Our assessment rituals still overvalue blank-file production.
Whiteboard problems, toy services, take-home projects that begin from nothing: these measure a slice of the work, and increasingly the slice the machine is best at imitating. They are not useless, but they are overfunded in the imagination.
Better signal is messier. Give someone a small codebase and ask what it does. Give them a pull request and ask what they would block. Give them a bug report, logs, and a suspicious test, then ask where they would look first. Ask them which change they would make smallest. Ask them what evidence would change their mind.
That is closer to the job. Less theatrical, maybe. More inconvenient for interview scheduling. Also more honest.
The Part Nobody Wants to Measure
A lot of engineering culture still points its instruments at output. Tickets closed. Points burned down. Commits landed. Pull requests merged.
The dashboard is green, which narrows the problem down to reality.
None of those numbers tell you whether the engineer understood the system. They do not tell you whether the code fits the existing shape, whether the edge cases were considered, or whether the next person will be able to reason about it under pressure.
AI makes this worse if we let it. It can flood the system with output faster than the organization can absorb responsibility for it. That does not make engineers obsolete. It makes judgment more expensive and more important.
The tools changed. The job got less theatrical.
It was always reading carefully, thinking critically, and writing as little code as necessary to solve the actual problem. That is still the job. It is just harder to hide from now.