AI Will Destroy Far More IT Jobs Than It Creates — but One Demanding New Role Is Emerging

The Job Destruction Is the Headline

AI is going to sharply reduce the number of people an IT department needs. Not reshuffle them — reduce them. If you're waiting for someone to reassure you that "technology always creates more jobs than it destroys," I'm not going to be that person, at least not about software.

Senior developers are moving from writing code most of the day to writing prompts most of the day, and their output multiplies by something close to ten in the process. The arithmetic isn't subtle; when one engineer does the work that used to take five, four seats don't get redefined, they disappear.

It doesn't stop at coders, though. The roles that grew up around software development are even more exposed, because so many of them existed to coordinate, specify, and check work that humans did slowly. When the software increasingly builds and verifies itself, you need far fewer business analysts translating requirements into tickets, far fewer scrum masters choreographing hand-offs between big teams, and far fewer QA people running manual passes against a spec. These were real, skilled jobs. A lot of them are not coming back.

So I'll state the headline plainly before I get to the hopeful part: for IT, the near-term story is subtraction. Anyone selling you a tidy "AI creates more than it destroys" narrative about software work isn't looking closely.

One Genuinely New Role Is Emerging

Here's the part that's actually new, and the reason I'm writing this. In my own work I keep running into a kind of need that - I'm sure - companies will clamor for in the near future.

The role is this, and it sounds easy; amost deceptively close to the current QA tester: someone who takes a freshly AI-built app or feature, plays around with it, and figures out how to make it better.

I say "play around" on purpose, not "test." We are leaving behind the world of rigid specifications and human-drawn mockups produced up front, where coding was merely the implementation step. That world is ending because the models got good at the part we assumed only humans could do. Today's models are genuinely excellent at UI — given the right context and a clear prompt, they produce layouts better than what a lot of human designers would hand you. (I've written before about how context is the real architecture in this kind of work.)

So the early stages of the development lifecycle collapse. You go from an idea, to a fleshed-out idea (via human conversation, but without nailing down every UI detail in Figma, like we used to do) and then you hand it to a model that builds a working feature and even tests it. The slow, expensive front half of the process, the part that used to employ designers, spec writers, and weeks of meetings, compresses into hours.

The new job appears in the stage after that: the moment you have a working, AI-built feature in front of you, you need a human who can do the one thing the model can't — look at a perfectly competent result and imagine how it can be improved further.

Why This Isn't a Business Analyst, and Isn't QA

If you squint, this sounds like a business analyst role, or maybe a QA role. It's neither, and the difference is the whole point.

QA, in its old form, verified software against a spec — does it match what we wrote down. This role has no fixed spec to verify against; the spec is the thing you're trying to discover. And a business analyst's classic job was to write that spec up front. But an AI-generated design is a leading question. It arrives looking finished, confident, and reasonable, and that's the trap. To improve it, you have to refuse to be led — to look at something that already works and see what it's missing, what would delight a user it currently only satisfies, what could be more powerful. It requires a true idea person.

That's harder than writing a spec from scratch, and frankly a lot of the business analysts I've worked with weren't great at the from-scratch version either. Many struggled to write specifications for genuinely usable interfaces in the first place. Improving an already-good interface is a steeper task. It demands a critical eye most people simply don't have, plus an understanding of the underlying technology that's broader and more multi-faceted than the surface-level familiarity a typical BA brings.

This is also why you can't smoothly redeploy the people the AI wave displaces into these seats. The instinct will be to retrain a laid-off scrum master or a manual QA tester into "AI product testing," and for most it won't take — not because they aren't capable people, but because the skills barely overlap. Coordinating a team, or checking output against a checklist, is a different muscle from imagining what a product should become.

This Is Real Work — and Enormous Responsibility

Make no mistake, this is not a soft job. Playing with software to find its next version is time-consuming and demands the same peak mental energy and focus that coding does. The old style of testing — checking a UI against a fixed spec, line by line — is gone. Testing becomes an active discipline. You aren't confirming that the thing matches a document; you're using it hard enough to set the stage for its next improvement.

And the responsibility is the part people underestimate. When the front half of the lifecycle collapses, the judgment that used to be spread across designers, analysts, product managers, and QA concentrates into this one person's hands. What they choose to push on, ignore, or reshape becomes the product. That's a heavy thing to carry, and it's another reason the role is hard to fill: you're not staffing a checker, you're staffing someone you trust to shape what ships.

Doing it well requires a specific and uncommon bundle of abilities:

• A feel for what stakeholders will actually get excited about — not what's on the requirements list, but what makes someone lean forward.
• Deep product understanding — you have to grasp the product's real challenges and untapped potential, not just its feature set.
• The ability to communicate it precisely — either you hand the developer (now a prompt engineer) a crisp description of the improvement, or you sketch the prompt yourself.

That last requirement trips up a lot of people. The role lives close to the product and close to the user, and it leans heavily on cultural and linguistic fluency with the audience you're building for. It's the same reason you wouldn't staff a U.S. consumer-marketing role with someone who doesn't yet have a deep, near-native feel for the U.S. market, its idioms, and its expectations.

Some BA seats, historically, were filled by people (often recent immigrants) brought in mainly to turn requirements into tickets, where that fluency wasn't required.

For this new job deep cultural, business, language, and product understanding is non-negotiable, because imagining what will delight a particular audience means understanding that audience at a level that's hard to fake.

The Shift Toward Product Ownership

Step back and a larger pattern shows up. The work that survives — and the rare new work that's appearing — is pulling toward product ownership and marketing, and away from the deeply-removed implementation roles that defined the last few decades.

Shipping software used to require large teams, most of whom sat two or three levels from the customer and never attended a single requirements-gathering meeting. The code was the hard part, and the coding team saw proliferation of various roles.

Now the code is fast and cheap, and the scarce, valuable work is the thinking that sits right next to the user: what to build, why, and how to make it land. I've argued for years that keeping developers out of requirements gathering was always a mistake — that the people building the thing belong in the room where its purpose is decided. AI makes that argument even stronger.

What You Can Actually Do About It

So here's the practical part, especially if you're a new graduate eyeing a career in IT — or anyone watching the old roles fade and wondering where they'll fit. Lean directly into this. The way to prepare for the job that's emerging is to start doing a primitive version of it now.

Build something with AI. Any product, however small — a tool for yourself, an app for a hobby, something only you will ever use. The project itself barely matters; what matters is what you do once it works. Keep coming back to it and asking how it could be better, then working with the model to make it so. Imagine an improvement, think it through with the model, watch it take shape, react to what comes back, and push again. That loop is the exact muscle this new role runs on, and almost nobody is deliberately training it yet.

You'll pick up real technical depth along the way, and not the part people fixate on. You don't need to memorize how to write a loop in Python. You need to understand how real systems are shaped, and the model is a patient, always-available teacher for precisely that. Ask it why it structured something the way it did. Press it on security, on what happens when ten thousand people show up at once, on how this would get tested, deployed, and monitored. Make it explain the trade-offs it just made on your behalf. Do that across enough projects and you'll build the broad, architectural understanding — security, scalability, CI/CD, testing, debugging, the whole surface — that separates someone who can genuinely shape a product from someone who can only check one.

So that's where I'll actually land. The old ladder into IT is being pulled up, and I won't pretend otherwise. But there's a new one going up beside it, and the people who climb it will be the ones who started building and improving real things with AI before anyone told them it counted as a job.