AI Skills with Matt Pocock

I got the grilling of my life in building a pretty simple API endpoint using the GrillMe skill. It asked me 35 questions, I kid you not. It was intense. And annoying. And it forced me to think more. Today's guest is the creator of this popular skill, Matt Pocock. Matt is a developer turned educator, well known for his Total TypeScript series, and now for his AI skills and educational videos. Today, we cover Matt's unusual path into tech after years of being a voice coach and building his own DIY coaching software. Matt's popular skills, GrillMe, Wayfinder, and why these skills became so widespread. Taking inspiration from decades-old programming books to build better software with AI, and many more. If you want to understand which software engineering fundamental approaches remain very useful when working with AI agents, this episode is for you. This episode is presented by TurboPuffer, vector and full-text search built on object storage. It's fast, cheap, and extremely scalable. This episode is presented by Linear, and I wanted to take you back in time to remind you how we used to get work done. Back when every line of code was written by an engineer like you or me, a tracker's job was to keep people in sync without slowing people down. Linear was built to be fast and low friction, and you could tell. In last year's The Pragmatic Engineer survey, Linear was the most loved tracker tool, and Jira the most disliked one for its sluggish performance. And data coming from The Pragmatic Engineer audience showed how Linear started to gain traction against existing tools, especially at startups and mid-sized companies. And since then, Linear grew up. They added all the stuff that larger companies need to manage work. Projects, initiatives, roadmaps, and customer requests. And large companies started to switch. For example, healthcare company Oscar helped move 600 engineers from Jira to Linear. OpenAI started with 100 seats and moved all 3,000 staff without any mandate. Coinbase, CashApp, Brexit, and Ramp are all on Linear. Many of them saw Linear as a way to consolidate a single tool that brings planning and building together. So now, let's fast forward to today. When you have AI agents inside a company, those agents need context to work well. They need access to things like specs, customer requests, history. Oh wait, these are all already in Linear. So when agents arrived, Linear became the ideal context layer. Today, 80% of enterprise workspaces in Linear have adopted agents. You can use agents like Codex, Cloud Code Linear Agent, or your own agent. Coinbase and Ramp both built their own internal agents and describe Linear as a place that their agent goes and picks up the context before starting work. See how it works at linear.app.pragmatic. Unlike many people in tech and on this podcast, you didn't start out to study computer science, right? Absolutely not. So for six years before I became a developer, I was a voice coach. I was a singing teacher working in London and working in Exeter where I went to university. I was teaching accents. I was teaching singing. I was teaching voice. I did a master's in it. I spent a lot of time thinking that was what my career was going to be. I didn't have any inkling of tech, didn't sort of think about it at all. I sort of ran my own website and stuff. But yeah, so I did that for a long time. And it's been an extremely important influence on my life. And I think my personality as well. Can you get a bit deeper, where did this voice come from? And what do you do as a voice coach? Who are people who came to you for help and what kind of help? So I started as a singing teacher. I was in a band and stuff at university. I sort of had a bit of experience doing singing. And so I set up my own company kind of at university and doing that stuff. And it was people who just wanted to sing better, who wanted to use their voice for choirs, who wanted to just do it as a hobby. It wasn't anything particularly professional. And I went and did a master's in it. And I started going to drama schools to teach people Shakespeare and stuff and like getting people in who wanted to do public speaking. I did a couple of big gigs for consulting companies, going and teaching them how to deliver speeches and how to talk better. It was wild. The reason I got out of it was because I realized in order to do it at a decent level, you had to live in London. I didn't want to live in London. I tried it for like two years. I just hated it. I hated it. I didn't grow up in London. I wanted to get back to the countryside and where I was from. And that's what I did. And so I learned how to be a developer. I was essentially self-taught in order to have something I could do remotely. So basically you were looking at like professions that you could do from outside of London that had a career or perspective or future. Exactly. And I was, I sort of taught myself how to build stuff and just sort of build basic stuff in JavaScript because I was interested in making my lessons better for my students. So I'd actually made sort of little flashcard apps. I was working like the first app I ever built was the most ambitious thing I've ever attempted. It was like a web audio analyzer. So I could analyze the spectrogram of your voice to see which resonant frequencies were happening, whether your T1 and T2 were like properly balanced and things like that. Extremely in depth, ran terribly, but actually made my lessons that little bit better. And so I was doing pretty hardcore stuff terribly straight away. And I realized, okay, I started looking at job postings and I thought, well, I could do a bit of JavaScript. I could do a bit of SAS. I could do a bit of bits and bobs. And I just jumped into it. I quit my job, had a couple of months off and eventually got a job. This was about 2017 where it was a little bit easier to get a job in the UK than it is now. And I just went from there. I guess in some ways you were also lucky because that was the peak. That was a time where demand was so high for engineers that people had to boot camps with a few months of experience. And I think people got a lot of chances from a lot of places who had the drive and the motivation and the smarts, right? Yeah. And because I had this history of talking to people, that was an unbelievable advantage, right? I could actually go into an interview and sound like a reasonable person instead of someone who comes straight from a CS degree who maybe didn't have those skills. So I had this bizarre ability of having zero technical knowledge or very little in the beginning, but the ability to explain technical knowledge to people, right? And so that basically all I needed to do was increase my technical knowledge a little bit. And I was very passionate about it. And that increased quite quickly. And then it was sort of seemed to be an unfair combination because I just rose through the ranks very quickly in various different companies. And I don't know, it felt, I felt different from the other software developers I was working with. That makes sense. And then how did you step up on the ladder? So like you decided I'm going to do this. You taught yourself. You went to some interviews. I'm assuming it has been a small company, right? Yeah. A tiny company with a couple of really inspiring software developers who work there, basically a guy, but I won't say his name because he likes his anonymity, but basically a guy who lived in sandals, who lived in a canal boat for a long time, like a, you know, long hair, proper hardcore. You know, it was around the time that Microsoft bought GitHub. I remember him coming in almost in tears. Yeah. Microsoft hater. Absolutely. The class, you know, I remember first thing he got me to do was set up CentOS 6 on my, on my Windows PC. Oh, this is a Linux. It's a pretty hardcore Linux distribution. Really hardcore Linux distribution because that's what our application was running on in the cloud or something, you know, so really lovely, wonderful guy and someone who taught me a lot straight away. And so basically that company ran into financial troubles. And so I had to move to an agency pretty quickly and I got a higher job there. From there, nine months later, I moved to another agency and then another agency, just sort of bouncing around different agencies. And then I was working in open source, which is kind of the next part of the story. And with the agencies, what tech stack were you using at the time? Yeah, it was TypeScript. It was React. Oh, it was TypeScript already back then. Well, I was pretty hardcore on TypeScript already, almost as in my second job. I think I was doing, you know, presentations on how important TypeScript was. We were working for a automobile manufacturer building a learning management system, right? You know, classic, boring agency stuff, right? And the front end team at that time was pretty small and we had a backend team in Portugal, right? So classic front end, backend split. The backend team were racing ahead. And at the time I joined, the front end team was really slow. We had a ton of bugs. The backend team kept changing their contracts without telling us. And we thought we need something to link us up a bit better. TypeScript felt like the obvious thing. And once we shipped it, our velocity just went, you know, we were faster than the backend team. And eventually they took people off our team because we were so quick. So yeah, that was my history with TypeScript. That's kind of my origin story with it. How did you get into open source? Was it at work? Was it on the side? It was, I would been constantly playing around with open source on the side. And I was interested in different things. By then I was into Twitter. I was sort of looking at people online and thinking that's something, someone I want to emulate, someone I want to look at. And there was a guy who crossed my radar called David Korsheid, who's the state machine and TypeScript guy on Twitter. A lovely, lovely guy. And I owe a lot of my career to him really. And I was working on a project. This is, I think, in my fourth job where we needed a state machine. It was a very complex application where you were on a video call with someone and you could navigate around a house in real time together using some sort of Matterport integration. And there was a lot of linking up that needed to be doing across the network boundary, a lot of complicated states. And so I used a library called XState at the time, XState version four, I think. That was a resounding success. And so I wondered, okay, how can I make this more type safe? And so I started to sort of build some tooling around it, have a fiddle built, a sort of CLI that constructed around it. And that got me the attention of David and I became a member of the XState core team. So I started contributing issues. I started having discussions about the implementation for TurboPack and met some of the team. Which was a lot faster build system, right? Yeah, it was a build system. Essentially, at the time they were trying to rival Webpack, what they were working with. And I was there initially when they were building the docs. I flew out to San Francisco. I was there for Next.js Conf when they announced it. You know, big, you know, really fun experience, and, like, I was, you know, there with everyone while they're, you know, getting everything ready for it. And so, you know, I do that, and already in the back of my head I'm thinking, I've seen the newsletter, sort of from my Total TypeScript stuff, creep up. I understand, okay, there's something really big here. And when I made a pre-release sale, that just went crazy. I was earning, let's say, X at Vercel, and that was like 30, 40X or something. You know, it was immediate. And X at Vercel was already a really, really good compensation. Absolutely. Very, very, very happy with that. But yeah, so I just, it was obvious. There was no other decision I could make. I loved working at Vercel. I would probably go back at some point, but I just couldn't stay. So I had to do this thing. And then tell me about Total TypeScript. So you had this idea. You started to build it two days a week on the weekends, and then you did this pre-release sale. Yeah. What's the— I almost, I try never to work on weekends, basically. I'm extremely radical about this. I just, I don't know. I mean, I think it's something I mostly fail at because I'm a quite obsessional person. I like trying to make something work, but I'm not one of these guys who's doing— what was it like? What's the SF thing where people go like 996, six days a week? 996. 996. It turns my stomach. You know, I just hate that stuff. Like, I am trying to, with everything I do, build a lifestyle and build a— A life where I can spend most of it with my family. That's my goal. And so, just to prefix that with all of my decisions after that hopefully make more sense in that light. So Total TypeScript, I was working with a guy called Joel Hooks. Joel Hooks is extremely funny, extremely influential on me. I've worked with him now for four years, and he came up with Egghead. He's worked with Kent C. Dodds on his courses, extremely successful course creator in the background. And I basically reached out to him and I said, Would you like to make this course? And he said, Hell yes. And we went from there. And so straight while I'm at Vercel, I'm also working with Joel, and we do this pre-release, and as I said, it just goes nuts. And I realized, okay, I've got to fully commit to this. And we get to, I think about January 2023, February 2023, and we release the full course. And I don't know, I think I need to look at the charts from around that time, but it reaches seven figures extremely quickly. And that's a revenue split between me and Joel, of course. There's expenses in that, but in terms of raw revenue, it was extremely exciting. Yeah, but the seven figures, that's one million dollars, which is, I mean, incredible milestone, right? Just nuts. Yeah, you know, and life-changing. And I realize, okay, I can wake up in the morning and this money is still going to come in. You know, this is something that I dreamed about for a long time when I was a singing teacher as well, making material that I could sell online. You know, this is something I'd been aiming for for a long time, sort of high-leverage work where I can do the work and then step back and go back to my family. And for the next couple of years, I worked on TypeScript, sort of expanding the course, selling a couple of supplementary courses. And yeah, that's basically where Total TypeScript was. And so that was the main portion of my success in the last four years has been Total TypeScript and building that out. Yeah, and Total TypeScript has been very inspirational, especially that you openly shared a big milestone when it hit two and a half million dollars of total revenue, which again, I think for many software engineers, that is, of course, we know this is before revenue share and there's expenses involved as well. But it's something that is pretty clearly a higher earning potential than many great software engineering jobs. Not necessarily all of them, especially when we're looking at the US and some of the AI labs and whatnot, which was probably an exception. But the fact that there is a market and a business to be made of what I feel is a bit kind of an honest model in the sense of like, hey, I created this thing, people pay for it because they want to learn and they hopefully get value from it because otherwise they would ask for a refund, right? Exactly. We do like a very extended refund policy. I don't tend to want to accept any other forms of money either. I don't like necessarily doing sponsored content. I'm not going to say never, you know, but I don't really—I've got a GitHub Sponsors page, but I'm really trying to take it down. For a long time I've been trying to take it down. I like the idea of just being someone who has, okay, these are the products you can buy from me. This is how you can support me. And hopefully this gives you, you know, 10x in terms of returns because this is a very lucrative industry, right? Like, and a lot of people have education budgets that they can spend. And if you want to spend some of your education budget on me, that's basically my model. And a lot of that money, a lot of the people taking the course, this is from people's education budgets. You know, this is companies coming and spending big on education. And that was a market that Joel was very key in pushing me towards and realizing this. You know, I didn't have much of a sense for— How much money was sloshing around in the industry, especially in that age, and honestly still. But the fact that it just hit that milestone so quickly within a couple of years, I mean, life-changing. Well, I mean, this sounds like an amazing story, and it could be a fairy tale ending where, like, you keep creating educational content for the rest of your life and it's highly in demand. But then AI happened. Yeah. And as we know, it's changing a lot of how we work, how we find information. For example, like, I don't Google that much. I actually work with AI agents or deep research or some of those things. I heard stories about educators, online educators, who are saying that their revenue and market share and mind share is just falling down because people might not want to sit through courses or sessions when you can just turn to the bot. How did you see AI impacting the industry, how people learn, and also your business, and also you as a teacher? It's complicated because AI has changed the game, right? It's changed how important knowledge is and specifically the types of knowledge that are important. So when I'm teaching my courses, I sort of think of there as being two layers. I'm teaching the syntax, obviously. I'm teaching the what, but there's also the why behind it, right? And it's very hard to teach the why without touching on the what, if that makes sense. So the sort of medium is I'm going to teach you this syntax, and maybe you might gather the sort of wisdom around it, right? I'm teaching you knowledge, but I'm also trying to teach you wisdom. Knowledge is now very cheap to acquire, right? Very, very cheap. You can just look it up. You know, you can. I have a teach skill that can just take you and just, you know, teach you the knowledge that you need. But the wisdom has got no easier to learn, right? It's still knocking about. Like, you are still going to run into the same issues that you ran into if you didn't have that wisdom before, even with AI. So. In terms of, like, my revenue from Total Tactscript, that's gone down, obviously, because I think people are not so interested in that material anymore. And I think people teaching that material are going to find it tricky because, again, that knowledge is really, really hard to come by. The only way that I've been able to not necessarily survive, but it took me a long time to figure out where I wanted to be in the AI space, because I'm not a researcher from OpenAI. I don't have the credentials to, like, talk about this stuff really, especially in 2020. Late 2023 was when I started looking at it. And I was initially making courses about how you put AI into applications. I thought, okay, I've been building front-end applications for a long time. It makes sense that AI is changing things a bit there. Started to be clear to me that that was the wrong bet to make. I wasn't sort of seeing the returns I was expecting. And I didn't, like, the material was good and I feel proud of it, but I didn't think I wanted to make more of it. And around December last year, which is a date that many people cite— Oh yes. We know, or as we call it, kind of the winter break where everyone came back AI-pilled. Yeah, exactly. The Peter break, right? The Peter break. The open-claw break, when OpenAI's 4.5 is out, people have a lot of time off and they just start slamming it and they realize, wow, okay, things are really happening. And that happened to me too. And I realized, okay, the AI is now good enough that you can delegate to it. You can actually make structures around the agents, and the agents can handle the knowledge, the syntax, the sort of, I call it the tactical stuff. Yeah. And you can handle the strategic stuff, the long-term thinking. I use that a lot. I know you had John Osterhout on this podcast. I've been really wanting to chat to him myself. Like, he's a huge influence on me. And he talks about the difference between tactical programming and strategic programming. AI has largely eaten tactical programming, in my view, and it's up to us to handle the strategic. And I realized, okay, in the strategic layer, there's a course I can create there. I was looking at Ralph Loops at the time. Sort of Jeffrey Huntley was building this really cool stuff where you can loop the agent and get it to follow these goals. And I thought, okay, there's definitely material here. I just need to find a structure within which I can put it and organize how to fiddle around with it. And I remember with the Ralph Loops, you also made a video that became very popular on YouTube, X, everywhere, where you basically said, like, all right, like, here's how I created a Ralph loop. Like, here's, I have a project that has a lot of, like, to-dos, and you did a great job in— Authentication, do you want the bearer token or do you want it in JSON, which is not as safe, et cetera. I'm like, okay, well, that's a decision to make. And then we go through all of these decisions, and it goes really low level, including like, okay, like how do we enforce rate limits? When it comes to rate limits, do you want to exactly do it when you get like a thousand per day and not allow a single more, which is more complexity? And I just realized it's been a long time since I've had such an involved design discussion with a team or an engineering team. And you typically have it when someone has deep domain knowledge. And I was both annoyed by, this is just simple, like, no, don't worry about that, but also impressed that this thing, this AI, this LLM, through a series of prompts, is able to do all of this. It's, I mean, everyone's got a grummy story, so I get so many of these in conferences. People say, you know, you've this very, very simple skill. It's really just telling the agent to interview you relentlessly about the topic. It's a very small skill. It just has this weird emergent behavior with it, where the models just start thinking a little bit outside the box, and they start throwing ideas at you. I think I got it originally from like a Tariq who works at Claude Code. He's saying basically, get the agent to interview you, and then you'll see better results. So I encoded that into a little skill, and I realized, wow, okay, it's just sort of ten times better than anything I've ever used. And that grummy skill was the first one. That sort of reminded me of the discussions I would have at my first job, you know, with the guy with the sandals. It's this very senior engineer in the room really getting me to think about everything that I'd done. It was the most familiar thing to me to actually working with someone like Andrei Ristake at Xstate. You know, it just felt like a really high quality developer was asking me these good questions, and I thought, wow, okay. And then I started sort of taking that and going like, how do I mine this? Agent for more software fundamental stuff. How do I make it feel more like a proper developer, a real senior? How do I tickle the right latent space in order to get its behavior to change and challenge me in an interesting way? Because if you can do that, if you can increase the quality of the conversation you're having with the agent, you're going to increase the quality of the outputs. What I liked about the Grill Me skill is it forced me to make decisions that I know what decision to make when I think about it, but it is my decision. So unlike when I tell, when you do the slash goal command, like build this. And it goes off and does this, and it makes all the decisions, or most key decisions. What I like about Grill Me is I both make the decision, but also sometimes it reminds me about things that I didn't think too much about, or maybe reminds me that I should do a bit of a research. For example, like it asks me, like, which authentication would I want to do, bearer token or OAuth posts or even OAuth. And then I'm like, hang on, like, I'm going to look up, like, what the differences are, or ask a different session to educate. So, like, it makes me a better professional. And I do have this belief that when you're working with AI, like, as long as we're learning, I think we're fine. As long as we stop learning and outsource the learning to this thing, trouble will be brewing maybe, you know, months or years down the road. 100%. There's two things there, right? I think what everybody underestimates about agents, everybody, is that there is a communication gap between you and the agents, right? There is a barrier there. You feel like, because the agent is not a human and because you understand your hierarchy of values, you think that the agent will just pick up on them, right? There's this sort of feeling of, yeah, just trust the model, especially with the top-tier models, you know, just trust the model. But the agent, however good it is, however smart the model is, you know, even Mythos, it can't read your mind. It can't read your mind. So you have to, there has to be some process of communicating your values to the agents, because often when you do it like a goal, when you just go, okay, just spam me out some code, give me some slop, the agent is going to produce something that's totally misaligned from you because it doesn't understand what you think is important. And so Grill Me is not only about implementation details, it's also about establishing, okay, do this, this is in scope, this is not in scope, here's what I think is important. And so it's the agent getting to know you. Matt just described the Grill Me skill. When I use this skill to design an API endpoint, the first questions it asked were about what the endpoint was and wasn't allowed to do and who it was allowed to do it for. Now, in my case, I had a decent idea of what I wanted, but it's generally a terrible idea to let an agent Agent improvise authentication and authorization, as they would often do. This brings us to our season sponsor, WorkOS. How do you authorize AI agents? The problem you have is how you want to control the scope of the agent. The tricky part is how permissions are static, but the job of what the agent does is dynamic. So teams pick between two bad options. Either you read the prompt, then approve every tool invocation called by hand, and then read the prompt again, then approve by hand again, until you eventually just stop reading the prompt. Or you just run in YOLO mode, letting it rip and hoping that whatever the agent does is not irreversible. But there's a better way. WorkOS just launched Airlock, intent-based access control for agents. You write the rules in plain English. For example, read repos and comments on PRs. Anything touching auth or billing needs sign-off, never push to main. Every call that the agent makes is judged against this task and allowed, denied, or sent to a human. Every verdict is logged by Airlock. The neat thing about Airlock is how there are no pre-granted scopes and there's no roles to assign. The task itself is what defines what the agent can do. WorkOS Airlock is in early access. Request it at workos.com/airlock. I'd also like to mention our presenting sponsor, TurboPuffer. Matt and I are discussing a fundamental question: how do you get agents to remember what's important? Here's an idea. What if instead of building a complex memory system, you just let the agent search its entire history? This seems like it would be very, very expensive, but with TurboPuffer, it isn't. TurboPuffer's object storage native architecture means that the marginal cost to store a session transcript is almost nothing, making it economical to index the entire chat history. And because TurboPuffer natively supports scale virtually without limit, you can create a dedicated search index for every agent. Here's a good example of this. Entire, another season sponsor of the podcast, indexes hundreds of millions of agent session transcripts for search and then lets the coding agent retrieve what it needs to recall how and why an engineering decision was made. Entire showed that their agent was more accurate, used fewer tokens, and took less time to find memories when it used TurboPuffer instead of Git history and a CLI. Agent memory is a complex and evolving use case, but perhaps there's a better lesson here. Maybe the best solution is the simple one: just search every transcript. With TurboPuffer, this is actually possible. If agent memory is something you're trying to solve, then please reach out to the TurboPuffer team at turbopuffer.com/pygmatic. And which other skills did you create? So from there, I thought, okay, how do I take that conversation and turn it into code? And I was immediately scared because I'd been working with models, you know, just before they were good and before the December winter where, you know, things got really good. And so I felt the constraints from what I'd been working with before. I knew that, for instance, the more context you put, you give to the agent, the worse it performs. I know you had Dex Horthy on this podcast, and Dex is a really big influence on me, especially his idea of the smart zone and the dumb zone. Smart zone and the dumb zone, yeah. So idea of that, just to kind of, so you don't have to go and listen to that podcast in full, although you should. You have essentially, the more context you give to the agent, every token is shouting for attention. And the more voices you put into that room, the harder it is to hear the important ones. And so the model starts losing the connections between things and making mistakes because of that. And you can think of that as a slow decline, but there is a portion of the context window where it's better and where it's worse. And so you have the smart zone, which is currently, I would say, about the first 150,000 tokens of frontier models, of a 1 million token window. Yeah, of any size token window. Of any size token window. It doesn't matter the context window size. It's all about raw amount of tokens, raw amount of attention relationships. And then the rest of it will slowly degrade more and more and more. And so I started thinking, how do I take work that's bigger than 150K tokens, which is not very large, and portion it out over multiple context windows, multiple sessions? And this took me a lot of tries, a lot of different fiddling around with different approaches. The Ralph Loops was one version of that. Ralph Loops are designed to make the most of the smart zone because they essentially just give the Ralph Loop a goal, and they say, do the smallest possible change that will get us further towards that goal, and then clear your context. And then clear the context, start from fresh. Exactly. And you're not technically starting from fresh because you've got the code base, right? There's a little bit of state saved in the file system and in the environment, but not in the model, essentially. So that's the idea. So I started thinking, how do I take that Ralph Loop idea, but make it a little bit more stable and turn that into skills? And so what I realized I needed was two different types of documents. You need a document for where you're going, which is the destination document. I used to call that a product requirements document, or a spec is what I call it now. So that's the specification that declares when you've reached the end. And then you need to break that spec down into individual tickets, one ticket per session. And so I'd have a very simple skill just to spec and then to tickets. And so you take that grilling session that you've had and you turn it into a spec. Now that spec can work over, you know, 30, 40 tickets, let's say. You can have really massive, great big chunks of work that are all tied into that spec. And so that's the main idea. You just grill, you turn that grilling into a spec, and then you just run some kind of implementer loop over those tickets until you've got a huge chunk of work. After the grilling, do you get user input as well, or throughout this process, or it depends? I was mostly designing this to be run for the user, like to be away from the keyboard totally, because there's this idea of, like, the day shift and the night shift. Have you heard of this? No, no, no. It's great. Basically, the optimal way to— is just garbage from the agent. It just can't handle it. And so I think in those sorts of professions, if you can turn—I assume they're doing simulations, right? I assume they're doing some kind of, you know, I don't know if you have like a Linter that can work on architectural diagram. I'm sure you have some variety of that, right? Some simulation. If you can make that text-based, if you can take the interactions that you have in your day-to-day life and turn them into text, which mostly they are anyway, then the agents are going to do a pretty good job. That's something I'm trying to do currently, is take all of the services that I use and plug them into agents, right? Make them available to the agents. But yeah, the more we can make our work agent-friendly, the better results we're going to get. Circling back to AI as a whole and what has changed, like it has changed so many things, but one thing that comes up with AI is often, especially researchers and people working in AI companies, is no priors. With AI, you should let go of everything that we know before because this thing is different. Start from scratch. The approaches might not work. In fact, let's assume they don't work and come up with new approaches. Having been a developer before AI and actually, like, you were really interested in building quality, great software, how much do you think AI has changed of everything, including the fundamentals? This is something that I thought too. I thought, right, AI has changed everything. I'm going to throw the baby out with the bathwater, right? I think we just need to look at everything in a new way. I started doing that a lot. I was especially looking at, like, spec-driven development, you know, which is—I have sort of mixed feelings towards. I think it's a strange term. It encompasses too much. And I thought, okay, right, maybe English is the hot new programming language, right? Which went viral at some point when Andrej Karpathy posted it. Exactly. Maybe I can just write a spec, and that specification is going to be persistent. It's going to be something I can edit and just get the agent to change it as it goes. And as I experimented with it, I tried it a lot, and I was just getting worse results than if I'd coded it by hand. And it wasn't getting better as well. And I noticed that every time I would sort of run this loop of change the spec, see the code change, the code would get worse. You're not supposed to look at the code, of course, but I looked at the code and it was garbage. And I thought, how is the agent going to perform well in here? How is it going to work? Because the feedback loops are so important to the agent. If you have a bad test suite, the agent is going to get bad signal from it, just like a human would. And I thought, how do I improve the test suite? How do I get this setup not Not like churning out garbage every time. And I just, I opened a book that I had on my shelf that I think was still wrapped in plastic the first time I took it out, which was The Pragmatic Programmer, which is everyone told me to read it. Everyone, like, you know, everyone said, you know, this is the best book ever. You just got it, and I bought it and I didn't read it for some reason. And I opened it, and it had a whole chapter, a whole section on software entropy. And software entropy is the concept that, you know, entropy is the idea that things go towards a more disordered state, that that is more likely than them going into an ordered state. And I realized, okay, software entropy is inevitable. What I'm seeing here is that agents are producing software entropy at a higher rate than ever. And I started looking more into that book, and almost every line I read, I thought, wow, this feels like it was written for today. You know, you should go back to that book. These ideas of, like, don't outrun your headlights, always work within your feedback loops, programming by coincidence, traceable, so many smart ideas. And I realized this book has been out for 25 years, right? This is probably in the agent's priors. Maybe if I just mention some of these concepts, especially the ones that are really pithy, like traceable, for instance, which is the idea that you should always get feedback really quickly on the work that you're doing. I guess the idea of the traceable is, right, you, like a traceable that leaves a mark. You implement a path that works like an important piece of a software instead of, like, building a database layer and the application layer and the, I don't know, whatever layer, like building all three and then putting them together. Like, just build one part of each, but they should work together. That was the problem I was seeing with agents. They would, you would get it to build a piece of software, even with Ralph loops, and you would, it would build the entire database, and then it would build the entire application layer on top of that. Then it would build the entire React component library. Only at the end would it start actually plugging things together and getting feedback on what it was doing. And it was maddening because things in the database, like, will affect what you show on the front end. You know, you only really know whether things are actually making sense. sense when you see it crossing those integration layers. And so another concept is vertical slices, right? Instead of these horizontal slices across these different deployable units, you have a vertical slice where it gets feedback on what it's doing straight away and builds out from there. And so I just started using these phrases in my prompts when I was talking to the agent, and I started noticing that it was saying those phrases back to me. It was repeating them back to me. It was saying, Okay, I'll turn this into a traceable. Because this is a traceable, I'll do this. It was using the words that I was using in its own reasoning traces. And so this is what I call a leading word, a light verb, let's say, which is a sort of fancy literary term, where you lead the agent just with a simple phrase that you repeat a couple of times in the skill or the prompt to change its behavior. And so traceable was a fantastic one. And I just started diving into different books, all the books I could find, to try to mine them for leading words. And another one was John Osterhout's book, Philosophy of Software Design, where I picked up tons of great stuff like deep modules, which is a massive one for me. It's interesting to consider if these agents have obviously been trained on those books, just still available for print. And of course, there's arguments of like what they're doing with those books or whatnot. But if it's in their training data and the agents, as they're trained, they connect all these different concepts and, yeah, these, I guess, leading words could invoke those concepts. And I wonder how, if this is much different to when on a topic you talk with a professional and you're trying to describe as an amateur what you want, and a professional says a word that does that, and a fellow professional gets it, and you use this jargon, right? And jargon, on one hand, it's not very inviting when you join a company and there's jargon, but we use it because it makes things faster, easier, fewer misunderstandings. Definitely. That was something, that idea led me to, because obviously you've got these leading words that are in the agent's priors, right? Like traceable, all that stuff. What about describing my application? What about describing my code? How do I get the agent to— because the agents are just... Awfully verbose, right? Especially Opus 5, for some reason people really go after that model for being verbose, and it really is. And I thought, how do I get it to be less verbose? How do we start talking a common language between me and the agents, this communication barrier again? And it led me to DDD, domain-driven design. Eric Evans' incredible book where he talks about ubiquitous language, a language, again, really deep in the agent's priors, it understands it really well. I sort of started. Toying with the idea of maybe changing Grillmate a little bit, because Grillmate is a very simple skill. But what if we, while we were ideating, while we were thinking about the application we were going to build, what if we were also building a domain language? What if we were also deciding on the right terms to use? And this turned into a skill called Grill with Docs, which is a terribly named skill, but it essentially creates this domain language as you go. And if you get the agent to use the domain language, the difference is night and day, because suddenly you're speaking the same language. You're able to describe the things you want to change in so many fewer words. Like I had this app that I sort of work on. There's this complicated interaction where there are ghost lessons and real lessons, and what happens when you turn a ghost lesson that's inside a ghost section inside a ghost course into a real lesson? That means the ghost section needs to become real, the ghost course needs to become real. How do you explain that? Well, that's the materialization cascade, right? And you came up with these terms. Yeah, with the agent, right? The agent is actually really good at coming up with these terms, and so I have a domain modeling skill. And we talk about jargon, but really it's domain language. And if you can integrate that, and integrate that not only with the way you talk about the app, but the app code itself, then you've got a stew going, right? Like, it's very, very exciting. And it means that the agent can navigate your codebase a lot easier. It can find the functions that mention that specific domain terminology, you know, just with a simple grep. It's just gorgeous. So that's something I've been really integrating with every part of my setup is DDD. But this is so interesting because in an effort to make these agents work more efficiently or do workflows that just mean that you can produce better software with fewer mistakes and these things, you start to go back in time, found this book that is now, I think, what is it, like 20, 30, 40 years old, and you're even still going back and finding gems from, I'm sure at some point you'll get to the mythical man month. Yeah, I've got it already, absolutely. Which is now more than— More than 50 years, and you're trying to find the right words to describe things, which is very curious because when I talk with Kent Beck on how they used to program with Ward Cunningham, as they were coming up with the concept of actually just domain design patterns, they had a thesaurus with them, and they would look through trying to find the right word that has the right meaning, and they had it on their desk. Right now, this feels we're going back to the fundamentals, the how that people have been asking themselves, and every now and then people write it in books, and it kind of spreads as wisdom, and now we're back to where we started, which is what you're trying to teach is the wisdom part. It's wild, right? Like, because AI is so different to humans, you need to optimize it. Imagine you essentially had a human who wakes up every morning and cannot remember who they are, right? The guy from Memento, you know? This is Memento-driven development, right? We are trying to optimize our codebases for new starters, so we're trying to have the most healthy codebase that we've ever had, because if you, a human, can work around a bad codebase, they just... Assessing failure rates. We've never been able to have that with, like, developers before. You know, that's kind of invasive for developers. But for agents, it's like, it's okay. It's okay, right? We are paying for this service, right? We need to understand how well we're optimizing for it. The first step there is actually getting a harness or observability around your agents, the entire organization to work out what's working and not. And you probably need someone whose job it is, or part of their job, is to look at that data and figure out what we're doing. Maybe some repos in your organization have better success rates than others. And so you take the lessons that are in there and you pass them out. I also think that most organizations need to gather around a common set of skills. You need a common software workflow process so that everyone can contribute back to it, so that you can experiment with things, you can A/B test things. You know, you can have one team doing one set of stuff and one team doing another set of stuff, and then you pass them afterwards. And so everyone working with agents in any kind of organization needs this experimental mindset. You need to be thinking, how do we get more juice out of these tokens that we're spending? And observability is the first step there. Yeah, and I also wonder if there's a human feedback loop in the sunstopped. I mean, just talk to your colleagues. Like, we do have rituals, team meetings, company-wide meetings for a reason. Like, there, share, here's what's working for me. Here's where it didn't work. Here's what I'm learning. Like, in the end, we are in charge of setting up the rules, deciding how we use them, where we use them, where we don't use them, and where we say, like, no, this needs to be—humans need to take 100%. Like, we're not even getting AI involved, which, again, will be different everywhere. And it's not only that, like, a lot of this stuff now, you don't need to be human in the loop before, right? You don't actually need to delegate that much time in order to build up a better codebase. I have loops that essentially every morning it will run my improved codebase architecture skill and give me a proposal for something that I could improve in the codebase. And then I can just press a button. I can say, okay, turn that into tickets, and then let's ship that. That is pretty easy to do, and it's pretty easy to stream that in with other work. And so. I think that, I don't know whether you need like 20% of your time focusing on the factory that builds your software as well as the software, because I feel like that's a massive, incredible investment into your future leverage, and not only your leverage with your work, but also your team's leverage and understanding and getting better at those skills. But of course, you need results, and you might need to hide that work for a bit before you actually reveal it to, this is what we've been doing. Well, and this is down to your environment, but yeah. And no one's going to be mad at you if you come back saying, Oh, by the way, guys, I also did this. Yeah, exactly. I wanted to ask about your specific kind of how you use tools. First one is coding agents, local or in the cloud. And you recently posted a pretty provocative tweet, which I'll quote you: I'm moving away from my local dev setup. Makes zero sense to me now. A lot of people ask me, How do you make your skills collaborative? How do you have a collaborative grilling session? And the answer to that is that you need more than just your terminal and you, right? We're in a phase now where every dev has like a hundred terminals available to them, and that seems crazy. It feels like you need those hundred terminals available to your entire organization. You need to be able to collaborate in a shared space. You need to be able to ask someone, tag someone in to your grilling session and say, Okay, do this. And so it makes a lot of sense for me to have a lot of those interactions in the place where you already work, in Slack or in Discord or in Teams, whatever, or Linear. And that is really the thing that's driving me to explore this. I don't work with a team particularly, but I understand the value of that, and I've been trying to build that into my flows. So on the train over here, I'm in Discord chatting to my Hetzner box, you know, building stuff for my course or fixing bugs that students are coming across. So I can see less value now in just doing things locally when I have this setup that I can port forward into, let's say, and, you know, and like see the dev server as it's making changes and— I don't know. It just feels like it makes way more sense to me than having a very, very expensive laptop that can do this stuff. It feels like wasted compute. And especially because on that remote box, I can set up schedules. I know the box is always going to be on. I have like a morning standup with my agent where it schedules my day for me, and it understands all of my Discord chats and all that. Yeah, having that remote feels like it makes just so much more sense for me. And the only thing I do locally now is debugging issues with the remote bot. Yeah, I think I wonder if there's a question of how easy it is to replicate some pretty complicated local setups in the cloud. But once that becomes possible, it's probably a matter of when, not an if. Yeah, and if anything, people are having this similar issue with local setups, right? With just a thousand Git worktrees just spamming their hard drive. And with, how do I have a worktree that I've got to run like five Docker containers in order to get my local dev setup? Well, that's often a little bit easier in the cloud because you can just provision the resources that you need on demand. And by the way, we're seeing that companies like Ramp, Stripe, Uber, that have platform teams that manage to take a local devs full setup and put it into the cloud on a cloud machine that you can now invoke with an at Slack or a website. They're seeing people use these agents far more except for front-end work, which you still want to have that feedback loop. There are a few exceptions where you really want to have that local dev setup for latency or whatnot, but they're also seeing like 70, 80 percent of devs are just voluntarily going for the cloud. Yeah, I mean, I think you can just tunnel through and just get the— if it's running a dev server and you just have that appearing on your local machine, how is that different from having it locally, right? Fair. I don't know. I think I've not experimented with that, but that's when I talked about that and said, oh, maybe front-end is a good exception, that was the immediate response that I got. Makes sense to me. I want to ask about planning and requirements. You're a big believer in Grillme and planning upfront, or getting the plan and then having the agent work. But there's a devil's advocate here. Agents are so fast at implementing, you could actually even have, like, several, like a few agents implement different architectures. What about the approach of, like, well, they're fast at implementing, so I might not need to do as much upfront planning. I can just course correct as I go. It depends what type of work you're doing, right? Because I believe that you shouldn't be using Grillme for everything. Essentially, you need Grillme for pieces of work where the actual thing being done is going to be quite large and hard to row back from. If you feel like, okay, this feature, maybe it's a whole new page, maybe it's a big feature, this code... You think if the agent gets it wrong, then the wrong code is going to be in its context window, influencing everything that comes afterwards. And actually going back and editing the stuff afterwards and doing the alignment after the fact is going to be expensive. Whereas for those cases, it makes sense to align first, to answer all of the tricky questions like your, you know, your JSON cookie or whatever, your authentication token first, and then do it. But for some cases, like simple bug fixes or just like move this button three pixels to the left, it's obvious that you don't need to align before that. You can see the thing if it's just like a five-line change or something, you can align afterwards. And so that's how I think of it, is that where you can, you should shift right as much as possible. And actually there are actually certain features that I have a little in my video editor, I have a button that I can send feedback to it, and I often use this for very simple tasks where I send the feedback, it goes into a GitHub issue, this immediately gets picked up by an implementer agent, gets just worked on immediately. Then a code review agent comes in and reviews the code, and then at the end I get to see this actual thing being fixed, and I can do my alignment then. And that's worked really well for things that are very easy to specify, things that I don't need to grill on. So those are the choices you've got. Is it a small enough thing that I can align afterwards? Then don't use Grill Me. Does it fit into a single session? Then use Grill Me. Does it span multiple sessions? I need to align over the entire thing? Then use Wayfinder. Interesting, because this is not all that different to where some tech companies landed years before, which is on the PRD, the product requirements document. If it's something trivial, just build it. If it requires the team, like it's a team-level scope, I mean write a PRD, send it out to the team, maybe CC some other teams, but it's not a blocker. And if it's something bigger, then it's a blocker, like we need to wait for feedback. Basically the way we would say it is like, look. If it's like a one-month project, like spend two days. Like, it's not a bad thing to spend like one or two days planning it because we're going to save time on it. But if it's a one-day project, like forget about it. If it's a one-year project, I mean, what are we doing? Like, it should be a smaller one. Totally. And I want to, like, there's a bit of sort of criticism I hear just from outside the room when you say that, which is that doesn't this sound like waterfall, what we're doing? When I'm talking about Wayfinder, and when I'm doing any kind of, like, building up any kind of spec, I do a lot of upfront aggressive prototyping before we get there. That's something that comes up again, again, and again. It's like, this is just waterfall. What are we doing, going back to the '70s? But agents give you this ability of just churning out slop, right? And sometimes you can use that to your advantage because a prototype, right, just getting a sense for what it should look like, you can build out three or four different versions and just choose your favorite and iterate on it and just keep churning, churning, churning. That can be a really powerful setup that we've not really had before, right? It was always expensive to produce prototypes. Now it's the cheapest that it's ever been, and that's an essential part of writing specs to me. It's actually producing these prototypes. Yeah, but also, like, with the waterfall criticism, I think Grady Booch might have told me this as well. It's like, don't forget, like, we should not criticize waterfall because, for example, a lot of big tech, the largest tech companies from like Amazon, Microsoft, Google, Meta, you name it, they are kind of doing mini waterfall. Like, pre-AI, they've been doing mini waterfall, which is, let's do a plan, let's agree on it, let's build it, let's ship it. And this is all done in like two weeks, a month, two months, three months. Three months is kind of... Problem that we've always had, you know what I mean? Like, it hasn't gone away. Hasn't gone away. You know, this is just, this is what I feel like. We're just having the same conversations we've had for 20 years. It's just there's this new elephant in the room. I want to ask you about living in the UK and AI. This is a question that also came from one of the readers. Now that you're based in the UK and outside of London, but you're now educating about AI, is being further away from Silicon Valley and the HQ of the labs making things easier or harder for you? I'm really just trying to plow my own furrow, really. Like, what I realized quite early on is that I have no power to predict the future, right? Because I'm so far away from things, I'm just a person in the field working with this stuff. I have no way of knowing what's coming, right? I don't know whether the models are going to improve. I don't have privileged access to stuff. And so I'm just trying to focus on what's working right now. And because of that, I think that's narrowed my scope a little bit. That means I can just try to get my stuff working. And it's sort of quite surprising to me that it's working as well as it is, you know, because I don't have this privileged access. I'm just trying to make this one approach work. So I think, yeah, you're probably right. I probably would be able to do this stuff if I lived in San Francisco, but then I'd have to live in San Francisco. You know, I don't want to do that. That's miserable. You know, I've got a great setup here. My parents are just down the road. You know, I've got my son growing up in the countryside. So it is what it is. And, yeah. Now, you're an educator at heart. How have you seen the business of teaching or educating software engineers change, and also how people want to learn, if you've observed any trends from before? Like already when you started, I feel you were on, at the time where online courses and learning over video became a lot more popular, as opposed to, let's say, a decade ago where it was maybe tutorials and before that it was books. Obviously they still exist, but there are just different preferences. Yeah, it was around COVID time that sort of video tutorials really took off. I think people wanted a much richer learning experience, and I was kind of just— After that wave, I suppose. I think that people's way they've learned hasn't changed that much, right? And their desire for certain types of materials hasn't changed. I think it's very sexy, the idea that, you know, an agent can just come in and teach you everything. And that sort of works in some contexts, but really what you want is curation, right? You want a human to have come in, understand the flow of the information. I always think of information as kind of like a graph, right? You have a piece of information that's dependent on another piece of information, dependent on another piece of information, and turning that graph into a linear path is how I think of my job, right? I'm just trying to teach you, like, find Dijkstra's algorithm through the graph so that you can learn it in the most sensible way. And that level of curation is just not something that, again, that's strategic, right? That's not something that AI is particularly good at. So, I mean, I've obviously made this huge pivot from TypeScript, from tactical stuff really to this strategic layer, and it's working okay for me. I really can't speak for other folks doing this work, and I know that lots of people are not having this level of success, I suppose. So I think what it shows is that agents have just changed the game in terms of what people value and what people prioritize, and the industry has shifted in seven months faster than it's, I think, ever done. You know, this is a huge shift. It doesn't mean we need to throw away our working practices, but it does mean that what we need to focus on is different. And I feel like I've been able to move with that quite well, whereas I think others just haven't because they're focused on different things. And I wonder if in your case, it's also with Total TypeScript, and even before with TypeScript and other things you shared, you were helping people use... The very popular tool at the time, TypeScript was gaining market share. There were migrations happening from Java to TypeScript, from Python to TypeScript, and so on. And so developers wanted to get really good, a lot of them, or the top 10% or top 20%, you name it, wanted to get really, really good with TypeScript, and they were looking for efficient ways of doing it. Now, AI is here, is changing how we work as software engineers, and I think it's particularly that building software is valuable. But there's a question of how do I use these tools more efficiently, which is more pressing right now than how do I write TypeScript efficiently, especially with the agent. So I wonder if you've kind of just a bit how you pivoted from voice acting to what you couldn't do from outside of London to a thing that you could do outside of London, which was still teaching. You've just pivoted to teaching a different area, which right now is, again, it's on so many people's minds. I think I've just been lucky, basically, of choosing the right thing at the right time. It would have been very easy for me to, and I actually took quite a fair bit of convincing to move into AI. Like back a couple of years ago, it was Joel, my business partner, who was pushing me to actually go, You've really got to try this. It's actually pretty good, and you can use it for all sorts of stuff. And it took about three months of me actually trying it and failing and trying it and failing before I realized, okay, this is great. I just feel quite fortunate that I've landed in the right place at the right time. And I try not to narrativeize it. I try not to think, Well done, Matt, you've been so smart, you know, making the right play at the right time, because I've made several mistakes as well, and I... Could have easily found myself in a different zone, and I mean, that's no bad thing. I would just go back to being an engineer. That's what I love too. Putting yourself back into the shoes of when you were someone just starting out in the industry today, for people starting out in the industry, early career, junior folks, what would you recommend them for tactical things to do? Like, they will know, like, look, I want to get that experience. I want to get that judgment, that taste, those fundamentals. You'll need to get repetitions in. If you found yourself in those shoes, how would you approach? Like, I want to be a builder, a software engineer with all these AI tools, whatnot, which is now confusing because now there's a mix of, do I use these AI tools just to do stuff for me? Do I get in the fundamentals, which is slow and so on? Yeah, I mean, I would love to be a junior right now. I would love to be in the exact position I was in, like 2014, where I was building these tools for my students, right? I actually got really nostalgic for it on the other day. I thought, I'd love to get back and do some singing teaching because just the ability to, like, I could finish a lesson and then just prompt the agent, okay, this tool didn't quite work in that way. I could maybe modify it a little bit and, you know, see it working. I just think the right thing to do is to use these agents as much as possible because that's how people are going to be working now. And I think the thing that I find valuable about my skill set is you're constantly in touch with the changes that are happening. Grill me, not only you're having a discussion with a senior developer, right? That's beneficial for the developer, but it's also beneficial for you. Keeps you thinking about these deeper ideas and the absolute— Rubbish that I was churning out, you know, with my spectrogram analysis tool. That would have been so much better if I had an agent to work with. It ran like a pig, you know, like it was, the performance was absolutely terrible. If I'd have been able to say, okay, this frame rate has dropped to 10 frames per second. How do I fix that? It would have seen the six nested for loops and gone, okay, maybe you should do something different there. So I think that there's never been a more empowering time to work on this stuff, as long as you're interested in not only the code you're producing, but also the process of creating the code. There's never been a better time to be a kind of navel-gazing programmer, just constantly thinking about your own processes and being introspective. This sounds like if you're motivated, you should be able to learn really fast compared to even before. Absolutely. It's just about being curious, about being adaptable, and that's the people that I see who are thriving in this new environment are the same people who were thriving 10 years ago, because they're just interested in this work, interested in making better software, and interested in their own process. And on interesting in making better software, I wanted to ask you about gardening. A software engineer on X, Lauren, posted, I'll quote her, Every team needs a gardener, someone quietly watching the stream of PRs flowing into your codebase, noticing the smells, the lint expressions creeping like ivy across your carefully planted garden, a steady hand tending the weeds that would otherwise engulf the garden. And to which you replied, I'd argue the only thing your team needs are gardeners. You probably do need a couple of other people as well. Yeah, yeah. But more specifically, I wanted to ask about this concept of gardening. I actually really love how Lauren described the weeds taking over the garden and getting them out. I think I made a tweet a while ago that we are—this was when I was sort of thinking about Ralph and sort of the agents sort of looping over stuff—we are essentially just Ralph's platform team, right? That's what we are now, and we are our agent's platform team. We are trying to build the environment for them to succeed. That's exactly how you should be thinking about it. Again, it's strategic. And that gardener metaphor is nice because— You know, it's very easy for the garden to itself just to suffer entropy, right? To gather weeds and to do all that stuff. So understanding and diagnosing that stuff before it becomes a problem in your own codebase is an essential skill, and might be the essential skill, right? As long as you can queue up work for agents, as long as you can build these loops now that we're starting to see, these processes where agents improve the codebase based on bug reports and feedbacks, that feels to me like really cool work and noble, interesting work as well. We talked about some great standout software engineers that you learned from, you got inspiration from. Today, what skill sets, experience, approach do you think makes a great software engineer? I'll use an example, which is Lars Gramel, who works at Vercel on the AI SDK, who I had a chat with the other day, and he is building an entire software factory for his extremely popular open source library that gets a ton of issues. We're talking about plumbing again. We're talking about gardening. We're, like, thinking about the—