‹ back to assist

working with an AI assistant

How goals get real work done

The trick that stops it building the wrong thing: agree the method before any work starts. Same instinct as a good method statement.

When people start using an AI assistant for real work, they type a request and hope. For anything bigger than a quick question that goes sideways fast: it guesses what you meant halfway through, over-builds, wanders off. The fix is a thing I call a goal.

A goal is a short document that says what "done" looks like before any work begins. You don't write it. You talk, and it writes it down. Then you fire it, and it goes and builds the thing, checking its own work against the document as it goes. The thinking happens up front, in plain English, so it builds what you actually meant instead of guessing.

If you've ever written a RAMS or a method statement, you've the instinct already. You don't start the work and figure out the method as you go. You agree the method, then the method does the work. Same here.

A real one, start to finish

Here's one from a while back. I wanted a place the lads' assistants could report problems and we could push fixes back. Watch how little I actually specify, and how much it pushes back before building anything.

The exchange below is tidied up, not word-for-word, but every step is real.

MeThe lads' assistants can't easily tell us when something's broken, and we can't push fixes out to them. We need a place they can post problems that we can also see. Like a wee notice board their bots can post to.
AssistantGood idea, solves a real gap. One fork before we shape it: this either has to be completely open, or it needs a login, otherwise the whole internet can post to it. Which way?
MeIt's either secret free or we need some auth on it.
AssistantThen I'd do both. Reading the site is public, nothing secret in it by design. But posting a report needs a per-person key, so the lads' bots can write but randoms can't. Open and safe at once.

That back-and-forth is the valuable bit. Two minutes of it kills a week of building the wrong thing. Notice I never said how to build it.

MeRight, make a goal for it I can fire.
AssistantDone. Two things worth your eye first: the reports page defaults to key-protected, not public, in case someone pastes something they shouldn't. And it won't be "done" until a real report posts from a real machine, that's the acceptance test, not "it runs". Veto either if it sits wrong.

It's allowed to disagree with me. A goal that just says yes to everything is useless. It's even allowed to come back with "this isn't worth building", which has saved me from myself more than once.

MeGrand. Fire it.
AssistantBuilding. (Twenty minutes later:) Done. Site's live, reporting works, here's what I tested and the one thing I'm not certain about yet.

And it built the lot. The site, the reporting, the keys, the security, the tests. It checked each piece before moving on, and reported honestly at the end: what it built, what it tested, what it was unsure of. No "all done!" without proof.

Why write it down instead of just asking?

  1. You read it back before you commit. A plan you can review beats a rushed instruction you can't.
  2. The "what does done look like" bit forces the thinking up front, which is exactly where jobs go sideways when you skip it.
  3. You can run it again. A goal that worked is reusable. The whole job becomes one line.
  4. It can't wander. The "out of scope" section names the "while you're in there, could you also" temptations and refuses them in advance.

Try it yourself

Start small. Next time you've a job that's more than a quick question, instead of just asking, try:

"Before you start, write me a short goal: what done looks like, what you should not do, and anything you should check with me first. Show me, let me tweak it, then run it."

That's the whole technique. The document is just the method statement. Firing it is just saying "go".