For years, developers were hired and valued for the technologies they knew.
Java, PHP, Python, databases, frameworks, libraries. Résumés were full of technologies with more or fewer years of experience, and job postings reflected that too:
“We're looking for a Java developer with five years of experience, knowledge of Spring, SQL…”
But artificial intelligence has already broken that model completely.
Today an AI can write a Java class, build a Go endpoint, generate a SQL query, or implement a design pattern without me having to remember the exact syntax — and eventually, better and faster than I could.
Then an uncomfortable question appears:
What does it really mean to be a developer when writing code stops being the central part of the job?
Maybe we're going back to the origin
When a client arrives with an idea, they rarely arrive with a perfectly defined requirement (side note: that has only happened to me once in nearly 30 years of career).
They arrive with a problem.
They tell us how their business works, what they need, what information they receive, what they want to get out of it, and who participates in the process.
And that's where our real work begins.
We ask.
- Who enters this data?
- Who can modify it?
- Who needs to see it?
- What happens when information is missing?
- Which existing systems are involved?
- What happens if something fails?
While we talk with the client, we're already building the system in our heads.
We think about processes, data, integrations, security, infrastructure, exceptions, and hundreds of small details that were probably never in the original idea.
When that process ends, something the client could have summarized as “I need a system that does this” has become an architecture.
And none of that disappears with artificial intelligence.
What changes is who executes
Until now, after doing that analysis, we handed the requirement to a team of developers, whose lead broke it down into specific tasks to divide among the team and move the system forward.
In the future — and to a large extent already in the present — that team can become a swarm of AI agents.
- One agent works on the backend.
- Another on the frontend.
- Another writes tests.
- Another reviews security.
- Another analyzes the database.
That said, human work begins to shift, but far from the fatalistic predictions, it does not disappear.
The job no longer consists necessarily of writing every line of code, but of defining, designing, directing, constraining, integrating, and validating.
And this can raise the value of something that for years seemed to lose importance: experience.
Where senior developers were being replaced by young talent, the trend today could be the opposite.
A senior developer does not only know how to write code.
After many years building systems, a senior developer recognizes patterns. Knows where problems tend to appear. Understands when a technically elegant solution can be a terrible decision for a company.
Can listen to a requirement and immediately start thinking about its consequences for infrastructure, security, data, integrations, and maintenance.
AI can generate code extraordinarily fast.
But someone still has to know what to ask it, why to ask it, and whether what it produced makes sense.
And then the junior problem appears
This is where, for me, one of the most interesting questions of this technological transformation appears.
Traditionally we trained developers through experience.
We gave a junior relatively small, controlled tasks. They wrote code. They made mistakes. They got a review. They corrected. They broke something. They learned why it broke.
Over the years they stopped thinking only about code and began to understand systems as a whole.
They went from junior to mid and eventually to senior.
But if now we say:
“I don't need you to write that code; AI can do it.”
we have just eliminated the essential part of the mechanism through which that person gained experience.
And a paradox appears:
How do we train the seniors of the future if we automate the tasks juniors used to learn with?
We can't simply turn a junior into an architect, analyst, or technical lead by handing them an AI.
Because knowing how to ask for something correctly requires understanding what we're asking for.
The junior will also have to change
This doesn't mean new developers don't need to learn programming.
It probably means exactly the opposite.
They'll need to understand the fundamentals, even if memorizing syntax becomes less important.
But they'll also have to develop, much earlier, capabilities we traditionally acquired after several years.
- Learning to interview.
- Learning to ask.
- Learning to model processes.
- Learning architecture.
- Learning how information flows inside an organization.
Learning to distinguish a technically possible solution from a reasonable one.
And, especially, learning to question what an AI produces.
Because there's another danger.
A developer who has never actually built a system can end up depending completely on AI's recommendations.
And if they don't have enough technical judgment to question them, they stop directing it.
It's the AI that starts directing them.
Companies will also have to change
Here seniors, architects, and technical leads will probably have a fundamental role.
Organizations will need to define internal frameworks, reference architectures, patterns, standards, constraints, and technological principles much more explicitly.
It won't be enough to tell a developer:
“Use AI to solve this.”
The ground within which humans and agents can work will have to be established.
- Which technologies we use.
- How we authenticate.
- How we design our APIs.
- How we store information.
- How we do observability.
- Which security standards we follow.
- Which decisions an agent can make autonomously and which require human intervention.
Knowledge then stops living exclusively in the heads of experienced developers and starts becoming structured context for humans and machines.
Maybe résumés will change too
For decades we hired people for the tools they knew.
“Five years of Java.”
“Three years of Angular.”
“Experience with PostgreSQL.”
That made sense when mastering the tool represented a large part of the cost of producing software.
But when an AI can go from Java to Go, from MySQL to PostgreSQL, or from Angular to another framework in seconds, syntax loses part of its differential value.
It doesn't mean technology stops mattering.
It means that perhaps understanding systems starts to matter much more than remembering how to write them.
Maybe the profiles of the future will talk less about languages and more about the ability to analyze domains, design architectures, understand processes, work within constraints, validate solutions, and direct agents.
And curiously, that wouldn't be moving away from software engineering.
It would be returning to its essence.
The important question is no longer whether AI can program
That discussion is starting to get old.
AI can already write code, and every year it will do it better.
The truly interesting question is another:
How do we train the next generation of engineers if the machine does precisely the work we used to learn to be engineers?
Perhaps that will be one of the great challenges of our profession in the coming years.
Not simply teaching people to use artificial intelligence.
But finding a new way to build experience in a world where it will be less and less necessary to personally write what we are building.