I can build it with AI. Can I explain it?
I thought I was pretty fluent in AI until a coworker asked me for help.
I had been using Claude Code to automate more of my workflow. One system surfaced signals that could help me start conversations earlier. The goal was to catch potential interest before it turned into an inbound lead, without spending my day sorting through noisy alerts.
I’m keeping the details private because it was internal work. But it worked well enough to be useful, saved me time, and let me focus on other things.
Then a coworker asked if I could help them automate more of their job.
Of course I could. I was already doing it.
We got on a call, and I started explaining Cowork. That led to questions. I started explaining skills. More questions. Some I could answer. Others made me realize I had never really stopped to ask them myself.
Why were my skills organized under one root instruction file? What belonged in a skill versus a prompt? How did all of this fit together?
At one point, I was trying to set up a scheduled task and couldn’t remember where to go.
I had built systems that did useful work for me, and here I was struggling to help someone get started.
It worked for me
My coworker never said anything that suggested they doubted me. The feeling that I had lost credibility was entirely mine.
But it was uncomfortable. I had thought of myself as someone who understood this stuff. In that moment, I felt just as lost as the person I was supposed to be helping.
My normal process was familiar: describe what I want, try it, see where it fails, adjust it. Sometimes I fixed the instructions manually. Sometimes a skill proposed changes for me to review.
There is a human approval step in that process. Proposing a change and applying it are different things, especially when an agent is helping automate actual work. I don’t want it deciding on its own that a rule I put there is inconvenient.
Still, getting useful results had let me avoid some questions. I knew how to use what I had built. I didn’t always know how to explain why it was built that way.
It worked, so I kept moving. Probably the Marine in me speaking a little.
What do you ask yourself?
On the call, I decided to bring it back to something basic: what goes into a prompt?
Take prospecting. Before you build a list, you make a bunch of decisions, even if you don’t consciously work through them every time.
- Who are my personas?
- What defines a current customer in our CRM?
- How do I determine whether an account is tier one?
- Should I exclude someone if I contacted them in the last 90 days?
- How long do I want the list to be?
Those are things I could explain. They were questions about work I already knew how to do.
If you answer them, you have the beginnings of a pretty good prompt. You’ve told the system what matters, what to leave out, and what you expect back.
That explanation made sense to my coworker. It also made something click for me.
I had been putting that judgment into my instructions without really recognizing it. What felt like mindlessly typing what I wanted was often me spelling out decisions I had learned to make through doing the job.
I could explain that much more clearly than I could explain my collection of skills.
Thinking out loud was the starting point
My first reaction was that prompting was simpler than I had made it sound. I was thinking out loud about how I would do the task.
But that doesn’t explain the whole system.
Knowing what should go into a prospecting list doesn’t automatically mean I understand how an agent chooses instructions, what context it has, or why changing one file affects something somewhere else.
The call exposed both sides. I had more useful knowledge to teach than I felt I did in that moment. I also had gaps that a working automation had made easy to overlook.
I don’t think forgetting where a setting lives means you don’t know what you’re doing. But I couldn’t blame all of my discomfort on forgetting a setting, either.
There were parts I had accepted because Claude suggested them and the result worked.
What changed afterward
Since then, I’ve put more effort into understanding the fundamentals behind what I’m building.
I still use AI heavily. I still want to automate work. But I’m less satisfied with getting a working result if I can’t explain the important decisions behind it.
I want to understand what information the system receives, which instructions control its behavior, and where I need to review what it does. When something fails, I want a better starting point than handing it back to Claude and hoping the next attempt works.
That shift has improved how I build. It has also changed what I think helping someone else should look like.
My coworker didn’t need a tour of every skill I had created. We needed to start with a task they understood and make the decisions behind it explicit. The tools were easier to discuss once we had something concrete to discuss them around.
I’m still proud of the automation I built. The time it saved was real.
But that call gave me a different way to check my progress: can I sit beside someone who has never used this and explain what I built, why it works, and where I still need to be careful?
I want to be able to say yes without hoping they don’t ask a follow-up.