At our Deloitte GPS IIO All Hands, I was asked to talk about how I keep pace with learning AI. I opened with a claim that does not go down easily: consuming AI content is not the same as getting better at AI.
It is easy to confuse the two. You follow the creators, read the newsletters, listen to the podcasts. You recognize the tools being discussed and can explain the latest announcement to someone else. There is learning in that. But you can stay very busy taking in information without ever finding out what you can do with it.
That is why my approach has two steps. Consume, then rebuild. Whatever I consume, I rebuild that same week with a coding agent. Small, throwaway, badly built. The first version does not need to impress anyone. It needs to put me in contact with the thing I thought I understood.
The rebuild changes the questions
Imagine watching a demonstration of an agent that answers questions from a document. The presenter uploads a file, asks a question and gets a useful answer. You understand the idea. It looks straightforward.
Now try building a small version. Give it a document with two similar sections. Ask a question whose answer is missing. Change the wording of a question that worked a moment ago. Suddenly you have more useful questions than the demonstration gave you. Where did that answer come from? Why did it choose this passage? How do you tell whether it has enough information to answer at all?
The rebuild gives the idea resistance. You have to make choices, see their consequences and decide what to change. That is where familiarity starts becoming judgment.
A coding agent helps me get to that point faster. But having it produce something that runs cannot be the end of the exercise. I still need to understand what the result depends on. Can I change an input and explain why the output changed? Can I recognize an answer that looks plausible but is wrong? If I cannot, there is more learning to do.
Keeping the build small matters. If every interesting idea turns into a large project, the learning slows down under the weight of everything surrounding it. One behavior is enough to investigate. The artifact can be disposable; the understanding is what I want to keep.
Input is not skill. The rebuild is where one becomes the other.
- ConsumeInputRead, watch, listen.
- RebuildPracticeMake a small version.
- Test / ReflectDevelop understandingChange inputs. Explain results.
- Apply / SharePut skill to useUse it. Write down what helped; return with new questions.
Consume → Rebuild → Test / Reflect → Apply / Share. Rebuilding and reflection turn the input into skill; using and sharing it informs what to learn next.
Four levels of keeping pace
There is another distinction I made in that conversation. “Keeping pace with AI” can mean several different kinds of work. I think about it at four levels: personal, organizational, embedded and production.
Each brings a different question into focus. What helps me work better? What helps my team deliver? What capability is already available in the platforms we use? And what does it take to make any of this dependable in everyday operation?
- PersonalIndividual assistanceUse a coding agent to explore a problem.
- OrganizationalShared team practicesShare a useful prompt and its context.
- EmbeddedAI within enterprise platformsConfigure a useful capability in Workday.
- ProductionOperating reliably at scaleCheck cost, latency and data access.
These are complementary perspectives, not a technical dependency stack. Production concerns such as cost, reliability and data access run across the other levels too.
Personal: individual assistance
This is the natural starting point. A coding agent, a chat assistant, help working through an unfamiliar problem. The benefit is close enough to see: something that took you longer becomes easier, or something you could not attempt becomes possible.
The learning loop is immediate. You try an approach, inspect the result and adjust. You begin to develop a sense of which tasks need a precise instruction, which need more context and which still demand careful review.
That is valuable. It is also easy to stay here. Becoming faster at your own work can feel like the whole opportunity because you experience the improvement directly. The next level asks whether anyone else can benefit from what you figured out.
Organizational: shared team practices
At the team level, the question becomes how the work gets delivered. If five people keep solving the same problem separately, five individual productivity gains can still leave a great deal of repeated effort.
Suppose someone finds a useful way to turn rough meeting notes into a first draft of requirements. Keeping the prompt to themselves helps one person. Sharing it, explaining the context it needs and showing where the output needs review gives the team something it can improve together.
The explanation matters as much as the prompt. A colleague needs to understand why it works and when it stops being useful. Otherwise, every unfamiliar result comes back to the person who created it. The person who made the team faster becomes its next bottleneck.
Whoever figures something out should write it down. That small habit lets learning accumulate across a team instead of disappearing into separate conversations and personal folders.
Embedded: AI within enterprise platforms
This is the level I want to explore more deeply, drawing on my Workday DevCon experience.
When we think about AI, it is tempting to start with something new to build. In an enterprise, I also want to examine the platforms already supporting the work. Workday is the platform closest to my own experience; the same question is relevant when looking at systems such as Oracle or ServiceNow. What useful capability is already there, and what would it take to put it to work?
That changes the learning task. You need to understand the capability, where it fits in the process, what access it needs and how people will use it. For something already available under the organization's agreement, the opportunity may be much closer than a new custom build suggests.
Availability alone does not make the choice worthwhile. A capability has to serve an actual need. The interesting work is understanding that fit well enough to configure it sensibly, secure it properly and help people adopt it.
For a consultant, that is a substantial part of adding value: knowing the platform well enough to connect what it can do with a problem worth solving.
Production: operating reliably at scale
Then the demonstration meets the working day.
One user gets a good answer. What happens when many people need answers at the same time? A short interaction costs very little. What does repeated use cost every day? The demonstration responds quickly. How does waiting change the experience when this becomes part of someone's normal workflow?
Data raises equally practical questions. What is the system allowed to see? What happens to the information sent to a hosted model? Who needs to understand those arrangements before the tool becomes part of the work?
These questions change what it means to be good at AI. Building the first version is one ability. Understanding its cost, behavior and limits well enough to operate it is another. The distance between them is where a great deal of the valuable work sits.
It is also why a rough rebuild is such a useful place to start. You encounter a small version of a real problem and develop better questions for the next one. Over time, those questions become more precise. You can see beyond what the demonstration shows you.
I want to keep following that thread into the AI capabilities within Workday: what they actually do, where they help and what it takes to use them well. The habit underneath that work stays the same. Consume something useful. Rebuild it while the idea is fresh. Understand what happened well enough to explain it to someone else.
That gives me a better measure of keeping pace: what I can now build, question and make useful.