I want to tell you about a developer I know — smart, experienced, someone who's shipped real systems at scale — who said something that's been stuck in my head for weeks. We were talking about AI coding tools, and he said: "I'm faster now. I just don't feel like I'm doing anything."
That sentence is more important than every productivity statistic I've read in 2026.
Ninety percent of developers are using AI coding tools. Forty-one percent of all code committed to GitHub is now AI-generated or substantially AI-assisted. The trend reports are unanimous: engineers are shifting from creators to curators. From writing code to orchestrating AI agents that write code. From designing solutions to reviewing AI-designed solutions. Everyone nods when they read that framing. It sounds like progress. It might even be progress.
But nobody's talking about what it actually costs to stop making things with your hands.
The Curator's Job Description Nobody Posted
Here's what "creator to curator" actually looks like on a Tuesday afternoon.
You open a task. Instead of designing the approach in your head, pulling up your editor, and building it out, you open a prompt interface. You describe what you need. The AI writes it. You read it — carefully, because you're accountable for it — and you either accept it, nudge it with a follow-up prompt, or throw it out and try again. Then you repeat. For hours.
The work is real. The decisions are real. You're not just rubber-stamping AI output — good engineers are constantly evaluating, redirecting, catching edge cases, pushing back on choices that are technically correct but architecturally wrong. That's valuable work. It requires skill. It's not the same work.
The difference is hard to articulate until you've felt it. Writing code is making something. You have an idea, you express it in a language, and it does something in the world. Curating AI output is approving something. You're evaluating, not authoring. The locus of creation has shifted. And for a lot of developers, that shift is quietly disorienting in a way that doesn't show up in any productivity dashboard.
Two Types of Developers, Two Very Different Experiences
I want to be careful here, because this isn't a universal story. There are two broad types of developers experiencing this transition, and they're having completely different reactions.
The first type chose this job — at least in part — because they love the craft. Writing code is tactile for them. There's satisfaction in the specific act of designing a function, getting the logic right, making the code readable. These are the developers who have opinions about naming conventions. Who refactor things that don't need to be refactored because cleaner code is satisfying. For this type, the shift to curation is a genuine loss. Not a catastrophic one, maybe, but a real one — like asking a chef to primarily evaluate food that other people cooked and calling it the same job.
The second type chose this job despite the boilerplate. They were interested in systems, in product problems, in the interesting parts of engineering. They spent years writing setup code, CRUD endpoints, and config files because that's what the job required on the way to the interesting stuff. For this type, AI tools are a liberation. The ratio of interesting-to-tedious work has flipped dramatically in their favor. They're thriving.
Both of these people exist on your team right now. The failure of most engineering leadership is treating them identically — rolling out AI tools to everyone with the same pitch, measuring the same productivity metrics, and assuming the transition is just a matter of learning the new workflow.
It isn't. One of these groups is losing something real. The other is gaining something real. Good leaders know which they're talking to.
The Burnout You Can't Explain
Here's the symptom I'm watching for. Not the obvious burnout — overwork, impossible deadlines — but a subtler kind. The developer who is shipping more than ever but feels somehow less connected to the work. Who can't really explain why they're less motivated when by every external measure things are going well. Who feels, as my friend put it, like they're doing something without doing anything.
This is an identity mismatch, not a workload problem. You can't solve it by adding more features to the AI tool or improving the onboarding docs. You solve it by acknowledging that the job changed in a deep way and having an honest conversation about it.
The companies that will retain their best engineers through this transition aren't the ones with the most advanced AI tooling. They're the ones where leadership actually talked to their engineers about what this feels like — and did something about the answer.
What Good Engineering Leaders Do
The engineering leaders getting this right aren't just buying tools and hoping people adapt. They're redesigning the work, not just adding a new layer on top of the old work. A few patterns worth stealing:
- Be explicit about the role change. Don't let engineers figure out on their own that their job has fundamentally shifted. Name it. Have the conversation. Some people will be relieved, some will grieve. Both reactions are valid.
- Protect the interesting work. If AI is handling the boilerplate, the humans need to be doing the architecture, the product thinking, the hard judgment calls. If you fill the time freed up by AI with more boilerplate from a bigger backlog, you've lost the whole benefit.
- Measure differently. Velocity metrics from the pre-AI era tell you almost nothing useful now. If a developer reviews and ships 400 AI-generated lines in a day, was that a productive day or a dangerous one? You need metrics that capture quality and ownership, not just throughput.
- Give people permission to reject AI output. There's a silent pressure building in a lot of teams: AI generated it, so shipping it faster is the right call. That's backwards. The humans who are accountable for the system need to be empowered — explicitly — to override, discard, or rework AI output when their judgment says to.
The Version Where You Win
Here's the thing. There's a version of "creator to curator" that is actually better for developers — not just more efficient, but more satisfying. It's the version where offloading the tedious work to AI gives you back time for the creative, high-judgment work that most developers went into this field to do. The architecture problems. The product-engineering collaboration. The debugging that requires actually understanding how the system works.
That version exists. It's not automatic. It requires leadership that's intentional about it, a culture that values the human judgment layer rather than just optimizing it away, and developers who are honest about what they're experiencing.
If your engineering team feels like they're on a conveyor belt right now, approving outputs and shipping features without ever feeling like they designed anything — that's not a feature of the AI era. That's a failure of how the AI era was introduced.
You used to write code. Now you curate it. That can be a downgrade, or it can be a promotion. The difference is almost entirely about what your organization does with the time AI gives back.
Sources: Pragmatic Engineer — Impact of AI on Software Engineers 2026 | Anthropic 2026 Agentic Coding Trends Report | CIO — How Agentic AI Will Reshape Engineering Workflows | Deloitte State of AI in the Enterprise 2026