Learning a new technology no longer gives me a toothache.
Before, mastering a framework took weeks. You read the docs, broke things, started over. The friction was part of the job. Today, I give the AI the context, it works through the documentation in a few minutes, I review, I adjust. The result comes faster. Almost always.
But one question stays with me and won't let go: who owns the merit of what gets built?
The observation
When I hit a wall today, it's almost never a technical problem. It's a context problem. A poorly framed objective. Something I didn't express precisely enough for the AI to produce what was needed.
The difficulty has shifted in nature. It's no longer in the code. It's in the clarity of intent.
I've built several tools over the past few months to speed up my own processes. A significant portion of the development was done by the AI — not by me. I move faster, that's a fact. But if someone asks me tomorrow whether I have mastery of a technology used in those tools, my honest answer is no. I supervised it. Reviewed it. Directed it. I didn't build it from scratch.
That's not false modesty. It's a professional observation.
What hasn't changed its name
A developer's resume lists technologies. React, Kubernetes, Spring Boot. That list has always been an implicit promise: I've practiced this, I've struggled with it, I know where the traps are.
That promise holds less and less. You can ship functional code in a technology you'd never touched before this morning. Claimed mastery and actual mastery have drifted apart — while the CV format hasn't kept up.
The problem isn't AI. The problem is that we're still measuring competence with the tools of before.
Where value is migrating
Three skills seem to be taking over from pure technical mastery.
The first: being able to frame an objective precisely enough for the AI to produce something usable. That's not trivial. In my experience, it's the most unevenly distributed skill among the developers I meet.
The second: being able to review and judge a result you didn't produce yourself. Spotting what's wrong in code you didn't write line by line requires a different kind of reading than the one you learn in school or as a self-taught developer. You're no longer debugging your own logic. You're auditing someone else's — who happens to be a machine.
The third: being willing to own responsibility for a result you didn't fully control in its details. That's the most uncomfortable one. Signing off on work you supervised rather than executed changes your relationship to your own output.
None of these three skills has an established name in the industry. They aren't taught the way a programming language is taught. They're acquired on the job, in silence, often without noticing.
The name that's missing
The word "developer" describes someone who writes code. The word "manager" describes someone who directs people. What we do today — directing an AI, judging its output, owning responsibility for it — doesn't have a stable name in the industry yet.
It isn't development in the classical sense. It isn't management either, since you're not directing anyone. It's a third thing, at the boundary between the two, that's already being practiced at scale without being named.
What the numbers say
This personal observation isn't isolated. A longitudinal study submitted to arXiv in May 2026 by Annie Vella and Kelly Blincoe followed professional developers across two measurement points six months apart. The main finding: 82% of participants report spending less time writing code than before. The authors propose a term to describe what has taken the place of writing: supervisory engineering work — directing, evaluating, and correcting AI outputs.
The Stack Overflow Developer Survey 2025 points in the same direction. 84% of developers use or plan to use AI in their work, and 51% of professionals use it daily. But adoption doesn't come with blind trust: 46% of developers don't trust the accuracy of AI-generated responses, compared to only 33% who do. We're using a tool at scale that we don't take at face value — which, mechanically, forces us to verify.
This verification, this steering, this correction: it's precisely the work that still has no proper name in the industry. The study gives it one. Whether it will stick, or whether the industry will find another, remains to be seen.
What this changes in practice
The most visible consequence touches how we present our skills. A resume that only lists technologies — Java, React, Kubernetes — describes a developer from before: someone who practiced, who struggled, who knows where the traps are.
A resume that reflects the work actually done today would mention something else: the ability to define a precise context for an AI, to evaluate the quality of an output you didn't produce yourself, to arbitrate between several proposals, to guarantee that a result is correct without having written it line by line.
Technical skills don't disappear from the equation. They become a prerequisite rather than a differentiator — you use them to judge what the AI produces, not necessarily to produce from scratch yourself.
I don't know what this job will be called in five years. I do know it already exists, because I practice it every day — and most of the developers I know practice it too, without always framing it that way.
The friction is gone. The responsibility has stayed entirely.
References
- Annie Vella, Kelly Blincoe — The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study (arXiv, May 2026)
- Stack Overflow — Developer Survey 2025 · AI