Snap laid off 1,000 people in April. Sixteen percent of the workforce, gone in one announcement. The reason CEO Evan Spiegel gave was clean and simple: AI now writes more than 65% of the company's new code, so Snap needs fewer people to write it.
This number went everywhere. Every founder I know forwarded it to me with some version of "see, this is the future." It's a good headline. It's also mostly misleading, and the way it's misleading tells you what engineering leadership looks like now.
The stat everyone quoted, and the layoffs it didn't explain
Here's the detail buried under the 65% headline: the people Snap cut weren't mostly engineers. They came out of product management and business partnerships. If AI writing two-thirds of the code was the real trigger, you'd expect the cuts to land hardest on engineering. They didn't.
There's also the small matter of what "AI-generated code" means as a metric. It counts every autocomplete suggestion a developer accepts, including five-line boilerplate templates the developer then spends two hours debugging and refining. A tool finishing your sentence isn't the same as a tool doing your job. Snap sent its cost-reduction letter to an activist investor fifteen days before the layoffs went out. Activist investor pressure explains a lot more of this story than AI does.
I'm not saying this to defend Snap or attack them. I say it because I've watched this pattern before, with different words attached. Companies make a hard financial call, then reach for the most fashionable justification on hand. Right now, the justification is AI. Five years ago it was "restructuring for efficiency." The tool changes. The instinct to dress up a business decision as an inevitability doesn't.
What the actual research says
If you want a number worth trusting, look at the METR study from mid-2025. Researchers ran a randomized controlled trial with experienced open-source developers using current AI coding tools on their own repositories. Result: developers using AI tools took 19% longer to finish their tasks. Not faster. Slower.
Here's the part worth sitting with longer than the slowdown itself: those developers believed they'd been about 20% faster. A 39-point gap between what they felt and what happened.
I bring this up because "AI writes most of our code now" gets repeated in board rooms as if it settles the productivity question. It doesn't. The bottleneck in software development was never typing speed. It's requirements shifting, architecture decisions rippling for years, coordination across a dozen people who each hold half the context, and testing catching the failure mode nobody predicted. AI helps with parts of this. It hasn't made the rest disappear.
So what are you managing now
Here's the question worth more than any percentage: if a meaningful chunk of the code in your repo was drafted by a model, what does your job as the person leading the team look like now?
Not less management. Harder management, aimed at different things.
You're managing judgment, not output. When a junior engineer used to write a bad function, you saw the bug in the code. When AI writes a plausible-looking function subtly wrong, you need someone with the judgment to catch it before it ships. Not a typing skill. The thing you spent years developing in your senior people, and now it's the scarcest resource on the team.
You're managing review capacity, because review is the bottleneck now. If AI produces code faster than humans safely review it, your team's throughput is capped by review, not by writing. Most engineering leaders I talk to are still staffing and scheduling as if writing is the constraint. It isn't. Flip the assumption, and your headcount decisions start looking different.
You're managing the gap between confidence and correctness. The METR finding, developers feeling faster while working slower, is the single most useful data point in this whole conversation. People trust AI output more than the output deserves. Your job now includes building the habits, checkpoints, and culture keeping this overconfidence from turning into a production incident.
You're managing whether your team is getting better. A junior developer who leans on AI for every function never builds the instinct for spotting when the AI is wrong. Skip protecting the parts of the job building judgment, and you're not saving time, you're borrowing against your team's future capability. A leadership decision, not a tooling decision.
None of this is about writing less code yourself, though most senior engineers I know are writing less of it already. It's about a shift: the scarce skill on your team moved from "produces correct code" to "tells correct code apart from confident-sounding wrong code." Harder to hire for, harder to teach, and exactly the thing skipped when a leadership team chases a headline stat instead of building a real practice.
Don't let a stat make your decisions for you
Snap's 65% number will get quoted at your next leadership offsite. Somebody will use it to justify a headcount freeze or a "do more with less" mandate. Before you nod along, ask the question nobody asked Snap: who got cut, and does the story match?
The honest version of this moment isn't "AI replaced our engineers." It's "the job of engineering leadership moved, and most of us haven't caught up yet." Writing code got partially automated. Judging whether the code is right, whether the architecture holds, and whether your team is growing did not. Manage for output instead of judgment, and this is the gap catching up with you, not the AI.
What are you managing on your team right now? If your honest answer is still "who's writing what," start there.