Latent Space: The AI Engineer Podcast
Original podcast
Watch the full show on YouTube: https://www.youtube.com/watch?v=rlM_fAKxB3Q
4,360 words · 2 speakers
Okay, we're here in the AI Engineer Europe podcast booth with Matt Polcock of AI Hero.
Hey man, how you doing?
Good man. It's nice to be in your neck of the woods for once.
Yeah, you do a lot of SF stuff, but nice, so nice to have you come to London.
Yeah. How do we stack up versus your other London event experiences?
It's the worst I've ever been to, by far the worst. Absolutely astonishing, astonishing location, great stuff.
You and I first connected when you were about to start your sort of creator journey and dev dev journey. You started Total TypeScript, which did very well, and then now you're running AI Hero. You are just about to finish a Claude Code course?
Yep, I run courses in two-week cohorts these days because AI moves so quickly. Hard to release a self-paced course and guarantee updates forever. And so, yeah, on the last couple of days of a two-week course, it was wonderful.
Does that mean that the Claude Code source leaked just as you started?
Yeah.
How was that? What did you?
Well, I'm cursed, you see, because I did a course on AI SDK and it was based on SDK V4. Day two of the course, they announced SDK V5, right? A huge breaking change. And this time, I think day two of the course, they released the 1 million contacts window, or maybe just before the course started. And yeah, now the Claude Code source has leaked. But fortunately, the course is not really about Claude Code. I noticed that when I was building it. It's mostly about engineering and software fundamentals. And that's, I mean, that's the talk I'm giving here too. It's kind of what I'm focused on now, is going back to these old texts, figuring out what's good, and translating that into the AI era.
Yeah, so people can see the talk you did, a workshop as well. You're one of the, I had three people do a double session where, you know, because you're a big London figure, I want to make sure that we have enough exposure to things. And I think oftentimes conferences are afraid to double down on speakers. But I think I have a particular thesis that YouTubers make particularly good. Conference speakers because you speak all the time for a living.
And I don't know, do you cringe when I call you a YouTuber? Is that a?
I'm used to it, right? I mean, like, I mean, my identity is I'm a teacher.
I really try, there's a whole category of YouTubers that I don't really try to interact with or try to be, which is the pundit, right? I'm not a pundit. I'm not a guy who's trying to predict the future. I'm just trying to teach.
You don't change your favorite ID every two weeks?
Exactly.
Like some other YouTubers?
Exactly. That stuff does do really well, right? And it's very, you know, it's hard not to fall into those traps because those numbers are really good. Uh, but yeah, I'm trying to teach stuff that's durable, that's makes sense, that I feel good about, you know, that kind of.
Yeah, fundamentals and of engineering and all that. What are the fundamentals that you hold dearly to?
I mean, I'll kind of rerun my talk a little bit now, which is.
Yeah, a little preview.
People can find it on.
Exactly. Yeah, yeah. The theory is that there's this idea that code doesn't matter anymore, right? We're in an era where you don't really need to think about the code or hold the code in mind when you're building applications because you can just use a description in English and use the AI as a kind of compiler to turn that into code. You don't need to care about the code, it's just a compile target. And I think that every time I tried that, every time I tried to ignore the code, I would just end up with this terrible mess. And so in kind of trying to better the compiler and improve the compiler, I went back to the old classic texts, you know, like extreme programming and pragmatic programmer and philosophy of software design and DDD, all that stuff. And what I found there was just, oh, I can just take these and just put them into my prompts, you know?
And I started going deeper and going deeper and going deeper, realizing, oh, okay, there's actually, there's so much more here than I realized and that everything that we were doing for humans really works with AI too. And actually keeping the code in mind and being really intentional about what you're building, not necessarily reviewing everything, but still keeping a sort of understanding of the architecture and the modules, especially. It really yields dividends because if you have a codebase that's easy to change for humans, it's going to be easy for AI to change too. And it's going to mean that you can work a lot faster because a codebase that's difficult to change for humans is going to be even worse for AI.
Yeah, I've been thinking a lot about the concept of a narrow waist. I don't know if you've heard about this thing. It comes from old internet architecture philosophy. You've heard about maybe layer one, two, three, four, five, six, seven. The narrow waist is layers three and four, where basically TCP, IP and HTTP have mostly dominated and there are no other alternatives effectively apart from web sockets.
Mm hmm.
And I think introducing narrow waist in a codebase allows you to contain slop, right? You can say, I don't care what goes on in here, but what goes in is defined by me. What goes out is defined by me. Do whatever you want inside.
Yes.
And so there's some equivalence of this in my mind, of this and the former decompositions of MVC. People call it Model View Controller. Today I call it Model View Claw. I view this a lot in terms of how I run AIE as well. AIE is now a nine-person business. Everyone has different parts of the elephant and I have to make sure that everyone sort of comes together and like produces a conference where nobody notices the rough edges down under the hood. And so part of it is, yes, I run the website. I run the speakers, I run the content, but everything has to flow from me down to, okay, what AV do you need? What hotels do you need?
What, you know, other sort of accommodations do you need? And there's a huge coordination issue. It's just everywhere and I don't even feel like it's really programming anymore. It's just systems.
In how you set up systems.
Yeah, this, I mean, what you said there about the idea of having self-contained boxes within, within any system actually, but let's use a codebase as an example. It's a fascinating idea and John Astor, how in his book Philosophy of Software Design talks about this, there's this idea of deep modules, basically a large amount of functionality with a simple interface.
Kind of ports and adapters, right? Like you have a port that talks to other ports, et cetera. And you're totally right in that when you have a codebase or a system designed like this, you can design the interface, be very intentional about that and be a human sitting there and understanding it, but then delegate the implementation, delegate the stuff that's going on inside. And that's how I've used AI best for coding. I imagine for what you're doing, putting it into an org, that would work great too.
Yeah, I see it both ends, right? I also, you know, because of recognition and Devin at Goldman Sachs is very, very different when you have tens of thousands of engineers. And it's a beautiful thing to see. You mentioned domain-driven design, DDD. I am one of those people, I guess, old enough to have had that. We have actually a DDD talk yesterday, one of the workshops from IKEA. Do you think it's catching on? Do you think it's important enough that I should be featuring it more? I think it's a very appealing concept for architects and people who work with large systems. Most people will never have encountered it in their software journey if they started more recently. I don't know.
Yeah. It's a fascinating idea because what DDD is, is a set of, like, I'm not like a DDD expert. This is something I'm encountering relatively new. But what you have with DDD is a set of building blocks and a set of practices that all fit together. And so what you have there, because it's been going around so long, it's kind of in the latent space of these, these models already, is if you say, you don't need to invent this whole new set of terms, you can just bolt on this framework, this system, that's very, very flexible, very composable, and allows you to build systems in this way. And because of that, it's very attractive. And so using a pre-built kind of framework for talking to the model
and having the model understand exactly what you're saying, because it understands, that just feels right. And Because it's so focused on outputs already and aligning the code with language, that's what DDD is essentially. You're trying to kind of create a unified domain model so that, the way I think about it now, is that so that the AI and you are speaking the same language.
That's so true.
That is so, so useful. So to make that concrete, I have a skill, I have a set of skills in map poker forward slash skills, which got insanely popular, has like 13,000 stars. And one of those skills is ubiquitous language skill. Ubiquitous language is essentially a concept where you create a document which essentially defines the terms of what you're talking about. And when you, uh, let's say you're a client and I'm a guy building a system for you. When I say, um, a mole, for instance, we might be talking about a health application where we're investigating moles, or we might be talking about spies or something, where we need to understand what a mole is in that context, you know?
Or the animal.
Or the animal, right? We might be building a zoo app or something, right? So you need all of these terminology and anyone who's worked on any mature project knows that you have all of this arcane jargon that goes along with it. So I have a skill that essentially scans your code base, looks for all of these terms and refines them with you. And I noticed that I keep that document open whenever I'm prompting, because it means that I can put so much more, with so much more clarity and have so much more better conversations with the AI because it's using my domain model, using my.
You keep the document, you keep the skill open?
I keep, I mean, it generates a markdown file that sits in my repo and I just keep that open, look at it all the time. So we're thinking along the same lines.
And does it, does that go in your agents MD, Cloud MD, or is that literally just for your human reference?
I keep a reference to it in agents.md. I'm very nervous about putting too much in it. Yeah. But it knows it's there if it needs to see anything. But mostly, when it's doing searches within the repo, when it's exploring, it'll use those terms and search for those terms and the, the document comes up.
Yeah. Just, just more broadly on AI trends, I, I think you have been really good at explaining and teaching things. How do you do what you do?
Your videos do so well.
I think the British accent doesn't hurt.
But I think you're also enormously amazing on Twitter. And like, you know, as much as people say I'm good at it, I'm not compared to what you do.
Well, I mean, I don't really understand it, first of all. What I do know is that I spent six years as a voice coach before I became a developer. And what I noticed when I became a developer is I would, you know, I started from the bottom, really. I was working as a junior, going up to mid, senior, blah. And the ability to communicate always just felt like a ridiculous, overpowered skill that I had in my locker that no one else had. And I think what I've chosen to do over the last couple of years is really narrow my focus. Again, I'm not trying to be a pundit, right? I'm just trying to teach stuff. And so that means I need to divide my time between learning the stuff and figuring out the right phrases to use about it. This is why, again, going back to these texts is so useful because I have all of these models now that I can use to explain things to people.
Yeah, I don't know. I don't know why I'm so good at it. Mostly I don't feel good at it. Mostly I feel like I just see the things that need to improve.
Maybe you can walk us through maybe the Quarko workshop or something else that you did. What goes into preparing something like that, right? Like, what is the research process? And what do you throw out?
Yeah. Let's say we have an explore and exploit phase, right? Where I'm figuring out what this workshop might look like. My most recent course took about two months to put together. It's about, I don't know, four and a half hours of very tightly edited video, but lots and lots of exercises, lots and lots of stuff in there, about a hundred different units, let's say. So let's say you, I figure out exactly, like, I start from scratch. What would be interesting to show? What's interesting in this environment? What's my angle here? And I just make a ton of stuff inside an obsidian vault. So tons of ideas, essentially a Zettelcaston, if you've ever heard of that approach. And these loose notes then kind of sort of start coagulating into a plan. And I have actually a custom application that I've built for planning this stuff too.
So this means that I can then start seeing sections, start seeing groupings of information that I want to see. From there, I prioritize each individual lesson and work out how important it is to the running of the course. P1, P2, P3. I then record all the P1s mostly, and then that's the course, essentially. Because most, loads of stuff gets left on the customer floor because we just can't fit it in or it has various concerns and things. So that approach and developing this idea that each lesson should only teach one thing.
Each lesson should depend and the dependencies between all the knowledge should be super clear and you should always challenge people without overwhelming them. And this is, I suppose, just instincts I build up over a long time of doing this. But if you keep that idea in your head, then it's hard to go wrong.
Yeah. Do you feel any changes in how people learn? Because there's a lot of, you can just ask a Grok, you can ask ChatGPT. I don't know, this is, I guess, a more broader education concept, right? Of, um, like, do you give people more exercises? You know, is it more hands on?
So there are three things that you can teach people. You can teach them knowledge and you do that through lectures, right? This is how things work, these are the terms. You can teach them skills. This is how to do it. Try doing it with interactive exercise. Or you can teach them wisdom. And wisdom is the hardest. How do you teach wisdom? For me, that's been, um, doing discussions, small group discussions in workshops is kind of the recommended approach. But wisdom is something that is really hard to get. And actually, working with AI is something you can, can sort of get to wisdom a little bit by talking to AI. You've never really been able to have that with any kind of, uh, learning mechanism before. You know, books are mostly knowledge based.
You know, there's a little bit of wisdom you can glean from them, but you've got to do a bit of work on your own to get there. But what I've noticed is the more I lean into the kind of AI experimental stuff, the more it actually turns people off my materials. I'm finding that actually a traditional approach is what
Give me the lectures, yes.
Yeah, what still works for most people to be honest. Most people just still want to learn a traditional way and I'm totally fine with it.
The, uh, you know, back when there was the creator economy wave and Maven was all about the interactive discussions. And it turns out people just want lectures.
Um, that's right.
They, maybe a bit of homework, but a lot of them don't even do the homework.
That's right. Yeah.
And I, so what you're saying is I've arrived at the optimal form factor, which is just, just lectures.
I mean, I, I'm very careful with my stuff to, um, really force people to do the work, essentially.
I see.
Even in my typescript stuff, I would, uh, structure it so that people would have almost, uh, you'd essentially just be thrust into a problem and have to solve it on your own. I would give you the knowledge afterwards and that approach has felt pretty good, really.
So, yeah.
Something I've noticed, when I started AI engineer. I was pretty conscious about it being fifty percent Python, fifty percent TypeScript. I would say that's changed. I think this year is the year the TypeScript overtook Python in the GitHub survey. And I didn't really foresee that coming. I think that Python is somewhat more expressive, especially useful in the backend. And TypeScript has the TypeScript dependency issues that we've always had in TypeScript. I don't know. I think like, do you think TypeScript is winning? I mean, you would be biased to it saying yes.
Of course. My echo chamber is a hundred percent TypeScript. And again, no punditry. I'm not a pundit. I mean, what you have with TypeScript is this incredibly rich ecosystem of frameworks and tools and extraordinary.
You have the Vercel next JS and the Cloudera next JS.
I'm taking the piss.
But you know, so you can't overlook TypeScript in any conversation, you know, when it comes to building applications. And that just seems like everyone who's building this stuff, everyone who's building chat applications is mostly doing it. If you're concerned about UX, you're concerned about shipping great stuff, you're mostly doing it in TypeScript, at least that's what I see.
Yeah. I think it could be that TypeScript is going to win AI engineering. And that's something I haven't anticipated or seen, or I don't even know how to sort of position around this. Because I think it really does mean a lot of different things for what frameworks I choose to promote or bet on in my line of work. Yeah, that's interesting. Any other topics in AI that you're particularly captivated by? You know, you're finishing up your cloud code exploration. What's next?
Well, I think this has been the most successful course I've ever done. So like, for the last eighteen months, I've been trying to figure out my positioning, trying to work out where I fit. I even sort of, that idea of sort of TypeScript coming and eating Python is something that I was betting on for a little bit. I even made a TypeScript evals framework called Everlight.
I didn't see that, yeah.
Yeah, which is sort of stalled in its development and stuff. But, you know, people are not really interested in evals, you know, like evals are not sexy. Like, no one's excited to do evals these days, right?
We have many, many people who disagree here.
I mean, from everyone I've talked to and the content I produce on it, it doesn't go anywhere, or at least people are not kind of into it yet, I think. In terms of where I'm going next, I think that.
I think that the coding agents kind of debate is sort of ending, really. Like, they're mostly coagulating towards a similar approach, which is, you know, file-based systems, a simple set of tools. And I think I'm interested in expanding into that kind of area and looking at how to make a course that potentially, like, does all the agents at once, possibly. And sort of trying to build frameworks and build methods of, you know, software factories that are kind of independent of the agent that you're using.
So a kind of meta level on top of that.
That's kind of where I'm at. And I think that coming up for the next couple of, maybe the next few months, let's say, I'm not a clairvoyant, that the inversion of control is going to be really important, where you put more control in the hands of the developer and less in the harness.
Yeah. Um, oh, I thought the developer wants less control, not more. Is that not true?
I think there's a trade-off, right? Because if you're using Cloucode, let's say, and until recently you couldn't see Cloucode's internals, right? You sort of had a, there was a sense of a box around Cloucode that you didn't need to look inside. And that's comforting, right? Because you just sort of go, okay, what does the harness want me to do? Let's lean in its direction, let's not worry too much about what's inside. And what you get is you get ease of use, but you lose observability. You lose the ability to kind of control what's going on and tweak what's going on. And there's, that trade-off is really interesting to me, because let's say we look at Pi instead, which is composed out of tiny little primitives that you totally build up from the ground.
Now, what that means if you're able to use Pi really well is you have total control over the system and you can observe all the parts of the system. But then you have more stuff to maintain, stuff to care about, stuff that can go wrong, and it's all up to you. So that trade off is something I'm interested in exploring next, for sure.
Yeah, I think it's very interesting, all the, these developments. I think the world needs more like teachers like yourself. I have been also asked to do more stuff like that on my podcast and a lot of people are trying to also just like get out, get more productive with the AI. And I wonder how to do that well. I think you're obviously more focused on engineering and programming and software engineering. But there's a, there's equivalents of like more generalists that want to know, okay, well, how do I live my life more efficiently, just in general? How do I run my team and my company more efficiently?
Totally.
It seems like Obsidian is kind of winning there, weirdly. They're four people.
Really? They're really that small? Four people? Wow, I didn't know that.
They, they recently posted a job for a fifth person and that thing got nine million views because everyone was like, what do you mean you, you've done this with four people?
That's crazy. I never, wow. I mean, that, the stuff that we're doing as software engineers now is like, we seem to be a step ahead of everyone else because we're able to work in a domain where AI is actually producing quality stuff. And so what I'm doing is as I'm working with my, with my set of skills that I'm kind of authoring, I'm thinking, how can I pull these out and use these in my everyday life? For instance, what do I take out of Claude code?
I'm gonna look up your skills right now.
Claude.ai, yeah, mappocop forward slash skills. And there's one, one in particular called Grill Me.
Okay.
Which is like three sentences long.
And which basically gets the AI to interview you relentlessly, right? Until you reach a shared idea. I'm sure everyone's sort of had that technique or used that technique. And I've realised I need that skill in all sorts of domains. Any kind of domain where I want the AI to be aligned with me, I want to reach a shared understanding with the AI. And I want it to sort of artificially, maybe even, sort of just question its own assumptions, question my assumptions until we reach a shared design concept. And I've used that for all sorts of stuff, for generating documents, for doing tons and tons of things like this. And so I think the more I break these down into individual composable parts, the more useful they are outside of software engineering too.
Yeah, just like the 20 questions and all that. Okay, this has been beautiful catching up. I also want to just introduce the in-space audience to your work. I think the work of explaining AI, keeping up to date, is never done. So just glad to have friends who've also made the crossover from JavaScript to AI.
Absolutely. It's been a fun journey. It continues to be.
All right. Thank you.
Thanks.
Page updated October 24, 2026 · transcript and summary are machine-generated
