A week or so ago, Garry Tan — the CEO of Y Combinator — posted a short essay on X called "Thin Harness, Fat Skills." A few days later he boiled it down even further in a follow-up post: push smart, fuzzy human judgment into markdown skills, push deterministic work into code, and keep the harness in the middle as thin as you can get away with.
The tip came from a CTO-calibre developer who thinks like a business owner — just one of a handful of senior software people worth listening to in the twenty years I've been trawling the dev space. As he told me about this post, I immediately went to reference it. He was spot on, of course.
Garry had named something I'd been doing without a name.
I'm going to explain what it means, why it matters for anyone running AI ops for a small team, and how I'm using it right now to ship a technical grant application with ten working days on the clock. I'm a marketing guy, not a developer. That's the whole point. And it actually goes beyond running AI ops — it can be applied to how you work with AI on pretty much anything. I chose this topic today partly so I could further develop, clarify, and understand the concepts myself, because to be honest there's still some fuzziness around this for me too. It's pretty damn technical. On a scale of 1 to 10, where 1 is a total noob boomer and 10 is a chap like Garry Tan, I'm somewhere in the 5 or 6 range. So I need to write these concepts down so I can properly think about them, digest them, and expand/expound to get the best use out of them. I hope anyone who reads this can do the same.
What Tan Actually Said
Tan's core claim is that the bottleneck in AI work is not the model's intelligence. "Model" here refers to the LLM — Claude, Gemini, GPT, whichever one you're using. The models are fine. The bottleneck is whether the model understands your schema — your data, your conventions, the specific shape of your problem. Not to mention domain expertise, which is hugely important.
He lays out a three-layer stack.
Fat skills on top. These are markdown files. Procedures. Playbooks. Not prompts. They teach the model how to do something — how you run a CEO review, how to look for the exact type of investment data that you are interested in, how you run a weekly client check-in, how you onboard a charity to your platform. They encode judgment. They are the part that's specific to you and your work. Tan says 90% of the value lives here. The beauty is that this is just simple markdown or text files, in English (or your native language for that matter). You can write these, ask the model to shape them better for a prompt, but they're your rules.
Thin harness in the middle. The harness is the plumbing — the bit of software that runs the model and handles reading and writing files on your behalf. Think of it like the pipes under the sink. It has to work, but nobody goes to look at it. Tan's point is that most teams overbuild this layer. They stuff it with tools, wrappers, and custom connectors until it slows everything down and gets in the way of the skills. Keep it small. The cleverness belongs in the skills, not in the plumbing.
Fat code at the bottom. For anything that has to be exactly right every time — payments, auth, cryptographic proofs, database writes — use real code. Not a language model deciding. Real deterministic code. And crucially: don't rewrite it if it already exists. Use other people's code that's battle-tested and proven. The point is that it already exists, it's been tested, and you don't have to build it again.
Why This Matters If You're Not a Developer
When AI first came out, and even up until about six months ago, I used to think of AI as "a smart thing I ask questions." That's about as wrong as thinking of a carpenter as "a person who owns a hammer."
The shift Tan is pointing at is that your work with AI isn't what you say in any one conversation. It's the set of skills — the markdown playbooks — that you accumulate over time. Those skills are the asset. Each one is a small, inspectable, version-controlled procedure that captures how you actually do a piece of work when you do it well. The beauty is that this is just simple markdown — a human-written set of rules you gather over time as you learn with AI and AI learns with you. About you, what you're doing, your interests, your skills, your gaps. Everything. Otherwise, all you have are a bunch of disjointed search queries that lack context and are essentially a waste of your time.
Once you have the skills — or markdown, or rules, whatever you want to call them — the loop is almost uninteresting. You run the rule. The model follows the procedure. You inspect the output. If it needs fixing, you don't fix the output — you fix the rule. Then every future run is better.
For a small operator, this is the unlock. You don't need a team of engineers. You need:
1. Your own judgment, written down as skills (fat). 2. One working harness that can read and run those skills (thin — in this case, the model itself or maybe something you write that doesn't exist, but it stays thin!). 3. The rest of the work delegated to software that already exists and is already good (fat code someone else wrote). This could be another SaaS, or someone else's agent.
That's the shape of leverage for a non-developer in 2026 — and very likely beyond. You are not building software. You are writing down what you know, connecting it to a loop, and composing what other people have already built.
Walking Through The Frame: The Charity Infrastructure Project
Abstract principles are useless without a worked example. So here's the charity infrastructure project I wrote about on Day 13 — small-charity donations, multi-jurisdiction governance, a working prototype I built in 48 hours — mapped onto Tan's three layers. I'm not naming the project or the grant here, same reason as last week. I'd rather not invite competition.
Here's what I did. This is the same process I'd suggest for anyone applying the frame to their own work.
Step 1 — Write down the fuzzy work first
I sat down yesterday and wrote a list of every decision in this project that requires judgment. No code. Just judgment calls. I got nine:
- Onboarding a new charity (which wallet, which signers, what governance document)
- Generating a jurisdiction-specific trustee brief (UK vs. US vs. South Africa vs. Bermuda)
- Interpreting a donor's natural-language intent ("$20 to music education in Cape Town" → which charity, which rail)
- Vetting a prospective pilot organisation against public registries
- Recording the demo video (shot list, fallback footage, what counts as "undeniable")
- Running a CEO-style review on the grant document before it ships
- Writing the monthly impact story for funders once the pilot is live
- Resolving a natural-language charity search against the database
- Prepping for the foundation's learning convenings across the grant year
Each one is a skill. Each one gets a markdown file. Four of them I need before the deadline. The other five can be drafted across the pilot year — and the fact that the pilot year is, in substance, "write the other five skills and prove they work" is itself the grant's deliverable. That reframing alone changed the shape of the application, which I'm still in the process of writing because the project is changing nearly daily. The more theories I can prove before the deadline, the better.
Step 2 — Identify the fat-code layer and refuse to rebuild it
Then I made a second list. Everything this project needs that has to be exactly right every time. Not opinions. Not judgment calls. The things that have to work the same way on every single execution — moving money, keeping records that regulators will accept, verifying that an organisation is who it says it is, settling a payment.
For each one, I wrote down the category of work, then went looking for an existing piece of software that already handles it well at scale. I didn't build any of it. I'm not going to. That's the whole fat-code layer — other people's code, battle-tested, already running somewhere with real money or real users on it. Compose it. Don't rebuild it.
If that sounds obvious, it is. And yet almost everyone I know in my position — a non-developer with an idea — defaults to "let me get a developer to build the back end." That is exactly the wrong instinct. What you actually want is to find existing software for every category of deterministic work, plug it in, and own only the thin middle layer that connects it together. Maybe an entrepreneur or an investor would think, yeah — but then you have no moat. The moat will come once the system proves itself and starts to propagate your theories that are really based as simply as possible.
Whenever I caught myself about to write something into this layer, the engineering-review skill stopped me. That is its entire job, and it earns its keep several times a week.
Step 3 — Keep the harness small
What's left — the thin harness — is everything I actually own in code. A small server. A single payment endpoint. A simple database. A donate page. A basic dashboard. That's it. Every time something new wants to go into this layer, it has to pass the engineering-review skill and it has to be something that genuinely can't be composed. Wow, sounds simple, like anyone could come in and replace you. Yes, now — but who would do this, because there's literally no money in doing so, and frankly, quite a lot of work, hand wringing, and chasing charity feedback. The moat will come when this system quietly sneaks in the back door in 12 months because it's been using all of my business rules to improve and learn, with me driving it.
The harness is boring on purpose. The skills are where the project's character lives. The fat code is where the safety and scale come from.
Why this matters for the deadline
Here's the whole thing in one line: I've got a hypothesis, I've got a working prototype that shows the hypothesis could be true, and the grant funds the year of proof.
The hypothesis is that AI can help donors find and fund small charities faster, cheaper, and across more borders than any existing platform allows. The prototype is live. It works. A real donation has gone through it, end to end, to a real charity.
What I need the grant for is the blow-out. More pilot organisations. More countries. More of the judgment work codified as rules the system keeps improving. More evidence that the whole thing is actually learning as it runs. That is the deliverable. Not "we will build software." Most of the software is already built by other people and better than I could do it. The deliverable is a self-learning system — a growing library of rules, running against a thin middle layer, composing the best infrastructure on the planet — and proof that it helps a small charity receive a donation it wouldn't otherwise have received.
If I'd tried to ship this the old way — design a database, build every component, stand it all up myself — I'd already be two months behind a ten-working-day clock, and it'd be ugly and full of bugs! With the frame, the work left is skill-writing, narrative, and a demo. Which is the work I'm actually good at.
The Mental Shift
Here's the shift I want to put down clearly, because I think it's going to matter for a lot of people running small ops with AI over the next year — and for the broader workforce beyond that. The people who get this are going to 10x their skills. I'm pretty sure about that. The fact that I'm writing this down now, applied to my specific case, could actually become a new rule that I train my model on. You can see it working in action through this post. Example — "Before we do this, make sure you read this post I wrote about how I want to work. Make sure I am following these rules. If I'm not, change the rule to codify it."
I'm doing it now, and you can see how it works.
Stop thinking about AI as a tool you talk to. Start thinking about it as a loop you own. The value of the loop is not in the model at the centre — that's a commodity, it changes every six weeks, and you don't control it. The value is in the skills you've written and the infrastructure you've composed. Those are the durable assets, and they're yours. You wrote them. You understand them. And they evolve as you and your AI co-pilot evolve your creepy, deepening relationship together. Only mildly joking there — I do love AI for the things it helps me do, but that's kind of creepy too.
Whether you're a fund manager, a badass developer that doesn't have much business experience, a nonprofit ED, or a boomer noob to AI, you can handle this part.
If I lose my Claude subscription tomorrow, the skills still work on whatever model comes next. They're markdown on your hard drive, ideally in a vault system like the one we wrote about in our AI OS post. If Tan's specific harness goes away tomorrow, my skills move to the next harness in an afternoon. The thing I own is the judgment I've written down and the composition of services I've chosen. The harness is interchangeable.
This is also why I don't spend time fine-tuning models or building custom agents. The marginal return on that work is low and the half-life is short. The marginal return on a well-written skill or rule is permanent.
A Self-Learning Practice For The Fat-Skills Frame
The frame only works if the skills get better over time. That's a practice, not a one-time build. Here's the practice I'm adopting and suggesting to anyone who wants to use this seriously. Eight rules. None of them are complicated.
1. Write the skill while doing the work, not after. Memory lies. Write the first version of a skill during a real call, a real proposal, a real onboarding — not from recollection. The detail that matters is the detail you only notice in the moment. This is a habit I've built into my daily routine after years of journaling. I wrote about where the habit came from on Day 9.
2. Edit the skill, not the output. When a run gives a bad answer, the temptation is to fix the answer. Don't. Fix the procedure, so the next run — and every run after it — is better. This is the entire compounding mechanism. Fix outputs and you've wasted ten minutes. Fix the skill and you've earned back ten minutes a week forever. This doesn't even have to mean opening the markdown file and editing by hand. Just tell the model: "Mate, you messed this up — go back and fix the rule where we already handled this." Done.
3. Run a new skill three times before you trust it. Three real uses. Different inputs, different contexts, different tone. If it holds up on all three, it's a skill. If it only works in the one context you built it for, it's a prompt.
4. Keep a skills changelog. One file per skill with dated edits and why. In six months, you'll see the actual shape of what you got better at. It's the best learning log I've kept in years, and it takes two minutes per edit. Oooo, this one came from my AI co-pilot. Liking it.
5. Read one external skill pack a week. There's a lot of open-source work to steal patterns from. Find a pack you respect, read it, write down what you want to borrow. Don't copy — adapt. But stop inventing in isolation.
6. Run a monthly skill review. Which skills did you actually reach for? Which ones never got used? Prune ruthlessly. Merge overlapping skills. Split any skill that's trying to do two jobs. The inventory should stay small and earn its keep.
7. Before writing code, look for fat code. Every time you're about to build something that has to be exactly right — auth, payments, accounting, custody, verification — pause and ask whether someone has already built it, shipped it, and hardened it. Usually yes. Compose it. Writing it yourself is almost always the wrong answer.
8. The model is interchangeable; the skills are the asset. Don't tune skills for a specific model's quirks. Write them for a capable generalist reader, human or machine — write them for YOU. That's the only version that survives model churn — and model churn happens every few weeks now. These are rules you write, in your own language, that you understand. Keep it simple, stupid.
If you do this for three months, you'll have something most teams won't have: a library of your own judgment in a form that compounds. That library is worth more than any particular AI subscription, any particular model, any particular harness.
That's the actual point of Tan's essay. The loop is a commodity. The skills are the compounding asset. The fat code is leverage you didn't have to build.
If you don't know how to implement the technical part, that's what I'm here for. I'll help on a per-task basis. I can get you set up — you know your guidelines and your rules way better than I do. You may just not be sure where to start. That is exactly why I created this service. There, I'm a sales guy, of course I had to slip in a tiny pitch — but I think you'll see the value you'll get back for a month or a few months will easily pay for itself.
Today
Today is skill day, not writing day. First drafts of four grant-critical skills — the charity onboarding procedure, the jurisdiction governance brief generator, the demo recording script, and the meta-skill that pass-reviews the grant document. I'm running the engineering-review skill against the server and the payment endpoint with an explicit goal of zero additions. The harness stays thin.
And I'm pushing $1–$10 of real money through the live chain today — from the on-ramp, through the payment endpoint, into a real charity wallet, confirmed end to end. If that works, the demo recording happens later this week.
The thin voice I mentioned on Day 13 keeps showing up in these runs. I'm listening.
Revenue: $0. Clients: 2. Prospects: 5.
Day 18 of 365.