AI has changed how we write code, and it continues to do so. We are trying different approaches and looking for more effective ways to work. Agents let us write code faster, but as they become more autonomous, our understanding of the project decreases.

I want to explain how I use this loss of understanding as a feedback signal. It helps me decide when I can delegate more to AI and when I need to slow down and figure things out.

Two Ends of the Spectrum

Consider two opposite approaches to writing code with AI:

• AI pair programming — AI acts as a programming partner: the developer leads the conversation, decides what to do next, and reads and checks every change. The developer stays in control of the process and understands how the implementation works.
• Vibe coding — the developer describes the desired result, and AI implements it independently. The developer judges the code by whether it works, without trying to understand how it is implemented.

The choice between these two extremes is fairly simple. If I am writing disposable code or building a simple automation, vibe coding saves me a lot of time. In a long-lived project, I prefer more control, even if it takes longer.

In practice, however, there are many approaches between these two extremes. We can roughly map them onto a spectrum:

This is only a rough model. The relationship between autonomy, time savings, and understanding varies by project, model capabilities, and developer experience. It also leaves out factors such as the quality and cost of the result.

As we move from AI pair programming toward vibe coding, we spend less time, but we also lose some understanding of the project. We want to find the balance that makes us most effective in the long run. First, though, we need to figure out why understanding the project matters at all.

The Necessary Level of Understanding

I believe that engineers need to understand code — at least for now.

Humans still drive the project. They set its long-term vision, define business goals, make architectural decisions, and take responsibility for the result. This is especially clear in large projects, where AI still needs human direction. Even when AI can solve every technical problem without human involvement, the business will still need some understanding of the project because leaky abstractions are not going away.

Understanding a project does not mean knowing every line of its code. Even before AI, I worked with many technologies: languages, libraries, frameworks, and databases. When learning a new technology, I studied its documentation, looked at its API, and read technical blogs by developers. This gave me an abstract model of the technology. I had a general idea of how it worked even though I had not read all of its source code.

When working with AI-generated code, I try to maintain the same high-level picture and go into detail only in a few specific areas. If I understand the data flow, the project structure, and the reasoning behind key decisions, I understand the project on a technical level. In this sense, working with AI resembles the work of a software architect. You do not need to keep the implementation of every module in your head, but you do need to understand how the system fits together and be able to quickly go one level deeper when necessary.

The Edge of Understanding

There is no single optimal level of autonomy. I keep moving along this spectrum, trying to stay near the edge where I still understand enough to guide the work and assess the consequences of changes. I delegate as much work to AI as I can without crossing that edge.

The edge varies from one part of the project to another. Just as models can use different levels of reasoning depending on the task, I need to understand some parts of the code more deeply than others.

For example, AI can implement a module from start to finish while I review its boundaries, data flow, error handling, and tests without reading the boilerplate code line by line. But if I can no longer explain where and why the data changes, or assess the consequences of the next edit, I need to stop and look deeper.

When I start to lose understanding, I slow down and look into that part before moving forward. This is the understanding loop: I delegate work to AI until I notice my mental model starting to fall apart. Then I fill in the missing context and continue. This loop lets me save time without giving up control.

Coding at the Edge

To stay near this edge, I need to notice when my understanding is no longer enough. Here are some of the checks I use:

• I understand the flow of data through the system.
• I can predict where the next change needs to be made.
• I understand how a change will affect other parts of the project.
• I can navigate the project without getting lost.

When I notice a gap in my mental model, I focus on that part of the project and go deeper as needed. I examine its data flow, its connections to other parts of the project, and the reasoning behind key decisions. I do not need to rebuild my understanding of the whole project, only to fill that one gap.

I do not necessarily need to read code to do that. Often, a conversation with the agent is enough. I can ask why specific decisions were made, what alternatives were considered, and so on. Sometimes I only need to ask one question. Other times, we explore a technical topic in depth. The conversation may also reveal that I am not satisfied with the current solution. The agent may not be satisfied with it either: it needs a rubber duck too.

I know I have restored my understanding when I can explain how this part works in my own words and predict which parts of the project a change will affect. After that, I can speed up again and delegate more to AI.

Learning

With AI pair programming, I set the direction myself, so I tend to stay within my existing mental model. The agent can offer advice or point out mistakes, but it usually stays close to the path I have chosen. With vibe coding, I can get a result without building a mental model of the implementation at all.

When I work at the edge, the agent can lead me into unfamiliar territory, and the understanding loop helps me fit the new knowledge into the broader picture of the project. This works like progressive overload in training: you gradually increase the load as your capacity grows, pushing your limit a little further each time.

Over time, my mental model becomes more accurate, and I can confidently delegate more work to the agent while maintaining the same level of control. The edge gradually moves to the right, and the work takes less time.

Conclusion

Coding at the edge of understanding is a way to delegate as much work to AI as my mental model of the project allows. As long as that model lets me guide the work and assess the consequences of changes, I can move faster. Once it no longer does, I slow down to fill in the missing context.

The understanding loop saves time while preserving the control I need and helping me learn. As the edge of understanding shifts, I can confidently delegate more work to AI.