Rejecting novelty because it will dumb us down, steal our jobs, destroy our abilities or anything on that direction is a historically common reaction...
Last week I left Brett Codes walking off the factory floor and promised you he was not alone. He isn’t. Open any “I’m done with AI coding” thread and the comments are full of experienced people saying a version of the same thing... some of them already halfway out the door.
So when we say that AI is making the value of coding tend to zero, because anyone can type specs into a harness and spit out some code, we are telling your developers that their skills are becoming worthless?
It feels natural that some will reject AI coding on that context. But it reads as less the rejection of a tool, and more the rejection of a way of working... and that way of working is older than IDEs, OOP or even the punch cards.
What motivates someone, what drives someone to be consistently happy at work and doing their work goes way beyond the tool they use. We all have our buttons to push and be pushed... and those change even throughout the day, the week and many times throughout your life... imagine amongst different individuals?
What you cannot deny is: this accessible (for now) intelligence at our apps and terminals has the capacity to increase/speed up our output. But that doesn’t necessarily produce a better outcome for the company, or more happiness for the individual.
So before your best problem-solving engineers/developers/employees walk away from the factory floor because they are tired of validating a machine output, let’s talk about what is missing.
Issue 1 named the trap: one program, not three.
Issue 2 named the destination: AI-native, not AI-ready.
Issue 3 put three bodies on the table that have to move together.
Issue 4 kept the model in the loop, not in the room.
Issue 5 found Herbie: your bottleneck doesn’t burn tokens.
Issue 6 brought the peer-reviewed witness: more shipped, same typing.
Issue 7 taught one repo and moved a fleet.
Issue 8 found the sandbox was not holding, and told you to keep the gate.
Issue 9 asked who reviews the reviewers, and pointed at this week.
The factory was always there
The idea of controlling the output of software production always existed and always will. The more established the problem, the larger the company, the more regulated the environment... more people want to feel the control, establish a framework and guardrails that let us predict (or imagine we can predict) the future.
This idea of being a backend Java engineer at a financial institution for 40y of your life never appealed to a lot of people. The romanticization of craftsman’s work, of a creative space to put your ideas into motion, can be intrinsic to humans (or it’s just a reflection of our society)... it is why the gaming industry can fill its ranks with passionate developers who endure brutal crunch for not enough money, while private equity tech pays a lot more for the sake of “doing the boring, but simple”.
And this predates Agentic AI! I was a developer, I was a data engineer, I was a data scientist, I was a lead, I was a manager, I was a CTO... I led teams and I led teams of teams. Back then, I sat with teams whose whole job was to turn someone else’s spec into code. The PO/PM decided the what and why, they were the only ones with access to “the customer”. The ticket arrived in its own glory, format, standards... the developer had to make it true, close and pull the next one. Great people doing the best with the context and knowledge they had... many times, not even thinking if that was the thing that should be. A real software factory before a single robot (or AI) actually participated in our daily lives. And many would wake up one day after a retro, a planning or just moving tickets in Jira to ask: is this it? Is this my life?
This hasn’t changed. But AI might have finally exposed it... the fear is out there. I have mentees and former colleagues constantly asking what my plan is “if this continues”. Some are making career changes, but many are grinding to absorb the novelties and ensure they are not left behind.
Faster now, gains much later
Even the ones that are accelerating are asking questions. Because they see that their backlog tasks for the sprint can be wrapped up in less time with Agentic Coding. For the owners of the capital (let’s not digress into Marx), it’s another dream coming true. More productivity means more output, which we hope means more outcome... more outcome means more revenue and/or less cost. And all that brings to a bigger profit margin.
From last week’s edition though, we surfaced that keeping humans at the gate (the entire “human in the loop” angle) might not be the work that lots of people signed up for... a faster and more efficient job doesn’t mean happier employees, because you are talking about someone’s skill/craft.
I’m eager to see what developer experience scientific papers will show in a few years, because the first ones that are still talking about chat-interface with LLMs already tell a very interesting story.
Take Chen et al. (ICSE-SEIP 2026), a survey of 2989 developers using Copilot. 86% are satisfied or very satisfied, but around 60% save less than 1h per week... so yeah, satisfaction barely correlates with time-savings (r = 0.34, weak). And here is a caveat I’ll come back to: that study is about the Copilot/chat experience, which is not what a lot of us are doing at all today. The concept of Loop Engineering, letting good models “run amidst the code and documents to solve a goal, however long it takes”, is in vogue now.
How will this efficiency/productivity, employee happiness and financial outcomes fit together in the future of Agentic Coding? What will change? Let’s remember that the personal computer took decades to show up as a real productivity gain in the workplace: Robert Solow quipped in 1987 that “you can see the computer age everywhere but in the productivity statistics”, and Erik Brynjolfsson gave that gap a name, “The Productivity Paradox of Information Technology”, in the Communications of the ACM in 1993.
If we have clear guardrails to create specs that will be taken by agents to produce a code output that will be validated by your developers (because someone still needs to be responsible), is that creating a new gap? Or surfacing one that already existed?
The two things the factory never asked for
So what did Chen and colleagues find when they went past the survey and actually sat with developers? Eleven interviews, and out of them six factors of what “productive” even means with these tools. Four of them you already track, more or less: whether people need to ask a colleague less, whether the tool lowers the friction, how fast the task closes, how painful the review gets. Fine. But two of the six do not live on any dashboard you own, and those are the ones that matter here: technical expertise and ownership of work.
Expertise first. One interviewee said the quiet part out loud: “if the code just works, then you just accept it”. A senior remembered learning the craft by going through “tons and tons of stack traces”, the exact apprenticeship a junior today never gets. And my favourite line from the whole paper, because it is basically my beat 2 in their words: juniors “never wrote anything from scratch. Given a template, they don’t know what to do with it.” That is the factory, right there. The template arrives, you fill it, you never learn what the template was for.
Then ownership. Their developers kept saying there is “nothing like doing it yourself”. And that is not nostalgia: one of them pointed out that when you wrote the majority of it, in an incident “you’d know exactly where the issue is and where to look”. Ownership is not a feeling to protect, it is how someone stays responsible for a thing at 3am. The authors go one step further and say ownership shapes the “long-term identity of a developer and broader team culture”. Read that again with your best engineer’s face in mind.
So here is the punchline for the whole movement: expertise and ownership are exactly the two things a spec-in, code-out factory never asked anyone for. The people walking off are not rejecting the tool, they are grieving the two things the job stopped containing. It was never really about the AI, remember? :-]
Your dashboard cannot see it
Now the part that should bother any CTO reading this. Chen et al. put their six factors next to the frameworks we actually run on, SPACE and DORA. Guess which two map to neither? Technical expertise: no. Ownership of work: no. Their words, not mine: these long-term factors “remain largely unaddressed in existing frameworks and surveys”.
So look at what your end-of-the-week dashboard optimizes. Task completion, throughput, cycle time... the one factor DORA does cover. You are steering hard on the number that agentic coding already inflates for free, and you are structurally blind to the two that are quietly draining out the bottom. You cannot manage what you cannot see, and right now you literally cannot see it.
This is the three-body reading... again not a happy one. Every model release makes the capability body sprint a bit faster. Not one of them makes expertise or ownership appear on a chart. So capability sprints, the people body hollows out in the dark and the board deck stays green the whole quarter. The gap never announces itself. It shows up later, the way last week’s tables started to wobble, once the person who knew why has already left.
One floor up from the evidence
Now the caveat I promised you a few beats ago, because I would much rather say it than have you catch me on it. Chen and colleagues studied GitHub Copilot, the autocomplete-and-chat kind of help. Agentic workflows, the harness running the loop on its own, they put explicitly out of scope. And it is one company. So, strictly, their paper does not measure the exact thing this whole issue is about.
That is not a hole in the argument, it is the handoff. A hand-off to long-term risks that agentic code brings forward with its autonomy and continuous interaction with developers. So this initial and peer-reviewed evidence already shows expertise and ownership disentegrating with the mild version, the chatbot. Imagine what will happen with the Agentic version that is clearing your sprint on a Tuesday night...
And this gap is exactly where I have been standing for the last year. So I am not arguing over their heads, I am standing one floor up from a result they already nailed down, telling you what it looks like from up here.
Run it on yourself
Before the next “AI adoption” all-hands, and before someone forwards you another “I’m done with AI” video with “thoughts?” on top, more 3 common-sense things you can check this week.
Read one closed ticket. Pick the fastest one from last sprint. Did it ask the developer for a single decision that was not already written in the spec? If not, you did not speed up a craftsman, you sped up a factory line. Which is completely fine, but only if you meant to.
Find the number that would notice. Look at the dashboard you actually review. Which metric moves if expertise or ownership drops for a whole quarter? If the honest answer is “none”, that is not a gap to backfill later, that is the finding (ask Chen et al.’s table).
The “is this the life?” test. Ask your best builder to describe last week in one word: making, or approving? You are not measuring their mood. You are measuring whether the job you designed still holds the thing that keeps them from recording their own video.
The whole thing, in one line
The people leaving are not done with AI. They are done with a job you designed to have no craft in it, and the machine just did it faster.
Coming up
Next week I want to get my hands dirty again. Less about who is holding the gate, more about the work itself :-]
Sources
Valerie Chen, Jasmyn He, Behnjamin Williams, Jason Valentino, Ameet Talwalkar, “Beyond the Commit: Developer Perspectives on Productivity with AI Coding Assistants”, ICSE-SEIP ‘26 (IEEE/ACM International Conference on Software Engineering, Software Engineering in Practice track), Rio de Janeiro, April 2026, https://doi.org/10.1145/3786583.3786848
Robert M. Solow, “We’d Better Watch Out”, New York Times Book Review, 12 July 1987, p. 36.
Erik Brynjolfsson, “The Productivity Paradox of Information Technology”, Communications of the ACM 36(12), 1993, pp. 66-77. https://doi.org/10.1145/163298.163309
Valerie Chen, Ameet Talwalkar, Robert Brennan, Graham Neubig, “Code with me or for me? How increasing AI automation transforms developer workflows”, arXiv:2507.08149, 2025 (preprint) https://arxiv.org/abs/2507.08149