AI Reduced the Cost of Writing Code. It Didn't Reduce the Cost of Understanding It.
AI has made writing software dramatically cheaper.
Generating a function, creating an API endpoint, writing a database query, producing tests, refactoring a component, or fixing a straightforward bug can now take a fraction of the time it used to.
But there is an important distinction:
AI reduced the cost of producing code. It did not reduce the cost of understanding what that code means for the system.
And that distinction is becoming increasingly important.
The Shift From Writing to Verifying
A 2026 longitudinal study by Annie Vella and Kelly Blincoe examined how professional software engineers' work changed with AI coding assistants.
The researchers surveyed engineers at two points six months apart. In the second survey, 82% of participants reported spending less time writing code.
The study also found a broader shift from creation toward verification activities — including directing AI, evaluating its output, and correcting what it produces. The researchers describe this emerging category of work as “supervisory engineering work.” (arXiv)
That finding matches something increasingly visible in real product development.
AI can produce code very quickly.
The difficult part is deciding whether that code should exist in the first place.
Code Can Be Correct and Still Be Wrong
Consider a simple request:
“Add an endpoint that lets users update their profile.”
An AI coding assistant can probably generate the endpoint.
It can create the route.
It can write the controller.
It can add validation.
It can update the database.
It can even generate tests.
But production engineering starts asking different questions.
Who is allowed to update this profile?
Can one user modify another user's data?
What happens if the request is replayed?
What happens if the database is unavailable?
What happens if two updates arrive simultaneously?
Are all user-controlled fields validated?
Could sensitive fields accidentally become writable?
Is the API consistent with the authentication model already used elsewhere?
What happens when this endpoint is called 100,000 times?
The generated function may be perfectly valid code.
And the implementation can still be wrong for the system.
What I Look For When Reviewing AI-Generated Code
When reviewing AI-generated code, I care about five things before I care about whether the implementation is elegant.
1. Intent
Does the code actually solve the product problem?
AI is very good at implementing the request it is given.
That does not necessarily mean it understands why the request exists.
A technically correct implementation can solve the wrong problem, introduce unnecessary complexity, or create behavior that conflicts with the actual product requirement.
The first question should therefore be:
Is this the right thing to build?
Not:
Does this code look good?
2. Architecture
Does the change fit the existing system?
AI can produce an impressive implementation in isolation.
But production systems are rarely isolated.
There are existing services, databases, queues, authentication systems, caching layers, conventions, deployment processes and technical constraints.
An AI-generated feature can quietly introduce:
-
a second way of doing the same thing
-
duplicated business logic
-
unnecessary abstractions
-
inconsistent data access
-
another state-management pattern
-
another dependency
-
another service boundary
The code may work.
The architecture may still get worse.
3. Security
What can this code do that the user should not be allowed to do?
This is one of the areas where review becomes especially important.
I want to know:
-
Is authentication actually enforced?
-
Is authorization checked?
-
Is ownership verified?
-
Is user input validated?
-
Are secrets protected?
-
Can sensitive data leak through responses or logs?
-
Can an attacker manipulate identifiers?
-
Are internal APIs exposed unintentionally?
Security is not something that can be delegated simply because the generated code passes its tests.
The question isn't only:
“Does this request work?”
It is also:
“Who else can make this request, with what data, and under what conditions?”
4. Failure
What happens when the happy path stops working?
AI-generated code often looks strongest when everything works.
Production systems are defined by what happens when things don't.
What happens when:
-
the database is slow?
-
Redis disappears?
-
an external API times out?
-
a request is retried?
-
a queue contains duplicate messages?
-
a network connection drops?
-
a transaction partially fails?
-
two users perform the same action simultaneously?
A successful response is only one possible outcome.
Engineering requires understanding the others.
5. Operations
Can we actually operate this code after it ships?
Production code needs more than correctness.
We need to know:
-
Can we observe failures?
-
Can we trace requests?
-
Can we identify abnormal behavior?
-
Can we measure its cost?
-
Can we roll it back?
-
Can another engineer debug it?
-
Can we understand why it exists six months later?
A feature that works but cannot be understood or operated becomes technical debt surprisingly quickly.
The New Engineering Bottleneck
This is where AI-assisted development gets interesting.
If writing code becomes significantly faster, the bottleneck doesn't necessarily disappear.
It can move.
Instead of spending most of the time typing implementation details, engineers may spend more time:
directing → reviewing → testing → debugging → validating → deciding
The 2026 longitudinal study provides evidence for exactly this kind of shift toward verification and supervisory work. (arXiv)
That changes what developer productivity means.
If an engineer can generate 10 times more code but only review twice as much code, the system has not necessarily become 10 times more productive.
It may simply be producing technical decisions faster than humans can safely evaluate them.
AI Makes Context More Valuable
This is also why I think system understanding becomes more valuable as coding becomes more automated.
Knowing syntax is useful.
Knowing a framework is useful.
Knowing how to implement a feature is useful.
But understanding why the system works the way it does becomes even more important when implementation itself can be delegated.
An engineer needs to understand:
What is the source of truth?
Where does state live?
Who owns this data?
What happens during failure?
What are the security boundaries?
What assumptions does this service make?
What happens when traffic increases?
What happens when another engineer changes this six months from now?
Those questions cannot be answered reliably by looking at a generated function in isolation.
They require system-level context.
The Role of the Engineer Is Changing
I don't think AI makes software engineering less important.
I think it changes where engineering value is concentrated.
The engineer of the future may spend less time manually producing every line of implementation and more time deciding:
-
what should be built
-
what should not be built
-
how systems should interact
-
whether generated code is safe
-
whether the implementation matches the product intent
-
how the system behaves under failure
-
what consequences a technical decision creates
AI can accelerate implementation.
Engineering still has to own the consequences.
The faster code generation becomes, the more valuable the ability to understand, question, verify and take responsibility for that code becomes.
Research
Vella, A. & Blincoe, K. (2026). The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study. The study surveyed professional software engineers at two points six months apart and examined changes in task focus, productivity and developer experience. (arXiv)
Read the full research paper on arXiv
Key finding: 82% of participants reported spending less time writing code, alongside a broader shift toward verification and what the researchers call supervisory engineering work. (arXiv)
