AI Can Make Us Faster, but Leadership Still Has to Make Us Better

I recently happened to watch WIRED’s “Computer Scientist Explains Machine Learning in 5 Levels of Difficulty,” featuring Hilary Mason (YouTube). What stayed with me afterward was not really the technical explanation itself. I found myself reflecting on two things that have been on my mind quite a bit lately: leadership and AI.

The first thing that stood out was how Hilary communicated. She was explaining the same subject to people with very different levels of understanding, and she adjusted her words, examples, and level of detail depending on who was sitting in front of her. With younger people, she used simpler concepts. As the level of knowledge increased, so did the complexity of the conversation. She was meeting people where they were instead of expecting everyone else to meet her where she was.

That immediately made me think about leadership. In a previous post, I wrote that words matter, but intent matters just as much. I think Hilary demonstrated that well. Her intent did not seem to be proving that she was the smartest person in the room. Her intent was to help the other person understand. I wish we saw more of this in corporate environments. Sometimes people seem to believe that using more buzzwords, acronyms, or complicated explanations somehow demonstrates expertise. I do not find that very useful. If someone is incredibly knowledgeable but nobody can understand what they are trying to communicate, how much value are they really creating?

As we move into leadership, I think our value increasingly comes from taking something complicated and making it understandable enough for people to make decisions and move forward. Expertise matters, but so does the ability to translate that expertise for the person sitting across the table.

The video also made me think about AI. When Hilary was explaining machine learning to younger participants, she used the word “guess.” I liked that word because it removes some of the magic around AI. Those guesses can be incredibly sophisticated and based on amounts of information no individual human could ever consume, but they still depend heavily on patterns, data, and context.

And where does much of that context come from? From us.

Think about Instagram. How does it know what we may want to see next? We provide signals through what we stop on, skip, like, share, search, and follow. The application may be free to use, but our behavior becomes part of the exchange. Google represents another version of the same broader idea. For years, billions of people have searched, clicked, watched, navigated, and interacted with digital systems, creating an enormous amount of information about what humans look for and find useful.

But the world providing that context is not perfect. We are biased. We make bad assumptions. We repeat misinformation. We contradict ourselves. We follow trends. We sometimes reward what is entertaining more than what is accurate. AI systems can compare information, identify inconsistencies, and sometimes challenge flawed assumptions, but they are still working from the information, objectives, and context available to them. More context does not automatically mean better context.

That is why I keep coming back to a phrase I have been thinking about: confidence through observation versus competence through experience.

Humans can gain confidence through observation too. We can read books, watch videos, attend conferences, listen to experts, and learn enough terminology to sound knowledgeable. But confidence and competence are not always the same thing. Experience teaches us what breaks. It teaches us which assumptions become dangerous, where the edge cases are, and eventually what questions we should be asking in the first place.

I recently saw a good example of this during a Spring Boot upgrade. Today, a developer can ask an AI coding assistant to upgrade an application. The tool can update dependencies, modify configuration, resolve compilation errors, and get the application running much faster than someone doing everything manually. The build passes. The tests are green. Everything can appear successful.

But what happens if a framework change affects how configuration is read and production ends up pointing to development data? The application may still start. Nothing necessarily crashes. Everything can look healthy while the system is doing something it absolutely should not be doing.

That is where experience matters. An experienced engineer may still use AI to perform much of the upgrade, but experience causes them to ask different questions. What changed in configuration behavior? How are profiles being resolved? What happens when a production property is missing? Could the application start successfully while connecting to the wrong database or endpoint?

AI can help answer those questions, but someone still has to know that those questions need to be asked.

That, to me, is one of the biggest leadership questions around AI. AI can make it much easier to get something done without making it equally easy to understand what just happened. Someone may suddenly be able to produce a solution they could not have created a few years ago, but increased capability does not automatically mean increased competence.

I also hear more people talking about how much AI they are using, how many tokens they consumed, or how much code they generated. There is even a term now, “tokenmaxxing,” around maximizing token usage. I cannot help but think about how software development once treated lines of code as a proxy for productivity. More code looked like more work until we eventually learned that better engineering often meant accomplishing more with less. We created abstractions, frameworks, reusable libraries, and eventually low-code and no-code solutions because solving the problem mattered more than how much code it took.

Why should tokens be any different?

Someone consuming ten times more tokens does not necessarily create ten times more value. If leaders begin rewarding AI activity instead of outcomes, we risk repeating an old mistake with a new measurement.

The more important question, in my view, is what AI does to how people develop over time. I have heard this directly from people I mentor and from younger engineers. The pattern is simple: “I can type what I want, the tool gives me a solution, and it works. But I do not fully know what is happening underneath.”

That is worth paying attention to.

For someone early in their career, the first few years are supposed to be where the fundamentals become real. Debugging, tracing through code, understanding how configuration is loaded, figuring out why a dependency behaves a certain way, and learning how systems fail are not simply obstacles standing in the way of productivity. They are part of how judgment gets built.

And part of gaining that experience is making mistakes.

That sounds obvious, but I think many organizations struggle with it in practice. We say we want people to take ownership, grow, experiment, and learn, but when something goes wrong the conversation can quickly become: Whose fault was this? Or whose responsibility was it?

Those can be legitimate questions, but I do not think they should be the first or only questions.

Accountability asks something broader: What happened? What did we miss? What did we learn? What needs to change? And yes, who owns making sure that change happens? Responsibility matters. Someone may own the decision, the system, or the follow-up. But when identifying the person becomes more important than understanding the failure, the organization risks learning very little.

Over time, a blame-oriented culture creates different behavior. People become more focused on protecting themselves than learning. They document defensively. They avoid reasonable risks. They escalate decisions they could otherwise make themselves. An organization may eventually see fewer visible mistakes, but that does not necessarily mean it has become better. It may simply mean people have become better at avoiding ownership.

If experience is supposed to build competence, people need enough psychological safety to make reasonable mistakes and learn from them. That does not mean ignoring negligence, avoiding accountability, or accepting the same mistake repeatedly. It means recognizing that some mistakes are part of becoming better at the work.

This is where AI makes the leadership challenge even more interesting. If people are afraid to make mistakes, there is a temptation to lean even more heavily on the machine because it gives them something that feels safer: an answer. But if they never wrestle with the problem, make a bad assumption, discover why it was wrong, and adjust their thinking, then one of the most valuable parts of experience may disappear along with the friction.

And this is not only a young-engineer problem.

Someone can have ten years of experience without having ten years of growth. Repeating the same patterns for a decade is not the same as becoming more capable. Experience only becomes valuable when it is paired with reflection, curiosity, learning, and the willingness to challenge what we think we already know. A person with fifteen years behind them can become just as dependent on AI as someone with one year if they stop thinking critically about the output.

That is why I do not think the real question is junior versus senior. The real question is whether AI is helping someone develop better judgment or helping them avoid developing it.

Two people can close the exact same ticket today and become very different engineers five years from now. One may use AI to accelerate understanding. The other may use AI to reach the answer without ever really building the underlying mental model. The same can be true of someone with one year of experience or someone with fifteen.

That is where leadership has a bigger responsibility than simply encouraging people to use AI. If companies are going to push AI heavily through adoption goals, AI-first initiatives, token measurements, or productivity expectations, leaders also need to think about what kind of workforce those decisions are creating over time.

The more AI removes friction from the work, the more intentional leaders need to become about how people build judgment.

What experiences still need to be preserved? What learning needs to be recreated in a different way? When should AI give someone the answer, and when should it help them understand the problem? How do we make sure people still know enough about the systems they are working on to recognize when an answer looks correct on the surface but is fundamentally unsafe underneath?

Those are the questions I think leaders should be solving.

I am not anti-AI. I use it regularly, and I think it can be an incredible accelerator. For someone with experience, AI can remove repetitive work, help explore alternatives, expose them to unfamiliar areas, and create more time to think about the actual problem. For someone earlier in their career, it can also be a powerful learning tool when it helps explain why something works instead of simply doing the work for them.

But leaders should be careful not to confuse increased capability with increased competence.

The goal should not be to create people who are simply very good at asking a machine for answers. The goal should be to develop people who understand enough to question those answers, learn from them, and recognize when they should not be trusted.

Maybe that is why I keep coming back to Hilary Mason’s conversations in the video. She could have demonstrated her expertise by giving everyone the most technically impressive explanation possible. Instead, she adapted to the person in front of her. She listened, adjusted, and tried to create understanding. To me, that is good leadership.

So when I hear companies ask how much AI their people are using, I think there should be another question beside it: What are our people becoming because of the way we are using AI?

Are we using AI to increase human capability, or are we slowly removing some of the experiences that create capability in the first place?

Observation can create confidence. Experience can create competence, but only when experience actually produces growth. Good leadership, in my view, is not about resisting AI or blindly embracing it. It is about creating an environment where people can use these tools, make reasonable mistakes, learn from them, and continue developing the judgment to know when the tool is helping and when it is not.

The responsibility of a leader is not to protect people from technology or from mistakes. It is to create an environment where both can become opportunities to build better judgment.

And perhaps fittingly, I did use AI to help me write this blog post. I used it to help organize some of my thoughts, challenge a few of my arguments, and clean up the writing. But I also went through it myself, changed things I did not agree with, removed things that did not sound like me, and made sure the points actually represent what I believe.

AI helped me write this post.

But the thinking, the experience behind it, and the point I wanted to make are still mine.