A few weeks ago I said on Twitter that the role of specialists in a language or framework is on its last legs and, as expected, some people started calling me every name under the sun.
Normal.
It is not a comfortable idea. Nobody likes hearing that they are losing value at full speed. But the more I look at the market, the clearer it becomes that I fell short.
Today I am here to expand that 280-character post with my full opinion. You already saw a small introduction in the video where I mentioned that code typists have their days numbered in January 2026. If you have not watched or read it, no need, in this post we are going to recap and continue.
Regarding what I mentioned in that video, I stand by every word. And not only that: what has been happening in the market lately points to a much deeper change than even I thought.
Table of contents
1 - Recap: I fell short
In that post I said that AI could increase the amount of code we produce by between 30% and 40%. I also explained that, in many cases, 70% of the work is not writing code, but understanding the problem, talking to people and operating in a real environment.
That part is still very much the same.
At first I thought AI was only going to change the role of the code typist: the person who simply translates Jira into code. And honestly, I was wrong.
AI is changing the entire role. And not only that: it is pushing the emergence of a new position, or at least a modern version of something that already existed.
2 - The analyst programmer is back, and it comes with AI
If you run into the cesspool that is LinkedIn and filter for senior roles at tech companies of a certain level, you will start seeing names that, until recently, were not that common: Forward Deployed Engineer, Product Engineer, Product Builder, Full Stack Builder...
They are not exactly the same role in every company, but they all point in the same direction: profiles that understand the problem, talk to customers or the business, build, deploy and iterate.
And when you read those job posts, the funny thing is that the description sounds extremely familiar.
It is the old-school analyst programmer. But with AI.
Yes, that role that, in the vast majority of the Spanish market, or well, the global market, died 15 years ago. That role that existed before we decided to specialize in frontend, backend, DevOps, SRE, mobile and 50 other titles we invented so we would not step on each other's toes is back, and it is coming back strong and without brakes.
In these kinds of job posts they ask you to talk to customers, to decide yourself what needs to be built, and of course design, programming and deployment are taken for granted, whether in the technology or with the characteristics they ask for.
All of that without anyone from product, without a designer making mockups or a scrum master handing you tickets as if you were a little kid, all by yourself, end-to-end.
This is where my prediction from a few months ago falls short. My view was that we would come out "stronger as engineers", and even though that is still true, another layer needs to be added: we are going to come out stronger as people who understand the product, the business and know how to communicate outside a purely technical circle.
3 - The reality of the market
In that post I was working with AI but I was not taking it to the limit. I was clear that it was going to be a tool, and that replacing 100% of engineers did not seem viable to me, and it still is not, but watch out, because I have seen something that changed my mindset.
In senior job openings at top companies, in the requirements section, having AI experience is no longer seen as a nice-to-have, it has become a mandatory requirement to get into those companies.
And before someone jumps in with the usual stuff, that AI hallucinates, that it generates bad code, that "I do it better by hand", I will tell you one thing: that is no longer a good enough argument.
Of course AI makes mistakes. A junior also makes mistakes, a senior also makes mistakes and the architect who has been at the company for ten years also makes mistakes. The difference is that you do not judge a person for not getting it right the first time, but by how you guide them, what context you give them, how you review their work and how you integrate the result.
The same thing happens with AI. If your only conclusion after using it is "it hallucinates", maybe the problem is not only the tool. Maybe the problem is that you do not know how to ask it, constrain it, verify it or turn it into part of your workflow.
This does not mean specialists disappear. It means that the average specialist, the one who only knows how to move inside a very narrow little box, will have less and less room.
3.1 - The company numbers
In that post I talked about the qualitative change: how the way we program changes. Today I want to talk about the quantitative change, the one that hurts, at least for me. Pure math.
A traditional team consists of the following
- 1 Product owner
- 1 Designer
- 3-4 Backend developers
- 1-2 Front end developers
- 1 QA
- 1 DevOps
- 1 Manager
In some organizations the QA role, as well as the DevOps role, is actually someone from the team, whether someone from front or back takes care of it. In the teams I have worked with lately, I have always been the one, for example, in charge of setting up deployment pipelines, etc. Sometimes you are missing access, you ask for it, or you ask for whatever specific thing you need, they give it to you and off you go.
From the company's point of view, this is a massive amount of overhead. A traditional team can have 7, 8 or 9 people between product, design, backend, frontend, QA, DevOps and management. Between salaries, taxes, coordination, meetings and handoffs, the bill is huge.
If part of those functions is absorbed by more autonomous profiles, supported by AI, the economic incentive is obvious: fewer people to coordinate, less time waiting for other teams, fewer meetings and faster delivery.
Did you really think the CFOs of the world were going to ignore these savings? Come on.
3.2 - The issue with specialists
It is obvious that with the use of AI as a work tool, the quality bar goes up. Someone who was an "average" developer, to put it somehow, once they mastered the use of AI (skills, agents, harness, etc.) became a good developer, and in some cases a very good one.
What I did not explain well is that AI does not only raise the bar in depth, but also in breadth.
Many junior and mid developers have been sold a lie in recent years with hyper-specialization: "I am a React frontend developer with TypeScript and Next.js". Fine, perfect. And what else?
In today's job offers you need to know a bit of everything: API integrations, data synchronization, identity management between systems, data pipelines, deployments, observability, how to use AI, basic frontend knowledge, etc.
You do not have to be the best in the world at React, or C#, or Java. But you need to have enough judgment in several areas to move forward without getting blocked every two hours and to know when AI is helping you and when it is selling you smoke with a lot of confidence.
This, my friends, does not kill the excellent specialist. It kills the comfortable specialist.
The top 1% who know a huge amount about something will still have a place. The problem is for those who have confused specialization with not wanting to learn anything else.
3.3 - From T-Shaped to M-Shaped developers
For years people talked about the T-Shaped profile: someone with depth in one area and general knowledge in others. That made sense in large teams, where you could be very good or even a reference in frontend and lean on backend, DevOps, QA, product or design.
But AI pushes toward something more like an M-Shaped profile: several columns of reasonable depth. You do not need to be top 1% in five disciplines, but you do need enough judgment in several of them to be able to direct AI, review what it generates and make decisions without constantly depending on someone else.
4 - What this means for you
It is my blog and I do what I want, specifically, I am going to give my opinion on what needs to be done.
First of all, start using AI seriously, TODAY, not tomorrow, not "when I have time", TODAY. Whether it is Cursor, Claude, Copilot, Codex or whatever the hell you want. Use AI daily in real projects until it becomes an extension of your brain. Do not let it run wild, define rules, direct it, review it and iterate.
Learn product. I have said it many times: lots of programmers clock in, read Jira tickets, change the code and, three years later, they do not even know what the company sells. In the world we are heading toward, if you do not understand the business, you are replaceable.
Widen your stack. If you only know frontend, learn backend. If you have only worked in backend, learn a few DevOps things. If you have never done an integration with an external system in your life, get on it.
The T-Shaped Developer has evolved into the M-Shaped Developer, and this is mandatory, not optional for your future.
Learn to talk to humans, there is not much mystery to it. If your little guy shrivels up when speaking in a meeting, you have a serious problem.
I do not think that just anyone with Claude is going to replace a good engineer. That is not the point.
What I do believe is that anyone with product judgment, business context and well-used AI will be able to do many of the tasks that used to justify having a person whose only job was grinding through tickets.
And that is the problem: if your professional value was only translating a Jira story into code, your margin is going to shrink a lot. Companies are not simply looking for hands that execute. They want profiles that understand problems, make decisions and use AI as muscle.
If you are only hands, you are screwed. If you are brain + product judgment + technical capability + AI, the future looks quite a bit better.
