Coding agents make it incredibly easy to skip the learning. Tell an agent that you need to deploy your app to the cloud. Give it access to your code and Azure subscription. A few minutes later, you might have an application running in production. Great. Now, why did it choose those particular services?
Why that hosting option instead of another one? Why that pricing tier? Why is one service publicly accessible while another isn’t? Which choices followed from your requirements, and which were reasonable defaults? What happens when your traffic increases by a factor of 100? You might not know, and worse, you might not know enough to ask.
Execution used to produce understanding
Before coding agents, getting an application into production required us to work through much of this ourselves. We’d read documentation, try something, and discover that it didn’t work. An error would teach us what a configuration controlled. Someone more experienced would point out that the service we’d chosen wasn’t quite appropriate for what we were building. Eventually, we’d get the app running.
Much of that process was inefficient. An agent can now skip large parts of it, and that’s a good thing: I don’t particularly care whether I remember the command to create a cloud resource. But the inefficiency had a useful side effect: somewhere between the first command and the working application, we developed a mental model of the system. We learned which options existed, what constrained them, and what followed from our choices.
Coding agents can take us straight from intent to outcome. But in doing so, they risk taking us around the learning that used to happen in between. We removed the mechanical work and accidentally removed the conditions in which understanding developed.
Learn alongside the work
What if you could put your coding agent into learning mode? The agent would still do the work. You wouldn’t have to type every command or reproduce what it can already do. But alongside the main session, the agent would start a separate learning conversation when the work reveals something worth understanding:
I chose a consumption-based hosting option because this application has variable traffic and doesn’t require persistent local state. That reduces operational overhead, but it also affects its scaling and latency characteristics.
What assumption about this application’s workload might make that a poor choice?
Now you’re involved. You might know the answer or give a partial one, so the agent pushes you a little further. If you have no idea, it can back up and explain the concepts you need first. Its explanation might make you curious about latency, alternatives, or cost at scale. Suddenly, you’re learning about a decision that was just made in an application you’re actually building. The work becomes the source material for learning.
Learning mode shouldn’t produce a textbook about everything the agent does. It should give you enough context to engage with an idea, then ask you something. Your answer gives it information about your understanding. If you’re new to a technology, asking you to choose between two services you’ve never heard of makes little sense. So the agent should explain what they are, relate them to concepts you understand, and check whether you’ve grasped the distinction. Once you’ve demonstrated familiarity, it can demand more by presenting the constraints and asking which option you’d choose before revealing what it did.
This Socratic interaction does more than shorten the explanation. It turns you from a passive observer into an active participant. When you’ve demonstrated that you understand something, the agent can move on instead of explaining it again.
Keep learning outside the working context
The learning conversation should be separate from the agent’s main working context. Suppose the agent provisions infrastructure and you become curious about autoscaling. You might spend the next twenty minutes exploring how different scaling strategies work and what they cost. That’s useful to you but probably useless to the task. A pedagogical detour shouldn’t consume the context the agent needs to finish its work.
Think of the learning conversation as a scratchpad alongside the task. It can see what the working agent sees and what happened during the session, but your exploration doesn’t become part of the main conversation. When you’re done, you close it and continue working.
This separation also matters because the finished artifact doesn’t contain the story of how it came to exist. Imagine watching someone make a sword. They heat the metal, hammer it, inspect it, and change their approach based on what they observe. You can ask what they were looking for or what would happen if they skipped a step. Return several days later to inspect the finished sword, and reconstructing every consequential decision becomes considerably harder.
Agentic work is no different. The useful learning material includes the constraints the agent discovered and assumptions it revised. Failed approaches matter too. What agents learn while doing the work can improve shared organizational knowledge, while learning mode uses that same moment to improve your understanding. Both depend on capturing the reasoning while it is still available.
Teaching becomes another form of review
Of course, the agent might teach you something that’s wrong. So can someone senior to you. Watching either of them discover a mistake can be one of the most educational parts of working together.
Perhaps the agent initially chooses service A and explains why. Later, it discovers a constraint that invalidates an assumption and switches to service B. What changed? Why does the new information matter? Why is B now preferable? The correction teaches you how the decision depends on its context rather than presenting the final choice as universally right.
Better still, perhaps you expose the problem. You ask why it didn’t choose B, its explanation isn’t convincing, and you keep pulling on the thread until the agent realizes that B is the better choice after all. The learning then goes both ways. The agent teaches you about the work, while your questions force it to explain and pressure-test its decisions. Teaching becomes another form of review.
Start from what I already know
Learning mode becomes more interesting if it remembers. The task determines what’s relevant now, while the agent’s memory determines what’s relevant to you. If you’ve demonstrated that you understand managed identities, it shouldn’t teach them again. If you’ve repeatedly struggled with networking concepts, it should recognize that. When you understand containers but haven’t used a particular hosting service, it can start from the concepts you already know.
Two developers could ask an agent to perform exactly the same task and receive different learning experiences. Over time, the agent would build a model of your technical literacy based on what you’ve demonstrated rather than only what you’ve claimed: today’s task supplies the material while yesterday’s learning determines where you start.
The goal isn’t to make you capable of reproducing everything the agent did without it. You don’t need to remember every command or configuration property. Instead, aim for something closer to architect-level familiarity. Understand the concepts and available options, including their important tradeoffs. Learn to recognize when the assumptions behind a decision don’t match your situation. The mechanics can stay delegated.
Know enough to be skeptical
So why bother learning any of this if the agent can design the architecture and troubleshoot whatever breaks? Because without understanding, how do you know whether its choices are good for you? It’s running doesn’t tell you whether the architecture is unnecessarily expensive or built around a default that conflicts with a requirement you forgot to mention.
If you don’t understand enough about the system, you can’t bring a critical dose of skepticism to the agent’s work. The next time you encounter a similar problem, you still can’t express a technical preference because you never learned enough to have one. You describe the outcome and once again delegate the judgment along with the execution. Externalizing judgment requires enough understanding to explain what good looks like in the first place.
Repeat that pattern and our ability to produce software increases while our ability to understand it decreases. We end up with sophisticated-looking applications that tip over the moment you touch them, built by people whose only debugging strategy is asking the agent to fix whatever the agent built.
Coding agents are removing enormous amounts of mechanical work from software development. We shouldn’t put that work back just so people can learn. Instead, we need to reconsider how learning happens when execution is delegated. A learning mode could keep us intellectually involved in our work, adapt to what we understand, and let our questions challenge the agent in return.
And it’s not just coding that’s affected. The same problem appears when an agent creates a go-to-market plan or designs a marketing campaign. The more judgment we delegate, the easier it becomes to receive sophisticated outcomes without developing the understanding required to evaluate them.
We’ve spent a lot of effort making agents better at doing the work for us. Now let’s make sure we’re still learning while they do.