Learning Is in the Doing
Satya Nadella says you cannot offload your learning. Here is the part he did not get into.
Couple months ago, Satya Nadella wrote a post called “A frontier without an ecosystem is not stable” about the future of organisations in an AI-driven economy. Much of his argument is actually about learning. If you have followed me for some time now, you all know learning has been at the center of my work with Resilium Labs. It is what I write about, it is what I consult on, and hell, it is one of the main theses of my book. So you can imagine my surprise when the CEO of Microsoft published a piece on it. It even made me wonder if he had subscribed to my newsletter, or read my book. I checked. He has not. Unfortunately.
He said this.
You can offload a task, or even a job, but you can never offload your learning.
His point is that the future of the firm is the ability to compound that learning across people and AI. I think he is right.
Of course, the post blew up and got tens of millions of views, and most of the reaction I saw went one of two ways. Some people reduced it to a simple diagram, with human capital in one box, and token capital in the other, and missed that the whole point is the loop between them. Others went after Microsoft for the hypocrisy of it, one of the few big model owners warning everyone else not to hand their value to a few big model owners, while it burns through capex and fights its own budget battles. Both are fair enough actually. But I want to discuss the part almost nobody focused on, the learning itself. In a world where the focus is on efficiency, execution, and shipping faster, a CEO talking about learning is something I want to celebrate.
He is a CEO, so naturally, the examples he uses are focused on economics. He explained that the thing that matters most is not which model you pick but the loop you build on top of it, your own data, your own evaluations, your own knowledge base. If you build that, the learning stays inside your company. If you skip it, you are renting someone else’s model and handing them the value. I agree with all of it.
But there is another kind of learning he does not really get into, and it is the one I focus on. It is not in your data or your logs. It is what a team learns by running the system, keeping it up and making it better. I mean load testing, chaos engineering, gamedays, readiness reviews, and learning from incidents. I mean actually doing them, not the reports they produce.
I wrote the final chapter of my book about this, and a newsletter earlier this year called When the pair programmer is confidently wrong. AI does not just take the task, it can take the thinking, and the thinking is where the learning is. In the book I put it like this.
AI that drafts the postmortem outsources the sensemaking. AI that surfaces related incidents from organizational history while the team does their own analysis supports it.
It is the same tool either way. What changes is whether your people are still doing the thinking. This is not a new worry. Lisanne Bainbridge described it back in 1983 in her paper Ironies of Automation, the more you automate, the more the human skills fade, so when the automation finally fails, the person who has to step in has not practised in years. AI makes it worse, because it does not just take the routine work, it takes the judgment and the diagnosis, which is exactly the work that teaches you how a system fails. That kind of judgment only forms where you get repeated feedback, the exact thing an agent removes when it does the diagnosis for you.
It shows up clearest in the practices. You run a load test and you find out where the system breaks, but only if you sit with the result and it changes how you think about the system. A gameday teaches the people who were in the room and felt the pressure. It does not teach the runbook. An incident review is useful because a group of people argue through what happened and come out understanding the system better than they did before. The write-up is just what is left after the real work is done.
Most of these you do on purpose, before anything is on fire. You do not have to wait for a real incident to teach you. A load test, a chaos experiment, a gameday is deliberate practice, controlled exposure you run on your own schedule, with people rested and paying attention instead of woken at 3am. It lets you build the expertise before you need it, and it compresses years of production lessons into reps you actually chose to take.
So I get nervous when I hear that an agent will write your postmortem, run your gameday, and do your readiness review. It probably can, and the documents will probably look fine. But by doing so, you have now given away the part where people actually learned something. This is the same pattern I described in AI does not solve your problems, it just moves them somewhere you cannot see. This time, the thing it moves is the learning. You end up with a pile of good-looking reports and a team that has slowly stopped understanding its own systems, and it is easy to miss until something breaks that the team struggles to figure out.
And this is not only about keeping things from breaking. A team that really understands its system, and knows where the gaps are, can change it fast and safely. Over time they build an intuition for how the system behaves, a tacit knowledge that lives nowhere in the docs, and that is what lets them catch problems before customers feel them and recover fast when something novel breaks. A system no one on the team understands is slow and expensive to improve, and every change is a gamble. That is the economic angle here. The running system is not just something you keep alive, it is what you build the customer experience on. An agent can move fast here too, but speed on top of a system no human understands only holds until it breaks in a way no one can explain.
This gets more problematic when the code was written by AI in the first place. If your team did not write it, they never built the understanding that writing it would have given them. So the only place that understanding can still come from is running the thing, testing it, breaking it on purpose, and learning from what goes wrong. That is the whole argument of when AI writes your code, chaos engineering writes your insurance policy. It is one of the few places left where a human actually meets the system. If you offload that part too, you end up shipping and operating something no one on the team really understands.
Satya says his loop captures even this. It accumulates, in his words, “tacit knowledge unique to the firm,” and he is right, it does. But that tacit knowledge comes from the building side, the workflows and the traces of how the work gets done. Running and operating the system is the other half, and the tacit knowledge there is a different animal. The intuition a team builds from sitting through enough outages to feel the next one coming, from knowing which alert to trust and which to ignore, is the kind Michael Polanyi meant when he said we can know more than we can tell. You cannot fully write it down, so you cannot fully encode it into a training trace either. It forms in the people running the thing, and it stays there. Satya said it himself, “Without human direction, you have compute running in circles.” The practices are where that direction gets built, and you cannot copy it or buy it or get it by letting an agent do the work for you.
I am not saying you should keep AI out of all this. Use it for the boring parts and let it pull the numbers, find patterns across a thousand old incidents faster than any human could, maybe even draft the first version so people have something to react to. It can actually get very good at the failures you have already had. That is staying in the loop, compounding across people and AI, and it is worth doing. But the failures that take your business down are usually the ones nobody has seen yet, and there is no trace of them to train on, because they have not happened yet. Understanding them and recovering from them takes people who have kept their hand in, and these people only exist if you are still doing the practice. AI can take the failures you have already survived, but the new ones will still be yours to unpack.
So I would finish Satya Nadella’s sentence like this. You can offload a task. You can offload a job. You cannot offload your learning. And that learning is not just a data loop, it is a handful of practices your people have to keep doing themselves. Hand those to an agent and you get something that looks like it is learning, sitting on top of a team that has stopped.
//Adrian
PS: If you are connected to Satya, feel free to send him the link to my newsletter. He might even subscribe this time. :D