Own your AI skill files, or your job becomes one
On 4 June I wrote a page in a private folder arguing that the scarce thing in an age of AI is your own judgement, and that keeping hold of it is the whole game. Sixty-eight days later Garry Tan, the president of Y Combinator, made the same argument on a stage at Startup School, at an event he says had about 7,000 people in it.
He said it better. He also said it to the wrong room.
His version has something mine didn't: a unit you can point at.
The unit is a page of English
If you haven't met one, a skill file is a page of plain English that tells an AI agent how you do a particular job. Not code. English. Tan's test for whether you've written a good one is whether a smart intern could follow it on their first day. That's the entire spec.
Here's one of mine, compressed to a sentence: when a new research note arrives, check it against everything already in my notes, resolve the links, and if it contradicts something I already believe, flag it, don't overwrite it.
That isn't a document. That's how I handle new information, taken out of my head and made executable by something that never gets tired.
Tan's move is to notice what that implies. A skill file is a piece of your cognition, extracted, written down, and running. And the same file is two completely different futures depending on one thing: who controls the repo it lives in.
Maya, and the one variable
He runs it as a thought experiment. Call her Maya, a support engineer. Over two years she teaches her agents 40 skills. How to triage a P0 at two in the morning. How to talk down a customer who's twenty minutes from leaving. How to write a postmortem that actually prevents the next incident.
Forty files. Two years of hard-won judgement, sitting on a disk.
Version one: the files are in Maya's repo. She changes jobs and turns up on day one already operating with two years of compounded judgement on tap. Every year she works, she compounds.
Version two: the files are in the company's repo, under the company's IT policy. She leaves with nothing. The company carries on running her judgement without her, forever, and her name isn't in the commit history.
Same files. Same Maya. One variable.
Tan's line for version two is the one I haven't been able to put down. She didn't have a career. She had an extraction.
We thought we were exempt
There's a historical rhyme here and it isn't a comforting one.
Craftsmen owned their tools, and that ownership is most of what made them free. A man with his own tools can walk. The factory ended that arrangement. The loom belonged to the mill, and the weaver belonged to whoever owned the loom.
Knowledge workers assumed we'd been let off. Our tools lived in our heads, where nobody could inventory them or ask for them back at the door. That assumption held for about two centuries and it's quietly expiring now, in folders of markdown files. For the first time, the way you do the thing can be extracted, versioned, and owned by somebody who isn't you.
The part Tan didn't need to say
He was talking to founders. Founders already own their repos. Telling a room of people starting companies to own their skill files is like telling them to own their laptops: true, and already handled.
The people this actually bites are employed.
If you're any good with AI at work, you're doing it inside a company account, under a company policy, in a company workspace. Every genuinely useful thing you've taught it, every correction, every "no, not like that, like this", is accumulating in a place you will lose access to on the day you hand the laptop back. You aren't building a career asset. You're training your replacement's manual, and you're doing it enthusiastically, because it makes this week easier.
Nobody is being sinister about it. That's what makes it work.
Where I'm standing
I should declare my position, because it changes how you ought to read this.
I spent 38 years inside large organisations. Systems programmer first, writing assembler close to the metal, back when we wrote our own editors. Then project and programme management. Then business continuity, which I've been doing in one form or another since 1985. Four books along the way.
In July I was made redundant. I'm on garden leave until the end of September.
Everything I know how to do is in a repo I own. Not because I saw this coming and planned for it. I built it because I have ADHD and couldn't hold anything in my head, so I started writing down how I do things and pointing agents at the result. The ownership turned out to be the valuable part, and I got there by accident.
If you want to see what that actually looks like rather than take my word for it, I wrote it up in July: a walk through the notes, the skill files and the agent setup I run, prompted by an earlier talk of Tan's that described my own system back to me. It's honest about the part that isn't working, which is that none of it has made me any money yet.
I'm not writing this from the safe side of the fence. I'm writing it about a week after realising which side I'd landed on.
What to do about it, if you're employed
Write it down. Pick the task you do every week that you hate the most, and describe how you do it, in English, the way you'd explain it to a competent new starter. That page is the asset. It didn't exist before you wrote it and no model on earth has it, because it only existed in your head.
Keep a copy that's yours. This is the whole argument in one sentence. A copy in a personal repo, a personal notes folder, anywhere that survives your leaving date.
Know where the line is, and stay on the right side of it. Your employer's data, customer details, contracts, internal systems and anything covered by your contract are not yours and taking them is theft. The method is different. How you triage, how you decide, how you sequence a mess into something workable: that's yours, it walked in with you, and writing it down in general terms doesn't change whose it is. If you can't describe your approach without naming a customer, you've written the wrong document.
Do it for the next job, not this one. The point isn't to leave. The point is that if you go, you go whole.
One more thing, and it's the bit I'd rather leave out.
I had this thesis on 4 June. It sat in a private folder for sixty-eight days while I got on with other work, and then somebody with a much bigger platform said it out loud to thousands of people. The thinking wasn't the problem. I'd done the thinking. I just never published it.
Being early and quiet is indistinguishable, afterwards, from being late.
Tan's talk is here. If you watch one part, watch the last fifteen minutes. That's where the argument actually lives.
Then go and write one page about how you do the thing you're best at, and put it somewhere you'll still be able to reach after you hand the laptop back.