The productivity gain is real. I take it every day. Code that used to take an afternoon takes an hour, and the hour is not a trick. It is real work done faster.
But there is a debt building underneath the gain, and I am building it too. Most of what used to make a junior into a senior is being automated away. And judgment is built from repetition.
The repeated work is small and unglamorous, which is why nobody mourns it. Debugging and figuring things out. Stumbling onto something and making mistakes and learning from it. Reading and observing. Typing and sometimes writing. Taking notes. Questioning and searching why something is a certain way. None of these look like training. They look like the slow parts of the job, the parts you would automate first. That is exactly the problem. The slow parts were the training. Debugging was never only fixing. It was how you learned the system, one wrong turn at a time. A mistake taught you where the edges were. Reading code taught you how someone else thought. Notes were thinking with your hands. Take the doing away and you take the learning away with it, quietly, without anyone deciding to.
That is how I learned. By looking and learning. By saying I don’t know how to do it, and someone explaining it to me, or learning from Stack Overflow or docs or tutorials or any random blog. Coming across dozens of results before finding the appropriate one. Sometimes the explanation came from a person. Sometimes it came from a page. Either way, the learning started with admitting I did not know.
The dozens were not wasted time. Choosing among them was the training. You learned what appropriate looked like by seeing twenty things that were not. The model hands you one answer now, and the choosing goes with the dozens. The practice was never only finding the answer. It was learning to recognize it. Appropriateness is a judgment, and you cannot borrow it from a single answer, because a single answer never shows you the near-misses.
Meetings are recorded and transcribed now, and that gives people a reason to be less present. You can always read the transcript later, so nobody listens now. Attention is outsourced the same way the typing is. That is a second kind of practice disappearing. Paying attention used to be part of the job. Now the machine pays attention for you, and you get the summary, and the summary is not the same as having been there. Being present is bare minimum. It is just respectful. And it does not waste time in follow-ups that could have been handled if one was present. That is one small item in a long list of other things.
I do purely AI-assisted development. I am not describing someone else’s problem. I see the bite already. It is not a prediction. It is recurring. In discussions about newly built items, the answers about what is happening under the hood get less and less nuanced. During alerts, the most prominent statements are "Claude thinks xyz." The model’s guess stands in for someone’s understanding, and the room moves on it. Architecture reviews are sometimes going away, because shipping is so cheap in time that review starts to feel like the expensive part. The review that used to catch the misunderstanding now costs more than the shipment it would have reviewed. System design has started to take a step back. Nuanced discussions and decisions are rare. And it is less common now that when an error occurs, a developer knows from the message where something might be wrong. The error message used to be a map. Now it is noise. People see less and less of the bigger picture, and of the contracts between systems. Nobody holds the whole thing in their head anymore, because nobody had to build it piece by piece.
What goes missing is resiliency, and understanding of consequences on decision making. Every action has a reaction. In a system, if you don’t foresee it, it is a recipe for failure in one place, or everywhere, or both. A contract between systems exists to say what touches what before anything moves.
Resiliency is not something you add later; it is what you get from foreseeing where a change lands before you make it. And when nobody holds the whole in view, nobody can say what a decision will touch, so decisions get made blind to what follows, and what follows arrives anyway. The reaction does not wait to be foreseen. It just arrives, and the team meets a failure it never decided to risk.
This is not only my view from my rooms. A September 2026 survey of 300 senior engineering leaders found that 35% of AI-generated code reaches production before engineers have fully understood it. And 93% said an AI hallucination had misdiagnosed a root cause at least once. It comes from a debugging company, and it polled leaders at large companies with complex codebases, so read it as the hard end of the industry, not the whole of it. Even at that end, the numbers say what I see: engineers in it spend an average of 16.9 hours a week debugging AI-generated code, about twice as long as they spend writing it. The code ships. The understanding does not always ship with it.
This is software engineering as I see it. Other trades have their own version of the same trade. Wherever the machine does the doing, the practice goes, and wherever the practice goes, the judgment goes later.
I use LLMs every day. What I want to keep is the craft underneath the speed: the debugging, the figuring out, the stumbling onto something and learning from it. Those were how judgment got built. The choosing among dozens was the training. Use the model for the doing. But the judgment is not part of the doing to hand over with it.
The practice is disappearing now. The shortage arrives later. You cannot hire judgment later if the practice that builds it is gone today. Nobody decided to stop training people. The doing just moved to the model, and the learning moved with it, quietly. The tools keep getting better either way. The question is only whether the craft and the judgment stay with the person doing the work. That is the part I want to keep.