Subscribe
Share
Share
Embed
Episode 1 of The Skill Tree is a conversation with Nick Cannariato about how people actually use Claude skills once they move past the toy stage. Neil Roberts and Nick Nisi talk with him about narrative frameworks for talks and blog posts, connector-heavy research workflows, skill generation, memory systems, and the strange mix of control, curiosity, and frustration that makes AI-assisted work productive.
The discussion stays practical even when it gets philosophical. Nick C explains how his post and talk skills grew out of a dislike for one-size-fits-all story structures, how he uses Claude connectors to automate real sales and research work, and why the right response to repetitive work is often to tell the machine to do more of it.
Case project is trying to prove about evidence, state machines, memory, and AI-assisted software work00:00 Opening, Guest Intro, and the Cult of Skills01:04 Meet Neil and Nick Nisi03:50 Ideation, Pi, and the New Skills04:11 Monomyths, Story Circle, and 22 Narrative Frameworks08:44 What the Post and Talk Skills Do in Practice10:23 Born Out of Spite11:05 Connectors: Slack, Gong, Notion, and Deal Research13:35 Meta-Skills, skill-forge, and Hidden Anthropic Docs16:27 How Nick C Organizes His Skills18:28 Case, Evidence, and AI State Machines20:56 Auto-Dream Mode and Memory Management23:34 Stealing Ideas, Markdown Files, and bat-kol26:35 Evernote, GitHub, and Becoming an Engineer29:06 AI Anxiety vs. Shipping More Than Ever33:35 The Thursday Estimate That Shipped Monday37:21 Why AI Fits How Our Brains Learn38:12 The Blog-Writing Hack: Mine Your Claude Transcripts39:51 Parting Advice42:53 Break Stuff and Get Paid to Fix ItNick C explains that his post and talk skills were built as a reaction against forcing every talk or blog post into the Hero's Journey or Story Circle. Instead, he has Claude choose from a larger set of narrative frameworks, including more technical, absurdist, and open-ended structures that better fit conference talks, support stories, and real-world writing that does not resolve into a clean heroic arc.
This part of the episode gets into something bigger than presentation structure. The hosts are really talking about taste: how much of yourself you want to preserve when AI helps you write, and how a good skill can encode preferences that are hard to express in a single prompt.
One of the clearest through-lines in the episode is that skills become more valuable when they are attached to actual work. Nick C walks through using Claude connectors with Slack, Gong, and Notion to recover context from meetings, assemble research, and update documentation without having to manually retrace everything himself. That same impulse shows up in his skill-generation workflow, where one skill helps tune and improve other skills.
Nick Nisi describes a parallel idea in Case, his system for taking issues from intake through implementation while still requiring evidence that the work really happened. Between the two approaches, the episode draws a useful line between lightweight reusable instructions and heavier orchestration systems that manage agents, memory, and proof.
The last third of the conversation shifts into what AI work feels like day to day. The hosts talk about shipping faster, using Claude as a patient collaborator for exploration, and reducing the fear that used to come with unfamiliar code or vague estimates. At the same time, they acknowledge the tradeoffs: trust has to be calibrated, review still matters, and some kinds of craft can atrophy if you stop caring about the underlying systems completely.
What makes the conversation useful is that nobody treats this as abstract future-of-work discourse. The examples stay grounded in real projects, real habits, and the way these tools change how people learn by letting them revisit a problem in layers instead of having to understand everything at once.
ideation - Nick Nisi's skill for turning rough ideas into clearer implementation artifactsnew-post and conference-talk-builder - Nick Cannariato's skills for generating posts, talks, and narrative structureCase and Playwright - Nick Nisi's evidence-driven system for automated implementation and verificationskill-forge, octoflow, and bat-kol - examples of meta-skills, Git workflow hooks, and voice-tuning experimentsNick Cannariato is a software engineer at WorkOS with a background in support, product development, and technical writing. In this conversation he brings a strong point of view on automation, storytelling, and what happens when people who were never traditional software engineers suddenly have tools that let them build and ship anyway.
The Skill Tree is a podcast about AI skills, agents, developer workflows, and practical ways to use LLMs. Neil Roberts and Nick Nisi talk with developers, tool builders, and creatives about prompt engineering, evals, scripting, tooling, MCP, and the systems people use to make AI actually useful.
Neil: I feel like this is a Nick-run episode. Lots of Nicks.
Nick N: Hoy hoy, welcome to the Skill Tree Podcast. I am Nick Nisi, and I'm joined today by Neil Roberts. Neil, how's it going?
Neil: Good. It's an honor just to be nominated.
Nick N: We love nominating you. And we have a special guest this week. We have Nick Canariato. Nick, how's it going?
Nick C: Doing well. Well pronounced. I'll give that to you. That was well done.
Nick N: I just think about "canary" and "auto" like you taught me and it works.
Nick C: My name is as you said Nick Canariato. I also go by `birdcar` everywhere. I am a solutions engineer at WorkOS with Nick, which is how I got roped into this and also indoctrinated in the cult of skills, so we'll just let that be the intro.
Neil: What does that make Nick?
Nick C: He's not not a cult leader.
Neil: He has cult leader vibes.
Nick N: I use Vim, you know.
Nick C: Obviously. You were already evangelical before you found the Claude, and now you're moving on from there.
Neil: Nick and I should probably introduce ourselves as well because we didn't even do that in our first episode. Which I called the zeroeth episode because that's what it deserved.
Nick N: You want to go first, Neil?
Neil: I'm Neil. I am `pottedmeat` on the various socials, which I got because I was told that I liked potted meat a lot as a child and I also thought no one will claim this username ever so it'll be easy for me to get. Although I did have to fight a little bit to get it on GitHub. It was previously owned by someone else. But it's mine now.
Nick N: Are you saying that potted meat is a food?
Neil: It's a food product.
Nick C: That was my next question. What exactly is potted meat and why am I scared?
Neil: I think it's when you're done taking as much meat off the bone as you can, it's the little bit that's left over.
Nick N: Amazing.
Neil: That's me. I've been programming for a long time. I have been doing JavaScript almost the entire time. I remember doing JavaScript in high school in 1998 for an image carousel. So that's my oldest, fondest memory of JavaScript.
Nick N: That's even ES3 JavaScript). That's wild.
Nick C: That's way back there.
Neil: I made a crossfade image gallery.
Nick C: The hard way. Very nice.
Neil: I had no idea what I was doing, but I somehow did it.
Nick C: Neither did anyone else in 1998, so you were doing pretty good.
Neil: I pretty quickly got to being involved in open source, which is how I found my way to SitePen where I work now. I've been there off and on for a very long time, and I got the pleasure of working with Nick for a while while I was there.
Nick N: Yeah. It was a great pleasure working with you.
Neil: I always find it difficult to say what SitePen does, but it's just a group of pretty much all senior engineers that can adapt to any environment and help out where we're needed.
Nick N: I would always just be like, "Have you ever heard of Dojo?" Nowadays everybody's like, "No, not at all."
Nick C: Nope.
Nick N: I'm Nick Nisi, and I'm `nicknisi` everywhere. That's my handle on everything. That's really easy to memorize. I have done JavaScript maybe not as long as Neil, but for a while. I worked at SitePen, worked on Dojo, did that for 7 years and then left and went and did other things and made my way to WorkOS where I've been for the last year, a lot of which working with Nick. Really enjoy it. I've done podcasts on and off over the years and conferences, and I've officiated 11 weddings to round that out. I guess I like talking and making myself the center of things.
Neil: My fun Nick Vim story is I have a coworker that likes Vim and he ran into my office one day and said, "You know Nick Nisi?" I was like, "Yeah." He was very excited.
Nick C: Infamous.
Neil: Nick was a big celebrity to him, and he was very excited to find that out.
Nick N: I don't know how to respond to that. So we have been talking about skills, and last time we talked about my ideation skill and still love it, still going strong. I have actually converted it into an npm package called Pi Ideation as I've been playing with Pi. And really enjoying that. There's good and bad to it for sure. Pi, I mean, and we could talk about that later. But I've been talking to Nick quite a bit about the ideation skill and different skills and we've been kind of collaborating on different ones within WorkOS to solve various different problems. And Nick, you've been working on a really cool skill. What's it called?
Nick C: The post skill and the new talk skill are 2 that are of the same regard and they were born of frustration with your content generation skills, which is I think why you think they're cool.
Nick N: Probably.
Nick C: I have very strong opinions in general across the board, but in particular about Joseph Campbell and the Monomyth and deeply despising them and the ideas behind them with everything in me. I find them to be the "Pop-Tart is a sandwich" argument of narrative history and I like the humanities, I'm one of those people who found their way into tech. And so I pointed Claude at his skill because I liked the idea of, "Hey, generate an outline for me or generate a presentation." But I very specifically wanted it not to use the Monomyth or the Story Circle, whatever if you're taking the Dan Harmon route, which is slightly more refined. And so I basically was like, "Hey, I'm an absurdist nihilist and I think that narrative doesn't always need conflict and I'm definitely not always a hero." And sometimes you're giving a lightning talk at a tech conference and the arc of the story is: I fucked up, I did worse things, I learned nothing, please help. And the story arc of the Story Circle doesn't really help that. And so I kind of angrily used Nick Nisi's ideation skill against him and pointed it at his talk skill and said, "Hey, generate me something that'll do something different." And it spit out this Rube Goldberg machine of a narrative engine that will try to match it to a narrative framework or a set of narrative frameworks that work really well together based on how much time you're giving a talk or how long your post should be. And then it will take your transcript or your blog post or whatever and it'll turn it into a bunch of slides in Slidev, which is my preferred markdown-based presentation software. We all have one. There will be a new one by the time I finish speaking. And then now that he's got me on WhisperFlow for just brain dumping into the terminal and having it print out a blog post for me.
Nick N: There's a lot to unpack in that. The Hero's Journey or the Story Circle is a way of telling a story with a specific framework. Like you have an issue, you struggle with it, you suffer greatly, and you come back to your starting point changed. I'm skipping a bunch of steps. If you have watched any episode of Community) or Rick and Morty, you are familiar with the Story Circle because they all follow that because that's Dan Harmon's condensed Hero's Journey, which is like 17 steps or something. His is 8 steps. And so it's just a condensed version of that. And I really enjoyed that. And I feel like it's hacking your audience to keep them compelled in what you're trying to teach. If you're doing a presentation or a blog post and you're actually leading somewhere. And I agree, it doesn't always fit everywhere. I wouldn't say I hate it, I like it a lot.
Neil: Cleaning the Fridge: The Hero's Journey.
Nick N: But Nick came to me and was basically like, "I just hate that so much." Really great. Like you turned it into—well, explain it. Yours doesn't use Story Circle. It uses a bunch, right?
Nick C: I keep adding more to it. I think right now I'm at 22 narrative frameworks. But if you go into the references folder, you'll see a bunch of them. There's the Kafkaesque Labyrinth and it has examples for exactly how that would work in a technical talk or like Metamorphosis. So those are the Kafka ones. It has a Sisyphean Arc one. I was a founder previously and I built a support tool and therefore a lot of my public facing talks are somewhat Sisyphean because support work doesn't really end. There's no journey home. You just have more queue to handle. There's 22 frameworks based on a bunch of books that I read and philosophers that I like and also different cultural storytelling. I'm not gonna even try to pronounce it because I can't, but there is a Chinese story framework where there is no conflict, there's only surprise, and I think that works super well. There's 22-ish frameworks, and then as I read more or think more, I prompt it to add more things.
Neil: In preparation for the episode, I installed the podcast skill that has our previous episode and I installed the new post skill and I ran it through it. I told it just to write a blog post about our episode and it used the Montaigne narrative framework. I think is what I'm pronouncing.
Nick C: That is a French essayist from 1580, so you're welcome. You can enjoy that.
Nick N: So Nick, how have you found using these skills in practice?
Nick C: For presentations, if it's given enough—if I give it a transcript, just a word vomit, it's pretty much done. I can actually point you directly to one because our coworker Zach was giving a go-to-market using Claude Skills talk and I showed him the story frameworks and he was like, "You should do a talk about how much you hate why this was developed." And so I actually had it spit out a talk based on 3 paragraphs and I've basically left it untouched. It's done. And I also gave it an old talk for my blog the other day and had it backdated and it just one-shot the actual blog post itself. So if you give it enough context, I think it does really well. I've also given the talk skill in particular a really rough idea and it's gotten me 80%, but that last 20% is the hard editing part where my brain has to really lock in on getting stuff done, which is still a win because I don't have to think about presenting and it gives me a framework for my ideas. I do want to go back through and give it a confidence score similar to ideation because I'm stealing that for a few other things and that's been pretty useful. But overall, it's been great to use and it really does spit out surprisingly good results that sound like me.
Nick N: I am reading this now. First off, the design is super cool. All of the animations, the hand-drawn animation things.
Nick C: Thank you. That's Rough Notation. I'm a big fountain pen person, and so I wanted there to be something hand-drawn feeling on it. Thank you.
Nick N: That's cool. So are all of your skills born out of spite?
Nick C: I think most development for me is born out of spite. I became a founder out of spite. I don't know that I do much that isn't spiteful, at least not to start. I eventually find joy, but I guess my own monomyth there is my call to adventure is anger, and then I return home joyful. And then some of them are just born from a frustration with monotony. My brain does not enjoy doing things very frequently. It's why I like software. I work as a solutions engineer, so I do a lot of sales stuff, and sales tools themselves are designed for people who do not automate things. And that means that you're doing a bunch of manual labor and a bunch of manual research and copying and pasting, et cetera. And so I like trying to automate that away as much as humanly possible. It's actually why I can't go to Pi because I need all of Claude's connectors at work.
Nick N: That's what's keeping me there right now. I'm really enjoying Pi, but oh the connectors. Neil, I don't know if you've even looked at Pi or know what we're talking about with that.
Neil: I just learned about how often people use connectors today.
Nick N: It's so good. Being able to just copy a link to a Slack thread and paste it in and then now Claude has all of the context of that thread and I can just continue the conversation or work on something based on this 97-post thread. Oh, it's amazing. Or summarize that. Just go summarize this. I know Slack has that now, but connecting that and Notion and just everything. I was trying to do all of that with Pi, and it's a little bit more difficult.
Nick C: Connectors themselves are what really make my workflow at work when I'm not developing something or doing something personally really shine. I think yesterday or the other day, I remembered that I was asked to do something offhand in a meeting. I didn't remember which meeting. I couldn't remember exactly what the ask was. But I knew what customer it was related to. And so I just told Claude, "Hey, review my Gong calls." We use Gong to record things. I was like, "Review my Gong calls, figure out what Adam asked me to do, review this channel that I think the information is in, summarize all of that and let me know what I need to do." And it generated a Notion page for me basically and I issued some edits, but it reviewed everything. It got all my transcripts together. I have it running deal research right now. I give it a customer URL and it will generate an entire hub of information and it's idempotent. So as the engagement with a customer goes on, I can have it update our discovery documentation and even generate closing arguments for them based on a coaching framework that our sales lead has. I'm using a skill for kind of everything, including... I ended up making this meta skill that tunes skills. I discovered that Anthropic hides good information in docs that aren't for humans. If you add .md to the skill documentation, there's actually way more information about skills in there that they just don't want you, the human being, to read for some reason. There are a bunch of headers where you can specify tool usage and you can specify agent call out and even pre-authorize other skills. I have skills that can call ideation and preload it automatically. I basically created an ideation plugin, but specifically for generating skills and for generating highly optimized context-managed skills. And that's what's driving most of my day at work right now.
Nick N: Wow. That's amazing. I want to dig into that a little bit because I have something like that too, an auto skill skill. But I've let it languish a little bit and I'll tell you why. It's because Anthropic has released a Claude Skill Claude skill that is really good. I don't know, maybe I just give it too much because I'm like, it's Claude that makes this, so it's going to know how to fine-tune mine the best for Claude. I don't know, maybe I need to dig into that or maybe supplement it with other things like you're doing. Because I really like that and I like that it even has a reviewer and I tell it to review my skills all the time. That's really good. And then it also has evals now. So it'll kick off a bunch of sub-agents and ask it questions with and without your skill and do comparisons against it. And it'll even generate a web UI for you to go look at the comparison between them. And that blows my mind every time.
Nick C: So I tried using Anthropic's built-in one and maybe it's gotten better in the—when did I—we're talking about LLMs, so I think I updated this 2 weeks ago. So I built this 2 weeks ago.
Nick N: Right around then they released Skills 2.0.
Neil: It's always how it goes.
Nick C: So in 2 weeks I'm now a dinosaur. Maybe this is bad, but I fed it every popular skill creation skill.
Nick C: I fed it the PDF that Anthropic released for writing good skills. I fed it the secret documentation URLs directly that I found on Anthropic's website. And I fed it Anthropic's own skill creator and also some ancillary stuff. And the general idea was skills are one thing and their skill creator is good at creating skills, but Claude surfaces a bunch of other primitives like agents and those manage context, especially if you're doing what I do and you're saying, "Hey, read whole transcripts of hour-long demo meetings with customers," right? Now that we have a million token context window by default, this is less of a thing, but I was running out of context very fast. And so deferring to an agent that's designed to understand what we're looking for in the call, give me a summary that's actually effective. And also do all of that in a non-blocking I/O way meant that I could kick off a really long-running research task and then do another one and another one and have 8 things running at once. And I've never been able to get Anthropic's skill creator to do that itself. And I took their eval idea and I took other stuff like that. I also made it so that I could feed a random file path to my skill-forge creator and it will recommend updates and give you a score and say, "Hey, this is inaccurate in these ways and doesn't follow these rules and could probably grow in other ways." You can also tell it, "Hey, this skill at this location. I'm thinking I want to add this feature. Can you do that in a performant way or how do I do that?" And it'll kick off a brownfield ideation-style exploration. I go back and forth. I have used theirs. But if it's all markdown files anyway, and if I'm generating some stuff, I like it to be done kind of my way. The whole point of this is that there's no moat. You can do whatever you want.
Neil: So how do you conceptualize all these different skills that you have? Is there a hierarchy that you have in mind or—because it seems like if you're managing all that stuff, how's it all in your head?
Nick C: There's a small hierarchy, so there are some things that happen automatically. I have a skill slash command called octoflow that has a bunch of my persnickety rules for how I like git to work and that is actually hooked into anytime Claude tries to write a git commit. So it'll just automatically hook in and then go ahead and use my rules instead. It'll rewrite commit messages and make sure "why not how"—things like that. So that's one set. In one part of my brain, it's like, are there things that can automatically happen since my primary work area is Claude and I have the ability to hook in to various commands that are being run? The second thing is just pure generation. The 2 things I need to make most often are other skills that can automate other parts of my job or demo apps in particular. So really broad surface area, but not very deep. And that's where with those 2 kinds of functions of my job, I have pretty literally just the ideation skill and my own skill creator. And then the third piece is deep research. And typically that research has to be rewritten in my voice or understood with my way of thinking about our product at WorkOS or other things like that. And for that one, we've got 2 competing plugins internally at WorkOS for this. And then I just threw a third into the ring. So we'll see what happens with that. But the general way I think about it is: if I don't have to think about it, that's great. If Claude can be aware of it and can hook into it, then perfect. If I do have to be aware of it, I think of it as a trigger that kicks off a process of other Claude things happening. And then if I'm like harnessing or directing something, I think about Nisi's work on Case a lot. How can I harness and learn from and make my workflow faster? And so if a customer asks me a question that can be answered by the docs, I'm just gonna answer that. But if they ask me a question that has weird implications for how to do something and whether they should do it, that's more where I'm interacting with Claude and having it understand some smarts, kicking off an agent, things like that.
Neil: Do you want to talk about Case, Nick?
Nick N: Since you mentioned it, I suppose I can. Case is my attempt at basically automating my role as much as possible in some specific ways. I'm a DX engineer at WorkOS and I work on the open source repos and so that's mostly SDKs across various languages. And Case is this attempt to be able to take an issue that comes in or a feature that I want to make for the SDKs and basically have it do it from start to finish. And it does a big, big focus on evidence. It needs to prove to me without me having to look at the code. I do look at the code, but it needs to prove to me without looking at the code that it did what I asked or that it fixed a bug. So in a lot of ways, the most simple case of that is just do all the unit test pass. Yes. Yep. Okay. Good. But in a UI bug, for example, I want it to actually spin up an example app and show me that it fixed the issue. I want to see the issue—you reproducing the issue and then I wanna see you doing a fix and then it no longer being an issue. And so it uses the Playwright CLI, which you can record videos from, to do that. And so it's putting all of that together, using a TypeScript orchestrator and a TypeScript state machine to facilitate ensuring that it goes between states and knows how to go back based on validations and verifications, and it has to cryptographically prove to itself that it actually did the work because otherwise it'll cheat and it's lazy, which is hilarious. And right now it's all rewritten completely as its own thing built on top of Pi. I kind of became Pi obsessed for a week. And it's really cool. The same thing that you were talking about, Nick, where I want to be able to just set it off, but sometimes there's not enough context and I need to guide it. And so the big deal with that is I can say `case --agent` and load it that way. And then it's going to load all the context that it knows about whatever issue that we want to work on, and then just drop me into a chat where we can go back and forth on it and I can kind of give it all of the context that it needs to then let it continue the state machine and take it to completion. The idea is I can just kick those off or eventually automatically have those kicked off as new issues come in. And then I'm just coming in to make sure that it's doing things, but also the final step is that it learns from itself. It does a retrospective after each task and it's going to clean up memory. It's gonna say, "Oh, I was working on TanStack Start and I kept doing this thing incorrectly." And so it has a TanStack Start specific memory file where it can be like, "Oh, once I figured it out, I can just add that." So maybe I'll never run into that again. Is kind of the goal of that. I'm playing with this concept of what Claude has now by default, which is this auto-dream mode. I don't know if you've seen that.
Neil: Tell us about it. Sounds interesting.
Nick N: It's enabled, I think, by default and I've seen tweets about it and I went and looked for it and—Claude is always making memory files in its
.claude directory in your home directory and they're just markdown files, but those can get unwieldy, right? So it has a dream state where it will go and kick off a process to go look at those memory files and sort them. What's still relevant? What's no longer relevant? What can I get rid of and what can I improve? But I need to keep this under 250 lines per file so that it's not getting unwieldy and just blowing up your context with unnecessary crap. And it works in a similar way to how your brain works at night. It's sorting things for long-term memory and getting rid of other things and just kind of cleaning out your brain as you go. That's just built into Claude now and I think there's always learnings—what they're doing you can bring to what you're trying to do as well. Really cool. But the whole idea of memory is just fascinating. Once we learn something, I don't ever want you to do the same mistake again.
Neil: So how do you organize that in the skill? Is it defined files or do you let it make new files?
Nick N: Very poorly at the moment, but it's defined files as it learns about new repos that I let it work in. Because all of the SDKs are in separate repos. So it's kind of working cross-repo like that. And it's keeping the memory in-house, mostly because I didn't want to blow up each repo with a bunch of Case files. This experiment may not actually pan out. So I didn't want to just have all this bloat everywhere. So it writes back to itself, which is a problem right now because hard coded in there is my `/user/nicknisi`. Like you're gonna write directly to this place. So Case isn't very usable by anyone else right now. But there's a lot of good ideas to steal from there for sure.
Neil: Is it a single file then or?
Nick N: No, it's several files. It has a docs directory internally, which doesn't have to be reloaded every time you make a change to a skill file, you have to tick the version number and reload that and then Claude picks it up. These don't because they're just random files on your hard disk. And so it's writing to there and it has a high level one that's like, "I'm Case and this is my philosophy and what I do." And then it has JavaScript-specific ones, TypeScript-specific ones, Ruby-specific ones, and then it has specific frameworks. This is more practical for the JavaScript world where it's like I have a TanStack Start one, a Next.js one, a React one, and just keeps track of them like that. So when it loads a React project, it doesn't have to know anything about TanStack Start.
Neil: I'm pulling it up now.
Nick C: I still am barely processing how Case works and trying to cram all of it into my brain to process how to steal from it basically.
Nick N: That's a good topic. How do you steal things?
Nick C: I came of age in the "internet is for stealing" cohort, which is sadly not really as much of a thing anymore or as common anyway. And discovered open source early, but mostly as a script kiddie who also needed tools to steal things. And I would say that that muscle is pretty built in. I think the hardest thing is not how do you steal, but when. The theoretical effort of doing my own thing has now dropped to almost zero. Not quite. It's theoretical. It's theoretically almost zero. It's actually a lot more. I'll lose an hour and a half trying to make my own thing do a thing. But whatever. And I think it's more like—going back to the skill creator conversation—it's more like how much do I spend arguing with this thing someone else built for a very clear purpose versus having full control and iterating on something. And I think the closer that I get to "I don't know, it's a public facing markdown file," the more that I get to "Hey Claude, read this thing. I want it to do basically exactly that, but in this context and in exactly this way that I want it to." My skill forge is an example of doing that, but to your ideation skill—which I was just straight up using your ideation skill to write skills for a while. And then that felt too heavy or it wasn't quite doing what I wanted it to do because it wasn't a skill expert. It was a code expert, right? One of the success engineers at work and I have had this back and forth where we're both writing different skills to generate support responses in our voice. And I have the unique experience today of being frustrated with my own work and his work simultaneously, which led to—and I haven't kicked the tires on this yet—this plugin I just made called bat-kol, which the divine echo, think of it in that way. And basically I wanted to be able to tell it, "Hey, I need you to summarize everything I just discovered with you in a professional voice for this channel versus in this channel." And I want to be able to override what that voice file looks like in given directories if I talk differently in a specific project versus anything else. And oh by the way using these connectors that you have and other CLI tools I have, go scrape everything I've ever said anywhere and retrospectively learn and update my voice as I issue corrections. And so this is my answer to that. At this point I'm stealing from myself and I'm gonna deprecate the other thing, but that's the idea for me, right? The closer that I get to "I don't know, it's a bunch of markdown files, try some stuff, things change week to week," then the more I just think steal it, why not?
Nick N: Oh, this is good. I'm gonna steal this one for sure.
Neil: I mean I think almost everything I do is taking a skill and then tweaking it and tweaking it some more. I just don't think that anyone creates exactly what you need at any given time. And that is one of the neat parts of doing this kind of agentic development. People are so worried about having things taken away from them. But I find myself really injecting a lot of myself into what I do. And I find that really interesting.
Nick C: I have a ton of thoughts there. My journey into software development was, like many things that we've discussed about my life on this podcast, kind of born of spite. So it's very funny to have gone full circle right now. So I got my first job in tech, capital T real tech, at GitHub. And the way that I got that was that Evernote pissed me off. They used to have a syncing problem. I don't know if you guys remember this, where if you tried to sync from your phone and it failed for some reason, it would just nuke some percentage of your notes in Evernote back on your desktop and they were unrecoverable. You just couldn't find them again. And I wanted an Everything Brain and Evernote had just nuked half of my Everything Brain. And so I got really mad and I started looking around and Googling and trying to figure out, "Hey, this new thing markdown is really cool. I like it. I grew up on a typewriter, I would really like to write like this." And this website called GitHub kept coming up and I had no idea what it was or how to use it. But all roads about markdown led to GitHub. And so I taught myself Git. I still live inside of one repository that runs basically every aspect of my life. Issues are my task management platform and all of my notes and daily journals are markdown files. And as I wanted to do more with that I added more skills. And then I was working at GitHub and I got really frustrated. I was on the support team. I got frustrated that engineers wouldn't listen to me and fix stuff. And so I learned how to be a software engineer so that I could fix my own stuff. And the problem with that is that I've now worked at so many places that did really high-level engineering, that I have a mental model for how an application should work and all of the ways it can go wrong and all of the ways a feature should be built. But I don't have any of the practical muscle around building it. And being given Claude was like being put on steroids.
Because I know exactly what I want it to do. I can tell it and I know when it's not doing it right, and I know enough of the code to know that isn't the right abstraction and that isn't what you're doing. But it's really for the first time ever that I can, in a weekend, launch this thing and have it solve all my problems. And that is insane to me. I understand that people are worried about stuff being taken away from them, but I'm watching support engineers in grassroots communities that I'm a part of ship tools for the first time ever and have no idea how to code, have no idea how to do anything. They're automating and they're fixing bugs in production code. It's wild. It's a brave new world.
Nick N: And to that end, I saw a tweet I think from Lenny from Lenny's Podcast talking about how the number of software jobs right now is higher than it has been in several years, since the COVID spike that happened. Everybody thinks it's gonna take their job. And I personally think that all of the layoffs "due to AI," that's just a cool way to spin "We've had too many people for too long," and that's not as cool to say. But I agree. I can totally feel that AI anxiety for sure. But at the same time, I am shipping more than I have ever shipped before. And honestly, I'm having more fun than I've ever had before. And I don't feel a hint of burnout. Coming out of Meta, I was toasted and I was like, I don't even know if I want to be in this anymore. And now I'm just having fun, shipping stuff, doing cool things. A lot of times I feel like that meme from The Office—Steve Carell with the long hair and the fanny pack standing next to a boss and he's like taking credit for having no idea why he's there or whatever. That's how I feel sometimes. But I have less personal connection to the code that I'm shipping. I review it, it's what I would have written, but I think I saw some video where he was basically like, "You suffer and that pain of coming to a solution on something is growth and we're just not getting that anymore because we're not suffering with the code as much." But I would argue that maybe we're suffering in other ways.
Neil: We're suffering with the AI.
Nick N: Oh, for sure.
Nick C: I'm still too much of a control freak. I'm still watching what Claude is doing and learning in some ways and I'm not—I've seen Nick work and there's 40 of them running and he has no idea what's happening at any given moment on his computer. And I can't get there—my anxiety won't let me. I'm not quite on that level. But I do think that there is more and different pain. Especially as I have it doing research for me, I am learning a lot about the codebase that I would otherwise not do, and I'm just doing it faster. Typically in solutions engineering or support engineering, you become a subject matter expert because you spend 6 months to 2 years of your life answering questions about that thing. And I have now been at WorkOS for almost 6 months, maybe 7 months now. And the net result of having these tools is that areas of the product that even folks who've been here a really long time had very little exposure to, I'm now ingesting unbelievably fast. I help one customer, I go really deep on this thing, and then the next time they ask me a question, I'm not having to do the research. I just know how that code works. And so I think that whenever an abstraction happens, there is a type of atrophy, right? I use fountain pens, so I have strong opinions about nibs and ink viscosity and stuff like that. And some people are just gonna buy a Bic and it's gonna be fine. I understand that this is a thing I care about.
Neil: We're all showing each other our pens.
Nick N: This is a Bic, in fact.
Nick C: Exactly. But I have not lost the ability to get hyper into this if I want to. I haven't lost the ability to dive into these internals if I want to. I'm still having kind of a love affair with PHP outside of AI-generated stuff, and am hand-writing that. And it's fine. It's maybe good. I don't know. We can talk about that some other time. But I get the anxiety, I get the lack of control, but my experience has just been that I'm learning way more. I'm not learning less. I'm not losing things.
Nick N: For sure. And it's fun too because you're right. I have varying projects where I'm trusting the AI more, or it's like it's known that this is just gonna be more of a vibe-coded thing. And then the SDK stuff, I'm like, "No, that has to—I have to sign off on every line of that and understand it through and through because that's code that's going into someone else's app and I need to vouch for that for sure." Because it would look bad on me and WorkOS and all of that. And so I have different states or different ways I work with projects. It's fun though, when new things come up, you get a manager that's like, "Hey, can you go dig into this or what would it take to do this?" Usually or in the past, it's always been like, "Oh, I don't know, I don't want to commit to anything. That's a lot of unknown unknowns to me that I have to jump into." And now, I just I'm like, "No, I got a buddy that will go spelunking with me and we'll get to the bottom of it."
This became very clear to me at an on-site. I think it was the GTM on-site that we were at in New York. I was in a room on meetings with—I had just shipped the CLI that did AI installing. You could run it in any project and it would just install AuthKit, which is one of our products, into your app. Figure out, "Oh, you're using Next. Okay, well, I'll install it and pull in the SDK and set it up correctly for your app and get going." On the call, they're like, "Oh, how long would it take to add the rest of the SDKs that we have?" So I had 5 SDKs that I started with and there was like 12 more. And they're like, "How long do you think that would take?" And this was on a Thursday afternoon. And I was like, "Eh, I think I can ship it by Tuesday." And I shipped it by Monday evening. Which was like, that's unheard of to be ahead of schedule on one of my estimates. And also for me to just be kind of confidently being like "3 business days from now, it'll be done." That's really cool. And it's all because I just don't even have a fear anymore. It's the fear of getting started on things. AI just completely takes that away because I can come in with the dumbest questions possible to Claude. And Claude is infinitely patient with me and guides me through it. And I can be like, "All right, now let's take this from a different angle and let me—I still don't understand, so let's break it down this way. Oh, go generate a mermaid diagram that walks me through it." And I do that constantly just because I don't have a firm enough grasp on things as I initially jump into them. If I asked either of you to do that with me, you would just be like, "I can't work with them anymore, at all." And so we just have this buddy that will do that for us nonstop. And then we can solidify those workflows through these skills, which is another amazing way to scratch my tinkering itch, which is why I fell in love with this stuff.
Neil: Whenever I do that kind of stuff, I really enjoy trying to guess what's happening. So as I'm explaining it, I'll say "I think this is happening. I think this happens over here."
Nick N: You're absolutely right.
Neil: "You're so smart." It's really fun. I mean, that conversation where I'm learning about something has become one of the more enjoyable parts of that whole process. And that's usually the first thing I do. And that makes it—that really helps with procrastination. You can kind of be silly or angry or whatever, depending on what your mood is as you're getting started with something. And it's all pretty fun.
Nick N: And it's really interesting too because the 2 examples of projects where I'm not writing the code and I'm not even reviewing the code—I'm more just doing tests around that. Manual tests, smoke tests, unit tests, a lot of unit tests. I'm not reading every single line of code. On those projects, it's still amazing to me that when someone asks me something specific about them—that's Case and the CLI for me—when someone asks me something, I can go super deep on the technical bits of that. And it doesn't matter that I didn't write—the CLI is like 50,000 lines of TypeScript now. And I didn't write a line of that myself. And I can go super deep and tell you exactly what it's doing at every step. And that's really cool because I have found that level to come in at where I only need to understand it to this level and anything below that, it's just artifacts to me. And that's how I'm starting to think about these things. These are much lower stakes projects in that if there's a bug with the CLI, I can quickly fix it. It's not something in someone's code. I don't know. It's a new way to think about things, but also I'm very surprised that when people ask me questions, I'm not just like, "I don't know, I didn't write it." No, I know what it's doing. And I suggest and coerce it to go in specific ways. I'm a big state machine fan. I wanted it to use state machines for everything. And turns out that's a great solution for AI projects in general, just keeping them on task.
Neil: That's really interesting. I don't think I've heard someone talk about it, but it does seem like one of the ways in which AI allows us to work is a better fit for how our brain stores memories. Because if you're just working with something that you have to go really deep on right away, it's completely overwhelming and you're really gonna have trouble connecting those dots, especially because that level of depth is draining part of your memory. And AI really gives you that chance of making that first level connection and then digging a little bit deeper the next time and digging a little deeper the next time, to where it just seems like that's really freeing up your mind to work the way that it's meant to work.
Nick N: Neil, you're like a summary skill that said what I was trying to say much better than I did.
Neil: It's an interesting thought. I'm gonna fall asleep thinking about that tonight. I'll say, I've really wanted to blog for a long time. I think I'm gonna pull out that new post skill and give it a try every now and then.
Nick N: Let me give you a hack or a cheat that I've been thinking about a lot and I tried it with—I wrote a blog post a while back. I forgot which one it was. But let's say that you want to write about something that you've been working on. How have you been working? You've been working with Claude, right? Or with an LLM to do it. So you can tell Claude—tell the post skill—to go analyze your Claude transcripts from that project over the last 2 weeks or for the specific features that you've been working on and have it pull out information. I did it for the evals one and it pulled out these anecdotes about how I was coming to these revelations about how evals worked and highlighted those in the blog post. And that was just amazing to me because I was reliving my own highlights through that. And it was totally mundane things that I was like, "Oh yeah, that makes sense." And it was like, "Oh, once we got you to understand this, then everything changed and we were streamlined." It's just so cool, reliving it through that. So you can use that to just build up the context about how the sausage was made, if that's the type of blog post that you want to write, which is really cool. And not something that you just immediately think about—Claude can analyze its own performance and do things based on that.
Neil: Giving story to your own life is something that is interesting. I mean I haven't really explored it, but that's really fun.
Nick N: Well, Nick, any parting thoughts before we let you go? Any insights or hacks or cheats that you wanna showcase?
Nick C: I mean the biggest cheat that I can say is I spent a lot of today helping some folks on the GTM team set up Claude Code and in particular set up GitHub because they've started generating stuff and they've gotten to the point where they're like, "I don't know how to share this with other people." And so we had to talk about putting it in a repo. And then we had to talk about what a repo is and why this works. And then we got to the end of that and they were like, "Okay, cool. So when I do something on my computer, everyone else can see it." And I was like, "No, that's deploying. That's different. That's a totally separate thing. We'll have to talk about that later." And the theme over and over again that I kept—I watched it click in someone and it was that she was like, "Oh, I need to go write up everything that we just did." We had this whole session in Claude—in one Claude Code session—we got it all working, whatever. And she's like, "Oh, I need to go write this up." And she started handwriting notes. And I was like, "Oh, or you could just tell it to generate a draft of the things that you want it to do, like what's the shape of it." And I think the biggest hack is just tell it to do more stuff. Refuse to do manual labor. Refuse to do repetitive work. If it has a connector, if it has an MCP service, give it a shot. Do it yourself and let it run in the background and you'll be surprised what you're capable of doing if you build a skill and then hate that skill and be really mad at it and then tell it why you're mad at it and watch it repair itself and fix itself over time. You finally have a mirror that you can look at and yell at that actively gets better and improves over time. And I think that's powerful in a way that takes a while to connect if you're used to computing being this scary fragile thing. If you're capable of just kind of being like, "No, that wasn't right, do it this way. Okay, that was almost right. Do it more." And that person is infinitely patient and that person continues to generate things and is even capable of cleaning itself up. I think the more you lean into that, the better it gets.
Neil: That also makes me think of—it rewards thoughtfulness too. It does ask a lot of you in terms of thinking through why you want something, how you want it to be done, and really take time with it. You don't have to, but when you do, it really can give you some outsized rewards.
Nick C: Some of my best hacks, the things I've come up with, the plugins that I've shipped have come from me watching Claude burn its wheels and being like, "Stop doing that. This is what I want you to do instead of running down this aisle." And then that leads to a whole other road where I do something else.
Nick N: For sure. Don't be afraid to stop Claude. Interrupt it.
Neil: Well sometimes you have to stop yourself. Every now and then you have a bad day and you've spent an hour yelling at it without really stopping to think about what you should have been saying.
Nick N: Also, just go. It's so easy to refactor things or to shape things and go a different route. Throw the spaghetti at the wall and see what sticks and then move on. Rather than plan it all—that's such a powerful unlock with all of these tools too.
Nick C: I feel like I don't want to be the "no safety, just go" guy. And I don't run in dangerously skip permissions mode the way that you do, Nisi, almost ever. But I will say that as someone who came of age on the internet when convincing people to run `rm -rf / --no-preserve-root` was a fun joke, and as someone who got bit by that and had to explain to his parents why he fucked up his computer and rebuild it and learn a lot of the internals there—fuck up. Actually break stuff. Do it so much that you are actually doing something scary. That is the actual way that you learn how any of this works. It's been how I built a career: just break the thing and then go, "If you pay me, I'll fix it." And then you're pretty good to go from there.
Nick N: Amazing. That's a great spot to end on. Nick, thank you so much for joining us.
Nick C: Thanks for having me.
Nick N: Neil, any parting words?
Neil: I don't think so. I think I've done all of my philosophical speculating for the episode.
Nick N: Great. Well, just like Sisyphus, we'll keep pushing this up the hill and we will see you next time.
Neil: We actually ended the epi...