Last week, Fortune ran a story about IBM tripling its Gen Z entry-level hiring1. The framing was optimistic — a counter-narrative to the doom and gloom of AI eating junior jobs. IBM's CHRO Nickle LaMoreaux positioned the company as a bold contrarian, doubling down on young talent while the rest of the industry runs scared.
It's a good story. It's also incomplete, and the parts they left out tell you a lot more about what's actually happening.
The Numbers They Buried
Here's the timeline nobody at IBM wants you to piece together.
In October 2025, CEO Arvind Krishna publicly pledged to hire more college graduates2. Days later — literally days — IBM announced it would cut thousands of workers in the fourth quarter as it shifted focus to software and AI3. A spokesperson confirmed the layoffs would impact a "low single-digit percentage" of the global workforce. At 270,000 employees, that's somewhere between 2,700 and 8,100 people.
But that wasn't the first cut. The Register reported approximately 9,000 US job cuts earlier in 2025, with significant portions shifting to India4. CIO Magazine confirmed this was IBM's third major workforce reduction since September 2024, following an estimated 8,000 to 10,000 positions eliminated then, and another 5,000 to 7,000 in March 20255.
Add those up. Across 18 months, IBM has cut somewhere in the region of 20,000 to 25,000 roles — while telling Fortune they're "tripling entry-level hiring"1.
The spokesperson's carefully worded reassurance? US headcount would remain "roughly flat." In other words: cut experienced, well-paid engineers. Backfill with entry-level hires at a fraction of the cost. Call it an investment in youth.
This Isn't New. IBM Has Done It Before.
If the pattern sounds familiar, it should. IBM has been here before — and it didn't end well.
In 2018, ProPublica published a landmark investigation revealing that IBM had eliminated more than 20,000 American employees aged 40 and over in the preceding five years alone — roughly 60% of its total US job cuts during that period11. Internal documents showed a deliberate strategy to "correct seniority mix" by replacing older workers with younger, cheaper hires. A 2006 paper from IBM's own consulting arm described boomers as "gray hairs" and "old heads," concluding that younger generations were "generally much more innovative and receptive to technology"11.
The EEOC investigation found that 85.85% of IBM employees considered for layoff between 2013 and 2018 were over 40 years old. Internal emails showed executives referring to older workers as "dinobabies" and planning to make them an "extinct species."
The EEOC investigated and confirmed a pattern of intentional age bias between 2013 and 201812. Internal emails surfaced in court showed IBM's most senior executives discussing plans to make older workers an "extinct species," referring to them as "dinobabies" while planning to hire "early professionals" to shift the company's demographics12. The EEOC found that 85.85% of employees considered for layoff during that period were over 4013.
Multiple lawsuits followed — and continue to this day. In 2023, two former HR managers in their 60s, both top performers with decades of service, sued IBM after being terminated and replaced by younger, less experienced workers14. In January 2026, a 61-year-old sales specialist alleged IBM used an impossible performance improvement plan to push him out after decades of strong results15. The company has faced age discrimination claims in New York, Texas, Connecticut, Massachusetts, and beyond.
The playbook is consistent: cut experienced workers, frame it as a skills transformation, backfill with cheaper talent, and bury the age data. In the 2010s, the justification was "digital transformation." In 2025, it's "AI readiness." The language changes. The economics don't.
This matters because the current Gen Z hiring story isn't happening in a vacuum. It's happening at a company with a documented, litigated, EEOC-confirmed history of replacing older workers with younger ones under the banner of modernisation. When IBM says it's "tripling entry-level hiring," the question isn't just why — it's who are they replacing, and is this the same pattern with a new label?
The Job That No Longer Exists
The most revealing detail in the Fortune piece wasn't the hiring numbers. It was this: IBM's CHRO said that an entry-level developer used to spend 34 hours a week writing code. Now they spend their time on marketing, client meetings, and building new products instead of maintaining old ones8.
Read that again. The entry-level software developer role at IBM is no longer primarily a software development role.
IBM has rewritten these positions so that AI handles the coding tasks that juniors used to do, and the juniors handle everything else — the customer interaction, the cross-functional work, the tasks that used to belong to product managers, account managers, and marketing teams.
If that sounds familiar, it should. It's the product-minded engineer model that we've been writing about — the convergence of PM, PjM, and engineer into a single role. Except IBM isn't framing it that way. They're framing it as hiring more people, when in reality they're hiring different people to do more things at a lower cost.
This isn't a bet on Gen Z. It's a headcount arbitrage.
What Sonar's 1,149 Developers Actually Said
The Fortune headline landed in the same week as Sonar's 2026 State of Code Developer Survey, based on responses from 1,149 professional developers6. The timing is instructive, because the survey's findings make IBM's cheerful hiring story look a lot less convincing.
The article that surfaced this — a Medium post arguing that 48% of developers think AI code is incorrect — got the headline right but missed the deeper story. Let's look at what the survey actually found.
96% of developers don't fully trust that AI-generated code is functionally correct. Only 4% completely trust it. But here's the part most people skip: 61% agree that AI regularly produces code that looks correct but isn't reliable6. That's a critical distinction. The problem isn't that AI writes obviously bad code. The problem is that it writes subtly bad code that passes a glance review.
The survey found that developers report AI gives them a 35% average productivity boost. But that boost is being swallowed by a verification bottleneck — 95% of developers spend time reviewing, testing, and correcting AI output, with 59% rating that effort as "moderate" or "substantial." And 38% say reviewing AI code takes more effort than reviewing human-written code6.
Here's where it gets directly relevant to IBM's hiring strategy: the experience gap tells the real story.
Junior developers (under 10 years of experience) report a 40% productivity increase from AI. Senior developers report 32%. That sounds like a win for juniors — until you look at the other data. 66% of junior developers say AI produces code that looks correct but isn't reliable, versus only 48% of senior developers. Junior developers are 40% more likely to say reviewing AI code requires more effort than human code6.
In plain terms: juniors are faster with AI but worse at catching AI's mistakes. Senior developers are more sceptical, more targeted in how they use AI, and better at spotting problems before they ship.
To be clear — this isn't an indictment of Gen Z. Quite the opposite. I work with junior developers regularly and they bring something a lot of my generation has lost: hunger, curiosity, and an eagerness to learn that makes them genuinely exciting to collaborate with. They pick up new tools faster. They're less precious about how things have always been done. They ask better questions about why than many senior engineers who stopped asking years ago.
The problem isn't the people. The problem is the strategy. IBM is taking talented, eager young engineers and dropping them into roles that have been hollowed out — where AI does the coding and the human does everything else, without the architectural experience to know when the AI has got it wrong. That's not investing in Gen Z. That's setting them up to be the verification layer for a system they haven't been given the tools to verify. The experience gap in the Sonar data isn't a statement about ability. It's a statement about what happens when you skip the part where people learn how systems actually work.
IBM's strategy is to cut the seniors and triple the juniors. Think about what that means for code quality — and for the juniors who'll be blamed when it deteriorates.
The Hard Truth About "Untrusted" AI Code
The Medium article framed developer distrust of AI code as a story about AI's limitations. It's not. It's a story about how engineers use AI.
The Sonar survey found that AI is highly effective at generating documentation (74% effective), explaining existing code (66%), and green-field prototyping (62%). Where it falls apart is the complex, context-dependent work: refactoring existing code (43% effective), debugging (44%), and adding functionality to existing systems (42%)6.
Most engineers who complain about AI code quality are using AI for the wrong tasks. They're asking it to refactor a legacy codebase it has no context for, or to debug a concurrency issue in a system it can't reason about holistically. Then they're surprised when the output is unreliable.
The engineers who get results from AI — the ones in that 4% who trust it completely — are the ones who break problems into small, well-defined pieces. They architect the system themselves, then use AI as a code generation tool within the boundaries they've set. They write the specs, define the interfaces, and let AI handle the implementation of isolated components.
This is a skills problem, not a tools problem. And it's one that IBM's hiring strategy makes worse, not better.
When you take a junior developer who hasn't yet learned to decompose systems, hand them an AI tool, and tell them their job is now "customer interaction and marketing" with some coding on the side — you're not creating an AI-augmented engineer. You're creating someone who generates plausible-looking code they don't fully understand, in a system they haven't been trained to think about architecturally.
The Sonar data confirms this: 88% of developers report at least one negative impact of AI on technical debt. The number one negative impact? Code that looked correct but wasn't reliable — reported by 53% of developers. The second? Unnecessary or duplicative code, at 40%6. These are exactly the problems you'd expect when people use AI without strong architectural judgment.
What IBM Is Really Telling You
Strip away the PR, and IBM's strategy reveals a few things clearly.
First, the old entry-level engineering role is dead. IBM admitted this themselves — LaMoreaux said the entry-level jobs from two to three years ago can now be done by AI8. They're not hiring more engineers. They're hiring fewer engineers and calling them something else.
Second, experienced engineers are expensive and IBM doesn't want to pay for them. The "tripling entry-level hiring" story only makes sense when you know about the 20,000+ experienced roles eliminated in the same period345. You don't triple junior hiring out of optimism. You do it because you've gutted your senior workforce and need to backfill at a fraction of the cost. One analyst described IBM as "playing chess" with long-term labour decisions9 — but it looks a lot more like cost arbitrage with a PR strategy attached.
Third, they're worried about the pipeline — but not for the reasons they say. LaMoreaux's argument about the mid-level manager shortage is correct1. If you cut all juniors, you have nobody to promote in five years and you're poaching from competitors at a 30% premium8. But that's an argument for maintaining a pipeline, not tripling it. The scale of the hire suggests something else: they need a large intake of lower-cost talent to cover the non-coding work that senior engineers used to handle as part of a broader role.
Korn Ferry's own research found that 37% of organisations plan to replace entry-level roles with AI7. Their analysts warned this would create a leadership pipeline crisis10. IBM is positioning itself as the company that defied this trend. In reality, they redefined "entry-level" to mean something AI can't do — client work, relationship management, cross-functional coordination — and they're hiring bright, capable young people into roles that have been stripped of the very work that would teach them to become the senior engineers IBM just cut.
The Freight Train Has a Timetable
AI isn't a future disruption. It's a current one. And IBM's story — when you read all of it, not just the headline — tells you exactly where the impact is landing.
IBM didn't hire juniors and then figure out what to do with them. They redesigned more than 70 internal workflows through automation and AI first, then cut the headcount that those workflows used to require. CIO Magazine reported this explicitly: the restructuring was designed to reduce internal complexity and redirect effort5. The order matters. They simplified the work, then changed the workforce.
Most organisations are trying to do this backwards. They're handing AI tools to teams whose processes are undocumented, whose architectures are tangled, and whose codebases require a specific person to hold it all together in their head. The Sonar data shows exactly what happens: 88% of developers report at least one negative impact on technical debt from AI, with the top problem being code that looks correct but isn't reliable. 53% of developers flagged this. The second biggest problem — 40% — is unnecessary, duplicative code6.
AI doesn't fix broken systems. It generates broken code faster.
This is the hard truth that IBM's press release dances around and the Sonar survey makes unavoidable. If your processes are a mess, AI amplifies the mess. If your architecture requires tribal knowledge to navigate, AI agents can't navigate it either. If your codebase is a monolith where changing one thing breaks three others, an AI agent will break those three things with supreme confidence and pass the review because the code looks correct.
Three Roads, Two of Them End Badly
Every organisation is now facing the same fork in the road, whether they realise it or not.
Option one: ignore it. This is the path to irrelevance. Korn Ferry found that 43% of companies plan to replace roles with AI7. Your competitors are on this list even if you're not. The companies that ignore AI won't fail dramatically — they'll just get slower, more expensive, and less competitive until someone leaner eats their lunch.
Option two: adopt AI into your current environment. This is what most companies are doing right now, and it's the most dangerous option because it feels like progress. You give your team Copilot or ChatGPT, they start generating code faster, and for a few months the productivity numbers look great. Then the technical debt starts compounding. The Sonar survey found that toil doesn't decrease with AI adoption — it shifts6. Frequent AI users spend less time debugging legacy code but more time managing technical debt and correcting AI-generated code. You end up with the worst of both worlds: the speed of AI-generated output with the quality problems of a system that was never designed for it.
This is where IBM is heading with its junior hiring blitz, and the data suggests they know it. Their juniors get a 40% productivity boost — and are also the ones least equipped to catch AI's subtle errors. That's a technical debt time bomb with a two-to-three year fuse.
Option three: get AI-ready first. Simplify your processes. Clean your architecture. Break your monolith into components with clear interfaces that an AI agent can reason about in isolation. Document the decisions that currently live in someone's head. Build the verification pipelines that catch problems before they ship. Then bring in AI — into an environment that's designed to make it effective.
The Sonar data backs this up directly. Developers at organisations with formal quality gates and automated review processes report significantly better outcomes from AI adoption — fewer outages, better code quality, less technical debt6. The companies seeing real returns from AI aren't the ones that adopted it fastest. They're the ones that prepared their systems for it.
The Army-of-One Opportunity
IBM's accidental revelation is this: they've rewritten entry-level roles so that one person does coding, marketing, client interaction, and product work. They've proved that a single person augmented by AI can cover the ground that three or four specialists used to.
The difference is that IBM needs 270,000 people to execute this because they're a services behemoth with the overhead, politics, and coordination costs that come with that scale. They're trying to make a battleship more agile by hiring younger sailors.
If you're a founder, a small company, or a product team — you don't have IBM's constraints. You can take the same insight and apply it at the scale where it actually works. One product-minded engineer who understands system architecture, can talk to customers, and knows how to direct AI tools effectively is more productive than a team of five where no one has the full picture.
But — and this is the critical "but" — that only works if the systems they're working on are designed for it. A brilliant engineer with AI tools pointed at a well-architected system with clean interfaces, good documentation, and automated quality gates will be phenomenally productive. The same engineer pointed at a legacy monolith with no tests, no documentation, and deployment processes that require three people and a prayer? They'll generate more mess, faster.
This isn't theoretical for us. We build this way at uRadical — and the results speak for themselves.
Music Bingo Live is a real-time entertainment platform serving thousands of concurrent users. It's built with simple, testable architecture and clear component boundaries. When we bring AI agents into the development workflow, they operate within established patterns. They can't run amok because the architecture doesn't let them — the interfaces are defined, the components are isolated, and the patterns are consistent. When an agent produces something that drifts from the established approach, it's immediately obvious in code review. The PR practically reviews itself because there's a clear standard to review against.
MyWelcomeBook is the same story in a different domain — a multi-tenant SaaS platform built from day one with the kind of clean separation that makes AI-assisted development effective rather than dangerous. The architecture was designed so that any single component can be understood, tested, and modified in isolation. That's not a constraint we added to accommodate AI. It's good engineering practice that happens to make AI collaboration dramatically more productive.
The pattern is consistent across every project we run: establish the architecture, define the boundaries, set the standards, then let AI agents operate within them. The agents become force multipliers instead of chaos generators — because they're working within a system that was designed to be reasoned about in parts, not held together by one person's institutional knowledge.
The 61% of developers in the Sonar survey who say AI produces code that looks correct but isn't reliable6? They're not wrong about the output. They're working in codebases where "correct" is impossible to verify without understanding the entire system at once. Break the system into parts an agent can reason about individually, and the reliability problem largely solves itself.
The companies that will win this aren't the ones hiring the most people or the fewest. They're the ones whose engineering, processes, and architecture are ready for AI to operate within. That's not a staffing decision. It's an engineering decision. And it needs to happen now, before the freight train arrives — because for most organisations, it's already in the station.
References
- Fortune, "IBM is tripling the number of Gen Z entry-level jobs after finding the limits of AI adoption," February 13, 2026
- Fortune, "IBM's CEO admits Gen Z's hiring nightmare is real — but after promising to hire more grads, he's laying off thousands of workers," November 5, 2025
- CNBC, "IBM to cut thousands of jobs in the fourth quarter," November 4, 2025
- The Register, "IBM cutting several thousand jobs in latest layoffs," November 4, 2025
- CIO Magazine, "IBM to cut thousands of jobs as Red Hat growth slows," November 5, 2025
- Sonar, "State of Code Developer Survey Report 2026"
- Korn Ferry, "2026 Talent Acquisition Trends Report," October 28, 2025
- Axios, "IBM plans to triple entry-level hiring this year because of AI," February 13, 2026
- Newsweek, "IBM is targeting Gen Z by tripling its hiring," February 13, 2026
- HR Dive, "Over one-third of companies plan to replace entry roles with AI, survey says," November 6, 2025
- ProPublica, "Cutting 'Old Heads' at IBM," March 22, 2018
- Public Justice, "Federal Court in Boston Rules that IBM Broke Federal Law," October 8, 2025
- Gibbs Mura, "IBM Age Discrimination Lawsuits," 2025
- HR Dive, "HR pros say IBM fired them due to their age, planned to replace them with AI," September 22, 2023
- Human Resources Director, "IBM faces age bias lawsuit alleging impossible performance improvement plan," January 8, 2026