Someone on X posted an observation some time ago that kept me wondering. Junior developers are embracing AI-assisted development with enthusiasm, very senior engineers understand immediately why it matters, and the cohort in the middle (the twenty-year veterans, the staff engineers, the technical leads who built their careers on mastery) are the ones digging in. Not everyone of course, but statistically.
The pattern is counterintuitive until you think about it.
Junior developers have no sunk cost. They entered a world where the tool already existed. They didn’t spend a decade internalizing the syntax, the patterns, the framework idiosyncrasies, the hard-won debugging reflexes that constitute expertise in the execution layer of software development. They never had to. The tool was there. Embracing it isn’t a betrayal of anything they built. It’s just the environment.
Very senior engineers (the ones who’ve been in the field long enough to have worked on systems that nobody maintains anymore, who’ve watched the same tech debt accumulate across enough companies to know it will never be addressed through normal means) understand something the middle cohort doesn’t: most of the code that exists right now is quietly rotting. Not dramatically. Not in any way that will trigger an emergency. Just slowly, session by session, deadline by deadline, becoming harder to reason about, harder to change, more expensive to touch. The landscape evolves, those projects linger. These engineers see AI-assisted development not as a threat to their expertise but as the first credible answer to a problem they’ve watched worsen for several decades.
The middle is where it gets complicated.
The twenty-year veteran has something the junior doesn’t and something the thirty-year veteran has already recategorized: a very large investment in execution skill. Not a theoretical investment. A real one. Years of deliberate practice, late nights with documentation, hard problems solved through accumulated pattern recognition. That investment is not imaginary. It produced real results. It was the thing that got them promoted, that earned them credibility, that made them the person people came to with hard problems.
The sunk cost fallacy, in its clinical form, is using the cost of a past investment to justify a present decision. The problem here isn’t that the investment was worthless, but that it was genuinely valuable, in a context that is changing. The effort done in those past decades’ return depended on the next decades looking like it, and that post moved.
Most mid-senior engineers gained deep structural knowledge (system design, domain reasoning, the ability to recognize when something is wrong before it breaks), still transfers. The execution skill (knowing exactly which parameters a function takes, the specific incantation for a build configuration, the muscle memory of a particular framework) is exactly the layer the tool now handles under direction. Not autonomously, not flawlessly, but fast enough and well enough that producing it by hand is no longer where the value sits.
That distinction is where people get stuck. Because the execution skill was the visible, measurable, teachable part. It was the thing that could be demonstrated in an interview, evaluated in a code review, cited in a performance review, what moved the needle. The structural judgment underneath it is harder to name and harder to claim.
By every indicator, I should be in the resistant middle. I’m not. I built a methodology that treats the tool as the primary executor and the specification as the primary artifact. Besides, it’s not that I don’t have sunk costs. I do. Having an education in AI pre-ChatGPT and in NLP probably has something to do with it, but the excitement I feel when using these tools might go beyond that.
Another likely reason is that I got far enough into the practice to see what the tool actually does to the work. It doesn’t replace the judgment. It removes the friction between the judgment and its execution. That’s not a threat to expertise. It’s what expertise was always supposed to feel like. Be the architect, not the mason, plumber, contractor, electrician, painter, and janitor.
The junior developer gets there by default. The very senior engineer gets there through pattern recognition. The middle cohort has to choose it, which means accepting that the most valuable part of what they built over twenty years is not the part that’s changing.
That’s harder than it sounds. But it’s the only move that works.
---
*Juan Carlos Ghiringhelli is the founder of Pragmaworks (pragmaworks.dev), and a twenty-year veteran who chose the other path.*