RetrospectiveDevelopment Experience vs. AI Experience, Seen While Training New Developers
When I helped with AI training for people in non-development roles, I thought the gap between those explaining the technology and those using it came from development experience. I assumed developers would find it easier to imagine how to use AI.
Later, while serving as an assistant instructor in training for junior developers, I revisited that assumption. Helping with exercises and answering questions showed me that working with AI can feel unfamiliar even to people with development experience. I had assumed the concepts and working methods I used every day would be familiar to other developers too.
The participants I met that day were not what I had expected. They were comfortable with code, but deciding what to hand to AI and what context to explain was new to them. I felt I should see this not as a difference in development ability, but as a difference in how much each person had used AI.
Hands-On Over Explanation
Development knowledge helps you read and review code that AI produces. But deciding which parts of your work to hand off, what context to explain, and where to make the call yourself is a separate matter. Understanding code was not the same as being used to handing work to AI.
What development knowledge helps with
Reading and reviewing code that AI produces.
What has to be learned separately
Deciding what to hand off, what context to explain, and where to make the call yourself.
Supporting the training also made me think about how to pass on the perspective and know-how I had built up. I wondered whether explaining features and showing how to use them would be enough for others to apply them to their own work.
I think people need the experience of applying AI to their actual work and finding it helpful. Even handing off a small task shows where an explanation fell short and which parts of the result need checking. As those experiences add up, it should get easier to judge how much to hand off next time and what to do yourself.
Even as the one explaining how to use AI, I felt the first step was to find something worth trying in the other person’s current work, rather than passing on the approach I happened to be used to.
Who Wrote It, How to Check
Looking back on this also made me think about the reliability of AI-written code. The first thing that came to mind was that people make mistakes too.
That does not mean we should take AI errors lightly because people make mistakes. It is closer to saying that checking is necessary no matter who wrote the code. Just as something is not correct merely because a person wrote it, we need to examine what an AI-generated result actually does.
So I want to put the question “How do we check this result?” next to “Can we trust AI?” The responsibility for deciding whether to use the result stays with people.
If we help people use AI, I believe we should cover how to check results as well as how to get them.
Procedures and Human Decisions
I also thought it mattered to distinguish what to hand off in automation. Work with a clear procedure to repeat is different from work that requires deciding what to do.
The example I thought of was a meeting. Choosing a direction in a meeting takes human judgment. Recording and organizing what was discussed afterward, on the other hand, could be designed as a repeatable procedure. Handing off the decision itself is different from helping make sure the work that follows a decision is not missed.
A decision for people
Choosing a direction in a meeting
Picking a direction takes human judgment
A procedure to repeat
Recording and organizing afterward
Can be designed as a repeatable procedure that AI helps with
If we only apply ways of repeating actions without this distinction, we may lose sight of why we are repeating them. I am interested in an approach where people own the purpose of the work and the judgments in it, then look for the follow-up procedures AI can help with.
The question that stayed with me after serving as an assistant instructor was how to connect the approaches I had learned with other people’s work. I do not think my way is the right answer for everyone. People do different work and need different kinds of help.
Still, I felt that bringing AI into work calls for someone who helps make that connection: someone who listens to the work people do, helps them find parts they could hand off, and works out how to check the results. Alongside explaining how to use AI well, I became interested in helping others find ways to use it in their own work.