Do We Still Understand the Systems We Build?
Agents let us deliver software faster. But that speed can leave us with less understanding and weaker judgement.
I’ve been thinking about what happens to our understanding of a system when agents allow us to build it much faster. Part of the answer lies in how we used to learn a system while building it.
The learning loop we lost
Writing code without agents took much longer. But that slower process also helped us learn. While implementing a feature, we had to follow the main flows, work across different parts of the codebase, and deal with edge cases. By the time we finished, we usually had a better understanding of how the system worked.
It was not typing the code that gave us this knowledge. It was the time we spent inside the system.
Agents have changed this relationship. They can generate and modify code much faster than we can absorb the changes. The speed of production has increased, but the speed at which our brains learn how a system works has not.
We may understand each change when we review it. But then we move on to the next task, the next plan, and the next implementation. Each change makes sense on its own, while our understanding of how all the pieces fit together slowly weakens or becomes outdated.
What planning and review cannot replace
An obvious counterargument is that we were already building software through small pull requests before agents. We were already reviewing changes made by other people and moving from one task to the next.
That’s true, but I think there’s still an important difference.
When colleagues left comments on our pull requests, we had to understand the feedback, think through the problem, discuss it, and change the code. Sometimes we disagreed. Sometimes the discussion showed that everyone had missed something. The process was slower, but it gave us time to sit with the problem and learn from it.
Now we can pass the same comment directly to an agent. The agent updates the code, we check that the issue is resolved, and everyone moves on. The feedback loop still exists, but we may no longer work through it ourselves. The problem gets fixed, but the learning opportunity is gone.
It doesn’t have to be this way. We can still stop and think through the feedback ourselves. But the easiest path is to let the agent deal with it, especially when many other tasks are waiting.
Another counterargument is that we now spend more time writing requirements, specifications, and architecture plans. If we design a change and review its implementation plan, shouldn’t we already understand the system?
That’s partly true, but planning, implementation, and real-world use give us different kinds of knowledge.
A specification tells us what we want to build. Implementation shows us how that idea fits into the existing codebase. Real-world use shows us whether it actually works.
During implementation, we often discover hidden dependencies, old assumptions, unexpected states, and edge cases that we missed during planning. It’s almost impossible to predict everything in advance.
An agent can find these problems too, but we may see only the final solution or a short summary. The information is available, but we may not spend enough time with it to fully understand or retain it.
Faster delivery, weaker judgement
Maybe we’re not only losing knowledge of a particular system but also getting less practice using our own technical judgement.
Judgement develops through making decisions, seeing their results, and fixing our mistakes. When we face a challenging problem and ask an agent for an answer before thinking it through ourselves, we skip part of that practice.
The agent may give us a good answer, and we may understand it when we read it. But understanding someone else’s reasoning isn’t always the same as doing the reasoning ourselves.
I’ve noticed this in myself. When I face a hard problem, my first reaction is usually to ask an agent. Thinking it through on my own feels slower and more uncomfortable. My brain naturally looks for a shortcut.
At the same time, agents don’t always reduce the number of decisions we need to make. Because they increase the speed of production, they can create many more decisions for us to review. We may write less code ourselves while having to approve more plans, changes, and technical choices throughout the day.
This creates a dangerous cycle. Faster production creates more decisions. More decisions create mental fatigue. Fatigue makes us delegate more thinking to agents. Less practice weakens our judgement, making us depend on agents even more.
I often feel more mentally drained at the end of a working day than I did when development moved more slowly. Constantly switching between tasks and reviewing so many decisions doesn’t feel sustainable. If we don’t intentionally slow down, it’s easy to keep generating, keep approving, and gradually lose the ability to judge the work properly.
Knowing when to slow down
The obvious way to break this cycle is to think first and ask the agent second. We need to form our own view, make some decisions ourselves, and then use the agent to challenge or improve our thinking.
But this is harder than it sounds.
Once agents make faster delivery possible, that pace can quickly become expected. Product teams and management then start planning around it, even though our ability to think, review, and make careful decisions hasn’t increased at the same rate.
An engineer who stops to think deeply can start to feel like the bottleneck. The pressure no longer comes only from our own desire to take the easier path. It also comes from an environment that rewards visible output more than careful thinking.
This creates a hidden risk for companies. The same process that increases a company’s output may weaken its ability to understand and control what it produces. In the short term, this looks like higher productivity. The cost may become visible only later, when the system behaves unexpectedly and too few people understand it well enough to question what was built or take control.
Maintaining control doesn’t mean thinking deeply about every change an agent makes. There are too many, and doing so would remove much of the value agents provide. The challenge is to know where speed is safe and where we still need to slow down and think for ourselves.
Some decisions are local, easy to reverse, and safe to delegate. Others affect the whole system and may be expensive to undo. Those decisions still require independent human judgement.
This is where system design becomes especially important. Decisions about how the parts fit together affect how much the system costs, how secure and reliable it is, how well it performs, and how difficult it will be to change.
The effects of these decisions are often difficult to see immediately. A design can seem reasonable today and still create serious problems months later. The code works, the tests pass, and the feature is released. That doesn’t mean the decision was good for the system as a whole.
Agents can help us explore options and identify tradeoffs. But we still need enough understanding to judge their suggestions. If we delegate both the reasoning and the final decision, we risk becoming a proxy between the agent and the codebase. We may approve changes without knowing whether they make sense at all.
The feedback we cannot speed up
Even when we give ourselves enough time to think before making an important decision, some answers only come from seeing the system in use.
We need to see how people use it, how it behaves under load, how much it costs, how it fails, and how difficult it is to change later. This is how we learn whether we made a good decision.
Agents can write tests, simulate users, and explore possible failures. All of this can speed up some feedback loops, but it can’t show us everything. Real users, production incidents, changing requirements, maintenance, and time still teach us things that are difficult to predict.
Agents can make implementation faster, but we still have to wait for real-world feedback.
If a system changes too quickly, we face two problems. First, we don’t have enough time to understand its current state. Second, by the time we learn whether an earlier decision was good, the system may already have changed several times. We may receive feedback about a version of the system that no longer exists.
We can now build systems faster than we can think about them, and change them faster than we can learn from them.
So, do we still understand the systems we build?
We can, but it no longer happens automatically. In the past, our understanding and judgement often developed as we implemented changes, responded to feedback, and saw the results of our decisions. Now we have to make sure those learning loops still happen.
The answer isn’t to stop using agents or to make every decision ourselves. We need to know what we can safely delegate. For important decisions, we need to stay involved long enough to learn from the results.
When code becomes easy to generate, producing more of it may no longer be the most valuable skill. What matters more is knowing when to slow down, when to think first, and when the agent’s answer isn’t enough.
That may be the real moat.