Read the Numbers, Not the Headlines
2025 was a rough year on paper. Over 157,000 tech workers were laid off across 587 companies, and a chunk of those cuts were tied directly to AI productivity gains. Salesforce's Marc Benioff said it out loud in January: no net-new software engineers in 2025, because AI tools had already given his teams around 30% more output. Amazon, Microsoft, Google — all cut deeply, and engineering roles were not spared.
That's real. I'm not going to pretend it isn't. But BCG's 2025 AI Value Creation report adds a number the headlines skip: only 5% of organizations have actually achieved substantial, measurable value from AI. The other 95% are still in the figuring-it-out phase. Which means the engineers who know how to build and evaluate AI systems, not just use them, are in genuinely short supply right now. The roles shrinking aren't 'software engineer.' They're a particular version of the job — the one where the main skill is translating a JIRA ticket into typed syntax.
Two Years Changed the Tool Market Completely
In early 2024, this was basically Copilot versus everyone else. By early 2026, it's a different picture.
GitHub Copilot still has scale — 20 million total users, 4.7 million paid, 90% of Fortune 100. But the story of 2025 was Claude Code eating into that lead at the enterprise level. The ACTI Index measured Claude Code adoption at 69% among enterprise dev teams by January 2026, up from Copilot's 35% in December 2025. Teams using it were reporting 32–45% more story points per sprint and 39–50% faster PR merges. Heavy users, meaning people using it for 76% or more of their coding workflow, reported 2.9× higher productivity than occasional users.
Then there's Cursor. An AI-native IDE that hit $1 billion in annualized revenue by November 2025, a $29.3 billion valuation, 360,000+ paid subscribers, and usage at more than half of Fortune 500 companies including NVIDIA, Shopify, and OpenAI's own internal teams. Cursor is not a side project anymore. It's infrastructure.
"We're not hiring engineers in 2025. We got about 30% more productivity from our engineers by using AI tools — so we didn't need to make those hires."
— Marc Benioff, CEO of Salesforce, January 2025
Developers Are Using These Tools — But Not Trusting Them
Stack Overflow's 2025 survey put AI tool adoption at 84% of developers — up from 76% in 2024 and 70% the year before. Daily use jumped to 51%. Those numbers are high. What's interesting is the gap: only 33% of developers said they trust the accuracy of what AI tools produce. People are using these things constantly and second-guessing them constantly at the same time.
JetBrains saw similar numbers: 85% using AI tools, 62% relying on a coding assistant as a core part of their workflow, 1 in 5 saving more than 8 hours a week. A full working day back every week is not nothing. The engineers using that time well — on architecture, on code review, on understanding systems — are pulling ahead.
Andrej Karpathy coined the term 'vibe coding' in February 2025 — describing the mode where you just describe what you want to an AI and ship whatever comes out, without really engaging with the code itself. Collins Dictionary named it their Word of the Year for 2025, which tells you how much it entered the cultural conversation. The Stack Overflow survey found 72% of professional developers explicitly said it's not part of their work. That gap between vibe coding as a trend and vibe coding as something you'd stake your production system on is where careers are diverging.
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
— Andrej Karpathy, co-founder of OpenAI, February 2025
The Part Nobody Puts in the Marketing Deck
Productivity gains are real. The quality risks are also real, and they're getting buried.
CMU studied 807 projects built with Cursor. They found 41% more code complexity, 30% more static analysis warnings, and 1.75× more logic errors compared to human-written baselines. Speed gains held for the first month, then faded by month three as teams spent more time untangling AI-generated code than they'd saved writing it. A 2026 industry analysis across AI-augmented teams found PR volume up 20% — but incidents per PR up 23.5%, and security issues 1.57× more common in AI-authored code than human-authored code.
GitHub's own numbers: ~29.1% of Copilot-generated Python code has potential security vulnerabilities. An Accenture study on Copilot enterprise usage found more PRs merged and more successful builds — but downstream quality issues that didn't show up until production. The productivity story is real; the quality story is just slower to surface.
None of this means stop using these tools. It means the engineer who actually reads the AI's output, catches the logic error in paragraph three, and pushes back on the flawed assumption in the generated test — that person is more valuable than they've ever been, not less.
Agents Are Doing Real Work Now
When Devin scored 13.86% on SWE-bench in early 2024, people were shocked. SWE-bench is a set of real, unresolved GitHub issues — not toy problems. The model had to read a codebase, understand a bug report, and generate a patch that passes the tests. 13.86% felt low, but the baseline for a single engineer tackling random issues cold was around 1.96%. It was a genuine signal.
By early 2026, multi-agent systems are past 50% on SWE-bench Verified. Agyn hit 72.2% on SWE-bench 500. Auggie at 51.8%, Cursor agents at 50.2%, Claude Code at 49.8%. Claude Opus 4.5 holds the top standardized score at 45.9% on the SEAL leaderboard. These numbers matter because SWE-bench is messy, real-world work — not a cleaned-up benchmark designed to show off.
In production: Mendral is running 16,000+ automated CI investigations a month. GitLab's Duo Agent Platform went GA in January 2026, handling end-to-end lifecycle tasks. Teams are genuinely delegating whole categories of work — CI failure triage, dependency upgrades, test generation — to agents that run without prompting. The engineers who are figuring out how to direct and evaluate these agents are the ones building something that compounds.
Where to Actually Put Your Energy
I spent a while trying to figure out what separates developers who are thriving in this environment from the ones who are stressed about it. It's not that the thriving ones have better tools. Everyone has the same tools. It's how they're using the time the tools return.
- Offload the work that was never interesting anyway. Boilerplate, CRUD scaffolding, repetitive tests, dependency upgrades, documentation — let agents handle it. That time should go somewhere real: design discussions, production post-mortems, reading the papers behind the tools you use.
- Become the person who catches what the AI missed. Only 33% of developers trust AI accuracy per Stack Overflow 2025. There is a massive amount of value in being the engineer who can reliably spot when an AI-generated PR is subtly wrong. That skill comes from deep domain knowledge, and it can't be automated.
- Read the code even when you didn't write it. The CMU data is pretty clear — teams that accept AI output without review lose the speed gains within three months. Every line that ships under your name should be a line you've actually read. Your professional judgment about the code is what you're employed for.
- Push yourself up the stack. Implementation is getting cheaper. The judgment about which problem to solve, which system to build, which tradeoff to accept — that's where the leverage is now. Use AI to compress the implementation phase so you have more time thinking at that level.
- Run agents on real projects and pay attention to where they fail. The only way to develop good orchestration instincts is to watch agents work on real codebases, not just demos. Open source contributions, side projects, internal tools — anything real. The failures teach you more than the successes.
- Get good at AI integration, not just AI use. The highest-demand skill in 2026 isn't knowing how to write prompts. It's knowing how to run AI reliably in production: evaluation pipelines, guardrails, fallback behavior, observability. Every team shipping AI features needs someone who thinks about this seriously.
Who Actually Has Something to Worry About
Accenture's 2025 workforce survey: 48% of workers feel secure in their jobs, down from 59% the year before. 82% of C-suite leaders expect more disruption in 2026. That's not noise.
The risk is concentrated. Developers whose primary value is throughput — how many tickets closed, how many endpoints written, how many tests committed — are in a genuinely difficult position. An agent can write thousands of lines per minute. If that's the metric by which you're measured, it's not a great benchmark to compete on.
Where I see strong job security: engineers who understand why systems fail in ways that aren't in the logs. Engineers who can take an ambiguous problem from a non-technical stakeholder and turn it into something buildable. Engineers who know when not to build the thing. Engineers who can make a judgment call at 2am on a production incident when the runbook doesn't cover the situation. Those skills compound with experience in a way that model capability — at least right now — doesn't.
"The question is not whether AI will change software engineering. It already has. The question is whether you are going to be the person who shapes how that change happens on your team, or the person it happens to."
— BCG — AI Value Creation Report, 2025
So Is the Job Dead?
No. But I understand why it feels like that from the outside.
The version of the job that's shrinking is specific: writing boilerplate, closing tickets, implementing features from spec without much need to think about whether the spec is right. That was always the lower end of the work. Automating it is, genuinely, a good thing for anyone who wanted to spend their career thinking about harder problems.
What's left — and what's getting more important — is harder to fake and harder to automate. Reasoning about complex systems with incomplete information. Catching errors in output you didn't generate. Understanding the organizational context behind a technical decision. Knowing when the AI is confidently wrong. Those things take time and experience to build, and they're worth more now than they were two years ago.