The death of the one-dimensional engineer: how AI is redefining software development

For a long time you could have a good career doing one part of the stack well. Teams were set up that way. One person turned designs into screens, someone else wrote the Playwright tests, and someone else built the same kind of API they’d already built many times before. The work moved along the line from one person to the next.

I don’t think that holds up for much longer. My view is that AI is putting real pressure on what I’d call the one-dimensional engineer: a developer whose value comes mostly from one narrow task that a model can now produce a decent first draft of in seconds.

Software engineering as a whole is a different question, and the data on that is more mixed than a lot of the commentary suggests. I’ll go through both, and I’ll try to be clear about which parts are evidence and which parts are my own forecast. Nobody knows exactly how this plays out, including me.

What has actually changed for specialists

Think about a front-end developer’s week a few years ago. Connecting to APIs, turning designs into layouts with Tailwind or Bootstrap, writing the logic behind each screen and then writing tests for it in Playwright or Cypress. That was a full job.

Give a current AI tool a clear spec and it will produce a reasonable first pass at most of that: the screens, the responsive layout, the API calls and a set of tests. It gets things wrong, sometimes in ways that are hard to spot, but it’s quick and each release is better than the last.

What it doesn’t do well is decide what should be built, how the pieces should fit together, or whether the output is actually correct and safe to ship. Those were always the harder parts of the job. If someone’s role was mostly the typing, they’re exposed. If they were already doing the thinking as well, AI takes the repetitive work away and what’s left is the part that was always worth more.

This is where people have started using the word orchestrator. The engineer plans the system, directs the AI tools, checks what comes back and takes responsibility for it. They write less of the code by hand, but they’re still accountable for all of it.

From ten people to three or four

This next part is opinion rather than data. Picture a fairly typical product team of ten: two back-end developers, two front-end developers, a QA automation engineer, a tester, a DevOps engineer, a UI/UX specialist, a project manager and a team lead.

By around 2030 I expect a lot of teams like that to look more like three or four people. A lead architect who directs the work, a full-stack engineer who is close to the product, and someone who specialises in AI systems and security. Each of them ends up working a bit like a team lead does now. They spend less time writing code line by line and more time planning, reviewing what the AI has produced and keeping the release process honest.

That leaves companies with a decision about their specialists. They can help them broaden into those roles or they can let them go. Some will do the first. I expect plenty will do the second.

What the numbers actually say

It’s easy to write something dramatic on this subject, so here’s the data. Most of it is from the US, and it doesn’t all point the same way.

I don’t read that as developers being finished. The official forecast says there will be more of them, not fewer. What the data does show is that it has become harder to get in at the bottom, and that hiring has moved towards senior people. That’s the reason I talk about one-dimensional engineers rather than engineers in general.

Part of it is also the end of the hiring boom. A lot of companies took on too many people and have been correcting since, so not every lost role is down to AI, and the two effects are hard to separate.

You can see the shift in job adverts as well. I recently came across a LinkedIn listing for a Senior Rust Developer that said “Rust knowledge not required”. One advert doesn’t make a trend, but the reasoning behind it is easy to follow. If you understand design patterns, data flow and security, the employer expects AI to help you with the syntax.

How I expect each role to change

Again, this is my forecast for roughly 2030 to 2035, so treat it as that. I’m not expecting any of these jobs to disappear overnight. What I expect is for the narrow version of each one to shrink.

What I’d focus on as a developer

The first thing is understanding the whole system. You should be able to follow a request from the screen, through the API, to the database and back, and explain what happens at each step. If you’ve spent your career on the front end, learn the back end properly. The same applies the other way round.

After that, get good at reviewing code you didn’t write, because that’s increasingly what the job is. Generated code often looks finished. The skill is noticing the missing permission check or the query that won’t hold up once there’s real data behind it.

Architecture and security become more important as syntax gets cheaper. AI will give you code that works long before it gives you code that’s safe, and knowing how to structure a system so it can still be changed in a couple of years is a different skill from knowing a language.

I’d also get closer to the product and the people using it, since deciding what’s worth building is the hardest part to automate. And use the tools every day. You can’t direct something you don’t understand, and part of understanding it is knowing where it goes wrong.

If you want a rough idea of where you stand, Claude is a reasonable place to start, as long as you’re honest with it about what you actually spend your week doing.

Where do the next senior engineers come from?

This is the part that worries me most. Senior engineers got their judgement by doing junior work. They wrote the boring code, broke things and were corrected. If companies stop hiring juniors because AI can do that work, that route goes away, and nothing has really replaced it yet.

I don’t think one group can fix it alone. Employers need new kinds of apprenticeship built around reviewing and directing AI work, with a senior person alongside. Cutting every junior role saves money now and leaves you short in ten years.

Governments will probably come under pressure to fund retraining, although so far most of the regulation debate has been about safety and copyright rather than what happens to the people doing the work. And people starting out can’t count on a traditional first job being there. Building real things, and being able to explain every decision in them, will count for more than a list of frameworks.

What it means if you’re hiring

This isn’t only a Big Tech story. For small businesses it’s mostly good news, because work that used to need a whole agency can often be done by one experienced person using AI properly. That’s how I work. You deal with me from start to finish, and it’s a big part of why my prices are lower than a traditional agency’s.

The catch is that AI doesn’t replace experience, and cheap and fast can still be wrong. When you’re hiring someone, I’d ask who checks the work and who is responsible when something goes wrong. If you’re building with AI yourself, these are the checks I’d run before launch.

Where I think this ends up

Making a living purely from turning wireframes into layouts, or from writing the same API again and again, is coming to an end. I’m fairly confident about that. I’m much less sure about the timing, or how many people it affects overall, given the official forecasts still point to growth. What I would bet on is that people who understand the whole system, the product and how to direct these tools will do well. I’d rather be one of them, so I’d start building those skills now.