This is not a piece about which model is best. It is not a piece about how AI will reshape engineering jobs, what the next eighteen months will look like, or which tools you should be adopting now to stay ahead. Those pieces exist in abundance. You do not need another one.
This is a piece about what to do while the dust is still settling — when the honest answer to most predictions is that we don't know yet, and won't know for a while.
The Oracle Economy
There is a particular shape that engineering discourse has taken over the last two years. Every week, several new voices arrive with confident predictions about what AI is doing to software development. The predictions contradict each other. The same data is read as evidence that engineering jobs will collapse and as evidence that demand for engineers will explode. The same tooling is described as a productivity revolution and as a quiet way to dismantle teams. The same models are called paradigm-shifting and underwhelming, often in the same news cycle.
A reasonable engineering leader, reading this, can feel two things at once. The first is genuine uncertainty about what their team should be doing differently. The second is pressure — sometimes from above, sometimes from peers, sometimes self-generated — to have an opinion. To be confidently navigating the change. To not be the person who says they don't know yet.
The pressure is real, and the temptation to perform certainty in response to it is real. But performed certainty is what the discourse is already saturated with. What it is short on is the calmer thing: honest acknowledgment that the situation is genuinely unclear, and disciplined work to evaluate it as evidence accumulates.
What I Don't Know
I don't know what AI is going to do to engineering teams in five years. Neither does anyone else, regardless of how confidently they are saying it.
I don't know whether the productivity gains we are seeing in narrow benchmarks generalise to the messy work of building production systems over months and years. I don't know whether the current generation of tools will look like obvious tooling in five years, the way version control does now, or whether it will look like a transitional technology that we mostly stopped using. I don't know whether teams that adopt aggressively will outperform teams that adopt cautiously over the long run, or the reverse. I don't know which roles will compress and which will expand. Nobody does. The data isn't in.
What I do know is that I have tools for evaluating new technology that worked for evaluating cloud, for evaluating containers, for evaluating microservices, for evaluating every previous wave of "this changes everything." Those tools are not predictive — they don't tell me what will happen. They tell me how to know what is happening, in a few months or a few years, in a way that an opinion published this morning cannot.
That is a quieter kind of knowledge than the oracle economy rewards. It is also more useful.
The Practitioner's Approach
The discipline of evaluating new technology has not changed. It has been written down in many places, by many practitioners, for decades. The shape is roughly:
Be mindful of your limits. You are not going to evaluate every model, every tool, every approach. Pick a small number of things to engage with seriously. Decline the rest without guilt. The opportunity cost of trying to follow everything is the depth you would have applied to anything.
Be curious. Read more than you publish. The signal-to-noise ratio in current discourse is poor, but it is not zero. The most useful pieces tend to be the ones that describe specific applications, name specific failure modes, and resist the urge to generalise. Find them. Read the primary sources rather than the takes about them.
Test. Use the tools on real work. Not demo projects, not benchmarks — the actual codebase you are responsible for, the actual problems your team is solving. The gap between a tool's marketing and its real-world utility is where the useful information lives, and you can only see that gap by working in it.
Evaluate against your principles, not against the discourse. Does this tool create value? Where does it create waste? Does it strengthen or erode the things you already know matter — clear ownership, sustainable pace, knowledge that compounds in the team rather than evaporating? These are the questions that survive every technology shift, because they are not about the technology.
Loop back. The first evaluation is not the final one. Tools change, your team changes, the work changes. What looked like a productivity gain in month one may look like accumulated debt in month six, or it may look like the new normal. You will not know which until you check. So check, on a cadence, deliberately.
What This Is Not
This is not an argument against engaging with AI tooling. The opposite. The work of evaluating these tools seriously is more important now than it was two years ago, because the tools are more capable and the stakes of getting the evaluation wrong are higher.
It is also not an argument for restraint as a posture. Restraint as a posture is its own kind of performance — the engineering leader who is conspicuously above the hype is performing certainty in the same way as the leader who is conspicuously riding it. The honest position is neither. It is engaged, attentive, and uncommitted to a conclusion the evidence does not yet support.
What it is, in the end, is an argument for not abandoning the values and practices that worked before this moment. The question of whether AI changes engineering is genuinely open. The question of whether the principles of good engineering leadership change is not. They do not. Aim to create value. Avoid waste. Evaluate honestly. Loop back when you have new information. Do not predict. Do not panic.
We don't know yet. And that's fine.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.