Part of it is honest: this blog is mostly me writing about things I’m learning, and for a couple of weeks, I hadn’t used AI to do anything new. I was just working.

And part of it is that I’ve decided to let this summer be a little lighter on the writing and a little heavier on the rest of my life. I think that’s allowed.

Either way, it points at something I hear constantly from people who are curious about AI but haven’t started. When you have a full day and fifty things competing for your attention, the idea of sitting down to “learn AI” feels like one more impossible task. It sounds like a project. Something you’d need a free weekend and a clear head for, and you have neither.

Don’t Try to “Learn AI”

Here’s the advice I keep giving, and the advice I keep having to take myself: don’t try to learn AI, or in my case, learn every new model, approach, harness, skill, etc. Pick one small, annoying, repeatable thing in your day and see if AI can do it for you. You’ll learn the other stuff in the process of solving that thing. That thing will teach you what else to try. What won’t help is waiting until you have a whole afternoon or day or weekend or week. You will never have that. Accept it.

For me, one of the first things that actually stuck was tiny. Every Monday I used to go through my calendar and add my AI notetaker to each meeting so they’d get recorded. It took two minutes and I forgot to do it half the time. Now something does it for me every Monday morning and I never think about it. That’s the whole thing. It is not impressive. But it was the first small win, and small wins are what got me here.

Learning is non-linear, frustrating and messy

I want to be honest about what happens when you try, because it isn’t always clean. Sometimes the five-minute experiment you were hoping for turns into three hours and it still doesn’t work. What seemed like such a simple thing to ask AI to do turns out to have a lot of nuance and edge cases you never thought about.

Sometimes the small thing you thought you’d spend 15 minutes on turns into three hours, it works, and then a week later something breaks and you have to go fiddle with it again.

And sometimes it changes your day so much that you can’t believe you spent so long doing it the old way. That’s what hooks you. When it works, it’s like magic. But learning how it works can make you feel behind, frustrated and uncomfortable. Do it anyway.

The rabbit holes are how you learn

Here’s the part I most want you to hear. Even the three hours that end with nothing working are not lost. Every single time, you come out the other side knowing something you didn’t. Sometimes it’s what not to try next time. Sometimes it’s that you were too ambitious and the idea needs to be smaller. And sometimes, halfway down the hole, you realize the steps the AI just took to solve this problem are almost the same steps it would take to solve a completely different problem you’ve been living with. So yes, it might pull you down a rabbit hole. But it’s a useful rabbit hole.

You don’t get to know which of these you’re in until you start. That’s why I keep saying to pick the smallest possible thing. The stakes are low, and the learning is real either way.

So this is for the people who read a post like my last one, or watched the webinar I did recently, and thought, “That’s really cool that people are building these things. I just don’t have the time or space to even think about it.”

Pick your one thing

You have time and space for one thing. Everyone does.

Think of the task you do by hand every week that makes you go, “honestly, anyone could do this. I’m only doing it myself because there’s no one else around to.” That’s the one. Something repeatable. Something that doesn’t matter much if it comes out wrong the first time. Hand that one to AI and see what happens.

That’s how you learn. Not by carving out a weekend to study AI, but by fixing one annoying thing, and then the next, and then the one after that.

I’ll be back to writing about new things. I just have to go build one first.

The model is the brain. It reasons, it writes, it decides what should happen next. But a brain by itself can’t do anything in the world. It needs a body: hands to act with, legs to go somewhere. That body, the tools it’s connected to and what it’s allowed to touch, is the harness. And here’s the part that trips people up: the brain is the same one across Chat, Cowork, and Claude Code. What’s different is the body it’s been given.

Same brain, three different bodies.

In Chat, the brain has no body at all. Whatever it decides, an answer, a draft, a plan, still has to get from that chat window into your actual life, and nothing automates that. You’re the one who copies the text into an email, opens the doc, pastes it in, hits send. Chat produces the thinking. You provide the arms and legs. A smarter model here just means a better answer. It still can’t do anything with that answer except hand it to you.

Cowork, and its OpenAI equivalent, ChatGPT Work, give the brain a small body, hands that can work inside a sealed room on Anthropic’s or OpenAI’s own servers, not legs that walk out into your actual life. You hand it a task, it builds the thing in that contained space, and hands you back a finished deck or document. A smarter model here means it’s more reliable at that specific kind of task, fewer mistakes, less back and forth. But the body is still bounded to a fixed set of task shapes, and you carry the finished thing the last step into your world yourself.

Claude Code, and its OpenAI equivalent, Codex, give the brain a full body, out in your actual world. Real files, real accounts. It reads my actual documents. It writes into my actual Greenhouse pipeline, my actual calendar. When I ask it to make a change, in most cases, it just makes it, instead of describing the change back to me and waiting for me to go do it. A smarter model here doesn’t just mean a better answer or a more reliable single task. It means it can chain more of those steps together, one after another, without going sideways.

What that actually looks like.

Take a real example, and one I actually use. After a meeting, I could copy and paste the transcript and ask Chat what my action items were. I may even be able to connect it to the note-taking tool directly, so I don’t have to copy and paste at all. It’s smart enough to extract the tasks, but I have to go open my real task list and type each one in myself. Handing that same transcript to Cowork, it might output a clean document listing the tasks, but I still copy the ones I want into my actual list myself.

In Claude Code, it reads the transcript, pulls out anything that sounds like a task or a commitment, and hands me what it believes is the right list, getting better over time the more context it has about my team and the work we do. I still decide what’s actually a task and what isn’t. Once I say yes, though, it takes the next step and writes the approved tasks straight into my real list, which shows up in the morning brief I read every day. I never open a file. I never type a single note.

So the tools aren’t smarter or dumber than each other. The brain underneath is the same one, wherever you’re using it, and that’s true no matter which company built it. Claude and Claude Code. ChatGPT and Codex. Copilot and Copilot Studio. Grok, Gemini, whatever comes next. It’s not even hypothetical: Microsoft’s own Copilot can run directly on Anthropic’s Claude models, the same brain showing up inside a completely different company’s product. What’s different is the body it’s been given, how much of the work of turning a good answer into a real result has been built in, and how much of that work is still yours.

I’ll admit the names Claude Code & Codex still confuse people, myself included. None of what I just described, reading a transcript, updating a task list, is code. Claude Code is named for one thing it happens to be very good at, not for the whole of what it can do.

One more dial: which brain you pick.

One more piece worth naming: even within one tool, you’re usually choosing between a few sizes of that same brain. Anthropic has Haiku, Sonnet, and Opus. OpenAI just released GPT-5.6 in three tiers of its own. That’s a different dial from which tool you’re using, and it works a lot like staffing a team. You wouldn’t put your most senior person on something anyone on the team could knock out in five minutes, and you wouldn’t hand your hardest strategic call to whoever’s fastest and cheapest.

Haiku is the quick, capable teammate you send simple, high-volume work to. Opus is the person you bring in when a problem needs real judgment, and you’re willing to pay for their time and wait for it. Running everything through the biggest model isn’t smarter, it’s just slower and more expensive for work that never needed that much thought. The tool decides the body. The size of the brain you pick decides how good it is inside that body.

That’s also why so many people are leaving chat behind for Claude Code and Codex. Companies know this too. Every time a new model ships, the makers loosen the tool’s permissions right along with it, more steps allowed before it checks in, wider access to real files and accounts. The body isn’t growing on its own. It’s being given more, because the brain inside it finally earned it.

I used to go into systems and update fields myself, keeping a running task list of things I typed as the meeting was happening. Now I offload these things to AI, which frees me up to be more present in the meetings, and to capture more information in fields I wouldn’t have wanted to keep current manually.

The goal for me is to keep finding the non-personal work that AI keeps getting better at, and giving it to AI so I can focus on the pieces only I can do. For me, that is creating more space for people: candidates, my team, our colleagues. AI gives me an extra set of hands for the work that needs to get done, but isn’t what I wanted to be focusing on anyway.

If you know me, you know I like an active vacation. Hiking or biking, multiple days, the kind where you work hard from morning to late afternoon and then earn a slow evening. I like views that I earn and seeing beautiful things using my own physical effort. I used to be training for one of these types of things at any given time.

This time, I hadn’t taken one in over a year and had been spending way more time on a laptop than a treadmill or bike.

How it happened

I went from starting my own company to starting a new job with basically no gap in between, and somewhere in there a real break just kept sliding to later. I was heads down for a long time.

So when my partner and I booked five days of hiking in the Dolomites, I had a quiet worry I didn’t say out loud at first. I wasn’t sure I was still in hiking shape. Sure, I know about muscle memory and I hadn’t been completely sedentary, but I’d been at a desk for a year. These were not going to be easy hikes.

That’s where Claude Code came in. (Same tool I used to plan the garden. I keep finding new things to hand it.)

I didn’t come to it with a workout plan. I came to it with a problem. I told it where I was going, what the hikes were going to demand, and the exercises I was actually doing right now, and I asked it to help me figure out the honest gap between the two. Not the plan first. The reality first.

Then it built the plan.

It mapped out the weeks I had before the trip and put specific strength workouts on my calendar, the kind that actually matter for climbing hills with a pack. It found hikes within an hour of my house that fit what I needed, and it sequenced them so each one was a little longer or a little steeper than the last. The point was to build me up gradually so the Dolomites wouldn’t be the first hard thing my legs had seen in a year.

Here is the part that’s on me, not the tool. I did not follow the plan perfectly. I skipped workouts. Some weeks I did a lot less than it asked. The plan was good. My execution was, let’s say, human. It would be easy to write one of these posts like the tool waved a wand and I showed up to Italy a mountain goat. It didn’t, and I didn’t. It built me a great structure. I was the one who had to do the reps, and I didn’t always do them.

So I got on the plane genuinely unsure how it would go.

The first day was hard. Really hard. I spent most of it convinced my training hadn’t been enough, that I’d skipped one too many workouts and was about to pay for it for the rest of the week.

Then the second day happened.

It was a longer hike, at higher altitude, with more elevation gain than day one. And I did all of it with a huge smile on my face. That’s when it clicked that day one wasn’t about my fitness at all. It was the altitude. I just needed to acclimatize. Once my body caught up to the elevation, the training was there. I could feel it.

After that I did everything. Every hike on the itinerary, all five days. The big one was Tre Cime di Lavaredo. Three enormous stone towers with a trail that wraps around them and the view changing the whole way. It is, hands down, the most beautiful hike I have ever done. I stood at the spot where all three peaks line up and could not believe I had almost talked myself out of trusting that I could get there.

Here’s what surprised me, though. The part of the trip I wasn’t ready for wasn’t a mountain. It was Venice.

My partner is a city person. Every trip he’d ever taken was a city trip. This was his first hiking trip, the first vacation he’d ever had to train for, so we were both a little out of our element. He had to learn the mountains. I had to learn the city. We added a few days of Venice onto the end, a heat wave rolled in, and I realized I had no idea how to actually do a city. My whole style is to go hard for six or seven hours and relax at night. Wandering a sweltering city all day, no summit, no plan, was its own kind of hard.

What worked was hub and spoke. Two hours out, back to the air conditioning to recover, then out again. Relax in pieces through the day instead of saving it all for the evening.

Which, now that I write it down, is the same thing the training plan did. Take a big intimidating thing and break it into smaller pieces with recovery built in. Each hike a little longer than the last. Two hours of Venice at a time.

What this taught me about AI as a tool

This is why I keep encouraging people to experiment with Claude Code (or Codex, Gemini or whatever you have available). For me, it has been exceedingly good at turning something I’m intimidated by into a clear, sequenced, doable plan. It cannot do the work for me. It was never going to lace up my boots on a Tuesday when I didn’t feel like it. But on the days I did show up, I knew exactly what to do, and the days added up, even with the ones I missed.

I went a year without a real break, wasn’t sure my body still remembered how to do this, and stood on top of the prettiest hike of my life anyway. The plan got me to the trailhead ready enough. The rest, mountains and heat wave both, I figured out two hours at a time.

He describes what he calls the human sandwich. A human frames the task, AI does the work, a human judges the result. And one line stopped me: the frame is not the framer. The model is brilliant inside the frame. It does not build the frame.

That was the aha. I’d been feeling it every day without being able to say it.

I lead talent at a biotech company. For the past year I’ve used AI every day, and I’ve built a lot of my own tools with it to do my work. Some of them work beautifully. Others I built, used twice, and gave up on. For a long time I couldn’t tell you why one and not the other. This article crystalized that why.

Use AI when the output is verifiable

AI is extraordinary at doing the work once a human has decided what matters. It is not going to decide what matters for you. If you can confirm it’s true, AI can not only take the steps you took, it can take the action too. If correctness is a judgment with no answer key, that part stays yours.

The cleanest example I have runs every day at five o’clock. It’s a skill, which is just a specific list of steps I’ve written out for the AI to follow. It reads through my meeting recordings, pulls out every task and commitment I made, and files each one where it belongs. I used to do that by hand. Usually late, usually half of it lost. Now the tasks are just captured. I read the output, and most days it’s right. It works because I had already decided what I wanted: which recordings to read, what counts as a task, where each one goes. I wrote the steps. AI runs them. And I can check it in a minute, because each task either landed in the right place or it didn’t.

My ah ha moment: coding and knowledge work using AI are more the same than different

This is why everyone keeps telling you AI is incredible at coding. Code is about the most verifiable thing there is. It runs or it doesn’t. It passes the tests or it fails them. The models got so good at it precisely because correctness could be checked automatically, over and over, with no human needed to judge each answer. My five o’clock skill is the same idea in a much smaller package. The work is checkable, so AI can do it.

That line is the whole game, and most of the confusion about AI comes from being on the wrong side of it.

Some people decided years ago that AI wasn’t very good, and I understand why. They asked it to draft an email, and it came back sounding like nobody they’d ever met. Too formal, weirdly padded, full of phrases they would never say. So they rewrote the whole thing themselves, which took longer than if they’d just written it, and they walked away sure the tool was useless. I don’t think they were entirely wrong. Hand AI something that runs on your voice or your judgment, give it nothing to go on, and you get back something you have to redo. Honestly, there are still plenty of times I’m rewriting what it gave me anyway.

My experience ran the other direction. AI turned out to be a great thought partner, and the better the models got at long, multi-step work, the more I leaned on it for the hard calls. But over time I realized the strategy was still mine. AI gave me more data than I could gather on my own and more angles than I’d have thought of, and it would pressure-test a plan until it bent. It never once handed me the strategy. That’s the part a human has to decide. And that’s the part I’ve come to feel most secure about. Every model got better this year, and the call about what we should actually do has stayed exactly where it was. With me.

Four examples where AI shines for knowledge work

1. Multi-step processes across your tools. Check the calendar, read the notes, scan the Slack threads, pull it all into one summary that connects the dots. The newest version of this doesn’t just report back, it takes the action, as long as it understands what the action should be and the result is something you can verify. This is also the easiest place to start. Have AI read your calendar and tell you what’s on it. Then have it read your notes with a person so you walk in current. Then let it track the Slack threads too, so the whole history of someone sits in one place without you typing a word.

2. Making sense of a pile of disparate data. This is the one people get backwards. AI will not build your strategy. But hand it a mountain of data and it will find the connections you’d never have the hours to find yourself, and that is real fuel for the decision. The distinction matters: AI is the analyst, not the decider. It surfaces what’s in the data. You decide what to do about it.

3. A researcher. When there’s something I don’t understand yet, I can send AI to go research it and bring back what’s already out there, organized, so I can fold it into the decision. I did exactly that for this post. Halfway through writing, I asked it to check whether my verifiable idea actually held up, and it came back with a name for it and the research behind it in about 5 minutes. I didn’t have that language an hour earlier. What to make of it was still up to me. (I’d talked this whole post out loud first using Monologue, another tool the Every team built, before I wrote a word.)

3. As a thought partner, though not the kind that thinks for you. The kind that thinks against and with you. You can tell it to push back, to poke holes, to argue the side you don’t want to hear. You can even stand up a whole board of advisors, each with a different lens, and run a decision past all of them before you commit. I do this constantly.

Why expertise can’t just be outsourced to AI

If you’re an expert at something, this is the part that should make you excited instead of nervous. Once you’ve decided on a strategy and how to carry it out, AI is remarkable at the carrying out. You turn the plan into a set of steps, AI runs the ones that don’t need you, you check the output, and you move on. You’re still needed. You’re just no longer the one doing the work that never needed your expertise in the first place. That’s not a tool that replaces experts. It’s a tool that frees them to point that expertise at the next problem.

Which brings me back to the part of my job that’s actually my job. The framing and the judging. The part with no answer key.

The rest of it, the capturing and the connecting and the running of processes I’ve already designed, I’m thrilled to hand off. It was never the part I wanted to be doing at five o’clock anyway.

I can give it my meeting notes, the systems we use, running agendas and every half-formed idea I’d dropped in a doc over the course of a project. And it would pull all of it into one place that actually made sense. Not a summary that flattened everything. A real synthesis, with the threads connected.

I’m a data nerd, so I kept going. One more source, one more layer, one more cut of the analysis. The artifacts got bigger and more useful, and I was proud of them.

I want to be clear that I didn’t just take what it handed me at face value, and you shouldn’t either. The value wasn’t that it did the thinking for me. It was that it surfaced connections across sources I wouldn’t have spotted on my own. I’d go back and forth with it a ton, pushing and correcting, until the output was something I actually agreed with and could stand behind.

It was still way too big to share.

I had this giant, genuinely valuable thing. It made complete sense to me. But to hand it to anyone else, I was basically asking them to spend an hour reading something so they could get to the one decision I actually needed from them. The detail that made it valuable to me was the same detail that made it unusable for them.

My first instinct was to solve the wrong problem. Someone in my company had figured out how to let people comment on artifacts and store the comments in a google sheet. I thought this was awesome. Then I stepped back and realized that handing someone a behemoth and inviting them to comment on it isn’t a kindness. It’s still asking for their hour. I’d made the giant thing easier to respond to without making it any smaller. That wasn’t the fix. That was me being unwilling to cut.

The aha was almost embarrassing in how obvious it was. I could ask AI for help with this part too. Not just the building. The backing-off.

What AI helped me build

Formation Bio has a communications toolkit. It’s a real thing we’ve thought hard about: how to share an idea, how to make an ask, how to give someone what they need to support you without burying them. There’s a structure to it. Lead with the takeaway. Say why it matters. Give only the context this specific person needs. Make the ask explicit. Point to the detail without forcing it on anyone.

I gave that toolkit to Claude Code as context. And together we built a skill I’m calling Distill.

Here’s what it does, and the heart of it isn’t the writing. It’s the interview. I point it at one of my big sprawling things, a long doc, a deck, a pile of notes. Before it writes a single word, it asks me questions, one at a time. Who is this for? What is the one thing you want from them: a decision, feedback, or just awareness? What do they already know, so we don’t spend their time re-explaining what they already lived through?

How this helped me zoom out

Answering those questions is the actual work. Half the time I don’t know the answer until it asks. I’ll catch myself about to send something up to “leadership” without having decided whether I want a decision or just a nod. The questions force me to figure out what I need before I figure out what to say.

Only then does it produce the short version. The takeaway up top. The why. The few points that earn their place. The ask, with a date if there is one. And a link to the full detail, so nothing I built gets thrown away. It just gets moved behind a door instead of dumped on someone’s desk.

And that first question is the one I’d always skipped. When I’m building, the honest answer is me. I’m building for my own understanding, and that’s fine. That’s why the work is good. But the shared version has to be built for the person on the other end, and those are two different jobs.

The skill made me realize the second job is the harder one.

Adding is easy now. AI made it almost free. I can generate more context, more analysis, more pages than anyone could ever want, in minutes. The scarce skill isn’t production anymore. It’s deciding what to leave out. It’s knowing that the leadership team doesn’t want my methodology, they want my recommendation, and being disciplined enough to cut the rest even though I’m attached to it.

I’m not naturally good at that. My reflex is the opposite. So I built something that runs the move for me, using a standard the people I work with already know how to read.

The part I didn’t expect is what it does for my own work. When I distill something down to the takeaway and the ask, I can suddenly see where the project actually stands. The short version tells me what I really decided and what I still owe. Backing off the detail isn’t just how I share the work. It’s how I figure out where to go next.

You should build this for yourself

None of this is specific to me, or to the tools I happen to use. If you don’t have a communications template or a toolkit, build one. Write down the structure you wish people used when they shared things with you. Then give it to whatever AI you already work with. Go build your big thing, using all the context and data you finally have access to. Then do the harder part. Make it usable for the people you want to share it with.

I spent a long time getting good at building big things. It turns out the skill I was missing was making them small.

This content is much more relavent for engineers and product leaders. I am not either of those. I run recruiting at an AI native biotech.

I keep going back to these sources because I trust them. The people in them are actually using the tools. They show their work. When something doesn’t work, they say so. That’s not what I get from most of the AI content on LinkedIn or TikTok, where someone is usually selling a course or a vibe.

But there’s a layer of work underneath all of that, and it’s the thing I wish someone had named for me earlier. I think of it as translation.

What I mean by Translation

A podcast episode will get into how to wire up an agent that ships pull requests to production. A YouTube tutorial will walk through scaffolding an app with three MCP servers. An Anthropic engineer will post about refactoring a TypeScript repo with Codex.

I do have a GitHub repo. I do deploy things to Vercel. I just don’t do it for everything, and I can’t always tell which side of the line a given idea belongs on. Sometimes I wish someone would tell me “this one is worth a repo” or “this one is a script you run once and throw away.” That call is part of the translation, and nobody’s making it for me.

So when I hear “you can wire Claude up to your data with MCP,” I’m not thinking about clean architecture. I’m thinking “can I stop clicking through five Greenhouse screens to update a custom field on twelve open roles.” And then I’m thinking: is this a Claude Code skill I run from my terminal, or is it a small app I deploy so my team can use it too. Those are different answers and I usually figure it out by trying the wrong one first.

That’s the translation. Coder-source says: build this app. I hear: maybe I just need a script. Coder-source says: deploy this agent. I hear: maybe I just need a skill in Claude Code that runs once a week. The mental model the coder content gives me is built for shipping software to other people. The mental model I need is some mix of that and using software on myself, and I’m doing the mixing in real time.

The part that trips up people when you’re starting out

The most trustworthy content right now is made by and for people who write code. If you’re not one of those people, you don’t know going in that there’s a translation step. You just hear “agents,” “MCP,” “deploy,” and assume the gap between what they’re doing and what you’d do is bigger than it actually is. The translation step is invisible until someone tells you it exists.

The non-coder content that does exist hasn’t filled the gap. There’s a version of an AI marketing post that promises a campaign that will reach everyone and get them to respond. In theory I could translate that into candidate outreach. In practice the output is clunky, it sounds like AI, and no recruiter I know is actually going to send it. I trust the engineer talking about how she uses Claude Code at work more than I trust the LinkedIn post telling me AI will write my outreach for me, even though the engineer’s example is further from my day-to-day.

Where it gets a little easier (for me)

The one place I do this alongside other people is a community called PromptMates. It’s other recruiters and recruiting-ops people who are figuring this out for our function. They’re not coders either. They’re the ones who help me translate, and most of what I get there is “here’s how I solved a thing you were already trying to solve.” It’s not where I spend most of my AI time, but it is where the translation gets easier.

I want to be clear about what I’m not saying. I’m not asking anyone to make the coder content easier. I don’t want the AI Daily Brief to slow down. I don’t want the Anthropic engineers to stop talking about how they build agents. If you flatten the content, you lose the thing that makes it trustworthy.

I’d like to hear how other people do this

What I am saying is that the translation is a real skill, and it’s mostly invisible until you’re already doing it. I’d like to hear from people doing it in other corners. Not engineers translating for engineers. Marketers, finance leads, ops people, lawyers, anyone who is listening to the coder sources because the coder sources are the most honest, and then sitting with the question of what any of it has to do with their actual day.

What do you skip? What do you save for later? How do you decide a tool is worth a Saturday morning instead of “cool, noted, moving on”? When do you bother spinning something up properly, and when do you let it stay scrappy? Where do you draw the line between “this is real for me” and “this is interesting but not mine”?

I have a Google I/O backlog I haven’t touched. I’m still trying to get fluent in Claude Code and dipping into Codex when I have an hour. I know there’s more out there than I can absorb, and I’ve made peace with that.

I’ll be on a walk. The Daily Brief is already queued up.

That’s the point.

I work in recruiting. I am not a software engineer. And in the past year, I’ve built systems with AI that save me hours of work every single week. If you think AI is only for engineers and product people, you’re wrong.

I want to say that clearly because I keep meeting smart people in non-technical roles who watch their engineering and product teams build impressive things and conclude the AI conversation isn’t for them. It is. Let me show you what it looks like for me.

The fundamentals are the same

This week on LinkedIn I shared the explainer Claude made me of How AI Systems Are Built.

My Version Of This

I’m in meetings most of the day. Some are interviews. Some are 1:1s. Some are team meetings. Some are strategy meetings. Every one of them gets recorded. By the end of the day there’s a stack of transcripts and there is no way I can hold all of it in my head.

So at the end of the day, my meeting review runs. Every day at 5pm. I don’t have to remember to start it.

It pulls every transcript. It pulls out the action items. The things I committed to. The things someone else committed to. The thing someone said about a member of my team that I want to share with them when I see them Thursday. The note about a candidate’s preferences. The thing about an open role that I need to flag to my team.

Then it organizes everything for me. Tasks lined up for Obsidian. Follow-ups flagged. Playbook updates queued for the people I meet with regularly, so when I sit down with them next, I already have our recent history.

When the system finishes organizing, a triage view pops up for me. I walk through it item by item. Some are just reminders of what I was already going to do. Some are things I need to flag to a teammate that I would have lost in the noise. For each one, I decide what to do. Send now. Wait until Thursday. Push to Obsidian as a task. Drop it.

The system helps with that decision too. Before it flags something for me to send to someone, it checks Slack to see if I already mentioned it. That’s the kind of check I might have skipped on my own. Now I know whether I’m following up or repeating myself.

Here’s the flow:

A big note: This was not the V1 of this.

This is the version I run today. It took several rounds of iteration to land here.

This saves me hours every week. Hours I used to spend trying to remember which meeting that thing came up in. Hours I used to spend re-reading notes I’d already taken. Hours I used to spend worrying I’d missed something important.

It also lets me show up the way I want to show up. When I meet with someone on Thursday and I remember the specific thing they mentioned last week, that’s not because I have a great memory. It’s because the system caught it and routed it back to me at the right moment.

When a candidate’s name surfaces in a 1:1 and I already know where they are in the loop and what the last interviewer flagged, that’s the meeting review working.

When I keep a thread alive across weeks with someone I check in with, because the playbook captured what mattered to them and what we’re tracking together, that’s the same thing.

Why this is a huge unlock for me

This is big part of what the job of being a leader is. Making sure the right information reaches the right people. Making sure what we’re doing aligns to our strategy. Making sure the things I hear in meetings get tracked and acted on and not lost. AI is genuinely good at all of that.

My chief of staff brief opens my day. My meeting review closes it. Both run on schedule. I don’t have to remember to trigger either one. They give me my time back. They let me feel on top of my work instead of buried under it. I am extremely proud of both of them.

The operators in my company are using AI to extend their reach. I’m using AI to be a better leader. Both are real uses. Both are valuable. They’re just different.

What I am doing with the time I get back

The hours my meeting review saves me don’t disappear. I’m using them to chip away at the more ambitious builds I want. The kind of work I saw our product manager and VP of data science doing. Agents I want running on a schedule, not just when I sit down to do them. Agents that talk to each other and pass context back and forth. I build these little by little, in the spare time I get. I don’t get a lot of it. That’s okay.

So if you’ve been watching engineers and product people work with AI and assumed that’s not for you, please reconsider. I’m not asking you to build what they’re building. I’m asking you to look at the job you actually do and find the version of this that fits it. It exists. You just have to start.

When AI does something that feels like magic, it changes how you look at everything else on your plate. You start scanning your to-do list differently. Can AI help with this? Could AI do this entirely? Could AI do this better than I would? That change in thinking is real and valuable. It’s how you find the workflows that actually change how you work. But the same instinct that helps you discover the right AI applications will also push you toward the wrong ones, if you let it run unchecked.

The Deployment Cost

Every AI task comes with overhead that most people undercount. I think about it in three phases.

The first is setup: connecting the system to your data source, writing a prompt that actually captures what you want, dealing with authentication issues, configuring outputs. For a well-scoped, repeatable task with clean inputs, this is a one-time cost you pay once and amortize over every future run. For a one-off task with messy inputs, it’s a sunk cost you’ll never recover.

The second is iteration. AI outputs rarely land perfectly on the first pass. You prompt, review, adjust, re-prompt. This is fine, expected even, when the task is well-suited to the format and the inputs are solid. But iteration compounds fast when the underlying conditions aren’t right. One bad data connection, one ambiguous prompt, one edge case you didn’t account for, and you’re adding rounds of back-and-forth that weren’t in your mental budget.

The third is verification. Before you add anything AI-generated to a regular workflow, you need to check it. This is often the phase people skip, and the one that causes the most pain later. The real question is how long the check took. That verification time is part of the deployment cost too.

Sometimes that total cost is trivial. Sometimes it’s worth paying many times over for what you get. And sometimes you’re spending an hour of overhead to avoid fifteen minutes of work. That last one is the trap.

The Artifact That Taught Me

Last week I was building an artifact to document the current state of roles for a particular department. The output needed to capture nuance: how responsibilities were distributed, where there was overlap, what wasn’t formally defined but functionally existed. I knew what I was looking for. I figured AI could help me get there faster.

What I didn’t account for was that this wasn’t a task with a template or a playbook behind it. It was something new, which meant the model didn’t have the context it needed to get it right on the first try. Why would it? I hadn’t given it enough to work with. So every iteration required more explanation, more correction, more back-and-forth to get the framing right. Nuance isn’t something a model figures out automatically from a prompt. It has to be surfaced, explicitly, through context you provide or through rounds of iteration that force you to articulate things you hadn’t quite articulated yet.

Two hours later I had a decent artifact. I also had a version I could have built in thirty minutes that would have gotten the same job done.

I had optimized for what the output would look like before I asked whether AI was the right tool for this particular job at this particular moment.

The Filter I Use Now

The filter I use now starts with one question: is this a task I’m going to do more than once?

If yes, a playbook is worth building before you build anything else. A playbook isn’t complicated: it’s the context, structure, and parameters that give the model what it needs to get it right without a dozen rounds of correction. What’s the source data? What format do you want? What are the edge cases that trip it up? When you front-load that thinking, you start from a higher floor. Verifiability is still part of it, but your confidence on the first pass is higher, not because the output is always right, but because you’ve already worked out what right looks like.

If the task is one-off, the calculus changes. It might still be worth it, but only under one of two conditions. Either the source data is clean enough that the model has what it needs from the start, or you treat the session itself as a playbook draft, so even if you only do this once, you leave with something reusable for the next time something adjacent comes up.

What I was doing before was neither. I walked into sessions with messy inputs, no template, and the expectation that AI would figure out what I was trying to build. Sometimes it did. More often I was burning time I hadn’t accounted for and producing outputs I had to redo anyway.

The Pattern You Build

I truly believe you have to use AI badly in order to develop the judgment to use it well and that this is very much worth doing. The shift isn’t really about getting more cautious. It’s about asking a different question upfront.

Not: can AI do this?

The better question is: how do I set this up so it’s actually worth it? Clean source data. A playbook if you’re coming back to this task. A clear sense of what right looks like before you start. Those aren’t extra steps. They’re the reason the session goes well.

When I started building, everything looked like an AI opportunity. That’s still mostly true. I just know now that the opportunity isn’t just the task. It’s building the structure that makes the task worth doing with AI.

Not a person. A system of AI agents that does what a chief of staff does. Surfaces what matters before I ask. Prepares context before meetings. Monitors things I can’t watch myself. Flags when something needs my attention and knows when it doesn’t.

I’ll say upfront: this is the hardest thing I’ve built. Not hard to describe, but genuinely difficult to get right. I’m still getting it right.

But I’m here. And the path here is clearer than it looks, because there are levels, and believe it works best if you go through them in order.

I tried to skip them at times and the result was usually that I built something that technically ran but wasn’t actually usable. The levels aren’t arbitrary. Each one builds the intuition and the infrastructure you need for the next.

Also: I got the idea for this post after reading someone else write about levels of AI work. Their levels looked different from mine. That’s kind of the point. The specific levels will vary depending on what you do and what tools you have access to. The progression is what I think is worth seeing.

I thought it could be useful to share my map, at least so far.

Level 1: Chat

You bring everything to the model. It gives you back words.

You open a window, type something, read the response. You might paste in a document or a transcript to give it more to work with. You’re still doing the lifting: bringing information to the model, deciding what to ask, moving the output somewhere useful yourself.

This is where most people are. I started here too. Job descriptions. Interview questions. A paste-heavy workflow that was genuinely better than what I’d been doing before. That was enough.

Level 1 teaches you what the model can do. You develop an instinct for how to frame a question. Don’t underestimate it. You need that instinct before any of the later levels make sense.

Level 2: Connected data

The model reaches into your systems directly. You stop copy-pasting.

For me, this was Greenhouse and Fireflies connected through an internal integration at my company. Instead of copying and pasting candidate data into a chat window, I could ask questions about live data and get real answers. The model wasn’t smarter. The information architecture was different.

It changes what questions you can even think to ask. Before, calculating our average time-to-hire meant pulling offer dates from Greenhouse, application dates from a different view, job open dates from somewhere else, and then doing math in a spreadsheet. Now I ask Claude to run the query against our data warehouse and I get a number in a few seconds.

That’s what Level 2 actually changes. Not just how you access data. What data you bother to look for.

This level requires real setup: an API connection, an MCP integration, something that pipes your systems into the model’s reach. That’s the work of Level 2. But once it’s there, it’s there.

Level 3: Automation

A process that runs on its own, on a schedule or a command, without you initiating it each time.

Things run without you triggering them.

My morning briefing runs before I open my laptop, pulling calendar updates, pipeline changes, and relevant Slack threads into a summary I can read in two minutes. That’s the scheduled version. There’s also the command version: before a 1:1, I type one line and it checks Slack for relevant threads, scans my email, finds the last agenda doc from Drive, and tells me what I need to know walking in. That used to be ten minutes of switching tabs. Now it takes about thirty seconds.

Another one I use every week: my team has a Monday recruiting sync. Before I built the automation, I was pulling context together manually on Sundays: what closed last week, what moved in the pipeline, what came up in Slack. Now it runs Friday afternoon. It queries our pipeline data, scans the relevant Slack channels, pulls Fireflies summaries from the prior week’s meetings, and puts a structured prep into my calendar for Monday morning. I walk into that meeting already knowing what I need to know.

The shift at Level 3 is going from “I use AI when I think to” to “AI runs whether or not I think to.” The work you built at Level 2 starts working for you in the background.

Level 4: Agentic

You give it a goal and the tools to act on it. It figures out the steps.

The model decides what to do next based on what it finds. Not a fixed sequence you designed. Actual reasoning about what to look at, what to query, what to do with the output.

I asked Claude to build me a live view of my recruiting pipeline across all our open roles. I didn’t say which API to use, how to handle pagination, or how to filter out the test jobs and contract roles mixed in with the real ones. It figured all of that out. By the end of the session I had something I could open in a browser that showed me exactly where candidates were sitting. I described what I wanted. The model navigated.

It works for research too, not just building. I wanted a competitive landscape of companies hiring in AI drug development. I asked Claude to research them. I didn’t give it a list, a category definition, or a method. It had to figure out how to define the space, how to categorize the companies it found, and how to verify the data. It ran parallel searches, hit dead URLs and found working ones, flagged where headcount data was unreliable, and came back with a structured set of 11 companies organized into three sub-categories I hadn’t thought to define myself. I would have spent an afternoon on that. It took one session.

Level 4 requires you to be comfortable with the model having some autonomy. That comfort comes from Levels 1 through 3. You need to know how it reasons, where it gets confused, when to trust it. You don’t get that from reading about it.

Level 5: Orchestrated agents

One agent coordinates the others. It decides who runs, what each one sees, and how their outputs get combined.

Multiple agents working together, with something coordinating between them.

This is where the chief of staff idea lives. Instead of one agent doing everything, you have specialized agents: one for calendar context, one for Slack threads, one for the hiring pipeline, one for pulling action items from recent meetings. An orchestrator decides which ones to run, in what order, and what to pass between them.

At this level, you start thinking about things you didn’t have to think about before. Tokens. Context windows. What each agent actually needs to see versus what would be noise. How to hand information between agents without losing what matters. It’s a different kind of problem than the earlier levels.

I’ll be honest: this is hard. The earlier levels have tight feedback loops. Try something, see if it works, adjust. Orchestrated agents have more failure modes and the feedback is less immediate.

But it’s reachable. I’m here.

Why I’m sharing these now

The thing I’d want anyone reading this to take away is that the levels are real. You can’t shortcut them. I tried, early on: built something multi-step before I understood how the model reasoned, and it ran in circles and eventually fell apart. Knowing what Level 3 feels like is what makes Level 4 make sense. You need the intuition from each level before the next one clicks. Also, I’d like to give a huge +1 to “plan mode” in Claude code, especially as you advance through different levels. This was another recommendation I received. It slowed down the prep, but it made the outcome more accurate.

If you’re at Level 1, that’s not a stepping stone you’re rushing past. It’s where you build the instinct.

The chief of staff is still a work in progress. Most ambitious things are.

The dominant messages are urgency and fear. AI is going to wipe out all the knowledge work jobs in the next 2 years. Use it, but also be aware that eventually AI won’t need you either. There’s a version of this argument that says even if you adopt it now, the adoption only delays the inevitable, because the tools are going to keep improving until the humans in the loop are simply unnecessary. And, by the way, everyone is already way ahead of you.

I think these are the wrong frames. I don’t think they lead to helpful actions and more than that: I don’t think they are accurate.

What I actually experience when I use it.

What AI does, in my experience, is lower the activation energy to act on the ideas you already have.

I have had ideas for years. Tools I wanted to build. Automations that would make my work more predictable. Reports and dashboards that should exist since the data was there, but were too clunky to bring to life without friction. Then there are the things I wouldn’t have even considered attempting because the gap between the idea and the finished thing felt too wide. The cognitive overhead of figuring out where to start, learning a new tool, writing code I wasn’t sure would work was enough to keep most ideas in the “someday” category indefinitely.

That overhead is mostly gone now, which is incredible. I describe what I want, we work through it together, and things get built. Things that would have required a developer before, or more likely would have never happened at all.

Ideas realized lead to more ideas

I believe that what happens once something is out of your head and working is that more ideas come. Your brain has room again. You start noticing the next friction, the next thing you’ve been tolerating. And then you build that too.

It compounds. The more you act on ideas, the more ideas you have. I don’t think AI created that loop. I think it finally made it accessible.

The fear narrative assumes that what’s being automated is the work. What I’m finding is that what’s being reduced is the resistance to starting. I believe that if I’m experiencing this, other people are too. The excitement of building something successfully drives me to be more ambitious in the next build, to push the limit of what I thought I as capable of.

Humans usually get used to improvements, so this idea that improving things with AI will lead to us stagnating exactly where we are, but with AI doing the heavy lifting, just doesn’t resonate. Human nature is to create after all.

What about knowledge work?

I know not every job works like this. Some roles are largely about retrieving and applying knowledge on demand, and that’s probably where the displacement risk is most real. I’m not going to wave that away.

But there’s a category of knowledge work I think people are seriously underestimating: the knowledge that lives inside organizations. The institutional understanding of what customers actually need, what’s been tried before, where the friction is, what the company is actually good at. Right now, that knowledge is largely locked in people’s heads. Scattered across meeting notes, Slack threads, years of accumulated context that never got written down anywhere useful.

What AI is going to do is help connect that knowledge. Synthesize it. Help surface what a company should focus on next in ways that currently take years of accumulated context to do manually. The people who hold that context, who can frame the right question and evaluate the answer, are still going to be necessary. More necessary, maybe, because the synthesis becomes possible at a scale it wasn’t before.

I also think we’re going to see more builders. The gap between “I have an idea” and “I built the thing” is narrower than it has ever been. Not everyone needs to start a company. But a lot of people are going to try things they never would have tried before, because the barrier to starting is so much lower. That tends to create more work, not less. More ideas become real things, which means more real things need people to run them, grow them, and decide what they should be.

One more thing: AI isn’t free.

Right now, these tools are heavily subsidized. The pricing doesn’t reflect the actual cost of compute, which is both enormous and constrained. It’s a bit like early Uber, when rides were cheap because cheap was how you got people to adopt. Eventually the economics normalize. And when AI stops being close to free, the math on replacing a person with a tool gets more complicated than the current headlines suggest.

The fear narrative treats today’s pricing as a permanent feature. It probably isn’t.

Try curious instead.

I came to all of this with curiosity, not dread. That’s just how I’m wired. But I think curiosity is the more useful orientation here, not just the more comfortable one.

The fear framing puts you in a reactive posture. You’re adopting tools because someone told you to, trying to stay ahead of a threat you can’t fully see. That’s exhausting. And it tends to produce shallow engagement with the tools themselves, because you’re focused on not falling behind rather than on what you’re actually trying to do.

Curiosity is different. You’re asking: what do I wish was a little easier? Where do I lose an hour every week to something that shouldn’t take an hour? What’s the thing I’ve been meaning to fix but haven’t because it felt too complicated to start?

Start there. Hand it to AI. See what happens. Once you’ve done it once, you’ll do it again. And the ideas you have after that first win are yours. AI didn’t generate them. It just got something out of the way so you could.

In my field, what I keep finding is that more is possible than I thought. More tools, better processes, and further down the line, more drugs reaching patients who need them faster.

That’s not the story the news is telling. But it’s the one I’m living. Could I be wrong? Absolutely. But so could the people who are fear mongering and I’d rather trust my lived experience, at least for now.

I didn’t understand any of it. I didn’t know what HTML was. I didn’t know how email actually worked. I learned how to make a website later, in a class. By then it was already easier than it had been the year before.

That’s how I waited out the internet. Not on purpose. I was a kid. By the time I was paying attention, the tools had gotten friendlier, and I caught up without much friction. No repercussions. Just a slower entry into a world that ended up being fine.

A lot of people are wondering if they can do the same thing with AI. Will the dust settle, the way it did with websites and email? Will I be able to pick this up later, when it’s easier and the buttons are clearer?

So can you wait?

I get the instinct. It worked once. And being a beginner is exhausting. I’ve been one a hundred times in the last year. I’ve sat at my desk at 11pm trying to get something to work, then deleted the whole thing the next morning and started over. There’s no version of this where you skip the awkward part.

But here’s what I’d say to anyone weighing it. Start now. Not because I want to scare you into thinking you’ll fall behind. Not because I think you should do it to keep your job. There’s truth to both, and they’re not the reason.

The tools will get easier. You’ll figure them out. The part you can’t catch up on is the year of stumbling around that builds the instinct for what’s possible.

AI was a party trick at first.

When I started a year ago, AI felt like a party trick. I’d ask ChatGPT to write a job description and the result was kind of cool, but it didn’t fit into anything I actually did. I couldn’t repeat it cleanly. It didn’t connect to my data. It wasn’t part of a workflow. It was a demo, and demos are fun for about ten minutes.

A year of fumbling later, I think about all of it differently. I think about workflows. I think about what “agentic” actually means in practice, which is AI taking real steps on its own toward something I asked for, instead of just answering the prompt. I think about parallel agents running quietly underneath the surface, finishing tasks I’d otherwise be clicking through, so I can spend the saved time talking to people. None of that vocabulary meant anything to me a year ago. Some of it didn’t exist yet. But I can think in those terms now because I started bad and kept going.

That’s the compounding piece. The beginner knowledge stacks. Each small thing you build makes the next thing easier to imagine. And as your imagination grows, the size of what you try grows with it.

I’m still a beginner.

We have an idea of what our talent function could look like with AI doing real work. Knowing where every applicant comes from. Telling us if those are the companies we should be hiring from. Pointing out where our sourcing needs to sharpen. The vision is clear and it feels enormous. We don’t know the exact shape it will take. We don’t know if we’ll get all the way there.

What I do know is that the small things I’m building now are how we’ll get there. Each one teaches me something about what comes next. If I hadn’t started a year ago, this vision wouldn’t make sense to me even as a vision.

The longer I sit with being a beginner, the bigger I let myself imagine.

It’s also fun.

I didn’t expect it to be. There’s a particular feeling when something works the first time. When an agent does what you described. When a script you didn’t know how to write last week is now sitting on your desktop running. It feels like magic. The literal kind, where you didn’t quite believe it would work and then it did.

That feeling is the part you can’t get by waiting.

A few weeks ago I asked Claude to help me plan our garden. This weekend I planted it. There are little starts out there in the dirt now, doing whatever little starts do. I get to watch them bloom because I started.

The AI work feels the same. The small things I’m building right now are the planting. The blooming comes later. But it only comes if I start now.

The internet was fine to wait out. I’m planting this one.

That was the thing I kept hearing at the end of the week, in some version or another. “I came in thinking I couldn’t do this. I’m leaving having done it.”

The structure

The three days were called AI Accelerator Bootcamp. It was a block of time to make a thing that might actually change your job. We have an in person week once per quarter and we used it entirely for this purpose. A true investment in our team’s ability to use AI in our work.

The tech team spent weeks getting us ready. Two weeks before we started, they sent out setup artifacts for Claude Code, GitHub, and Vercel, so we walked in with the tools to build and launch an app instead of spending day one figuring out what to install. They broke us into teams of six to ten people, each with a builder lead and two tech people dedicated just to our team.

Builder leads did their own version of prep work. Justin Frick, Recruiting Manager on the talent team, was ours. He made sure each of us used the ideation tool in time to walk in with a real project. He also built most of his own stuff ahead of the bootcamp, so during the week he could focus on helping the team instead of his own backlog.

Sessions went crawl, walk, run (a phrase we use a lot at Formation). We started in ARK, our MCP hub, where you can build something useful in a chat interface without writing code. Then we moved into Claude Code. This was smart. Starting in Claude Code could have scared people off. Starting in ARK gave us a win we could feel by the first afternoon.

A bootcamp without that scaffolding is just a week where a bunch of people try and fail.

What my team built

Justin Frick built a Slackbot called the Greenhouse Gnome that reminds people to fill out scorecards, and if they don’t, adds a 15-minute calendar block so it actually gets done. And a talent mapping tool that pulls from our search and evaluation pipeline to research companies working on drugs and indications similar to ours. It creates boolean search strings to map talent ahead of the deal. He also built two games.

Brian Tesser built a dashboard that pulls a year’s worth of scorecards and interview transcripts and measures how well our interviewers are catching values signals. We recently trained our interviewers on listening for values. Brian’s dashboard tells us whether the training actually stuck, and who could use more support. Training without measurement is a guess. This makes it evidence-based.

Lucy Psaltis built a tool that auto-schedules kickoffs. In our process, when the first batch of candidates move to the interview, the team meets and has a kickoff so everyone is clear on what they are evaluating. Her tool finds time on the team’s calendars and flags if someone has OOO coming up, so we can think about alternates before we’re scrambling. She also got an in depth understanding of how webhooks work.

Glenice Gallagher built Form-E, a hiring sidekick that lives in Slack. You type /new-role, answer a few questions about the job, and Form-E notifies Glenice to open to the role in Greenhouse and drafts a hiring plan for Glenice to review before it goes to the hiring manager. Human in the loop, no wasted cycles. She also built a tool tracker artifact that flags the cost of each tool we use, when the renewal is up and links to the contract.

I built an MCP

My build wasn’t as cool looking, but I learned a ton. For the past year I’ve been using MCPs, not building them, because building them looked like the kind of thing you need to be an engineer to attempt. What this looked like in practice at the bootcamp was that I cloned a repo of another MCP our team had built, followed what Claude Code told me, and asked our tech team questions when I got stuck (to be honest here, I got stuck quite a bit). That’s the whole story. But it was still the first time I’d built one instead of just using one. And it felt pretty cool.

About the fact this happened at all

There is something worth saying about the fact that Formation did this. Our company didn’t buy us a training course or hand out a subscription. They cleared three days of our calendars, built the scaffolding for us to actually make things, and paired us with engineers who knew how to help. The skills we came out with don’t just serve Formation. They’re ours now. They follow us through the rest of our careers. Most companies don’t invest in their people this way. The ones that do are easy to spot later.

I wrote in my first post that small wins compound. I was describing my own year, where using ChatGPT to write job descriptions turned into building dashboards and querying data in conversation. That was a personal arc. Watching it happen across 100 people in three days was different. It wasn’t just compounding wins. It was compounding confidence.

People who came in on Tuesday unsure that they could learn to build anything useful walked out on Thursday having built something real. Tools their colleagues will use next week that will improve their work (and hopefully their life) a bit. That’s the version of this week I’ll remember. I can’t wait to see what we’ll build next.

This past January, I did a smaller version of the same thing. About a hundred reqs, a Sunday afternoon, tied to budget IDs from our finance system with custom fields that mapped to what finance needed to track. The goal was alignment: if finance was looking at headcount through a certain lens, I wanted our Greenhouse data to speak the same language. Finance is one of our internal customers. Custom fields are how I keep our data connected to theirs.

The evolution of my reporting process

For most of my career, Greenhouse reporting looked the same: pipeline history, pass-through rates, the “all” report. The basics. Then Greenhouse got better at custom reporting, and that’s when custom fields started to feel worth investing in. You could filter on them. Build views that reflected how your finance team or business leads actually thought about headcount, not just how the tool defaulted. The fields you chose to track became a way to stay in sync with the people who needed your data most.

The catch was always maintenance. A report is only as good as the data behind it. So I got selective. I’d track things I knew were stable. Budget IDs, for example, don’t change once they’re assigned. But anything dynamic I’d skip. Whether a role supported one project or several, and which ones, those things changed too often to maintain manually. The juice wasn’t worth the squeeze. So I just didn’t track them, which meant my reports and dashboards couldn’t reflect them, which meant my internal customers had to go somewhere else for that picture.

API vs MCP

Before I get into what changed, it helps to understand two terms.

An API is how software talks to other software. Greenhouse has one. It lets you read and write data programmatically. Pull a list of open jobs, update a custom field, check a candidate’s stage. But to use an API, you need something that can actually make those calls. The chat interface at claude.ai is just a conversation window. It can’t reach out to external systems on its own.

An MCP (Model Context Protocol) is what bridges that gap. It’s a standardized connector that gives a chat interface a way to reach into an external system during a conversation. When a tool has an MCP, you can ask questions about your data, filter it, interact with it, right in the chat. No code required. You can’t change the data, but you can meaningfully interact with it.

Claude Code is different because it’s also a code execution environment. It can write and run scripts that hit an API directly. No MCP needed. That’s what makes everything below possible today.

What you can do now

About a month ago, our company completed a planned reforecast to make sure the roles we were working on were aligned the most up to date needs of the organization.

Some roles were added. Some were removed entirely. The data finance was tracking had changed, and our Greenhouse records needed to reflect that. New information had come in that we hadn’t been capturing at all.

Before Claude Code, this would have been a project. Go into each job, find the right opening, update the fields one by one. I’ve done that work. It’s the kind of task you start on a Friday and finish on a Tuesday having lost track of several hours. Or more honestly, the kind you deprioritize because the ROI math doesn’t add up and you know the data will be stale again in three months anyway.

Instead, I pulled all the open reqs through the Greenhouse API, shared the updated spreadsheet from finance, and had Claude Code find the differences and run the updates. Done. Fast enough that I didn’t have time to resent it.

To be fair, I probably could have written a Python script to do this before Claude Code existed. But my Python skills are not great and the idea of actually doing it was too intimidating. I also could have asked a developer. But my honest read is that they have more pressing projects than making my ATS more useful, and I’d feel guilty asking.

I want to be clear about something: I never wrote a line of code to do any of this. I described what I needed in plain language. I asked Claude Code to verify anything with me before it touched my system. It showed me exactly what it was about to change, I clicked OK, and it ran. That’s the whole workflow. If you can explain what you want in a sentence, you can do this.

And because it was that easy, I kept going

I added fields I’d previously ruled out as too dynamic to maintain. Fields that captured business context our internal customers actually cared about but that I’d never been able to keep current. Then I built a dashboard off those fields. Filterable, React-based, not a Google Sheet. The people who needed that data could see it sorted however they needed, without anyone having to pull or format a report.

The reporting capability existed. The ambition was there. What was missing was the cost equation for keeping the data current. Once that changed, what I was willing to track expanded almost automatically.

Greenhouse doesn’t have an MCP yet. That’s why everything above requires Claude Code and direct API access rather than something you can do in a chat window.

That’s changing. I’m excited to work with the Greenhouse team on their MCP, which means I’ll have the chance to share what I actually want to be able to do and influence what gets built. When it ships, connecting your Greenhouse data to a chat interface becomes much more accessible. You’ll be able to ask questions about your pipeline, filter by custom fields, and explore your data conversationally, without writing a line of code.

One thing I’m asking for

The thing I’m pushing hardest for is interview kit questions.

At Formation Bio, we have structured interview kits. Our Talent Ops Lead builds and maintains them, and they’re genuinely valuable. But it’s a lot of work for one person, and hard to scale because every question has to be added and edited manually, one kit at a time.

At previous companies, I never bothered setting up interview kits consistently. The setup cost was too high and I knew I’d never keep them current. That’s a real loss. Consistent interview questions are one of the most straightforward ways to improve interview quality and reduce bias, and I was skipping them because the tooling made maintenance too painful.

If interview kit questions become writable from an external tool, that changes. You could build and update kits programmatically, standardize question sets across similar roles, and keep them current when job scopes change. The same pattern that made custom field maintenance manageable would apply to interview structure itself.

That’s what I’m asking for. I think they’ll get there.

What would you do if you knew it was easy?

If you use an ATS, a CRM, a project management tool, anything with custom fields and an API, I’d encourage you to think about what you’re not tracking because it’s too annoying to maintain. You probably already know what it is. The thing you skip every time because the clicks aren’t worth it.

Start there. Describe what you want to Claude Code in plain language. Ask it to show you what it’s going to do before it does anything. See what happens.

In my case it’s across jobs in Greenhouse. For you it’ll be something else. But everyone has that thing. And it’s probably smaller and more fixable than it feels.

Sourcing tools are the clearest example. The promise is that AI can find candidates faster than you can. And for some roles, it probably can. But for the kind of hiring I do most often, technical leadership in biotech, the professional record lives on LinkedIn. You can find people through conference appearances or published papers, and that’s useful. But without LinkedIn, you can’t triangulate. You don’t know if you’ve seen the full landscape. And if you don’t trust the output, you can’t act on it.

Scheduling has its own version of this problem. No tool has cracked recruiting coordination because the work is always specific to the organization. Who covers which leader’s calendar. How you respond when a candidate reschedules two days out. A general-purpose tool isn’t built for those details. So people evaluate these tools, get burned, put their heads down, and don’t look at AI again for a while. That’s a rational response to repeated disappointment.

I don’t think AI is the problem. I think data access is.

What I’ve seen actually work

When platforms open up their data in a structured way, something changes. I’ve been using integrations that connect directly to our interview transcripts and candidate pipelines, and the difference is real. Not because the AI is doing anything magic, but because it has access to the right information at the right time. I can ask a question about a candidate and get an answer grounded in what actually happened. I can look across a pipeline and surface patterns I wouldn’t have caught manually. The AI isn’t smarter. It just has the data it needs.

That experience is what makes the LinkedIn gap so frustrating. I know what this could look like. I’ve seen the pattern work elsewhere.

What I’ve noticed about LinkedIn data

Over the past year, my observation is that less work history is visible on public profiles than it used to be. I can’t point to a specific policy change. This is just what I’ve noticed. Whether it’s a platform shift, more users adjusting their privacy settings, or something else entirely, the trend feels real.

I understand why LinkedIn is protective of its data. The hiQ scraping case made that clear. There are real incentives to abuse open access and LinkedIn has been down that road. I’m not arguing against protecting the data.

What I am saying is that LinkedIn Recruiter has access to all of this, but it doesn’t work quickly or efficiently enough to change how I work. I’ve tried. Most recruiters I talk to have tried. The data is there. The product built on top of it isn’t solving the problem.

The ask

Build a paid, regulated, company-scoped way for recruiting teams to access LinkedIn data directly, one that works with how we actually work today.

I would pay for this. I’m already paying for LinkedIn. I’d happily pay more for access that’s gated, scoped to my organization, and limited to profiles that are public or marked open to work. I’m even fine with a constraint that all outreach goes through InMail. Keep the monetization, keep the protection. Just give us a way to get to people that fits modern workflows.

What agentic AI is genuinely good at is doing something repetitive, over and over, until it gets to the right answer. Research. Searching. Matching. Sourcing is almost a perfect use case for that. But right now I can’t apply any of the tools I’ve built or the skills I’ve developed to LinkedIn’s data, not in a way that’s fast, trustworthy, or scoped to my company’s needs.

Rather than waiting for LinkedIn Recruiter to become something it hasn’t become yet, I’d rather have a regulated path to use what I’m already building. One where LinkedIn controls the access, sets the terms, and gets paid for it. That works for everyone.

Why this matters beyond my wishlist

The broader shift I’ve been watching is that it’s now possible to build an AI layer that’s custom to your organization. Not a generic tool, but something that knows your workflows, your team, your exceptions. I’ve seen this work. The infrastructure exists. But in recruiting, a meaningful chunk of the data that layer needs lives behind a wall that only LinkedIn controls.

I’m not asking for that wall to come down. I’m asking for a door.

This was the first time I ever used Claude Code. Yes, you can access this file. Yes, you can run this command. Yes, you can write to this folder. I was trying to build an app. I had taken a project I’d created, something that already worked fine, asked the Claude chat interface to turn it into an instruction document, handed that document to Claude Code, and told it to build. Eight hours later I had something that looked...just okay. It also did nothing I actually needed.

I thought Claude Code sucked.

What I got wrong

The mistake was that I had assumed Claude Code was a coding app, so I went in expecting to ask it to write code and it would. And honestly, can you blame anyone for thinking that? Someone really should have thought through the name. Instead, I had taken something that worked and tried to make it into something it didn’t need to be. When it didn’t work the way I expected, I blamed the tool.

I should also say: I work in talent acquisition. A sense of urgency is basically a job requirement. Waiting eight hours for something completely underwhelming was probably the worst possible first impression this tool could have made on me. I was not inclined to give it another shot.

What changed it was a podcast. I was listening to How I AI when Teresa Torres talked about spending her whole day in Claude Code, giving it tasks and building her own to-do list app so she could just write out the things she didn’t want to forget, right there in the terminal. She had combined it with Obsidian. And I thought: wait, that’s something this can do? I had been so fixated on the app I was trying to build that I hadn’t considered there might be a completely different way to use it.

Full honesty: I still don't have a to-do list app that works for me exactly the way I want it to, and I'm constantly fiddling with it. I do now just put tasks in the terminal and I did manage to connect Claude Code to Obsidian, which is great, but it’s still not quite the way I wish it was. But it’s way better than rebuilding a google doc every week, so I’m calling it a win for now. Either way, trying to build it is what got me to keep going instead of walking away.

And the more I used it, the more I understood what it actually was. Claude Code isn't primarily an app builder, at least not for the kind of work I do. What it actually is, is a partner. Something you have a conversation with, that has access to your data and your files, and that can do the tedious multi-step work that you'd otherwise abandon halfway through. Once I understood that, everything changed.

The problem with tips

There’s a lot of content right now about how to use AI. Tips, lists, shortcuts, things you should never do. I’ve watched it. I’ve learned from some of it. The AI side of TikTok can keep me on the treadmill for a few miles, which is great. But the thing is I keep bumping into the same problem: the use case isn’t my use case. The thing they’re building isn’t the kind of thing that matters for my work or life. And by the time something makes it to “here are the five things you should avoid,” the field has usually already moved.

Some of the prompting advice I saw a year ago is basically irrelevant now. A setting I heard I needed to configure manually already existed in my setup without me doing anything. The tips have a short shelf life. That’s not a criticism of people sharing what they know. It’s just the reality of how fast this is moving. If you spend all your time trying to learn the right way to do it, the right way will have changed before you finish.

A better way to learn it

What actually helped me was treating Claude like a very smart colleague I could have a conversation with about what it could do. Not asking it to build things. Asking it what it had access to, what the limitations were, where the holes were in my ideas. I heard people say that Claude is a great way to learn Claude, and that’s true, but not in the way I first interpreted it. I thought it meant I could ask Claude to build me something and learn from watching it work. What I actually discovered is more useful: you ask it questions about itself, about your setup, about where your plan might break down. That conversation is the learning, at least for me.

Another resource I’ve found consistently useful is the AI Daily Brief podcast. I listen to it most days. It keeps me current without requiring me to go looking, and it covers things at a level that’s actually useful rather than just exciting. Their website also has a few companion pieces worth knowing about: a skills masterclass, a personal context portfolio, and a breakdown of Claude’s major recent upgrades. I’ve used a few of them and found them genuinely practical.

But honestly, most of what I know I learned by fiddling. I hear something that sounds interesting, I try it. Sometimes it applies to my work, sometimes it doesn’t. That process of trying things is what builds the instinct for where to reach next.

Start with the smallest thing

If I could give one piece of practical advice, it’s this: don’t start with an app. Start with the smallest thing that might be useful. I consistently find that when I have something that I try to make do more things that it needs to, it breaks. I keep doing it, so do as I say and not as I do here.

My smallest thing was asking Claude to cross-reference two spreadsheets and tell me where things matched and where they didn’t, then update fields in Greenhouse so I didn’t have to do it manually. That was it. Small, specific, immediately useful. But doing that one thing is why I reached for Claude Code when I was trying to plan a garden with 85 plant photos, four different beds, a dog, and a budget. If I hadn’t done the spreadsheet thing first, I never would have thought to use it there.

Every day when I look at my list of tasks on my yet to be perfect to-do list, I think about which ones AI could either do for me (check my email and Slack so I don’t miss anything), help with (I write a blog and then it helps me refine it), and most importantly, which ones it hopefully gives me more time to do myself (primarily connecting with people at work and in my life).

Small wins compound. That was true a year ago when I started with job descriptions, and it’s still true now. So really, a full day of clicking yes wasn’t wasted time. It taught me something a tutorial couldn’t have.

This year we decided to give it another try. I felt overwhelmed before I set foot in the garden center. There are just so many options. We went this morning and took pictures of everything we liked. By the time we left, even after narrowing things down to flowers that needed shade, repelled the things we wanted to repel and attracted the things we wanted to attract, we had 85 photos. But no real plan.

That’s where Claude Code came in.

I want to say something about Claude Code before I get into what it actually did, because I think the name puts people off. It sounds like a tool for software developers. And it can be that. But that’s not how I use it most of the time. I use it as a problem solver. A thinking partner. Something I can hand a messy situation to and have a real conversation with until it becomes less messy.

I also don’t think much about how I “prompt” it. I’ve seen people tie themselves in knots trying to write the perfect instructions. I don’t do that. I just write more free form. I say what I’m trying to do, what I’m concerned about, what I don’t know. I often ask it to ask me questions before building anything. I’m sure there are some super prompters out there that could get to the right thing faster, but I generally get there and so I don’t stress myself out trying to ask the perfect question.

So here’s what happened.

Our parameters: We have four distinct areas for planting, a dog and often have little kids visit. We wanted something that would attract butterflies and hummingbirds, repel mosquitos and bunnies, and look colorful from spring through fall. Some of the beds get very little sun and one of them gets a ton of sun. All of the flowers have sun preferences, times of year that they bloom and need a certain amount of room to grow well - this information was on the pictures we took and Claude code could read them since I put them into a folder and gave it access. We went back and forth until it had a real picture of what we were trying to do. It asked about things I hadn’t been able to articulate - do I want one color in spring and another in fall or did I not care? Most of the flowers are in the blue/purple category on that one side - am I SURE I want a huge yellow one too? (I do not). All of that by itself was enormously helpful.

Then it did all the things I would have eventually abandoned.

It looked up prices for every plant on the list at Mahoney’s and built a spreadsheet with quantities, individual costs, subtotals by bed, and a grand total. It went through all 85 photos from my phone, read the nursery tags in the pictures, identified the plants, and matched them back to the plan. It built a visual map of the beds organized by depth and bloom time so you can see what goes where and why. And it generated an HTML file with a photo of every plant so I could pull it up on my phone in the nursery aisle and actually know what I was looking at.

Check it out:

But I thought Claude Code was for…coding?

None of that is coding. It’s research, organization, and formatting. The stuff that’s not hard exactly, just tedious enough that I always told myself I’d get to it later. Having something that just does all of it, in the same conversation, without me having to switch between twelve tabs and a spreadsheet I’m building from scratch, is what made this project actually happen instead of becoming another thing I meant to do.

One thing worth saying: this isn't what you get from the regular Claude interface. Chat alone could have helped a lot. It could tell me what works for sun and shade, what attracts and repels stuff, give me a list of things to ask at the store, etc. But it can’t go to the garden center website, look up all the prices and create a spreadsheet. It also can’t take a folder of photos, label them and turn them into a webpage and garden map. I often feel like Claude code goes an extra step I didn’t even think to ask (the web page was the example in this session).

The “when we are all finished” small change that’s often not small

My partner said what about basil near the front steps? If I had done all of this work manually and then we wanted to throw something new in, I’d never re-do it all. But I could just tell Claude code to re-run everything + basil. Easy peasy. The spreadsheet updated. The map updated. The total recalculated. Same conversation, no starting over.

This is what I generally mean when I say I’m “doing a lot of stuff with AI”. I’m taking things that I’ve wished weren’t so tedious and leveraging what it’s good at to make it easy. It’s not that any individual task is impossible on your own. It’s that doing all of them in sequence, and then staying flexible when something changes, is exactly where having a sidekick that doesn’t get annoyed when you throw a wrench in the plan is incredible.

Last year we had seeds and hope. This year we have a plan, a spreadsheet, a map, and basil.

Subscribe now

A year ago, I was using ChatGPT to write job descriptions.

That’s where this started. Not with a grand strategy or a company initiative. I was heading up talent at an incubator at the time, a tiny team with more open roles than capacity. Learning to do more with less wasn’t optional. Just me, a hiring manager’s bullet points, and a tool that could turn them into something I’d actually want to read. Before that, I was doing what most recruiters do: opening LinkedIn, finding similar roles, piecing together something that felt right for the company I was in. ChatGPT made that faster and better. That was enough to get me hooked.

Then I started using it for interview questions. Behavioral questions, specifically. Give it the role context, ask for questions that would help evaluate a specific competency, and it returned options that were genuinely better than what I’d been pulling from memory or templates. Another small win.

Here’s the thing about small wins: they compound.

The experimental phase

Around this time, I started a consulting company, which forced me to learn faster. I got into automation workflows - which, to be clear, aren’t really AI. They’re just processes that trigger automatically when something happens. But they taught me something important: connecting to data is the real unlock.

I had clients who let me connect to their Greenhouse API. I started building things that could make their lives a little easier. Smaller things at first, like running scorecards through a language model and summarizing them, then sending that summary by email instead of making someone log into Greenhouse to find it. I experimented with SQL. I built a vector database to look at resume books and see how candidates might match open roles.

It was all very clunky. And experimental. And honestly, super fun and super frustrating at the same time. I cannot count the number of times I told my partner I was almost done, only to emerge from my office three hours later.

I also started posting what I was learning on LinkedIn. I wasn’t sure anyone would care, but it pulled me into some amazing communities and introduced me to people I wouldn’t have found otherwise. Joe Atkinson, Jason Miller, and the Promptmates community were among them. That was genuinely one of the best parts of that period.

I built my first custom GPT during this time and I want to pause here, because if you haven’t built one, it’s much easier than it sounds. I thought it was complicated. I was wrong. I even built a short course about it, and the feedback was that it was useful, which made me happy.

Joining Formation Bio

Last September, I joined Formation Bio. The company is AI native, the team is incredibly smart, and it gave me the opportunity to use AI at scale in a way that could genuinely amplify what our talent team was able to do.

I want to be clear about something: the use cases I’m describing are not about making decisions for us. AI is not screening out candidates or deciding who moves forward. What I wanted to do when I started was learn about our hiring process, our standards, and how we assess people.

We use an AI notetaker for our interviews, which means we have transcripts. Actual transcripts of what was said, not just what someone remembered afterward. I started analyzing those transcripts and comparing them to scorecards. Then comparing both to our company values. I was trying to understand two things: whether the candidates we were interviewing showed alignment with what we cared about, and how good our interviewers were at assessing those signals.

This is work I’d wanted to do at other points in my career. I just never had the time or the data. Reading through hundreds of transcripts wasn’t realistic. But now it was.

I’m a data person. I believe in evidence-based feedback. And there’s an important distinction between what was said in an interview, how the interviewer interpreted it, and what they wrote in their scorecard. Having transcripts meant I could actually trace that chain. I could go back and look at how we assessed people who ended up being successful here, understand the patterns in our decision-making, and think more clearly about what our strategy should look like going forward.

The data connection that changed everything

The thing that really changed my workflow was when my company connected my transcript data and my Greenhouse data directly into Claude. Before that, I was copying and pasting transcripts and scorecards into a chat window. After that, I could just have a conversation with the data.

We use an internally-built tool called ARK (AI Repository of Knowledge), an MCP hub that connects data sources to AI tools and makes it possible to build useful things for our teams. With Greenhouse data and transcript data both connected, I could ask things like: build me a pipeline for this department, show me which candidates are in process, flag which jobs are off track. There was always some back and forth to get it right, but I could generally get what I wanted.

One practical note: Greenhouse has rate limits on how many candidates it will return in a single API call. Even looping through calls, I was finding gaps in the data. That problem got solved when we started pulling pipeline data into our own internal Snowflake database first. Another big unlock.

Claude Code

The most recent chapter is something called Claude Code, which is what I use now and which has fundamentally changed how I work. I know that sounds dramatic, but for me it’s a force multiplying game changer. I can’t imagine going back.

Claude Code is a terminal-based AI coding agent. It connects to my data and it’s less like a chat interface and more like a building partner. At first I kept running into walls. Lots of fiddling, lots of trying, lots of starting over. And then something clicked.

Here’s what I’ve built since then: a morning briefing that runs every day and pulls together my calendar, Greenhouse updates, relevant Slack threads, and a hiring pipeline pulse before I’ve had coffee. A daily dashboard I can open in a browser that shows me what’s happening with my team and my meetings. A recruiting analytics pipeline that queries Snowflake and formats the output for leadership. Interview quality analysis that compares transcripts to scorecards across hundreds of interviews.

Beyond the scheduled stuff, I use it constantly for things that used to eat time. Before a meeting I can type a single /command and it pulls everything together: checks Slack for relevant threads, scans my email, finds the last doc or agenda from a prior conversation, and summarizes what I need to know. That used to be ten minutes of tab-switching. Now it’s one line. (Skills are a whole other blog post.) I also use it to update custom fields in Greenhouse in bulk through a conversation instead of clicking through hundreds of records individually. I describe what I want changed, it runs it, and I’m done.

The tools connect to Greenhouse, Snowflake, Fireflies, Slack, Gmail, and my calendar. The data was always there. Claude Code is how I get to it without a single click through a UI.

The thing that’s hard to describe is how much the timeline has compressed. For someone who has always had more ideas than time, that has been pretty thrilling. I never feel like I’m “caught up”, but I’ve also learned that that’s how everyone feels. The key is to start.

Why I’m writing this

When I tell people what I’m doing now, I can see them assuming it’s complicated. That it requires a technical background or a lot of training or something most people don’t have access to.

I don’t think that’s true. I started with job descriptions. I made a lot of mistakes. I emerged from my home office at strange hours having lost track of time. And I got here.

This blog is about that journey. The real version, not the polished one. I’ll write about what I’m building, what works, what doesn’t, and what it actually looks like to do this work inside a company that takes AI seriously.

We also have a company-wide building week coming up soon, three days where everyone sets aside their normal work and just makes things together. I don’t know many companies that do that. I feel lucky to be at one that does.

If any of that sounds interesting, I hope you’ll stick around.