In early 2026, researchers trying to measure AI's effect on developer productivity ran into a very human problem: some developers no longer wanted to accept tasks that might require them to work without AI.
The researchers called it a selection effect. I keep thinking about it as a small confession.
Not long ago, AI was an experiment living in a side panel. We opened it when autocomplete failed or when a regular expression became embarrassing. Now, for many developers, it is simply part of the room. It is there when we open the editor in the morning, when we inherit a repository nobody has touched in years, and when a test turns red late at night.
We can close the panel. We can turn off the agent. We still know how to code.
So why does working without it already feel like working with one hand missing?
AI took over the pauses
AI did not enter software development by announcing that it would replace us. It arrived one small relief at a time.
It completed the line we were already about to write. Then it drafted the test we had been postponing. It explained an unfamiliar function, translated a stack trace into plain English, and found the configuration flag buried in documentation we did not want to read again.
None of that felt like dependence. It felt like momentum.
But think about the last time your assistant went offline. The unsettling part was probably not that you had forgotten the language. It was the silence before the first move. You had to decide where to look. You had to hold the uncertainty by yourself. You had to stare at the error long enough for a theory to form.
Those pauses used to be ordinary. Now they feel like friction.
Perhaps that is what AI has changed most deeply. It has not only changed how we produce answers. It has changed how long we are willing to remain alone with a question.
The relief is real
It is easy to talk about AI dependence as if developers are trading discipline for laziness. That misses what the tool feels like from inside the work.
Software development contains a surprising amount of private shame. There is the senior engineer who has forgotten the syntax of a basic command. The new hire afraid that asking one more question will confirm everyone's doubts. The developer working in a second language who knows exactly what is wrong but cannot phrase the explanation quickly enough. The person joining a decade-old codebase where every important decision lives in somebody else's memory.
AI is patient with all of them.
It does not sigh when the question is repeated. It does not say, “You should already know this.” It is available at 2 a.m., and it can turn a blank screen into something that can be argued with. Even when the answer is imperfect, having an answer changes the emotional weight of beginning.
That matters. Sometimes what looks like productivity is actually relief: less fear of being stuck, less embarrassment, less loneliness in front of a machine that refuses to explain itself.
For many developers, AI has also returned energy to the parts of the job they care about. It can carry boilerplate, repetitive tests, migration scaffolding, and the hundredth variation of an API client. The mind arrives at the interesting problem less tired.
We should not dismiss that as a shortcut. A tool that gives people more courage to explore is doing something genuinely valuable.
The difficulty is that comfort and dependence grow from the same root.
We use what we do not fully trust
Developer surveys keep finding the same strange relationship: we use AI constantly while remaining suspicious of what it gives us.
That tension will be familiar to anyone who has watched a confident answer collapse under one edge case. The code looks right. The names are clean. The explanation is calm. Only after the third failing test do we notice that the model invented a method, misunderstood a business rule, or solved a simpler problem than the one we actually have.
And still, the next time we are stuck, we ask again.
This is not hypocrisy. Trust is not one thing.
We may not trust AI to make the final decision, but we trust it to give us a first direction. We may not trust the patch, but we trust the conversation to loosen the knot in our thinking. We may not believe the answer, but we believe there will be something on the screen instead of nothing.
AI has become the colleague we would never allow to merge directly to main, yet somehow miss the moment it leaves the room.
We move faster because the next step appears quickly. We remain responsible for checking whether it can hold our weight.
What disappears when the struggle disappears
There is a particular kind of knowledge that comes only from being stuck.
Before AI, an unfamiliar error might send us through the stack trace, into the caller, across the documentation, and finally toward an assumption we did not know we had made. The route was inefficient. It was also how the codebase became a place rather than a collection of files.
We remember the systems that once resisted us.
The bug that took an afternoon teaches us where state really lives. The production incident teaches us why a boring safeguard exists. The library we misunderstood three times becomes the library we can later explain to somebody else.
When AI removes the resistance, it may also remove the story that makes the lesson stay.
An early study on developers learning an unfamiliar library found something that feels intuitively true: people who delegated the task learned less than people who used AI to ask conceptual questions and test their own understanding. The important distinction was not “AI or no AI.” It was whether the tool replaced thought or participated in it.
This is especially difficult for junior developers. Experienced engineers can recognize a suspicious abstraction because they have built the wrong abstraction before. They can sense that a tidy patch does not belong in the system because they remember the system's scars. But where will the next generation get that instinct if every rough edge is smoothed before they touch it?
Mentorship was never only the transfer of answers. It was the slow transfer of taste: what to worry about, when to stop, which compromise will become expensive, and why a solution that works is still not ready.
AI can explain all of those ideas. It cannot yet recreate the feeling of another person choosing to stay beside you while you learn them.
The shortcut may be real. Understanding still has to cross the distance.
Code used to carry fingerprints
There is another change that is harder to measure because it lives between people.
Human-written code often carries traces of its author. A strange helper function may come with a memory of the incident that required it. An awkward comment may reveal exactly where someone was uncertain. During review, we do not only inspect the change; we reconstruct the thought behind it. We ask questions, and another person answers from the path they took.
AI-generated code can arrive without that path.
It may be polished and technically plausible, yet feel strangely ownerless. The author can describe what they asked for but not always why the result took this shape. The reviewer is then left doing work that used to belong partly to the writer: rebuilding intent, checking assumptions, and discovering the hidden edges of a decision that nobody remembers making.
This is the unease beneath many community discussions about AI-generated pull requests. The complaint is not simply that the code is bad. Bad code is familiar. The deeper discomfort is that the social contract has changed.
One person can now create a large change in minutes. Another person must still spend human attention to understand it. The time saved at the keyboard can quietly reappear in code review, maintenance, security work, or the night when the system fails and someone has to explain what the generated patch was trying to do.
Code has always been communication. When generation becomes nearly free, attention becomes the scarce part—and attention belongs to people.
Maybe the craft is moving
For some developers, none of this feels like loss. It feels like finally being allowed to work at the level they always wanted.
They write fewer lines and spend more time shaping the problem. They compare several designs before committing to one. They think about the user, the architecture, the failure modes, and the boundaries that an agent must not cross. The craft moves from producing every piece to directing the whole.
That can be a real evolution. We did not stop being developers when assemblers replaced machine code, or when frameworks replaced hand-built infrastructure. Software has always moved upward through abstraction.
But every abstraction depends on somebody understanding what is underneath.
A developer directing AI still needs taste. A reviewer still needs a mental model. An architect still needs to know what happens when the clean diagram meets a slow network, a corrupted message, an exhausted team, or a frightened user.
If AI writes more of the implementation, human judgment does not become less important. It becomes easier to overlook and harder to cultivate.
The hopeful version of this future is not one where developers matter less. It is one where we become more deliberate about what only people can carry: context, care, doubt, responsibility, and the ability to recognize when a technically correct answer is wrong for this particular system and these particular humans.
Stay, without disappearing
Can we still walk away from AI?
Individually, yes. We can close the panel tomorrow. Professionally, the question is already more complicated. Expectations are changing. Codebases are filling with generated work. New developers are meeting AI at the beginning of their careers, not halfway through them. Even someone who never uses an assistant will increasingly review and maintain code that came from one.
There is no private path back to a pre-AI industry.
But perhaps leaving is the wrong measure of freedom. The more meaningful question is whether we can remain present while the tool stays.
Remaining present means reading the patch even when every test is green. It means asking why after the answer works. It means refusing to merge what we cannot explain. It means giving junior developers the time to struggle without treating that time as waste, and giving reviewers credit for the invisible work of protecting a system from plausible mistakes.
It also means preserving moments when no assistant answers immediately—not as a purity ritual, but as a way to hear our own thinking again.
Most of us will keep using AI. The relief is real. The possibilities are real. So are the unease, the dependence, and the quiet fear that something we loved about the work may be slipping away.
We do not have to choose between denial and surrender.
The future of software will not be decided by what percentage of the code AI writes. It will be decided in smaller moments: whether we understand before we accept, whether we teach instead of merely forwarding an answer, whether we protect another person's attention, and whether we still take responsibility when the generated code reaches the real world.
AI can stay.
We must make sure that we do, too.
