At the start of 2026, I did not want to write another list of model releases. I wanted to talk about what it felt like to work in software while the tools, expectations, and career conversations were changing around us.
From Portugal, my experience of the job market did not resemble the optimism of every AI announcement. I saw competition for roles, pressure on salaries, and developers wondering how to position themselves. That was my observation, not a comprehensive labour-market study. It was still worth discussing.
The question behind my original essay remains useful: when the technology becomes more capable, what improves for the people using it?
Capability and a sustainable career are different questions
An assistant that can produce a useful first implementation changes the work. It can help someone explore an unfamiliar library, understand a repository, or turn an idea into a prototype. I have felt that change directly in my own projects.
It does not follow that every developer becomes more productive by the same amount. A person who can recognise a good solution, diagnose an error, and define a useful test has a different relationship with generated code from someone who has to accept it on trust.
That distinction worries me when I think about people entering the profession. If a team delegates its simpler tasks to an assistant, it still needs a way for junior engineers to learn how the system works. Removing the task without replacing the learning opportunity creates a problem that better code generation will not automatically solve.
Judgment becomes easier to see
When a first draft is cheap, decisions around it become more visible. Is this the right problem? What must remain true after the change? What evidence would convince us that it works? What should the system do when a dependency fails?
These questions were always engineering questions. AI makes them harder to avoid. A convincing implementation can arrive before the team has agreed on the behaviour it actually needs.
I do not think the answer is to abandon programming knowledge. Understanding code is part of judging it. The practical shift is to connect that knowledge to requirements, architecture, review, and operations rather than treat typing speed as the main measure of contribution.
Generation does not settle verification
A code change can look tidy, pass a narrow test, and still misunderstand the product. It can also preserve the intended behaviour while introducing a permission mistake or an operational surprise.
My concern is the gap between how quickly we can propose a change and how confidently we can accept it. Filling that gap takes explicit expectations, tests that exercise meaningful behaviour, and reviewers who understand the consequences of the change.
The answer is not a blanket rule that every AI-generated line is suspect. Human-written changes need the same discipline. The difference is that a high volume of plausible output makes weak review habits more expensive.
Competing globally does not require becoming generic
Remote work widened the set of people we can work with. AI tools also make some skills easier to access. That can feel threatening if a professional identity rests entirely on producing a familiar kind of implementation.
The response I find useful is specificity. Understand a domain. Learn where its systems fail. Become good at explaining tradeoffs and delivering a result someone can rely on. Show the decisions behind the work, not only a list of frameworks.
This is an approach to developing a career, not a guarantee of employment. Geography, timing, company budgets, and personal circumstances still matter. Treating uncertainty as an individual failure would miss much of the problem.
Keep space for disagreement
Using several assistants does not remove the need for independent thought. Agreement can be useful evidence, but it is not proof. If several outputs follow the same assumption, their consistency may hide the very question a reviewer should ask.
For architecture work, I want the alternative made explicit. What would make this choice wrong? What constraint would favour a different design? What evidence are we missing? Those questions turn a polished answer into something that can be examined.
Build a future we want to work in
I think about these changes as an engineer and as a parent. Seeing several technological shifts within one lifetime is exciting. Constant adaptation can also be exhausting. Both reactions can be true.
I do not have a final answer for what AI will mean for every career. I do have a direction for my own work: use the tools, understand their boundaries, keep learning, and make the reasoning behind important decisions available to other people.
The measure of progress should include more than what a model can generate. It should include whether a team can trust the result, whether newcomers can learn, and whether the people doing the work have a sustainable place in it.
That is the question I wanted to ask in January. It still seems more useful than another leaderboard.