Why the future of expertise may be less about what each of us knows and more about how we learn to work together
Lately, I’ve been hearing a lot about AI fluency and what it means for people working in increasingly AI-enabled environments. A recent conversation with a friend raised some interesting questions about AI adoption and where domain expertise fits. If AI can increasingly perform tasks that once required years of technical experience, how do we make sure we don’t lose the knowledge and judgment that help us understand whether the results are reasonable in the first place?
The next morning, with the conversation still on my mind, I watched a Maven Analytics workshop on building AI-fluent data teams that had been on my “to watch” list, and read a McKinsey article on AI fluency. Together, they pushed me to think beyond simply knowing how to use AI tools and toward the skills and ways of working that will allow us to use them well. There are people who have embraced these tools very quickly and are finding impressive ways to use them, but being comfortable with AI doesn’t necessarily mean being good at evaluating what it produces. Verification, bias, uncertainty and risk become increasingly important when it is so easy to generate an answer that sounds convincing.
As I considered these ideas, they began to remind me of another technological transition I experienced earlier in my career as a geologist.
When Geological Mapping Went Digital
When I started working in the oil and gas industry, geological mapping was transitioning from hand contouring to computer contouring. I was fortunate to come along at a point where I had some experience with both. Some of the more experienced geologists I worked with had spent much of their careers working with much sparser datasets and drawing their interpretations by hand. They had learned to think carefully about the geometry and distribution of depositional environments, because every contour they drew required them to make an interpretive decision.
As computer contouring became more common, newer geologists could work with much larger datasets and generate maps much more quickly. This became frustrating for some, particularly when a computer-generated surface was accepted without much consideration of whether the resulting map made geological sense. At the same time, relying entirely on the manual interpretation of an experienced geologist had its own limitations. Experience and geological intuition are extremely valuable, but they also contain assumptions, and those assumptions aren’t always immediately obvious.
What I didn’t fully appreciate at first was how much uncertainty existed in either approach. A computer-generated surface wasn’t simply a representation of the data; it was a representation of the data based on a particular interpolation method and a set of statistical assumptions. Changing those assumptions could produce a different surface. In areas where data were sparse, adding carefully considered constraints based on knowledge of the depositional environment could produce another. Several different interpretations could honour the same observed data and still look quite different between the points controlling the interpretation.
Geomodelling and Learning to Embrace Uncertainty
I came to understand this much better when I started building geological models. Instead of trying to create a single map that represented our best interpretation of the subsurface, modelling gave us the ability to consider different representations and carry those interpretations forward into reservoir simulation. Geological models are inherently non-unique; different interpretations can honour the same available data. The question was no longer simply whether a geological map looked reasonable – it also needed to explain what had happened in the reservoir.
Building those models also meant bringing together different types of information and expertise. Geophysics could provide another view of the subsurface, helping us constrain geometry and continuity in places where well control was limited, while bringing its own uncertainties and limitations. I also began learning from the reservoir engineers I worked with. They understood production behaviour, pressure, connectivity and fluid movement in ways that I didn’t, and those observations could tell us something about whether the geological interpretation was reasonable. A model could make perfect sense from a geological perspective but still struggle to reproduce historical production. When that happened, we needed to go back and reconsider what we had assumed about the reservoir.
Back then, I often felt that being a geomodeller was a bit of a go-between. I needed to understand the geological interpretation and why certain geometries mattered, as well as how geophysical interpretations helped constrain them, but I also needed to understand what the modelling software was doing and how different assumptions could affect the result. At the same time, I had to learn enough about reservoir engineering to understand what the engineers needed from the model and what production behaviour might be telling us about the geology.
Sometimes it was challenging to bring the domains together on a specific project. Over time, however, I think the different groups also learned to respect what the others brought to the table. The experienced geologist didn’t need to become the modelling expert, and the modeller didn’t suddenly acquire all their geological experience. Geophysicists and engineers brought different sources of evidence and different perspectives altogether. The quality of the model improved because those different kinds of expertise were brought together.
A Familiar Challenge With a Much More Powerful Tool
I see some parallels with what is happening with AI today. The scale of the technological change is obviously very different, but the underlying problem feels familiar. Computer contouring made it possible to generate a polished geological interpretation very quickly, even if the person creating it didn’t fully understand all of the assumptions behind it. Generative AI can now do something similar across a much broader range of work, producing analysis, code, explanations and recommendations that can appear remarkably complete and authoritative.
That makes it tempting to focus on learning how to use the technology. Early adopters have an important role to play in experimenting with AI, finding new applications and showing the rest of us what is possible. The concern is when the ability to produce an answer begins to be confused with the ability to evaluate one.
This is where I think domain expertise may become more important rather than less. A geologist can recognize that a mathematically reasonable surface doesn’t fit the depositional environment. An engineer can recognize that an interpretation doesn’t fit observed reservoir behaviour. In other fields, experienced practitioners will have their own versions of that same intuition. They know what questions to ask, what assumptions are important and when something that looks convincing doesn’t quite make sense.
AI also brings the uncertainty problem back in an interesting way. A generative AI system tends to give us an answer, while the reality may be that several answers are plausible depending on the available information and the assumptions being made. That is something geomodelling eventually taught me to be much more comfortable with. The goal wasn’t always to find the one correct representation of the subsurface, but to understand what interpretations were plausible, what evidence supported them and how uncertainty might affect the decisions we were making.
Multiplier in the Middle
Watching the Maven workshop introduced me to a variety of different AI adoption personas including resistors, enthusiasts and multipliers. I’m not sure these are necessarily fixed roles or universally accepted terminology, but I find the idea useful. A resistor may have deep experience and domain knowledge but be hesitant to adopt new tools. An enthusiast may be very comfortable experimenting with AI and discovering what it can do, but may not yet have the experience to recognize every limitation or risk.
The multiplier is particularly interesting to me because the role feels familiar. Rather than simply being an advocate for AI, a multiplier helps connect the technology with the people who have a deep understanding of the domain. They can help others learn how to use the tools, develop practical standards, recognize security or governance concerns and help determine where AI actually adds value. Just as importantly, they need to be willing to learn from the people around them.
That last part matters. My role as a geomodeller wasn’t valuable because I knew more than the geologists or engineers I worked with. In many areas, I clearly didn’t. The value came from the model bringing those different perspectives together. I learned from geoscientists who had spent more time working in the area, got a better sense of the production and reservoir behaviour from engineers, and gradually developed my own understanding of how the technology, statistics and different interpretations fit together.
Maybe Fluency Belongs to the Team
This makes me wonder whether we are placing too much emphasis on AI fluency as an individual capability. Individuals certainly need to become better at using AI, evaluating its output, verifying information and recognizing risk. However, it may be unrealistic to expect every person to have deep domain expertise, strong AI capabilities, technical knowledge, security awareness and an understanding of governance all at once.
Perhaps what we need instead are more AI-fluent teams. Those teams might include people who understand the domain deeply, people who are willing to experiment with emerging technology, people who understand data and systems, and people who understand security, governance and risk. Multipliers can help connect those perspectives, but they don’t necessarily replace any of them.
We often describe AI as a tool, and technically it is, but increasingly I find it more useful to think about working with AI as I would another contributor to a problem – almost like a team member. It can help explore ideas, suggest alternatives, summarize information, write code and identify connections we may not have considered. We can question its reasoning, provide additional context, reject suggestions that don’t make sense and ask it to approach the problem differently. That interaction feels less like operating traditional software and more like an iterative conversation with someone who brings a very different set of capabilities to the table.
There is an important difference, of course. AI doesn’t bring professional accountability, lived experience or responsibility for the decisions we make. It can produce convincing answers that are incomplete or even wrong, fail to recognize important context or produce an answer without adequately representing uncertainty. Treating AI as a member of the team therefore doesn’t mean treating it as an equal authority. In some ways, it means we need to become better at managing its contribution, just as we learn where to rely on different people and where another perspective is needed.
Interestingly, AI has been part of the team behind this blog. The idea began with a conversation with a friend and my memories of a previous transition within my career. As I worked through those memories with AI, I began making connections to evaluating uncertainty, what I had learned from others and the role I sometimes played between different areas of expertise. AI helped me organize those thoughts and explore how they might relate to AI fluency today. I still had to guide the narrative, decide which ideas best reflected my experience, and restructure writing to make it my own, but I was able to do all this in a matter of hours rather than days.
That experience makes the idea of collective fluency feel particularly relevant. The goal isn’t for AI to replace the expertise around the table. The opportunity comes from understanding what each contributor does well, recognizing where their limitations lie, and knowing when another perspective needs to be brought into the conversation.
Learning From Each Other
As AI takes on more of the tasks through which people have traditionally developed experience, we may need to be more intentional about creating opportunities to learn from one another. Someone who is comfortable experimenting with AI can show a more experienced colleague what is possible, while the domain expert can explain why an answer doesn’t quite make sense, what context is missing or what additional evidence should be considered. AI adds another perspective to that conversation, generating alternatives or connections that neither person may have considered on their own. Rather than simply correcting an AI-generated result, there is value in discussing why it needs to be challenged and how we might test it. That is where mentoring becomes multidirectional: we aren’t just transferring knowledge from one person to another, but creating an environment where technological fluency, domain expertise and professional judgment can develop together.
Similar questions are emerging in other professions as AI begins to take on work that traditionally helped people develop expertise. In law, there are concerns that junior lawyers may lose some of the foundational learning that came from working through documents and due diligence themselves. In medicine, researchers and educators are asking what happens when trainees begin relying on AI before they have developed enough clinical judgment to recognize when its recommendations may be wrong. The common concern isn’t necessarily that AI is doing the work, but that we may unintentionally remove some of the experiences through which people learned how to evaluate that work. We may therefore need to be more intentional about creating those learning experiences in other ways.
This will become particularly important for people early in their careers. Some of the work that AI is beginning to take over may be repetitive, time-consuming or inefficient, and there may be little reason to preserve the task itself. At the same time, we need to recognize that doing that work was sometimes part of the apprenticeship. It exposed people to messy data, unusual cases, mistakes and decisions that gradually helped them develop judgment. My own experience suggests that not all of that learning needs to come from doing the task ourselves; some of it comes from working alongside people with different expertise and understanding how they approach the same problem. If AI removes some of the work, teams may need to find new ways to make that reasoning visible by discussing assumptions, exploring uncertainty, comparing alternative interpretations and involving less-experienced team members in evaluating the results.
Perhaps AI fluency is ultimately about more than an individual’s ability to use AI. It involves knowing when to challenge it, drawing on domain expertise, recognizing uncertainty, learning from people with different perspectives and knowing when another perspective is needed. The goal isn’t for everyone to know everything, but to make sure the knowledge already present within a team continues to move between people—and that AI becomes part of that learning process rather than a shortcut around it. As AI becomes more integrated into how we work, some of the most important fluency may not exist within any one individual at all, but in how effectively we learn to work together.
Further Reading
McKinsey & Company: AI fluency — The next foundation of US economic competitiveness
Maven Analytics Workshop: Building AI-Fluent Data Teams — A Leader’s Playbook
The Guardian: What happens when medical students rely on AI – and never develop their own judgment?
In the next installment of Reading the Current — Visualizing the Energy Transition with Tableau — we’ll return to a topic that’s a little closer to home. Using Tableau to explore global CO₂ emissions and the changing energy mix, we’ll look beyond the visualization to understand the story behind the data and some of the real-world forces shaping the energy transition.