The Mind Outside Software

A Pull Request I Didn't Remember

What I study usually begins by accident, from a book or article I read, or from a conversation with the people I work with. I study, let the idea mature in a small personal project and, if it convinces me, I promote it into more important projects.

Last week I reopened a pull request from a personal project that I had merged ten days earlier. Many lines of code, generated by an AI agent following a very specific prompt of mine. A change request had arrived from the product team (my brother, with whom I share the project), so I picked the matter up again.

Looking at the diff, I realized something I never thought I would feel. I knew the intention behind the code perfectly. I knew what it was supposed to do. I even remembered the problem we had faced. And yet, while scrolling through those lines, there was a dark area: some functions had the structure of something foreign. They were written extremely well, perhaps better than I would have written them myself. The problem was that they did not live inside my head in the same way as classes I had built by hand in other projects.

At that moment I felt a very clear sense of debt. A subtle, invisible debt. I almost felt embarrassed while discussing it with the business team, again, my brother. Something stranger than the code itself was missing. The mental theory of that code was missing.

And that is exactly where I would like to begin today.

When Writing Meant Sedimentation

For decades programming was an extremely slow activity. Let's leave aside patterns like TDD for simplicity and focus on the pure concept of programming. You sat in front of a problem, moved through it word by word, returned to it over and over, wrote classes and methods that would be rewritten three days later. The same happened with specs, meaning specifications and automated tests. Productivity was low, but meanwhile, while the hand was moving, something silent was happening inside the mind. Maps were forming.

Maps of what? Systems, data flows, tradeoffs that only appeared after seeing a bug emerge where nobody expected it. Maps of almost muscular intuitions about where a certain type of problem would reappear later on. Writing code had a second silent layer, made of cognitive sedimentation. It was a slow, exhausting process, and precisely because of that, a deep one. You write code, but you paint it like a painter does. You observe it and sculpt it in your head like a sculptor.

Today, when an engineer can produce in one hour the same amount of code that only a few years ago required days, we should ask ourselves something that productivity metrics cannot describe. Where does all the understanding go that used to emerge during that very time?

Reading code and understanding it are two different professions

There is a distinction here that deserves academic clarity.

Reading code creates familiarity. You scroll through it, recognize patterns, roughly understand where things are going. Understanding code is another story. Understanding means executing it inside your own mind. A senior engineer, when facing a system they truly know, never really reads line by line. Their brain is doing something closer to internal emulation. It predicts where a bug will emerge. It senses which components will conflict. It anticipates which changes will produce side effects in apparently distant areas.

This capacity for internal simulation is the true level of understanding. And it is an expensive ability, because it requires compressing thousands of details into a navigable mental model.

In previous articles I spoke at length about how transformers drag around enormous caches without ever building true internal memory. Having access to a gigantic context window is not the same as having strong recall capabilities. The same applies to us. Being exposed to enormous quantities of code is very different from internalizing it. An entire system can pass before a developer's eyes without ever entering their cognitive structure.

And this is where a character I already mentioned in the previous article returns from a new angle.

Funes, except this time it's us

In the previous piece about KV Cache and forgetting, I used Borges' Funes the Memorious to describe a transformer problem. Funes remembers every leaf, every instant, every variation of the world, and precisely because of that he cannot truly think, because thinking means abstracting, and abstraction requires selectively losing information.

In that reasoning, Funes was a metaphor for the model.

But there is another angle that feels even more interesting to me, and the story supports it perfectly if read through the eyes of a 2026 engineer. Today, that text seems to speak about us as well. About us who use AI agents every day, about us who move through dozens of pull requests before lunch, about us who navigate repositories where more code passes before our eyes than the human mind is equipped to digest.

The risk engineers are facing today resembles Funes' destiny in a disturbing way. We see everything. We scroll through endless diffs. We approve change after change. Every day produces a volume of code exposure unprecedented in the history of the profession. And yet this exposure translates less and less into understanding, and more and more into a superficial saturation that imitates familiarity.

The cognitive saturation of our time has changed its nature. In the past it was born from information scarcity. Today it is born from excess, from an exposure we move through too quickly to transform into abstraction.

Before being a metaphor for models, Funes is a metaphor for a mind that sees too much and understands too little.

What we are really delegating

To frame the problem correctly, we need to make a subtle distinction, because human history is full of cognitive delegations and none of them destroyed civilization.

We delegated memory to writing. We delegated calculation to calculators. We delegated orientation to digital maps. Every cognitive technology moves part of thought outside the mind, and typically it does so while leaving some things intact. A calculator removes calculation from our hands, but the mathematical process remains understandable. A map removes the effort of remembering directions, but our geographical sense is not erased.

AI agents introduce something different, and the difference deserves careful handling. An agent capable of generating a thousand lines of code moves outside the human mind something that until yesterday was not delegable: intermediate chains of reasoning.

Inside those thousand lines live dozens of implicit decisions. Temporal priorities, assumptions about race conditions, tradeoffs around eventual consistency, invalidation strategies, decisions about the order in which state is written and read. These are micro-architectural decisions that historically emerged in front of the screen, while the engineer's mind lived through them one by one, crashed against each of them, and through that repeated friction built intuition.

When an agent crosses that entire sequence, the resulting system works. The logical path that generated it, however, passes through the human mind in a much more diluted way, almost like an image seen from the window of a fast train.

The continuity that breaks

For years, software engineering contained an implicit continuity between three moments:

intention,
implementation,
understanding.

You imagined a solution, slowly built it, and during construction the mental model refined itself. Thought produced code, and code reinforced thought.

Today that triangle tends to collapse. More and more often, what remains in our hands is only the initial intention and the final verification. The central part, the long part, the exhausting part, is traversed by the agent. And that is precisely the area where deep understanding historically emerged.

Try to imagine the concrete difference. Until a few years ago, saying "let's implement optimistic updates with distributed caching and a retry strategy" meant opening a week of battles. You wrote a draft, collided with a strange race condition, rewrote the invalidation logic, discovered that exponential retry coexisted poorly with a certain cache, and eventually reached a decent version. Every day of that battle deposited another layer of intuition into the mind that would remain for life.

Today that same request, formulated as a prompt, can produce a working solution in a few hours or even minutes. The code exists. The code runs. The unified mental theory explaining why it works exactly that way is far less guaranteed.

Maybe understanding does not disappear, but migrates

It would be too simple, however, to read all this as pure loss. Every major technological abstraction has also transformed the type of intuition humans needed. Programming in assembly built a different kind of understanding compared to high-level languages, and orchestrating AI agents is probably already beginning to build another one.

Intuition may not disappear at all. It may simply move toward higher levels of abstraction. Less tied to the individual function and more tied to the ability to contain systems, verify assumptions, recognize emerging fragilities, and guide agents through architectural spaces enormously larger than what a single human being could have explored alone.

The problem, perhaps, is not whether we are losing intuition. It is understanding which intuitions risk atrophying before the new ones have had enough time to form.

The risk is not producing software nobody wrote. It is producing software nobody truly thought through.

Fatigue as cognitive technology

I would like to spend a few minutes on a concept that seems central to me and that is too often treated as a detail: fatigue.

Cognitive fatigue has always been a functional, almost epistemological, part of software engineering. Writing parsers, debuggers, concurrent systems or complex algorithms meant moving slowly through complexity, and that slowness mattered. The brain needed it to build deep models, because the human mind constructs deep models through friction. Failed attempts. Errors that burn. Refactors that reveal the most subtle bug. Debugging sessions that consume an entire afternoon for five lines of code.

AI agents compress all this friction enormously. From the perspective of production, it is a tremendous gift. From the perspective of learning, it may also become a trap. Compressing experience often means compressing the opportunity to learn from that experience.

I like to use a parallel with music. A pianist learning a difficult piece is not merely training their fingers to reach the final performance. They are building deep neural structures through the slow repetition of movements, and those structures become the underground layer of interpretation. If someone magically gifted them the final performance without the years of study, they would have a concert. They still would not have a pianist.

Something similar applies to software. Years of debugging build almost physical intuitions about systems inside an engineer. A sense of latency, a perception of concurrency, a sensitivity to architectural fragility. These are not things you find in books because they are not concepts. They are mental calluses built by moving through countless real cases.

The real concern has a subtle shape. Engineers remain just as intelligent as before. What risks being interrupted is the silent process through which systemic intuition historically formed. If the agent goes to the gym in our place, the muscles stay where they are.

The illusion of control

There is a small psychological trap worth naming. When a system works, we immediately generate a feeling of control. We see the tests pass, the endpoint respond, the UI render correctly, and we perceive mastery. Real mastery, however, is measured elsewhere. It is measured when the system breaks.

When a bug appears in production at three in the morning, when an edge case nobody considered brings down a pipeline, when strange behavior emerges under unexpected load conditions, that is where the debt of understanding presents its invoice. That is where we discover whether we truly hold a theory of the system in our heads, or whether we merely possess a working system and a vague intuition of how it should behave.

This is why the value of an engineer reveals itself above all in moments of rupture. That is where we measure whether the mind truly contains the system, or merely skimmed across its surface.

Containing what grows faster than the mind

At this point I would like to lift my gaze, because I believe all this reflects a profound transformation in the profession of engineering itself.

For decades, a significant part of the value of someone writing software coincided with their ability to produce that software. In the world of AI agents, production is quietly becoming abundant, almost free. Scarcity moves elsewhere. It becomes the ability to build coherent mental representations of enormously complex systems that grow faster than the human mind evolved to follow.

This ability has a name I like to repeat to my imaginary "students" in this lesson: containment. To contain a system means knowing which abstractions truly matter, which details can be ignored without paying for them later, where the real complexity lives and where there is only apparent complexity, which parts of the code are accumulating invisible tension that will explode six months from now. It is an almost architectural capability of the mind, and it is precisely the type of ability AI agents, at least for now, do not replace at all.

Here I arrive at what feels like the most important reflection, and the one connecting this article to everything I have written in recent months about transformers, latent memory and forgetting.

Intelligence, both biological and artificial, has less and less to do with the quantity of information processed. It is instead about the quality of the mental compression built on top of that information. A great engineer, exactly like a well-designed transformer, is measured by the ability to transform enormous systems into governable cognitive structures. It is measured by the ability to forget the right things and remember the central ones.

The future of software engineering may belong to those who can still build a mental theory of the system while the system itself grows faster than the mind.

Forgetting enough, understanding enough

I would like to close by returning to the theme running through this entire series of articles: forgetting.

For years we believed that progress in artificial intelligence meant adding memory, context and generative capability. That story is true, but incomplete. The missing part concerns us.

The urgent question of the coming years will resemble less and less how much productivity we can extract from an agent, and more and more which cognitive processes we cannot afford to delegate completely. Human understanding emerges from a very delicate balance. Remembering enough to build continuity over time. Forgetting enough to abstract. AI agents are shifting both sides of that balance.

Returning to writing every line of code by hand would be romantic nostalgia and probably useless. But there is another version of the problem, one that follows me every morning when I open the editor with an agent beside me. It is the discipline of slowing down at the right moments. Of rereading a diff deeply instead of merely scanning it. Of asking the agent to explain its implicit assumptions instead of accepting them silently. Of occasionally writing the most important parts myself, even when the agent could do them better, because I need to let complexity pass through me again instead of merely observing it from the outside.

Not out of nostalgia for a lost craftsmanship, but because some forms of understanding are still born through the direct traversal of complexity, while others may be emerging precisely in the ability to orchestrate it.

The real challenge of the coming years will unfold on a different plane from software production speed. It will unfold in the possibility for engineers to continue mentally inhabiting systems that grow faster than their natural ability to understand them.

And perhaps the defining trait of a good engineer, in this strange decade, is exactly this: being able to watch an agent generate thousands of lines in ten minutes and deciding, with a certain clarity, during which of those ten minutes it is worth slowing down.