What AI will do to us

Or better yet what is currently doing to us

I was scrolling through the announcements. Another release. Another benchmark. Another list of things this new version can do that the previous one could not.

And the endless discussion of what AI is, what is capable of, the doomers, the utopians.

The coverage that followed had the same shape it always does. What does this mean for your workflow? What does this mean for your team? How do you use it effectively? How do you stay ahead of the people who are also figuring out how to use it?

I read through most of it. And then I closed the tab and sat for a while with a feeling of emptiness, knowing that all that information was somewhere in a documentation section of a particular site. But none of it asked the question that mattered most.

What is all of this doing to us?

Not to our output. Not to our productivity or our competitive position or our quarterly numbers. To us. To the people sitting at the keyboards. To the engineers and the leaders and the teams who are now, whether they chose it consciously or not, reorganising their working lives around a tool that is getting smarter at a rate that human beings are not.

I have been in technology long enough to recognise the pattern. Every release is framed as a gain. Every announcement is a celebration of what has become newly possible. And the energy around that is real. I feel it myself. There is something genuinely compelling about a tool that keeps expanding what it can do.

But there is a question that does not get asked at the launch party. And I think the cost of not asking it is starting to accumulate in ways we are only beginning to see.

The conversation we keep skipping

I want to be precise about what I am pointing at, because it is easy to hear this kind of concern and file it under the wrong category.

I am not talking primarily about job displacement, though that is a real and serious issue that deserves its own honest conversation. I am not talking about hallucinations or errors or safety benchmarks, though those matter enormously and are not yet solved. I am talking about something that operates at a slower frequency and is harder to see because it does not produce a visible incident. It produces a drift.

When a model gets better at reasoning, something changes in the room where humans used to reason together. The room gets quieter. The pauses get shorter. The arguments that used to happen because two people had genuinely different intuitions about a problem start to happen less, because there is now a third voice that is faster than both of them and carries no emotional stake in being right.

When a model gets better at writing, something shifts in the relationship between a person and the effort of forming their own thoughts. The blank page , which used to be a necessary friction, a space where you had to hold the discomfort of not yet knowing what you meant long enough to find out , becomes optional. You can skip it. You can start with output instead of starting with silence.

When a model gets better at coding, something moves in the space where a junior engineer used to spend three uncomfortable hours on a problem they could not crack. Those three hours were not inefficiency. They were formation. They were the process by which someone became a person who could hold a complex system in their mind and navigate it. When you remove that struggle, you do not just save time. You interrupt something that was quietly building a capability that cannot be installed any other way.

I have watched this happen in real teams. In engineers I have worked alongside and coached. In myself, on the days when I reach for the tool before I have even sat with the problem long enough to know what kind of problem it actually is.

The output gets faster. The thinking gets thinner. And because the output is visible and the thinking is not, the thinning does not show up anywhere that anyone is measuring.

What these systems are, and what they are not

Part of what makes this conversation difficult is the language we use to describe what is happening. We call these systems intelligent. We talk about them reasoning, understanding, and knowing things. We have absorbed, without quite deciding to, a framing that places these tools somewhere on a continuum with human cognition , just faster and more capable in certain domains.

That framing is doing significant damage, and not because it is purely wrong. It is wrong in the ways that matter most.

A large language model is trained on human text. It becomes extraordinarily good at the patterns of how human beings write and think and argue. It can recombine those patterns in ways that produce outputs that look like reasoning and read like insight. In a narrow, functional sense, something remarkable is happening inside these systems.

What they cannot do is understand. Not in the way a person understands something. Not with a body that has carried grief or made a promise they later had to break. Not with a history of being wrong about something that cost them a relationship and having to live inside that for years. Not with the capacity to sit across from another human being and feel, in the texture of the silence before they speak, that something underneath their words is different from the words themselves.

That gap is not a version problem. It is not something that the next release will close. It is a different category of thing entirely. And when we describe these systems as if that gap were merely a technical limitation being worked on, we do something subtle and consequential, we begin to calibrate human intelligence against machine output and find the human version slower, messier, and harder to justify.

That recalibration is not neutral. It does not stay contained to how we think about productivity. It starts to shape how people feel about their own minds. About the value of the slow, uncertain, embodied process of thinking something through without help. And once that feeling takes hold in a team, it changes what the team is willing to do.

How dependency builds without anyone deciding to build it

I want to describe a pattern I have observed carefully, because it is easy to dismiss as anecdote until you have seen it enough times that it starts to look structural.

An engineer begins using an AI assistant. The initial relationship is uncomplicated. They reach for it on the repetitive work, the boilerplate, the tasks that feel like friction between them and the problem they actually want to solve. This is a sensible choice. There is no reason to write the same kind of code manually that you have written a hundred times before. The tool handles it. The engineer moves on to the interesting part.

But six months later, something has shifted. They are reaching for the tool earlier in the process. Not just on the repetitive parts, but on the design questions. On the architectural decisions. On the places where the real thinking is supposed to happen. They are not doing this because they cannot think without the tool. They are doing it because the gap between what the tool produces in thirty seconds and what they would produce after twenty minutes of genuine effort has started to feel like evidence of their own inadequacy. The comparison is unfair, but that does not make it less real as an experience.

The tool did not engineer this feeling deliberately. There is no malice in a model. But the system behind the tool , the company that built it, the business model that depends on it becoming indispensable, the incentive structure that rewards increasing usage and would be damaged by decreasing it , that system understands exactly what it is doing. It is not designing for augmentation. It is designing for reliance. Those are different things, and the difference matters enormously.

When you build something that gets measurably smarter every year while the person using it stays roughly the same, the trajectory of that relationship only goes in one direction. You do not end up with someone who has been enhanced. You end up with someone who has been made dependent in ways they may not fully recognise, because the dependency formed gradually and because each individual step along the way felt entirely reasonable.

This is not a side effect that the industry is working to eliminate. In many cases, it is the product.

What happens to teams that stop disagreeing

There is a social and institutional dimension to this that gets even less attention than the individual one, and it may be more consequential at scale.

Teams think together. Not just in the sense that individuals who happen to work near each other each do their own thinking, but in the deeper sense that the quality of collective reasoning in a well-functioning team is genuinely higher than the sum of its parts. That happens through argument. Through the friction of people with different instincts pushing against each other until something that neither of them could have reached alone becomes visible.

That process is slow. It is uncomfortable. It requires people to hold uncertainty without resolving it prematurely. It requires a tolerance for being wrong in front of your colleagues. It requires the kind of psychological safety that takes a long time to build and very little time to damage. It is, in other words, exactly the kind of thing that a fast, confident, always-available tool makes it tempting to skip.

When a team starts routing its hard questions through a model before it routes them through each other, several things happen. The arguments get shorter, because there is already an answer on the table and arguing with an answer is harder than arguing with a colleague who is still forming their view. The junior voices get quieter, because the model does not hesitate the way a junior person hesitates, and hesitation is often where the most genuine thinking lives. The range of perspectives that gets considered narrows, because the model draws on what has already been written and published, not on the particular context and history and local knowledge that lives only in that room.

Over time, the team gets more efficient and less wise. And because wisdom is not a metric that anyone is tracking, the loss does not register until something goes wrong in a way that better collective thinking would have prevented.

Organisations that normalise machine-first thinking do not just change their workflows. They change the culture of how people relate to uncertainty and to each other. That is a long-term cost that will be very difficult to reverse once it is established.

When a team stops disagreeing, it does not become more aligned. It becomes more brittle. The arguments that felt inefficient were doing something the efficiency could not replace.

Who benefits from the dependency, and why they will not say so

This is the part of the conversation that gets avoided most consistently, and I want to try to have it plainly.

Every time a new model is released, the question asked loudest is what it can do. The question almost never asked is who benefits from you not being able to do without it.

The business model of these systems is not augmentation. Augmentation would mean building something that makes you more capable and then steps back. What is actually being built is something different, a tool that makes itself progressively harder to remove from your workflow, that captures your data and your patterns in ways that make switching costly, that is priced to create habitual use and structured to reward increasing dependence.

What makes it particularly effective is that the dependency does not feel like dependency while it is forming. It feels like getting better at your job. It feels like being more effective. Only later, when you try to think through a hard problem without it and feel the absence more acutely than you expected, do you begin to understand what has quietly happened.

The question for leaders is not whether to engage with these tools. That question is already answered. The question is whether you understand the power dynamics you are operating inside, and whether you are making deliberate choices about which parts of your team’s capability you are willing to trade and which parts you are going to protect.

The question under the benchmark

Every time a new model is released, the benchmarks go up. The capabilities expand. The list of things it can now do that it could not do before gets longer and more impressive. Some of what these systems can do is genuinely extraordinary, and I do not want to diminish that.

But the benchmarks measure the tool. They do not measure what the tool is doing to the people using it.

There is no benchmark for what happens to the engineer who stops working through problems by hand and loses, over two years, the ability to hold a complex system in their head without external scaffolding. There is no metric for the leader who has outsourced the uncomfortable ambiguity of difficult decisions to a prompt and slowly lost the tolerance for sitting with uncertainty that good leadership requires. There is no number for the team that stopped arguing about the right approach because the model gave them something adequate and the argument felt like inefficiency , and which, eighteen months later, ships something that causes harm because nobody in the room had the habit of pushing hard enough on the hard questions.

The industry measures what AI can do. Nobody with any institutional power is measuring what it does to us. And that asymmetry is not accidental. The companies releasing these models do not benefit from a public conversation about the cognitive and social costs of their products.

I use these tools. I used one while preparing this essay, and I am saying that directly because being transparent about the tool is itself a form of intellectual honesty that I think matters in this context. The thinking here is mine. So is the uncertainty that came with it. The tool helped me find what I was trying to say. It could not feel why it needed to be said, or what was at stake in saying it clearly.

What staying human actually requires

I am not making an argument against using these systems. That would be dishonest, given that I use them, and it would also be the wrong frame. The question is not whether to use them. The question is whether you are using them with clear eyes about what you are trading and what you are protecting.

What staying human requires, in this particular moment, is something harder than refusing a tool. It requires naming the question out loud, in the rooms where it is most inconvenient to ask.

What is this doing to us?

Not as a philosophical exercise. Not as a rhetorical gesture toward responsibility. As a real leadership question with real stakes and a real obligation to sit with the discomfort of not having a clean answer.

What skills are we in danger of losing if we keep handing over the work that built them? What judgment gets weaker when we stop exercising it? What becomes irreversible if the reliance runs deep enough for long enough , not just in individual people but in the culture of entire organisations?

And then the harder question, what do we choose to protect, and what are we willing to do to protect it?

Not by refusing the tool. By being deliberate about where the human has to stay in the loop , not because it is more efficient, but because some capabilities only form through the doing of them. Because struggle is not waste. Because the engineer who spends three hours on a problem they could have handed over in thirty seconds comes out of those three hours with something the model does not have and cannot give, the knowledge of what it feels like to be stuck, and the earned confidence that they can find their way through.

There is a kind of knowledge that cannot be downloaded or transferred. It is built in the body and the will, through repetition and failure and the specific sensation of something finally making sense after a long period of it refusing to. That knowledge is what we are here to protect. Not as a nostalgic gesture toward the way things used to be done. As a recognition that what makes human judgment irreplaceable is precisely the difficulty of building it, and that difficulty is not a problem to be solved but a process to be respected.

The releases will keep coming. The benchmarks will keep climbing. The capabilities will keep expanding.

But the question that does not get asked at the launch party remains the most important one.

Not what can we do with it.

What will it do to us.

And what are we going to do about that.

---

About the Author
Tino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.