In Which I Draw a Few Conclusions About Managing It
Last time I introduced the intern: brilliant, tireless, allergic to the word “no,” and gone before any of Its decisions come due. That post was the why. This one is the boring, useful part, the checklist I actually run. If the first post convinced you this is a management problem, this is the management.
It comes down to three kinds of question. What is this work? How do I drive It? And which of Its habits do I just have to stay scared of? The first two are decisions I make on purpose. The third is a list of things that will cost me if I forget them.
What kind of work is this?
This one I answer before I open the tool at all, because it sets how much of myself the work deserves.
The first cut is the obvious one: does this just need to get done, or does it need to be done well? Most things only need to get done. The second cut is sneakier and I keep mistaking it for the first: who is this for, and will it last? Work I do only for myself, that I’ll delete after or never reopen, is a different animal from work that walks into someone else’s day and stays there. They usually line up, but not always. A private scribble can deserve real care if it’s how I’m untangling something hard. A rushed reply to a colleague can stay rough as long as it’s correct. The line I hold is that the moment other people depend on a thing, its quality stops being my taste and becomes a promise I made on their behalf, and the intern cannot sign promises for me.
Do I want a result, or a machine that makes results?
This is the decision that changed how I actually operate It, and almost nobody frames it this way.
The intern is non-deterministic by nature. Ask It the same thing twice and you get two cousins, not the same answer. Sometimes that’s exactly what I want; variety is the whole point of a brainstorm. But often I want the same output every time, and the mistake is to keep asking It for it directly and getting annoyed when it drifts. The fix is to climb one rung up the ladder. Instead of asking It to produce the thing, I ask It to build the tool that produces the thing, and then I run the tool myself. It is a mediocre factory and an excellent factory builder. The factory It builds runs the same way every time, which is the entire point of wanting determinism in the first place.
This shows up most clearly with anything repetitive. The fifth time I catch myself prompting the same shape of task, that’s the tell: I never wanted It to do the task, I wanted it automated. So I ask once for the small script, and from then on it runs identically, for free, with no intern in the loop to have an off day. A good rule of thumb: if it would bother me that two runs came out different, I wanted a machine, and I should be building one instead of asking for an answer.
Do I keep going, or start over?
Once I’m in the middle of something, the constant question is whether to keep building on the current conversation or throw it out and start clean.
Early on, every useful exchange adds to a shared understanding It can build on, and the work gets faster and sharper. Then it tips. The same conversation fills up with dead ends and half-abandoned attempts, and It starts tripping over Its own earlier mistakes, defending decisions I’d already told It to drop. The kindest thing I can do at that point is delete all of it and come back with one tight prompt carrying only what survived. Iterating toward a good answer through repeated passes isn’t an AI quirk, by the way; it’s how people work too. The difference is the passes are nearly free now, which makes the decision of when to stop, and when to wipe the slate, matter more, not less. I’m still bad at it. I usually notice I should have reset a few exchanges after the point where I should have reset.
The habits to stay scared of
These aren’t decisions. They’re standing facts about the intern that punish you the moment you relax. I covered them in the first post, so here they are as a list, not a sermon:
- It doesn’t bear the consequences. It won’t get the late-night call. So close the loop while It’s still working: make It run the tests, sit in the failures, and fix them. Never trust the first “done.”
- It copies whatever It’s shown. Clean room, clean work; messy room, beautifully matched mess. Curate what It gets to look at.
- It is most confident exactly where It’s weakest. On the well-trodden stuff It’s superb. On the novel, the recent, or the precise, It is just as smooth and quietly making it up. Trust the average; verify the edge.
- It makes you worse if you let It. The effort It saves is the effort you used to learn from. Do the slow thing on purpose sometimes.
The whole map on one page
If you remember nothing else, remember the shape of it. Three questions, and the side of each one tells you what to do.
| Question | One side | Other side |
|---|---|---|
| How good must this be? | Just needs done | Needs done well |
| Who’s it for, will it last? | Just me, ephemeral | Shared, others depend on it |
| Same result every time? | Variation is fine | Want it fixed: build a tool |
| Doing this repeatedly? | Prompt each time | Automate it once |
| Converging or spiraling? | Enrich the context | Reset and start clean |
| Can I check Its work cheaply? | Yes: hand it over | No: do it myself or verify hard |
| What can It break? | Reversible: long leash | Permanent: read every line |
The first three questions decide what the work is. The next two decide how I drive It. The last two decide how scared to be. None of it is about clever prompting, which is the thing I keep coming back to: the skill was never in the asking. It was in knowing what to ask for, and what to never hand over at all.
Both of these posts were written with heavy help from the intern in question. It thinks the map is excellent. It would.
Comments