The "old developer versus new developer" framing usually shows up attached to something being sold. A course, a bootcamp, a tool. The pitch is that everything you knew is obsolete and there is a new way, available for a monthly fee.
That is not what happened. Something real did change, but it is narrower and more interesting than the pitch, and getting the shape of it right matters for what you spend the next year learning.
The one thing that actually changed
The cost of producing code fell by a lot. The cost of deciding what code should exist, and of verifying that the code in front of you is correct, did not fall at all.
That is the whole change. Everything else follows from it.
When producing code was expensive, the scarce skill was implementation. The person who could turn a Jira ticket into working software fastest was the most valuable person in the room. Knowing the API surface by heart, typing quickly, having written the same authentication flow six times, all of that compounded into real advantage.
Now the production step is cheap and the two steps around it are not. The scarce skill moved to the edges: knowing what to build, and knowing whether what came back is right.
What quietly lost value
I want to be specific here, because vagueness is how these articles avoid being wrong.
Memorising API surfaces. Knowing the exact argument order of a method used to separate people. It is now the least differentiated thing you can know.
Boilerplate throughput. Being fast at the scaffolding, the CRUD endpoint, the form with eleven fields. Still useful, no longer a differentiator, because the floor came up for everyone.
Being the person who knows the one flag. Institutional knowledge of obscure tool configuration was real leverage. Much of it is now a question you ask and get answered in ten seconds.
Writing from scratch as a default. Not because writing code is bad, but because starting from a blank file is now one option among several rather than the only one.
None of these went to zero. They went from "this is your edge" to "this is table stakes", which feels the same as going to zero if it was your edge.
What got more valuable
Reading code quickly and suspiciously. This is the big one. You now review far more code than you write, much of it produced in seconds by something that does not know your system's history. The engineers doing well with these tools are not reading less code. Most of them are reading considerably more, just faster, and with a sharper eye for the thing that looks plausible but is wrong.
Writing clearly. A specification that is ambiguous to a colleague is ambiguous to an agent, except the agent will not stop to ask. It will pick an interpretation and produce two hundred confident lines based on it. The ability to state precisely what you want, including what you do not want, is now directly load-bearing.
Verification. Can you tell whether this works? Not "does it run" but "is it correct, at the edges, under the conditions that actually occur in production". Tests, types, invariants, a data model that makes bad states unrepresentable. Every one of these got more valuable, because they are how you check work you did not do by hand.
Architecture and boundaries. When code is cheap, the volume goes up, and the cost of a bad boundary goes up with it. Deciding where the seams are, what owns what data, which module is allowed to know about which, is not something you can delegate, because it is the thing that determines whether the next ten changes are easy or awful.
Knowing when to stop. Cheap production makes it very easy to produce a lot. Restraint is now a technical skill.
The trap
The popular reading of all this is that the new developer does not need fundamentals. Just describe the outcome and review the result.
It is exactly inverted. Fundamentals matter more now, for a plain mechanical reason: you cannot review what you do not understand.
If you cannot read the query plan, you cannot tell that the generated query will fall over at a million rows. If you do not understand the event loop, you cannot see why the generated handler blocks. If you have never debugged a race condition, the code that has one looks fine, because code with a race condition always looks fine.
The engineer who skipped the fundamentals and leaned entirely on generation is not fast. They are fast until the first real bug, and then they are stuck in a way that is difficult to get unstuck from, because the codebase is large, they did not write it, and they do not have the mental model to hold it.
I have watched this happen. It is not a hypothetical.
What I actually changed in my own work
Concretely, since this is the part that usually goes missing:
I write the data model and the boundaries myself, by hand, before anything else touches the problem. That is the part where a wrong decision is expensive to unwind, and it is fast to do properly.
I write tests before delegating anything with a checkable answer. Not for ceremony. It gives the agent a target and gives me a way to tell it is done without reading every line at the same intensity.
I read every diff. All of it. This is the non-negotiable one. A diff I have not read is not work I have finished, it is work I have deferred with interest.
I keep the interesting parts. The problems that are actually fun to think about, I still do myself, partly because that is where judgment gets built and partly because if you delegate everything enjoyable about the job you will stop being good at it.
I stopped delegating anything where I cannot define done. If I cannot say what correct looks like, I am not going to recognise it when it arrives.
The part nobody wants to hear
The bar for "impressive" went up, not down.
When producing a working application in an evening was hard, doing it was a signal. Now that it is broadly achievable, it signals very little. What is left as a differentiator is the same set of things that was always hardest: choosing the right problem, having taste about how the solution should feel, and caring enough to finish the last twenty percent where the empty states and the error handling and the accessibility live.
Those did not get automated. They got more valuable, because the work surrounding them got cheaper.
So which one are you
The framing is wrong, is my honest answer. There is no old developer and new developer. There is one job whose centre of gravity moved from producing code to specifying and verifying it, and the people adapting well are mostly people with strong fundamentals who added a new set of tools on top.
The ones struggling fall into two groups that look opposite and share a cause. One refuses the tools and is now slower than they need to be at work that genuinely is faster now. The other adopted the tools without the fundamentals and cannot tell when the output is wrong.
Both made the same mistake, which is treating this as a replacement rather than a shift in where the hard part lives.
If you want the practical side of that shift, the guide to working with Claude Code covers how I actually run it day to day, and the skills piece covers what I would learn deliberately this year.
- #Engineering
- #AI
- #Career
- #Full Stack
- #Developer Tools