The question comes up in different phrasings, but the shape is always the same. A developer on my team, usually mid-week, usually one-on-one, usually after we have shipped a feature that Claude Code wrote most of. What are you actually going to want from me in twelve months. Am I going to have a job in three years. What does it mean to be a good developer now.
It is a fair question. It deserves a serious answer, not a slogan.
Here is what I actually tell them, refined over roughly eighteen months of having this same conversation across teams. This is the operating framework I use as a manager. It is a working document, not a keynote line.
Take the concern seriously before answering it
The first thing I do when the question comes is not to answer it. I acknowledge it.
The concern is legitimate. Not in an existential way, but in a very concrete way. The developer writing this month’s tickets is watching an AI produce, in five minutes, code that would have taken them two days last year. They are not imagining the shift. They are living it. Anyone who tells them “do not worry, the fundamentals do not change” is either lying, or has not shipped anything AI-augmented recently.
The fundamentals do change. The question is how, and what that means for the person at the keyboard.
The abstraction ladder, one rung at a time
The history of programming is a stack of moments where “the job is over” turned into “the job moved up.”
Assembly to high-level languages. The compiler was going to replace assembly programmers, because who would still hand-write instruction sets when a compiler could do it faster and with fewer bugs. The compiler did replace assembly programmers, but not the profession. The profession moved up a rung: from choosing instructions to designing algorithms.
High-level languages to frameworks. Rails, Django, later React and Next.js. Frameworks were going to replace the developer, because anyone could scaffold a CRUD app in a weekend. Frameworks did commoditise the layer they covered, but not the profession. The profession moved up again: from writing the CRUD to designing the system.
Frameworks to AI-augmented development. Same pattern, one more rung. AI is going to replace the developer who writes the boilerplate, the glue code, the standard CRUD, the tests for already-understood behavior. In my teams, it already has replaced most of that work. But the profession has not disappeared. It has moved to the next rung.
The consistent thing across every rung: what disappears is the layer just below where the human was thinking, and the human’s thinking moves one layer up. What matters now is where that new layer is, and what it demands of the person standing on it.
What loses value, what gains value
Precisely, at this rung:
What loses value. Writing boilerplate. Memorising syntax. Producing a first pass of a CRUD endpoint. Translating a well-defined ticket into working code. Any task where the specification is complete and the execution is mechanical.
What gains value. Reading a codebase you did not write and holding it in your head. Deciding what to build and what to explicitly not build. Framing a problem well enough that the code can be generated against it. Reviewing AI-generated code with enough depth to catch what the AI missed. Owning a system under production pressure.
The imbalance between the two lists is real, and it is what makes the transition uncomfortable. Producing code was a large fraction of the job, and it is now a small fraction. The people who identified with production feel like the ground moved. It did.
The four signs I watch for
The abstract answer to “what does a good developer look like now” is not useful. Here are four operational signs I watch for on my team, in every project, at every review. These are the signs that tell me a developer is moving up the ladder rather than staying on the disappearing rung.
Sign 1. They ask what invariant a piece of code protects before they write it. Not “what does this function do.” Not “what is the acceptance criteria.” What is the business rule this code exists to preserve, and what breaks if it does not. A developer who asks this question is thinking one level above the code. A developer who does not ask it is producing lines the AI could have produced.
Sign 2. They read AI-generated code with the same skepticism they read code from a stranger. They do not merge because it compiles. They do not merge because tests pass. They ask what the two layers below look like, they identify the load-bearing lines, they rewrite critical sections by hand when they cannot explain the choice. The AI produces plausible code very fast. Distinguishing plausible from correct is the new senior skill.
Sign 3. They can explain a module they did not write, in under sixty seconds, without opening the file. This is the ownership test. If nobody on the team can pass it for a given module, that module is dark matter in the codebase. A developer who commits to being an explainer, and not just a producer, is protecting the team from the failure mode that AI accelerates faster than we notice.
Sign 4. They propose the design before they propose the code. When I ask them to solve a problem, the first artifact I want back is not a pull request. It is a whiteboard, a note, a two-paragraph description of what they are going to build and why. If the design is right, the code writes itself, whether the human types it or the AI generates it. If the design is wrong, no amount of AI velocity will save the sprint.
These four signs are not a checklist for hiring. They are a checklist for the conversations I have every week with the people on my team, and for the calibration I do in performance reviews. They are what “senior” is starting to mean, in an org that ships with AI.
Understanding is the new scarce resource
Here is the paradox at the center of this transition.
At a moment when code has never been cheaper to produce, understanding code has never been more valuable. This is counterintuitive until you realise that production and comprehension are not the same skill. They were roughly correlated in the pre-AI era, because the person who wrote the code had, by necessity, held it in their head. That correlation is now broken.
Production is nearly free. Comprehension is not. Comprehension is time-intensive, requires focus, requires reading the two layers below, requires stating the invariant the code preserves. The AI does not produce comprehension when it produces code. It produces only the code. The comprehension has to be done by the human, or not at all.
A developer whose value is in production is competing with a tool that produces at ten times their speed. A developer whose value is in comprehension is doing something the AI cannot do. That describes the shape of the market you are entering. I am not writing it as a slogan.
What I now expect
The four signs above translate into what I now expect from any developer I work with, at whatever level.
More judgment, less typing. The value of your judgment on what to build has gone up. The value of your typing has gone down. Invest accordingly.
More framing, less execution. Frame a problem well and the execution is mostly free. Frame it badly and no execution speed will rescue you. The scarce work is upstream of the code.
More ownership, less production. Own the modules you touch. Explain them. Debug them under pressure. Do not let dark matter accumulate under your name. A production number is a vanity metric. An ownership number is not.
More reading, less writing. Read AI-generated code with the same care you would read a colleague’s PR from three years ago. Do not merge what you cannot explain. Do not ship what you cannot defend.
These are not luxuries. They are the job, restated for the current rung.
Where this fits in what I have written before
If you have read the rest of what I have published this year, the shape of this article is the fourth piece of a larger argument I have been trying to make.
The first piece was individual. In Stop Delegating Your Thinking to AI, I wrote about the personal discipline of not letting the AI think for you. The second piece was organisational. In Test Coverage Was Enough. Ownership Coverage Is What Matters Now, I wrote about the metric a team should track when it ships with AI at any meaningful volume. The third piece was leadership. In Building for the Day You Leave, I wrote about engineering the conditions under which a product survives its founder.
This piece is the one about the developer standing at the keyboard, asking whether the profession they trained for is still going to exist. It sits under the same thesis as the other three: AI compresses execution to nearly zero and moves the value into judgment, comprehension, and ownership. The developer who invests in those three skills will find the next decade of their career more open than any decade before it. The developer who does not will find the opposite.
The honest closing
The last thing I owe my team, when they ask this question, is honesty about the shape of the trade.
The bar is going up. That is the true part of the answer. Being a good developer in 2020 required competence at production. Being a good developer in 2026 requires competence at production plus competence at judgment, comprehension, and ownership. The old skills are not obsolete. They are necessary but no longer sufficient.
For the developers who wanted to keep growing anyway, this is a great decade. The scarce resource is exactly the kind of skill that grows with reading, thinking, and taking responsibility for larger systems. The AI is amplifying them, not competing with them.
For the developers who wanted to stay at the layer where the AI is now stronger, this is a hard decade. The tickets that were paying the rent are being written faster by a model. The comfortable middle rung is disappearing.
I do not pretend there is a soft version of this trade. I do tell my team, honestly, that the discomfort is the sign that the rung under them is moving up, and that they can move with it if they want to. That is the answer I give, in the same phrasing, every time the question comes.
Whether they take it seriously is their decision. My job is to give them the framework and the honest answer, and to leave the trade as real as it is.