“I’ve tried AI. Honestly, it’s not there yet.”
That sentence can be a perfectly honest account of an experience. It becomes more questionable when it claims to describe an entire technology, indefinitely.
Tried what, exactly? To do what? And when?
That last detail is beginning to matter quite a lot…
In my first piece, I wondered about the gap between the speed of machines and the pace of human beings. But there is another difficulty: we are not all looking at these machines from the same place. We use the same word, “AI”, for experiences that sometimes have very little in common.
Someone asks it to rephrase an email. The result is fine, a little pompous. They delete “in an ever-changing world”, shorten three sentences and get back to work.
Someone else gives it a software project, grants it access to the code, has it run tests, checks what breaks and tries again. They explore a possibility they would previously have ruled out for lack of time or resources.
The first person has saved a few minutes. The second is beginning to revise the list of things they thought they could take on.
When they discuss AI, their disagreement may be entirely sincere. They simply haven’t tried the same thing.
Yet it would be rather convenient to turn this difference into a ranking of people: the few insiders who supposedly understand, followed by the rest of humanity, happily busy missing the train.
That story is very flattering to the people telling it.
A developer can have a precise understanding of what models make possible in their own work and a very approximate idea of what a nurse, a teacher or a construction manager’s job requires. Being surprised by progress in your own field does not give you early access to the truth about every other one.
Capabilities remain uneven. So do the ways of checking them. A program can pass tests — provided those tests cover what matters. A delicate human decision rarely offers such a reassuring green button.
The gap between uses therefore deserves a closer look, without handing out certificates of clear-sightedness too quickly.
What I find more troubling is the way this gap can widen.
When you experiment regularly, you learn to frame a problem better, supply the right information and recognise a shaky answer. You also discover tasks you would not have thought of. The tool evolves while its user is learning how to use it.
Meanwhile, someone else may hold on to the memory of a disappointing attempt. Their judgement was reasonable when they formed it. It may become less accurate without their having changed anything at all.
It is an uncomfortable situation: you can fall behind by remaining faithful to an accurate observation.
Companies have a more organised version of the problem. They assess a tool, choose a few uses, write a procedure and train their teams. This work is necessary. But it can leave the impression that the matter has been dealt with.
The project has a manager, a budget and a shared folder. It therefore has every appearance of a settled matter…
Except that some of the limitations on which the procedure was based may have changed. A manual step becomes possible to automate. A method that used to cost too much becomes affordable. Conversely, a dependency emerges, a cost rises or a new version performs worse on a particular task.
It must be possible to revisit the arrangement without that revision being taken as an admission that someone did a poor job.
The same goes for decisions against using a tool. “We tried it; it doesn’t work” should leave a slightly more precise record: what was attempted, what failed and what would need to change for another attempt to be worthwhile. Otherwise, a provisional result eventually acquires the force of a company rule.
Of course, reassessing does not mean starting over with every announcement. You can spend so much time comparing new tools that you never finish anything with the old ones. Keeping up with developments then becomes a highly sophisticated way of putting off your work until tomorrow.
The useful question remains fairly down to earth: does this change help us do something that matters better, once we include the time spent checking, the errors and the rework?
Even those with plenty of practice can get the answer wrong. METR demonstrated this in a study conducted in 2025: the developers involved thought they were saving time with AI, while the measurements showed a slowdown. In the follow-up, using more recent tools, the researchers encountered further difficulties with measurement and participant selection. Their experience is a reminder of how difficult it is to move from a convincing impression to a sound conclusion. [1]
We also need to look at what we now decide to do.
If a tool makes a project affordable that we would otherwise have abandoned, its value goes beyond the time saved on a familiar task. But undertaking more projects is no guarantee that they are worthwhile. We can produce far more things that nobody needed. With a nice interface, these days.
Perhaps this is where more is asked of our judgement. When an idea costs less to put into practice, it becomes easier to try. It also becomes more tempting never to ask whether it is worth pursuing.
Here I recognise the impatience I wrote about in my first piece. It can push us to explore, to build, to move beyond habits that have become costly. It can also make us unfair to those who have neither the same tools, nor the same time to learn, nor the same freedom to make mistakes.
Because not everyone pays the same price for their mistakes.
The gap between experiences is real. How it evolves still needs to be measured, task by task, with less certainty than the spectacular curves suggest.
Meanwhile, there is something very concrete to do: return to a problem we had set aside, pin down what stopped us and see whether that obstacle still holds.
Sometimes the answer will be yes.
But it would be a shame to stop asking the question simply because we have already answered it.