A guy whom I know works at a mid-size fintech. Two months back, half his QA team got “restructured.” Not fired exactly, the company called it a shift, some folks moved to other projects, some just… left. He’s still there, but his job looks nothing like it did in March. He used to write test cases by hand, run them, log bugs, repeat. Now he reviews what an AI tool generates and fixes what it gets wrong. Same title, different job basically.Here’s the Pattern.
This isn’t some one-off story. If you talk to people in software right now, you hear versions of this everywhere. And it’s not random which jobs are getting hit first. There’s a pattern, and once you see it you can’t unsee it: the work getting automated is the work that was always repetitive, always high-labour, and honestly, always kind of boring to do by hand.
I’ve been tracking this only for a while now, partly because I do some of this work myself and wanted to know how worried to be. What I found is there are basically five buckets where this is happening, and understanding why AI is good at exactly these five tells you a lot more about the layoffs than any headline does.
Documentation, Testing, Boilerplate, Migration, Maintenance
Start with documentation, because it’s the clearest case. Someone has to write API docs, internal wikis, changelogs, onboarding guides. It’s necessary. Nobody wants to do it. I know developers who’d rather debug a memory leak at 2am than write a README. Tools like Mintlify and even plain Claude or ChatGPT can now read a codebase and spit out reasonable documentation in minutes, not days. Is it perfect? No. But it’s a solid first draft, and a solid first draft is 80% of the pain gone.
Testing is next, and it’s a bigger deal than people give it credit for. Writing unit tests, integration tests, regression suites, and the odd end-to-end test nobody wants to touch, this used to eat a huge chunk of a dev’s week. Now tools like GitHub Copilot or Diffblue can generate test cases from your existing code, flag edge cases a tired human might miss at 6pm on a Friday. A QA lead at a Bangalore SaaS company posted on Twitter that their test-writing time dropped by something like 60%. I spent way too long trying to verify that number and gave up, so take it with a pinch of salt, but it lines up with what my friend in Pune told me too.
Then there’s transformation, which is a less talked about but honestly huge one. Companies sitting on old COBOL systems, legacy Java, ancient PHP, and sometimes stuff nobody remembers who wrote, need this migrated to modern stacks. It used to take teams of contractors months, sometimes years. Now AI can read old code, understand what it’s doing, and rewrite it in a modern language with a human just checking the output. IBM’s been pushing watsonx specifically for this use case with mainframe clients. This alone could reshape a whole category of consulting work that used to be a guaranteed paycheck for a certain type of engineer.
Maintenance is the unglamorous one. Bug fixes, dependency updates, patching security holes, keeping the lights on basically. Nobody gets promoted for maintenance work, which is probably why companies are so eager to hand it to AI. Tools that can scan a codebase, flag outdated dependencies, and even write the fix themselves are already in production at places like Google, according to their own engineering blog posts about internal tooling.
And boilerplate code, the most obvious one of all. CRUD operations, form validation, standard API endpoints, pagination logic, the stuff every developer has typed a thousand times and could type in their sleep. GitHub’s own data on Copilot usage showed a large chunk of accepted suggestions are exactly this kind of repetitive scaffolding. It’s not creative work. It never really was.
None of this is “easy” exactly. Migrating a legacy banking system is real work, not a weekend project. My friend’s manager actually called the whole category “grading homework” once, which is a weirdly accurate way to put it, you’re not writing from scratch, you’re just checking someone else’s answer.
Speed Is the Real Story, Not Intelligence
Here’s what people mistake about this whole shift. They think companies are switching to AI because it’s smarter than humans at these tasks. It’s not really that. What’s actually happening is speed. Stupidly fast, in a way that changes the math completely.
Take the documentation example from before. A senior engineer writing docs for a mid-sized API, one with maybe 40 endpoints, would realistically spend three or four days on it if they’re doing it properly. Not because it’s hard, but because it’s tedious and they keep getting pulled into other things. An AI tool can generate a first pass in under an hour. Someone still needs to review it, fix the wrong bits, add context the AI didn’t have. That review might take half a day. So you’ve gone from four days to half a day. That’s not a small improvement, that’s a different category of speed.
Same story with the legacy code migration I mentioned. A COBOL-to-Java migration for a mid-size system used to be quoted in months by consulting firms, sometimes six months to a year depending on scope. I read about a case where a mid-size US insurance company, a regional one, not a household name, used AI-assisted migration and cut a similar project down to about six weeks. I don’t have the exact source bookmarked anymore, so take that one with a pinch of salt, but the order of magnitude tracks with what IBM and other vendors are claiming publicly.
This is the part that actually explains the layoffs, or at least a chunk of them. If one person with AI tools can do what used to take a team of five, you don’t need the other four. That’s just headcount math, no conspiracy required. A company doesn’t need to believe AI is a genius. It just needs to notice that a task which took a week now takes a day, multiply that across a hundred similar tasks a year, and the spreadsheet does the rest of the arguing for them.
I think this is where a lot of the “AI is coming for your job” panic gets it slightly wrong, though. It’s not that AI is replacing the thinking part of these jobs. It’s replacing the doing part. Which sounds like a small distinction until you realize most entry-level jobs in tech were almost entirely the doing part.
Is AI Actually Why People Are Getting Laid Off?
This is the part I go back and forth on, so let me just say where I land: I think AI automation is real and it’s eating real hours, but I don’t think it’s the main reason for most of the layoffs you’ve read headlines about.
Nobody at these companies says this part out loud, but it’s not hard to piece together. A lot of tech hiring in 2021 and 2022 was, by most accounts, overdone. Interest rates were basically zero and money was cheap, so companies hired like the growth would never stop. Then rates went up, growth slowed, and someone had to explain to shareholders why headcount needed to shrink. “We overhired during a bubble and now we’re correcting” is a bad look. “We’re becoming an AI-first company” is a great look, it’s the kind of line that makes your stock go up on the same day you cut 10% of your workforce. I’m not saying every company is lying. I’m saying the incentive to blame AI, even when the real reason is messier, is enormous.
That’s the part that gets left out of the AI headlines.
That said, in the five areas I listed above, the AI effect is not just a cover story, it’s actually happening. My friend’s QA team is a real example, not a headline. The dev I know who used to write boilerplate CRUD endpoints all day now spends maybe two hours a week on that and the rest reviewing AI output or working on actual system design. That’s not a narrative, that’s just what his calendar looks like now.
If I have to pick a number, I’d say the AI story is maybe 40% of the real reason and 60% convenient cover for a hiring correction that was already coming. Companies aren’t lying when they say AI helped them do more with less. They’re just not telling you it also helped them explain a headcount cut they’d already decided on for other reasons.
What’s Actually Left: Architecture and Judgment Calls
So if the doing part is getting eaten, what’s left? Mostly, it’s the stuff that doesn’t have a checkable right answer. Architecture decisions. Should this system be a monolith or microservices. Should we optimize for read speed or write speed. How do we design this so it doesn’t fall over in three years when we’re at ten times the users. AI can suggest options here, it’s actually decent at listing tradeoffs when you ask it to. But it can’t own the decision, because owning a decision means understanding context that isn’t written down anywhere. Company politics and a founder’s gut feeling about where the product is going next year, the kind of thing nobody puts in a doc.
High-level design is the same story. Someone still has to decide what the product should even do, not just how to build it. AI is actually bad at this in my experience. Ask it to design a feature from scratch with real constraints, actual users, existing tech debt, a deadline that doesn’t move, and it tends to give you something generic. Technically correct, contextually clueless. It hasn’t sat in the meetings where someone explained why the last version of this feature failed.
This is where I start to feel a bit uneasy writing this article, if I’m honest. Because the jobs that are safe, architecture, system design, product judgment, the calls nobody wants to own, are mostly senior jobs. You don’t walk into a company at 22 and get handed architecture decisions. You get handed boilerplate and testing, the exact stuff that’s disappearing first. So the traditional path, do the grunt work for a few years and earn your way into design decisions, that path is getting shorter at the bottom exactly when it matters most.
My friend actually brought this up unprompted. He said the junior devs on his team aren’t getting the same rep his generation got, because the AI just does what juniors used to do. He’s not sure where that leaves someone starting out in 2026. Neither am I, honestly. Nobody’s figured this part out yet, and I haven’t seen a company admit it publicly either.
Closing thoughts
I don’t have a neat answer for where this settles. Nobody does, not even the companies making these decisions in real time.
What I keep coming back to is that spreadsheet math from earlier. It’s not going away. If anything it gets more convincing every quarter as the tools get better at documentation, testing, migration, maintenance, boilerplate. The five buckets aren’t shrinking, they’re probably going to grow, and whatever bucket six turns out to be is likely already getting automated somewhere without anyone writing an article about it yet.
My friend’s team is hiring again, actually. Just for a different kind of role than the one that got cut. Whether that’s a fair trade for the people who were on the old team, I really don’t know. He doesn’t either.