“Go on then”

The skill isn’t writing better prompts anymore — it’s knowing when to stop writing them. Sometimes “go on then” beats a page of instructions. Sometimes it falls flat. Telling the two apart is the new craft.

I was telling Mollie this morning about a conversation I’d had with Dan on using AIP as a CRM. AIP is the knowledge graph we’ve been building at Activate Intelligence, a place where clients, projects, people, conversations and updates all live as connected entities rather than rows in a table. My suggestion to Dan was simple: just create a skill. AIP already works as infrastructure, it can already store companies and updates, so decide how you want to manage these things, how you want to call them, and let it do the rest. Create an empty folder if you like, and tell Cowork to set it up the way it finds most effective. Let it manage it for you.

It reminded me of when Apple decided it was no longer convenient for you to manage your MP3 files by yourself, in folders you understood. iTunes took over. A lot of people were upset. “I want to manage my files. I want my folders. I want control.” And the system was basically saying, well, it’s simply better if you don’t.

I think we’re at one of those points again. A few of us working at the forefront of this are already relinquishing control in terms of prompting. We’re not even writing the prompts anymore. We’re allowing Claude to write its own prompts. We set up the situation. We manage the context. Earlier today Mollie and I built a skill that prepares context before a call, so that aip.app goes into a meeting already knowing who’s in the room and what we last discussed. We set up a small experiment, pointed Claude Code at it, and let it iterate until the skill was working. The prompt it produced was very effective, and we hadn’t even read it until afterwards.

There’s something in this about trusting change, or resisting it. The farther away we get from direct control, the more agency we give these tools.

Here’s a small experiment I haven’t run but I’m confident would work. Put a job description and a stack of CVs in a folder. Point Claude at the folder. The most effective prompt, I think, would be three words.

Go on then.

Better, probably, than “analyse these CVs, compare them to the application, create a table with these columns, apply this weighting, blah, blah, blah”. With a reasoning model, “go on then” means it prompts itself. It works out what it’s doing. If you start with a big pile of instructions, it can get confused. It might not understand you completely, or it follows your structure when it had a better one in mind.

But, and this is the odd thing, it really is a matter of sensibility. I can describe the CV experiment and I’m pretty sure it will work. You’d probably agree. But there’s a whole other class of environments where “go on then” falls flat, where you do need the structured instructions and the specified output.

Knowing which is which is the skill. There are things I’m absolutely confident will work with minimal prompting. There are things I know won’t. And there is a large middle where you don’t know and you have to try to get it to work.

That’s the interesting space right now.

Leave a Reply