When Did You Start Being Ashamed of Your Code?
(Published on March 31, 2026 - Version française)
There's a scene that keeps repeating itself in my code reviews. A developer presents their work. They explain the choices, the architecture, the trade-offs. And at some point, there's a hesitation. A slight faltering. Then the sentence comes out, in a low voice, almost apologetically: "That part... I didn't write it. The AI did."
As if confessing something. Where does this shame come from? From two places, I think.
The first is internal. For decades, a developer's value was measured by their ability to memorize syntax, solve complex problems from a blank page, and forge every line through sheer effort. That image built their professional identity. And when AI automates that forge, some see it as a loss: if I'm no longer the one typing the code, am I still legitimate? Do I deserve my title, my salary, the credibility my colleagues give me? The developer feels like they've used a cheat code, a shameful shortcut, as if the value of their work were measured in the number of lines typed by hand.
The second is hierarchical. The fear, often unfounded but very real, that management thinks: "If AI does your job, why am I paying you?" That fear doesn't get said out loud. It manifests exactly as in the scene I described: a hesitation, words that apologize.
I'm going to be direct: this shame infuriates me. Not at them, but at the prevailing narrative that created it.
What I Told My Team, Clearly, Once and for All
I will never hold it against you for using AI to write code.
But I will hold it very much against you if you spend three hours writing something an agent would have produced in forty seconds. That's not heroism; it's waste: of your time, your energy, and frankly your brain, which deserves better than typing boilerplate.
The question has never been who wrote the lines. It has always been who is responsible for the code produced.
Your Code Has Always Had Thousands of Parents
The image of the lone developer forging every line has always been fiction. I once said, at a conference on pragmatism, that developers were geneticists. The code we write is an assembly of fragments that pass down from generation to generation. Sometimes it's entire chapters retrieved from Stack Overflow. Often it's three lines gleaned from an open-source project, a pattern seen in a book, a trick shown by a colleague. The result doesn't have two parents; it has thousands. Thousands of developers you've never met whose code lives in yours nonetheless.
AI hasn't changed that. It's just accelerated the transmission, and apparently that bothers people.
Pilot, Not Passenger
AI will do an excellent job if an excellent developer accompanies it. It's teamwork, not delegation, not outsourcing. A pair where one generates fast and the other thinks straight. And in that pair, you're the pilot, not because it's a nice metaphor, but because you're the one who signs off, you deploy, and you answer when something breaks in production at 3 a.m.
AI writing code without a competent developer accompanying the work is a source of silent technical debt. It doesn't know your business context. It doesn't know why you made that architectural choice six months ago. It doesn't see the implications on adjacent modules. It produces something that runs and seems correct, and those two qualities combined are exactly what makes the problem invisible until the day it blows up.
Stay vigilant, even on three lines that look simple. LLMs regularly suggest plausible but nonexistent libraries. A 2025 academic study (University of Texas, Oklahoma, and Virginia Tech) covering 576,000 code samples generated by 16 different models found that 19.7% of recommended packages existed in no public registry. Attackers register these hallucinated names to deposit malicious code: it's called "slopsquatting" and it's actively happening. Three unverified import lines can open a backdoor. Vigilance isn't paranoid distrust; it's the normal work of an engineer who understands what they're committing.
The More You Use It, The Less You Trust It
The Stack Overflow Developer Survey 2025 (49,000 developers, 177 countries) is quoted everywhere for its headline stat: 84% of developers use or plan to use AI tools, up from 76% the previous year. Great. Adoption is up.
What gets cited far less: in the same report, trust in the outputs of these tools has fallen to 29%. It was at 40% the year before. Overall favorable sentiment dropped from over 70% in 2023-2024 to 60% in 2025. The number-one frustration cited by 66% of respondents: receiving solutions that are "almost right but not quite." Frustration number two: debugging AI-generated code takes longer than writing it yourself (45% of respondents).
The more you use AI, the less you trust it. That's exactly the opposite of the normal technology adoption curve.
The METR study published in July 2025 points in the same direction. A randomized controlled trial on 16 experienced developers, 246 real tasks: with access to the best tools on the market (Cursor Pro with Claude 3.5/3.7), these developers took on average 19% longer than without AI. The most troubling detail: after the experiment, they still believed they had been 20% faster. Perception was systematically disconnected from measured reality.
This result is contextualized (large mature codebases, very senior developers) and METR itself warns against overgeneralizing, but it points to something real: time saved in generation is often spent elsewhere, in verification, correction, and integration. That's not an argument against AI; it's an argument for keeping your eyes open.
The Question We Avoid
Will the developers learning today by relying heavily on AI acquire the instincts they'll need when the tool is down, deprecated, or simply wrong on their specific problem?
I don't know. Nobody knows yet; nobody has followed these developers over time. But it's this question that genuinely worries me, far more than the shame of presenting AI-assisted code. A developer who apologizes for using AI can be sorted out in a five-minute conversation. A developer who can no longer read code they didn't generate themselves is a structural problem.
So
Stop apologizing. That code is yours, with everything that implies in terms of pride and responsibility.
Use the tools. Pilot them. Read what they produce. Understand it well enough to explain it to a colleague or defend it in review. And if you can't do that, the problem isn't AI: it's that you haven't really done your job.
Follow me on Bluesky: @bouchery.fr
