For my students · AI is not a tool
One will be clicking.
The other will be delegating.
Two people can sit in front of the same AI, on the same afternoon, with the same assignment, and be doing entirely different jobs. The difference is not the software. It is the relationship.
And the person who understands how to form productive relationships with those entities will operate very differently from the person who continues treating them as software.
One will be clicking.
The other will be delegating.
That is the whole lesson. Everything below is an attempt to make it impossible to forget, because the most common mistake I see is not a lack of skill with AI. It is a very good skill applied inside the wrong relationship.
Tuesday, 2:00 p.m.
Two students get the same job: turn a week of scattered notes, emails and meeting transcripts into a one-page project update for a client.
The first opens a chat, pastes in the notes, asks for a summary, copies it out, notices a missing meeting, goes back, pastes the transcript, asks again, reformats the result, checks it against the emails, pastes those too, asks for a shorter version, copies that into the document. It works. It took an hour and about forty moves, and every one of them went through her hands.
The second writes one paragraph: who the client is, what the update is for, where the material lives, what a good update looks like, what must not be said, and when to come back with a draft. Then she reads what comes back and judges it.
Same AI. Same afternoon. One was clicking. The other was delegating.
01 Clicking is not about the mouse
When I say clicking, I do not mean the physical act. I mean a posture: you remain the loop. Every piece of information moves because you moved it. Every next step happens because you decided it. The AI answers; you carry the answer somewhere; you decide what to ask next; you carry that back.
In that posture the AI can become extraordinarily capable and you will remain extraordinarily busy. Faster answers only make the loop spin faster, and you are still the thing it spins around. This is what treating it as software looks like: software waits to be operated. It does nothing between your clicks.
The trap is that clicking feels productive. You are touching everything. You can see every step. It feels like control. Very often it is just labor you have not noticed you no longer need to perform.
02 Delegating is handing over an outcome
Delegating means you stop issuing instructions and start describing what should become true. The entity works out the steps, within the authority you gave it, and you judge the result.
That is not a new skill. It is one of the oldest skills in working life, and it is the one that separates people who manage work from people who do tasks. Good managers do not tell a capable colleague which keys to press. They explain the goal, supply the context, draw the boundaries, say what done looks like, and agree on when to check in. That same structure is what a productive working relationship with an AI needs.
Figure 01
The five parts of a mandate
Outcome
What should be true when the work is done. Not the steps, the result.
Context
Who it is for, why it matters, where the material lives, what has already been tried.
Boundaries
What it may touch, what it may not, what it must never say or send on its own.
Standard
What a good result looks like, so both of you can tell when it is finished.
Checkpoint
When and how it comes back to you, and what it should raise rather than decide.
03 Why I say relationship, not prompt
A prompt is a single exchange. A relationship is what accumulates across exchanges, and that accumulation is where the real difference lives.
- Context builds up. An entity you work with repeatedly, given memory, files and a stable way of working, stops needing everything explained from scratch. Software never gets to know you.
- Trust is earned from the record. You would not give a new hire authority over the client account on the first day. You give a small mandate, look at what came back, and widen the authority as the track record grows. Do the same here.
- Feedback goes to results, not keystrokes. When something is wrong, you correct the standard or the context, not the individual step. That correction carries forward into the next piece of work.
This is a functional description. It makes no claim about consciousness or personhood. I call it an entity because it is a distinct participant you can address, brief, authorize within limits and evaluate by what it does, and because the word tool quietly assigns you the job of operator before you have even started.
Figure 02
Two relationships with the same system
| The question | Treating it as software | Treating it as an entity |
|---|---|---|
| What do you hand over? | An instruction | An outcome |
| Who moves the information? | You, every time | It does, within the access you granted |
| Who decides the next step? | You, after every answer | It does, and raises what it should not decide |
| Where does your time go? | Operating the loop | Defining the goal and judging the result |
| What improves over time? | Your speed at clicking | Its context, and the authority you can safely give it |
| What skill matters most? | Knowing the interface | Knowing what good looks like |
04 The one thing delegation does not remove
Here is the part students skip. Delegating does not mean you stop thinking. It moves your thinking to the two places it matters most: the beginning, where you decide what should be true, and the end, where you decide whether it is.
That is harder, not easier. Clicking lets you avoid ever deciding what a good result looks like, because you are always busy with the next step. Delegating forces the question. If you cannot tell a good project update from a bad one, handing it off will not save you. It will just produce bad updates faster, and they will have your name on them.
So the students who will do best are not the ones who know the most buttons. They are the ones who know their subject well enough to judge the work, and who have practiced saying clearly what they want.
This week’s exercise
The clicking audit
- Pick one task you did with AI in the last week.
- Count your moves. Every paste, copy, re-ask, reformat and carry. Write the number down.
- Rewrite it as a mandate using the five parts: outcome, context, boundaries, standard, checkpoint.
- Run it, and resist the urge to step in halfway.
- Judge only the result. Where it fell short, ask which of the five parts you left vague, and fix that, not the step.
05 Where I could be wrong
- Already true
- Current AI systems, given the right access, can interpret an objective, choose a method, use software, check what happened and revise. The architecture that separates a model directing its own process from a fixed workflow is described openly by the people who build these systems.
- What has to happen
- The access, memory and boundaries have to be in place. A bare chat window with no context and no connection to your work cannot hold a standing mandate, and pretending it can is how people get burned.
- Where I am probably wrong
- Reliability is uneven, and on some tasks the careful click-through is still the right call because the cost of a confident mistake is too high. Delegating to something you cannot evaluate is not delegation; it is gambling. If you do not yet know what good looks like, start by clicking and learning. Just do not mistake that stage for the destination.
The software will keep getting better either way. What will separate people is not access to it. It is whether they learned to stand in the right place relative to it.
One will be clicking.
The other will be delegating.
1 thought on “One Will Be Clicking. The Other Will Be Delegating.”