Recently, during an engineering conversation, I heard a sentence that made me stop:
“I cannot work anymore. I ran out of tokens.”
The AI coding tool had reached its usage limit, and a task had effectively come to a halt.
The immediate problem was easy enough to solve. Increase the limit, change the plan, remove the blocker. But I kept thinking about the sentence. Not because using AI is a problem. Quite the opposite. I want engineers to use the best tools available, and AI coding tools have become extraordinarily useful.
What caught my attention was the word cannot.
A few years ago, losing access to a development tool might have made an engineer slower. Today, for some kinds of work, losing access to the model can stop the workflow entirely.
That is a much more interesting engineering leadership problem.
The engineer had not forgotten how to type code. What disappeared was the workflow surrounding the code. AI had become the place to begin. It identified the relevant files, explained unfamiliar behaviour and suggested the next step. When an implementation failed, the error went back into the same conversation.
There is a lot to like about this workflow. Large codebases contain far more context than one person can hold. Spending hours locating the right module is not a noble engineering practice. Still, something changes when the tool always supplies the first interpretation.
Before AI, an engineer would usually begin with a rough theory. They would read, search, run the program and discover that part of the theory was wrong. The system became clearer through that correction. Today, the first theory can arrive before the engineer has looked at the problem. It may be better than the theory they would have formed alone. It may also be confidently wrong. In both cases, it shapes everything that follows.
The engineer is no longer starting from uncertainty. They are starting from an answer. This makes work easier to begin. It can also make it harder to notice what the answer has excluded.
I do not think engineers need to struggle for the sake of struggling. But there is a difference between removing wasted effort and removing the point at which someone starts thinking for themselves.
That is the part I worry we are losing.
In 2011, Betsy Sparrow, Jenny Liu and Daniel Wegner published research on how access to online information changes memory. People who expected information to remain available on a computer were less likely to remember the information itself. They were more likely to remember where it could be found.
That adaptation makes sense. We have always stored knowledge outside ourselves. Documentation, books and colleagues allow us to operate beyond the limits of individual memory. Generative AI goes further because it does not merely store the answer. It can decide what the answer means.
An engineer no longer has to remember an API. That is useful. But they may also stop building a clear model of how the surrounding system behaves, because the model can reconstruct one whenever needed. The difference only becomes visible when the reconstruction is incomplete.
Software contains reasons that are not obvious from the code. An ugly branch may protect an old customer workflow. A duplicated check may exist because the cleaner version failed under load. A service boundary may reflect organisational constraints rather than technical elegance. The model sees what is present in its context. An experienced engineer often knows what is missing.
That knowledge is difficult to measure because it rarely appears as output. It appears as the decision not to introduce another abstraction. When someone notices that the obvious fix would break an unrelated workflow. Or during an incident when the documented architecture no longer explains reality.
AI is very effective at producing plausible next steps. Engineering judgement is often the ability to know when the plausible next step is the wrong one.
The usual safeguard is code review. AI writes the code. A human checks it. The responsibility remains with the engineer. That works well when the engineer already understands the area being changed.
A senior engineer can ask AI to generate a routine implementation and immediately notice when it violates a local convention or ignores an operational constraint. The tool saves time without replacing the engineer’s view of the system. The harder case is also the more attractive one.
AI allows someone to work in a language they barely know or change a service they have never seen before. It finds the code, explains the pattern and produces an implementation that compiles. At that point, the engineer may be checking whether the result looks credible rather than whether the design is right. Those are not the same review. The code may be clean and tests may pass. Even the explanation may sound sensible. None of this proves that the change belongs in the system.
The most expensive mistakes are rarely obvious errors. They are reasonable decisions made without enough context. A human approving a pull request does not automatically solve this problem. Review works only when the reviewer has an independent position from which to disagree.
Otherwise, the human is not supervising the model. They are confirming that the model produced something recognisable.
AI coding tools make many tasks faster. I have seen that directly, and I would not want to return to working without them. But speed is surprisingly difficult to measure in software engineering. The author experiences the task up to the point where the code is written. The organisation experiences everything that comes afterwards.
Review, integration and maintenance are part of the same work, even when they happen later or are performed by someone else. A generated patch can be quick to create and bit back soon after. The original engineer saves time, while a reviewer has to reconstruct why the change exists. A feature ships sooner, while the codebase gains another way of solving a problem that already had an established approach.
This is one reason I found the 2025 METR study interesting.
Experienced open-source developers expected AI to make them 24 percent faster. After completing the work, they still believed it had made them roughly 20 percent faster. In the measured results, they had taken 19 percent longer.
The study was small, used tools available at that time and should not be interpreted as proof that AI makes software development slower. The interesting part was the gap between perception and measurement. AI makes work feel active very quickly. Something appears, and the engineer can react to it. That is a better experience. It may also make time spent correcting, redirecting and reviewing the output less visible.
The tool can genuinely help while our estimate of the benefit remains wrong.
This is why I am sceptical of adoption metrics presented as productivity metrics. The number of prompts, accepted suggestions or generated lines tells us that the tool is being used. It says little about the amount of engineering effort required to own the result.
The meaningful question is whether the whole team reaches a good outcome with less work. That is harder to measure. It is also the only boundary that matters.
The effect on experienced engineers is not my main concern. Experienced engineers already have something AI can amplify. They know the system, remember earlier failures and can reject an answer that is technically valid but inappropriate.
My concern is how someone becomes that engineer. Engineering judgement is built through work that rarely looks efficient. A junior engineer follows the wrong path through a repository or the abstraction which is rejected in review. A incident is a blessing of a lesson about how the system behaves differently from the diagram.
The lesson is the growth.
AI can improve this process. It can explain unfamiliar ideas without impatience and help someone attempt work beyond their current confidence. But finishing more difficult tasks does not necessarily mean the underlying judgement is developing at the same rate. An engineer can now produce code that suggests a level of understanding they do not yet have. The implementation is real, but the understanding may not be.
This gap will be easy to ignore because the work still gets completed.
Senior engineers may also spend less time teaching because AI handles the questions that once came to them. That appears efficient in the short term. The senior engineer produces more, and the junior engineer is less blocked. What disappears is the conversation around why the obvious solution is not always the right one.
Several years from now, we may discover that we increased the amount of code an organisation can produce without increasing the number of people capable of making difficult decisions about it.
The inefficiency we removed may have included the apprenticeship.
There is another interpretation of the engineer’s dependence on AI. Perhaps our systems have become unreasonable to understand without it.
A codebase spread across several repositories, with outdated documentation and unclear ownership, forces engineers to reconstruct context before every meaningful change. AI is extremely useful in that environment. It can trace relationships, summarise services and create a workable explanation from scattered information. But the success of the tool can obscure the failure of the organisation.
If every task begins by asking a model to explain the architecture, perhaps the architecture is not legible enough. If the same context has to be rebuilt in every session, perhaps we have not preserved it properly.
AI makes these problems easier to tolerate. That is useful, but it may also reduce the pressure to fix them. The documentation remains stale because the model can summarise the source. Domain boundaries remain unclear because the model can follow the calls. As a result knowledge remains scattered because it can be reconstructed on demand.
We end up paying repeatedly for context the organisation should already own. This is a problem of the architectural complexity.
When hearing that work stops, because we ran out of tokens, a leader should not turn a tooling issue into an impromptu examination of someone’s professional competence.
But the follow-up question matters. What part of the work became impossible? Was it the repetitive implementation? The unfamiliar syntax? The initial search through the repository? Or had the engineer lost the process through which they understood what to do next?
The answer would tell far more about the root of the issue. Leaders goal is not to create engineers who can prove they need no assistance. That would be a strange definition of competence. The goal is to create engineers whose judgement improves because the tool removes lower-value work.
They may rely on AI every day. Losing it may reduce their output significantly. But beneath the tool there should still be a person who understands the problem, can challenge the answer and knows how to continue when the model reaches the edge of its context.
“I cannot work anymore. I ran out of tokens” still makes me laugh. It also makes me uncomfortable. AI may become one of the most valuable tools our profession has ever adopted. The discomfort comes from how a tool can move from useful to necessary, and from necessary to unquestioned.
We will not notice that shift by counting how much code the model generates. We will notice it when the model is unavailable.
Work should become slower when a powerful tool disappears. It should not become impossible.