# Matt Pocock’s Agentic Engineering Workflow (just copy him)

**Channel:** David Ondrej
**Source:** https://www.youtube.com/watch?v=nQwJVHCtDDY
**Transcript page:** https://www.withtranscript.ai/video/nQwJVHCtDDY

## Chapters

- 0:00 — Harness vs Model and Programming Strategy
- 1:59 — Delegation Skills and AI Upskilling
- 4:45 — SERP API Sponsor and Teaching Skill Concept
- 7:05 — Demonstration of the Teach Skill Workflow
- 17:09 — Designing Effective Agent Skills
- 24:49 — Agent Environment Setup and Harness Tradeoffs
- 35:01 — Case Study and Human Oversight in AI Tasks
- 42:58 — AFK Agents, Loops, and Queue Workflows
- 53:52 — Building AI-Driven Businesses and Teams
- 1:00:33 — Practical Action Steps and Closing Remarks

## Transcript

**[0:00] Speaker A:** Everyone's obsessed with the model and I think they should be more interested in the harness. What you can do to get the most out of the harness, giving it the right prompts, giving it the right skills to work with, and improving the environment in which the model runs. As I sort of said with Fable, like the model is useful, but I think the harness has an equal amount of work and you have much more control of the harness than you do the model. People are focused on the wrong thing. They're looking at the big shiny new thing, when in fact just focus on the stuff that's been working for 30, 40 years, you know, and it really does work.

**[0:35] Speaker A:** Like people ask me all the time, how do you optimize for tokens, Ben? Have a code base that's easier to make changes in.

**[0:42] Speaker B:** Right, Matt, So what's going to be the main difference between people who use AI to get insanely ahead and the majority of people who only get a small boost from it?

**[0:50] Speaker A:** So in his book Philosophy of Software Design, John Ousterhout talks about the difference between tactical and strategic programming. So I find this distinction so useful when thinking about AI because tactical programming is all about the on the ground, day to day stuff. The actual writing of the code, the actual messing about with the syntax, figuring out bugs as they come up and actually creating the code, creating the commits. Strategic programming is winning the war, not the battle. It's longer term thinking. It's the general sitting right at the top. How does the code base need to look?

**[1:24] Speaker A:** What strategies can I use to improve our velocity? And for me, strategic programming has always been the most interesting, the most exciting. That's how I was thinking even when I was a junior. How can we increase our velocity, how can we do more with less? And AI is basically eaten. Tactical programming, it's gone, right? It's all gone. So AI is just better at doing tactical programming than you are because it can do it for cheaper.

**[1:48] Speaker B:** Right.

**[1:50] Speaker A:** And so you need to be great at strategic programming in order to get the most out of this infinite fleet of tactical programmers that you now have access to?

**[1:59] Speaker B:** So does that mean knowing how to orchestrate these agents? Plus some like fundamentals of software design, code based architecture, like how would you break that down into like these specific skills that people can learn?

**[2:10] Speaker A:** Yeah, great question. So strategic programming really hasn't changed in AI, right? AI is just all we're doing is instead of delegating to junior or mid level programmers, we're delegating to AI instead.

**[2:24] Speaker A:** So the things that you need to do, good delegation are still the same. You need to design the hard parts up front. You need to make sure those tasks are really, really well scoped. You need to be thinking about the interfaces between all of the modules in your code base. You know, you need to be thinking about test scenes and good tests.

**[2:42] Speaker A:** You need to essentially design a code base that's easy to work in and have just enough documentation that can point AI to the right places where it's going to make those changes and make them effectively.

**[2:52] Speaker B:** I think everybody at this point agrees that the AI progress is very fast, if not speeding up. So I think a lot of people also miss the part of upskilling themselves, right? Because the like, yeah, you can pay for subscriptions, you know, you can get the latest tools, but ultimately anybody can do that. But there is still going to be people who use these tools to massively grow their business, you know, to ship more and better software than ever before.

**[3:14] Speaker B:** There's going to be people who, like, tried a bit and, you know, maybe use the free version or a cheaper model. So how would you advise people to start teaching themselves to be better?

**[3:23] Speaker A:** Yeah, people ask me all the time, like, because, you know, I sell developer courses, right? So I'm sort of, you know, you can take my advice here with a pinch of salt. But I personally feel that my skills are a multiplier for AI, right?

**[3:38] Speaker A:** If I'm able to oversee a code base and think about how, like, things should be built and just tell AI how to do it, then AI just has so much richer context to work with. And I think of this, I mean, I see this everywhere and people like ctos and like people I talk to at conferences tell me this all the time, is that AI makes senior developers just 10 times better. And it sort of doesn't make sense to hire that many juniors anymore, because juniors get a little boost from AI, but seniors just get this ridiculous, huge boost from it and they can do so much more with it. So your skills are ceiling on what AI can do. And if your skills are low, then AI is not going to be able to go past that, you know, so getting good with AI is really about getting good at your domain, getting good at what AI is going to be doing for you.

**[4:29] Speaker A:** So a better teacher can use AI to teach people better than a random can, you know, So I think skills are more important now than they used to be because again, you just have this multiplier available to you and you can delegate more.

**[4:45] Speaker B:** So you recently shipped new teach skill, right? Can you tell us more about that? If You've ever tried pulling search data from the web at scale, you know it's a nightmare. You write a scraper, it works for a week, but then the layout changes. Then you hit captchas, your proxies get blocked, rate limits everywhere. And suddenly you find yourself maintaining scraping infrastructure instead of building the actual project. This is where SERP API comes in. It gives you clean, structured search results from Google, Bing, Yahoo and more through a single API call. You send a request and you get back a clean JSON object with exactly the data you want. No captcha solving, no rotating proxies, no broken HTML. They handle all of it. And for AI work, this is huge. Say you're building an agent that needs live information. Just use their Google Search API.

**[5:33] Speaker B:** Or maybe you're training an AI model that needs a data set. Their Google Images API gives You preclassified titles, URLs and thumbnails ready to go. A ton of production agents already use SERP API as one of their core tools. And you can get started with 250 free credits. No credit card required.

**[5:50] Speaker B:** Just scan the QR code on screen or click the first link below the video. Oh, and a huge thank you to SERP API for sponsoring this video.

**[5:57] Speaker A:** Yeah, I know a lot about teaching. I've been a teacher for 10 years, actually. So I was teaching singing and voice when I was just straight out of university.

**[6:07] Speaker A:** Then I became a developer and now I teach developers. I've been doing that for the last four years. So I know a lot about teaching. And I thought, okay, what if I take some of the teaching principles that I know about, such as the zone of proximal development, such as the difference between knowledge, skills and wisdom, Encode that into a skill and essentially use it to create a course on the fly about any topic. And that's what I've done. And it's extremely effective. I've actually been learning. I'm teaching myself Rubik's Cube from this. I can solve a Rubik's Cube now from memory thanks to this skill. And I've been using this for all sorts of stuff. So yesterday I was, I was messing about with what it might look like to ask the teach skill how to become a senior developer. And it basically went on this big journey, looking at a bunch of trusted resources, getting a big sort of curriculum together, and just produce something that was gorgeous.

**[7:00] Speaker A:** And so it was just. Absolutely. Let's give it a go.

**[7:04] Speaker B:** Yeah, I think people would love to see that.

**[7:05] Speaker A:** Definitely. Okay, so, David, what do you want to learn?

**[7:10] Speaker B:** Let's do like systems designed.

**[7:12] Speaker A:** I tell you what I mean.

**[7:14] Speaker A:** I've got an idea here, which is that a lot of people come to me. I teach courses for engineers, really, people who already know how to be an engineer. I'm intrigued by if this skill can teach you basically the basics of engineering, you know what I mean, to fill in the gaps that you might have if you're a vibe coder, you know. So I'm going to pretend that I'm a vibe coder. I'm going to invoke the teach skill.

**[7:37] Speaker A:** I'm inside an empty directory here, and I'm just going to let it roll. So I'm going to dictate something out and let's see how it goes. I am a vibe coder and I want to fill in my knowledge gaps so that I can ship better software. I know some very, very basic CLI commands, and I know just about enough to read some code and use the terminal, but that's about it. What do you think I should learn to develop my skills next?

**[8:06] Speaker B:** So I'm going to put that simple prompt, plain English. Anybody can ask this.

**[8:10] Speaker A:** Exactly. I mean, it's just a very, very simple request. And I'm not really talking about the subject that I'm trying to learn. I'm talking about my mission, the thing I want to get out of this, the reason I'm coming to this session with the teacher today. And you can think of this really as a collaborative effort, basically, I am talking to a teacher, and the agent is my teacher, and it should know how best to teach me.

**[8:33] Speaker B:** It's good that you brought it up and you created the skill recently. Because literally, I was thinking about this yesterday, right? Especially when Fable came out. I was like, how can I upskill myself to get the most out of it? Because, like, I know I'm not where I can be. You know, there's people much better than me, much more skilled than me. So, like, it's great timing that you have the skill now.

**[8:52] Speaker A:** Good.

**[8:53] Speaker A:** Well, this. So it's basically saying, okay, I've checked. The workspace is a blank slate. The TEACH skill, you need to run it in a workspace because it saves a bunch of information in that workspace. And so for a vibe coder who can recode and use a basic terminal, the highest leverage gap is almost never More syntax is the stuff around the code that lets you ship without fear. That's 100% true. So git reading errors, debugging, how software actually ships, Testing, totally. Git is where we start.

**[9:19] Speaker B:** Okay.

**[9:19] Speaker A:** But first, the mission. I don't want to guess. Three quick questions. The first thing the skill does is, is it basically aligns with what you want to do. I think of teaching and learning as not getting information into your head, but orienting you in the world, putting you in a new place in the world. And this is kind of a bit abstract and a bit, you know, spiritual almost, but it's not really. I mean, essentially you need to learn these skills in order to do something in the world.

**[9:48] Speaker B:** Yeah.

**[9:49] Speaker A:** And that's your mission. Right. So it's like, what are you building? What does ship's better software mean to you right now? What's a concrete project you're working on? So let's imagine I answer this. Let's imagine I was a. I'm a voice coach wanting to learn how to be a better coder. You know, that's actually who I was back then.

**[10:04] Speaker A:** So I'm a voice teacher and a singing teacher. I want to build a scheduling app to help me schedule my students, to help me retain notes on my students, to teach them better and to, you know, build something that they can help practice with. That's the kind of app that I'm looking at. So probably a full stack application with a database with some kind of authentication, but. But that's way beyond my abilities right now, by the way, I'm using Whisper Flow for dictation. It's really good.

**[10:28] Speaker B:** Yeah. So this is going to be also the game, like, how fast you can output your tokens from your brain and input them back into your brain.

**[10:35] Speaker A:** Totally.

**[10:35] Speaker B:** Yeah.

**[10:36] Speaker A:** I mean, like, dictation is. If we do a little sidebar on dictation. Anyone who's not doing dictation is just so much faster. Right. It's very fast for me because I'm like quite a fluid speaker, so I can translate my brain into words quite effectively.

**[10:52] Speaker B:** But it's a skill, you know, it's a skill at the end of the day. And people can learn to verbalize faults better and faster. Exactly.

**[10:58] Speaker A:** And it's a skill that is actually overpowered if you're a developer. It really, really is. Like, I found that being able to communicate and being able to speak was something that was just ridiculously overpowered in the development world. And so it has proved. So it has created a mission MD here. So it's basically saying, okay, who is this person? What do they want to build? Why it matters, what success looks like, being able to ship that app, not break it, get it live, and trust that it works for real students. This is now going to orient everything about this skill and what it does next. So you can see it's doing some searches here. So it's searching for some trusted resources. How does a full stack web app, front end backend, Blah, blah, blah, blah, blah.

**[11:40] Speaker A:** Let me set up your resources, a learning record, a reference cheat sheet and your first lesson. So it's going to start churning out some material that's running locally. And this is going to. The idea of this is I think of there are skills as stateless skills that don't need any state on the local system or any kind of like memory about what was done before. And then there are stateful skills. So skills that rely on information running locally. And this teach skill is a stateful skill because if you think about working with a great teacher, a teacher remembers what you've done before. A teacher knows about where you're sort of.

**[12:19] Speaker B:** Yeah.

**[12:20] Speaker A:** And need to go next, knows what your mission is, all that stuff. And so it's saving a bunch of states locally so it can remember everything. And it's first of all created a reference. So we've got a reference cheat sheet. It's now going to create the first lesson. And these are created as HTML.

**[12:35] Speaker A:** This means we can open it in a browser and have like a really rich thing to look at. Because learning stuff in the terminal is just brutal.

**[12:41] Speaker B:** Yeah. So you're using cloth code with Fable, right?

**[12:45] Speaker A:** I'm using claw code with opus 4.8 with medium effort. So I'm not using Fable. Not quite yet. I haven't decided whether I want to get into Fable yet or not.

**[12:55] Speaker B:** Really.

**[12:56] Speaker A:** Well, I mean, yeah, I don't really believe in all the. Kind of like yesterday. Was it yesterday when it was released? It's just so much unbelievable amount of noise, people saying they've one shot at this one shotting that. And yes, it does seem to be a step change. It does seem to be slightly better, but.

**[13:13] Speaker A:** But then you've got to weigh that against the cost of the tokens and how available it is, the latency of it. I prefer to essentially not try a new model when it comes out and wait about a month just to see how things shake out. That's what I did with opus 4.5, which was the last time I really had a massive new feeling about a model and it worked fine. You're not losing that much by just waiting a little while to see how things shakeout.

**[13:41] Speaker B:** All right, so this is the file it created.

**[13:43] Speaker A:** This is lesson one. Get your project's undo button. So we can see that it's using a more rich. Like actually seeing this in the HTML is a lot richer and yeah, nicer than doing in the terminal. This is saved locally, so you can always go back and reference this.

**[13:59] Speaker A:** And it's giving you actual things you can do in the terminal, giving you proper exercises to go and do it. So you make a folder, go into it, start getting it, create a file, check the status, stage it, save the snapshot. And because of course it's running like on my system, it knows what my setup is. It's probably already checked whether I've got Git installed, that kind of thing. So it's, you know, it's perfectly personalized education, you know. Exactly, totally personalized. So which command saves a snapshot of your stage changes? David, you reckon you can answer this one for me?

**[14:33] Speaker B:** Git go and save snapshot of your state changes. Git Commit, give, commit, Bam.

**[14:39] Speaker A:** So again, it's using techniques that are well known in education for increasing storage strength. Right? So quizzes are such an awkward thing. Like I sort of hate quizzes, but quizzes are just unreasonably effective for increasing the strength that something is stored in what command shows what has changed right now, David, good status. Good status. Yeah. Ouch.

**[15:04] Speaker B:** Bugger.

**[15:04] Speaker A:** I pressed the wrong thing. What does git add do to a change?

**[15:09] Speaker A:** Stages, changes, stage changes. A commit is best pictured as a save point. Save points. You broke a file but haven't committed to restore it. You run

**[15:23] Speaker B:** Git restore.

**[15:25] Speaker A:** Yeah, I think it's Git restore, isn't it? Yes, there it is. Very good. And so it then sends you off to read a primary source, if you fancy it. So the pro Git book and then invites you to ask your teacher follow up questions and create the next lesson. And so the idea of this is you. I think of knowledge as like a graph, right? It's like a big forest through which you're exploring. And what this is doing is it's creating a linear path through that graph.

**[15:52] Speaker A:** It's basically going, okay, you've learned this now that's. I know that you've learned it. It's in your learning record. We can see it's retaining a list of learning records in the top right here, which is your mission and your starting point. So it's captured your mission, a decision to start with, Git zone, approximal development, current estimates. You get the idea. So it's great. I freaking love it. And that's what I would recommend to anyone. Starting with especially developments because it's sort of I mean, I'm a developer.

**[16:23] Speaker A:** I know what developer education is. And so I've sort of put that into this teach skill. And I think I've always thought coding was quite easy to learn. I didn't have that much trouble when I was learning it myself. And I think this is a great way to do it.

**[16:39] Speaker B:** So is this live on GitHub somewhere?

**[16:40] Speaker A:** Where can people find this GitHub map Pocock skills. And if you head there, you just run this CLI command, NPX skills, latest ad map pocock skills. You can choose the teach skill and it will just save to your local setup. So whether you're using claw code, whether you're using codex, it will work. And you'll be able to then just invoke teach inside a fresh workspace.

**[17:04] Speaker B:** So you have, you know, perhaps the most, at least one of the most famous and popular skills repos.

**[17:09] Speaker B:** What separates a good agent skill from a bad one?

**[17:14] Speaker A:** It's such a deep question. It's such a deep question because it depends what you want.

**[17:21] Speaker A:** You can think of there as being two types of skills. There are skills that are procedures, skills that you intend to run yourself, and then there are skills that are more like abilities. Those are ability like things that you intend the model to invoke itself. And so a good ability, for instance, might be your coding standards, let's say. So let's say your agent is sort of doing its own thing, kind of working along, and it needs to check how you like your react code written.

**[17:52] Speaker A:** So it's going to write some react code. It pulls in the ability. Great react coding standards, let's say. And then it reads it and it understands, okay, I shouldn't use useeffect, I should use something different. A procedure is more like something.

**[18:07] Speaker A:** This is how I prefer my skills written. It's something that you invoke yourself to get the model to behave a certain way. It's something I love is my grill me skill. That's one of my most popular skills. What it essentially does, it turns the model into an adversari interviewer.

**[18:25] Speaker A:** So this is under productivity, under grill me. It's incredibly short. And you can see it's literally just four sentences. I think this skill maybe five sentences. And it's unreasonably effective because it just turns the agent into an adversarial interviewer, asking you questions, interviewing you, and popping up with ideas that you might not have considered until you reach a shared understanding.

**[18:49] Speaker A:** I've been using this for coding, first of all, just like as a replacement for plan mode so before you actually go and implement some code, you go, okay, here's my idea. Interview me about it. Let's reach a shared understanding. Let's flush out any weirdness or any unexpected stuff before we get in as much as you can. And it's just unreasonably effective. And this is a procedure. This is not an ability. I tend to prefer my skills as procedures. I like to be the one in control. I like to go, okay, we'll do. Grill me and then we'll go, let's write a product requirements document. So we use two prd, for instance. Then let's take that PRD and turn it into individual issues so that we can work through them. That's just personally how I like to do it. But other skills, such as superpowers from Opera, which is probably the most popular skills repo out there, it takes the opposite approach.

**[19:40] Speaker A:** And it prefers things to be more like the model is in control. But I've always preferred to me personally, be in control because I know my skills, I know my abilities. I don't want to delegate my thinking to the model.

**[19:51] Speaker B:** Yeah, I mean, that I think is one of the. See, I'm like playing with this idea of the list is like a list of abilities, you know, knowledge.

**[20:02] Speaker B:** Basically something that, like, if you could take the average, you know, 100x developer that uses AI versus, you know, 1x developer, whatever will be the list of the differences, right? You can say like, okay, some of these are like raw intelligence, you know, blah, blah, blah. But most of them are probably teachable. Most of them are some skills, some knowledge, something like that. So I'm obsessed with this idea.

**[20:24] Speaker B:** And I think one of them is kind of knowing when to have the AI ask you, right? Like kind of this grill me style of skill. Because personally, I found out like, the biggest difference. Instead of like saying one shot, this app, I describe my vision for this app and say, like, list out the 10 most consequential decisions, right? The software design decisions, architectural decisions, product decisions that will shape this project and ask interview me until you understand 98% about it. Right? So kind of that is like one of the things I would put on the list. What are some of the things you think are on the list?

**[21:00] Speaker A:** Well, can we. Can I challenge the idea that this is possible?

**[21:05] Speaker A:** Is there if I take this question in a different way? Because skills are really hard to write, Especially because every single skill that you write, it leaks a description, this description here, into the context window, right?

**[21:21] Speaker B:** Yeah.

**[21:21] Speaker A:** And you can disable this so you can There are some skills in here, I think, in my engineering. Zoom out, I think, which has disable model invocation. True. So this one, this skill can only be invoked by the user and this means its description is not leaked into context. Every single ability. Let's say we have the list. Let's say we have a hundred different skills.

**[21:46] Speaker A:** You're going to be leaking 100 descriptions into the context window, right?

**[21:51] Speaker B:** Okay, maybe. Let me rephrase. I didn't mean it for the AI. I meant the list is the person.

**[21:56] Speaker B:** Right? Like if you had to say, like, I know it's difficult to like, it's maybe reductionist to take someone who's like really insanely productive, you know, maybe like some of the top people at OpenAI Antithropic who like worth hundreds of typical developers. Right. What would be the list of their abilities, Skills, knowledge that compare them to an average developer.

**[22:19] Speaker A:** Yeah, got you.

**[22:20] Speaker A:** Well, this, I mean, you're kind of heading in my direction, I think, which is I prefer to hide most of these descriptions from the AI itself and keep all of that knowledge inside the human.

**[22:33] Speaker B:** Right.

**[22:34] Speaker A:** Inside the developer. And so I prefer. That's how I prefer my skills to be used is you essentially are the driver. You know, you take the steering wheel. And so I do think that this is such an exciting time to be a senior dev and to be able to share and proceduralize maybe your work into reusable chunks. In a code base, you have a function that's repeated three times. You take that function and you pull it out into a shared function. That is then you reduce the duplication, basically.

**[23:13] Speaker A:** And we're able to do that now with our own procedures, with how we build software. We're able to take these, okay, I've made this plan a hundred times. I know how to make good plans. I can turn that into a skill, distribute that to my team, and everyone can be planning in the same way, contributing back to that same skill, making everyone on the team better. So you're raising the floor really on what engineers can do.

**[23:36] Speaker A:** It's such an exciting time. And what I would say though is that skills, like, there's like. I'm going to sort of confuse our terminology a bit. I think of there as being three things that you need to be good at anything, which is you need knowledge, you need the fundamental sort of what is that thing? Like understanding it in your head.

**[23:57] Speaker A:** You need the skills, you need to be able to have done it a bunch of times to like, you know, in muscle memory. And then you need wisdom, you need to know when to do it, you need to know how it fits in in the real world. And wisdom is almost impossible to obtain without actually having done the thing in the exact context where you need to do it. So if you want to be like someone at Anthropic, sure, you can gain the knowledge, you can gain the skills, but then how are you going to gain the wisdom?

**[24:27] Speaker B:** Right?

**[24:28] Speaker A:** Like, you need to probably go to Anthropic to gain the wisdom to actually understand how to do the thing, you know? But I think it's like being able to bundle the first two knowledge and skills into something that's reusable is such a fascinating outcome of this weird age we're living in.

**[24:46] Speaker B:** So, currently we talked about skills.

**[24:49] Speaker B:** What's your agentic nginx setup? Like, what tools do you use? What models, how many agents?

**[24:56] Speaker A:** Yeah, so my setup is I use claude code essentially for planning and for some implementation locally. So I'm using Opus 4.8 with medium effort is kind of what I've landed on, and it works fine. I do most of my development and a lot of my work now afk. So with me away from the keyboard and the way I do that is with something I built, which is a tool called Sandcastle.

**[25:26] Speaker A:** And Sandcastle is essentially a way to run agents inside sandboxes. So you can inside, like if you don't run an agent in a sandbox, then it's going to do weird stuff. So it might randomly delete your home directory or exfiltrate your environment variables out to bad sites, etc. With Sandcastle, you're essentially able to plug in things like Docker or Podman and run agents. Run either this is what it looks like, run claude code inside some sandbox, which is extremely cool, extremely effective.

**[26:03] Speaker A:** And it means that you can parallelize a bunch of agents at once, either on your own machine, or you can use like Vercel sandboxes, for instance, to just ping up a remote agent and then pull the commits back into your local workspace. I've been doing that and I've been combining it actually with GitHub actions. So we can see inside, for instance here, inside the Actions tab of Map Pogo Sandcastle. This one, this was an agent review action which happened a little while ago, which checks out the branch. This runs on a pr.

**[26:37] Speaker A:** It runs the review agent, which is just a prompt to have locally. We can see all of the things the agent did. It's checking various things, blah, blah, blah, blah, type check, ran clean and then it replies saying, cool, it all looks good to me. So that's mostly how I've been doing things, is running agents using sandcastle on GitHub Actions and essentially just telling them to do things. And that has been extremely, unreasonably effective because you just get to parallelize as much as you want.

**[27:09] Speaker A:** You're not worried about constraining the resources on your local machine. And, yeah, it's just very, very quick to just spin up an agent and get it to do something.

**[27:19] Speaker B:** So in terms of models, are these 5.5 extra high? Are these another cloud codes, would you prefer?

**[27:24] Speaker A:** These are, I think, again, just claw code opus 4.8 medium, I think. I don't think I varied it too much, to be honest. I mostly don't worry about models that much. I mostly just use, like, I think.

**[27:41] Speaker A:** Yeah, this is my sort of hot take, I suppose, which is that everyone is obsessed with the model. Everyone's obsessed with the engine of the Formula one car. Whereas, in fact, the engine is really only a part of the whole system.

**[27:56] Speaker B:** Right.

**[27:56] Speaker A:** You've got the entire chassis, you've got how it.

**[28:00] Speaker A:** How it moves through the air. Everyone's obsessed with the model. And I think they should be more interested in the harness, what you can do to get the most out of the harness, giving it the right prompts, giving it the right skills to work with, and improving the environment in which the model runs, improving the code base and all that stuff. So, yeah, as I sort of said with Fable, like, I, the model is useful, but I think the harness has an equal amount of work and you have much more control of the harness than you do the model.

**[28:31] Speaker B:** That's true.

**[28:32] Speaker B:** I would maybe challenge you a bit on this, because I don't see why you cannot do both. Because obviously, I agree that you need the right skills, you need the right setup. All of that matters. But then if you swap in a better engine, all of that is instantly better, no?

**[28:47] Speaker A:** Yep, it totally is.

**[28:48] Speaker A:** But I think they. You need to think of them as 50. 50, right. So instead of the model being like 90% and sort of the 10% optimization of Harna, like, everyone's so focused on the model. People are not so, like, intrigued by.

**[29:05] Speaker A:** So, okay, let's go back one step. There's a famous idea in ML, which is the bitter lesson. You heard of the bitter lesson?

**[29:12] Speaker B:** Yes, yes.

**[29:14] Speaker A:** The bitter lesson is the idea that whatever you do in machine learning, research, compute, raw, compute will just beat you every time because compute is increasing at such a high rate that you can just essentially trust that the underlying thing will get better and that will beat any optimizations you put on top of it.

**[29:35] Speaker A:** And there's a sort of idea here that maybe I'm falling into the bitter lesson that instead of like, optimizing my setup, optimizing my harness, I should just wait for the models to get better, wait for the engine to get better, and then my car will be faster. I don't know. I still think there's a lot to be gained by just optimizing the harness and focusing on creating, like, good code bases that the agent can do well in instead of hamstringing the agent before it even gets started.

**[30:02] Speaker B:** I would say probably, I agree that you shouldn't wait. That was a very stupid idea. People just waiting around for AGI or not doing anything. Obviously. I completely agree with you there. I would say I'm somewhere in the middle. I would say, like, I'm actively trying to improve my setup every single day. Trying to, you know, get faster at using these agents. Figure out, okay, should I be using CMAX here? Should I be using, Should I put this on vps? Should I be using tailscale here, trying to like, actively improve everything else except for the model, but also trying to use the best model possible because fundamentally, like you said, you might be falling into that. I would say maybe if it's 50, 50 now, for the simplicity of this argument, what if, like, the model really becomes a lot better? Right? Like, let's assume the next generation, right?

**[30:46] Speaker B:** Like Opus 6, Fable 6, GPT 6, whatever. 7. Like, don't you think these models will require less steering and like, less hand holding as they become more competent or

**[30:59] Speaker A:** no, I'm not a pundit. Right. This is what I say to every single one of these questions. I'm trying to do the best with what I have right now. And I don't, I don't have the insight to know whether these things will get better.

**[31:13] Speaker A:** I don't really want to make predictions about the future. I think that if I try to keep my workspace and my harness agent agnostic as much as possible. If I try to apply good software fundamentals to what I'm doing, if I do stuff that's always worked, then it will probably continue to work in the future. You know what I mean? So if I try to over optimize around a model, if I get too focused on the model, I will lose focus on the fundamentals. That's, that's, that's my point of view.

**[31:44] Speaker B:** Yeah. So basically you're focused on like, okay, what has been true for the last 10, 20, 30 years, you know, the really best principles of great software. And it's likely going to hold up with the next model rather than people going from the model first and like, okay, this model maybe requires shorter prompts. This model, you know, sucks at that part. Let me patch that part. Like building up, you know, properly, proper foundation rather than like starting with the model maybe.

**[32:09] Speaker A:** Exactly. People are focused on the wrong thing. They're looking at the big shiny new thing, when in fact just focus on the stuff that's been working for 30, 40 years, you know.

**[32:19] Speaker B:** Yes.

**[32:20] Speaker A:** And it really does work, you know, if you have a code base that's easy to change. Like people, like people ask me all the time, like, how do you optimize for token spend? Right. How do you optimize for token spend? Have a code base that's easier to make changes in because then you can employ a stupider model. If your code base architecture is better, then you can get a cheaper model to do the same work because your guardrails are better. It's easier to explore. It needs to spend fewer tokens banging its head against the wall. If you're hamstringing your model from day one, then you will need a smart model to get the most out of it.

**[32:56] Speaker A:** But yeah, so I think thinking from the model first is the wrong way to do it.

**[33:01] Speaker B:** Yeah. So basically I would say like the exact opposite of you is like the quintessential vibe coder who like switching tools every single week. Right. Like there is a new replit update goes to replit agent, switches to lovable switches to this and that, constantly switching and never learning any, any programming principles, anything about software engineering. Nothing. You're like, your approach is basically the difference is in approach. It's not like you don't believe in AI, Obviously, right now you're heavily trying to be at the kind of AI and educating people how to use it. It's more about the difference of approach. It's like, listen, guys, learn the fundamentals, learn how code works, how good software looks like, and this is going to be valuable no matter what, no matter if OpenAI is ahead, anthropic is ahead, Gemini is ahead versus the exact opposite approach, which unfortunately, I think most of the people who are new to AI take is like jumping on the latest trend and like switching everything the moment, you know, some new update or tool comes out.

**[33:55] Speaker A:** Totally. And I think, you know, that's, you know, you can do that and that's exciting, but you're not really increasing your skills that way. And it's your skills. I firmly believe that other ceiling to what AI can do. You should be focused on yourself, you know, upskilling yourself for this new world instead of thinking.

**[34:14] Speaker A:** Right. How do I delegate my thinking? How do I delegate more? No, you should be pulling more into your own domain and delegating only the tactical stuff. Keep the strategic mindset. Keep thinking about, you know, the next months and weeks ahead, the roadmap of where you're going in your code instead of just trying to delegate that to, you know, people are obsessed by the idea that, you know, you can just delegate everything to AI and you can't. You really can't. And I don't see, I mean, again, I'm not a pundit, you know, I'm just looking at what we have right now and it doesn't. Yeah, I, I am the person in the real world that's driving this stuff. I need to be the one making product decisions.

**[34:52] Speaker A:** I know where I'm going and I think me as a developer, I should be in control and I need the skills to be able to do that.

**[35:00] Speaker B:** I agree.

**[35:01] Speaker B:** One note I'm going to share on Fable is that happened yesterday, which was a bit scary and it definitely doesn't follow security practices, is that I was setting up a new like a new agent for, for like Twitter and basically the Twitter API was bugged. The developer console was. Wasn't loading some buttons and I tried it on a different browser, it still didn't work. I disabled all extensions, it still didn't work. So I gave it like a few solid minutes to try to debug it and I failed. I mean I didn't. It wasn't the main thing I needed to get done so I didn't really try as hard as I could. But I gave it to Crustr, powered by Fable.

**[35:34] Speaker B:** It used a built in browser inside of Cursor. You know, I had to log in obviously to the console but apart from that it started clicking, it created API keys copied and again, I do not recommend this for production apps. This is just a simple thing for me. And then it figured out when it did the testing that those API keys were in a different like app in the console and they actually weren't using the credits I charged up. So then it moved the app again using the built in browser inside of Crystal. And like for me I really felt like, what am I doing here? Like obviously I described what we're building, why we're building it. Some of the, you know, kind of my version of grill me at the start but then I felt like, okay, I just logged in into the console and I just charged up a few dollars.

**[36:16] Speaker B:** But like everything else that I was doing, right? So, like, I felt like my value in this project was a lot lower than with previous models.

**[36:25] Speaker B:** So what's your thoughts on this?

**[36:28] Speaker A:** I mean, if you think about the AI's output, right, what it. What it was doing at the end there, it needed, like, how does the AI know at the end that it's done a good job?

**[36:40] Speaker B:** Right?

**[36:40] Speaker A:** What it is the theory here that you can disappear from the project completely? No, you're still needed. Right. Like, all we're doing here is we've just given the AI a set of tools and we're. It's, you know, we've given it a scoped task and it's performing that task. Right?

**[36:54] Speaker A:** You know, we've given it a goal and we said, you know, do, blah, blah, blah, blah, blah. I don't think of that as that particularly magical. You know, that's something that agents can do now. You just give them the tools and they go and do it. But to decide whether that's the right thing to do, to security test that, at the end of that, that's something that you're needed for, right?

**[37:13] Speaker A:** You, David, are needed for that, to know whether it's done a good job. And so, yeah, we can delegate more, but I don't think that's a reason to start thinking, you know, or have AI psychosis or anything. It's just, yeah, it's a reasonable thing that the AI can do with computer use.

**[37:29] Speaker B:** I've also seen a lot of people report, like, they were, you know, maybe looking for optimizations or doing some feature. And then again, I'm talking about Fable because it just came out, it's topical. Right. So it's on top of my mind. But a lot of people reported that they found, like, deeper bugs that they didn't notice at all, whereas other models completely miss those. And I would like, again, I would challenge you slightly that that's a sign of, like, AI being able to do more. I'm not saying we need to be completely removed from the loop, but, like, if the AI is redesigning the front end and it finds an issue in one of the, like, backend API endpoints, like a major security issue.

**[38:07] Speaker B:** I would argue that that's like, AI being more involved. It's not a 5050 at that point. Yep.

**[38:14] Speaker A:** So you're saying that the better a. The better the engine is, the more value you can bring to the business just by Having the engine and those effects are emergent. You don't know what you're going to get by increasing the power of the engine.

**[38:28] Speaker B:** Yeah, it will still know the vision, right? It will still know what you're doing here. Like, this is an educational repository for my students in my paid community, or this is something just for my team. It will be used by roughly five people. The purpose of this is xyz. It will still know the core idea, the initiative that comes from you. But in terms of the actions and, like, what happens, my argument would be that as the models get more powerful, more and more of these is going to be done by the AI. But not only that, the AI will spot what needs to be done, such as the example with the, you know, deep bugs that the user wasn't even debugging.

**[39:00] Speaker A:** Totally. But I think that we think that the model is the only way to get there. Right. What you could be doing is in your repository is you could run an. A cron job that runs every single day, let's say, and does a security review, and every day it checks a new part of the repo. Right. And you could use a relatively simple model for that and you probably get some decent results. I mean, this idea that there are deep bugs that you know, or deep sort of security things inside your application that the model could spot and others cannot, you know, like, sure, that's like, it sounds attractive, but you could probably also uncover those bugs with cheaper models if you just looked in the right places, you know, and you gave it the right prompt, let's say, for want of a better word, or the right harness.

**[39:44] Speaker A:** So I don't think there's something that's necessarily special about the model that does those things or, you know, and I think that's again, 50, 50. If you had a harness that sort of was looking specifically for those things, then you would find them. And I think we're lagging behind in our practices and expecting the model to just pick up the slack.

**[40:02] Speaker A:** You can absolutely just run OPUS and get it to do that stuff. You know, people were talking about this, like, when Opus 4.5 came out.

**[40:10] Speaker B:** Whoa.

**[40:10] Speaker A:** All these security things that Opus, it's just like, sure, it's found them. And you can just get that with a harness and just get it to do it again and again.

**[40:18] Speaker B:** I like, yeah, I understand, I understand. Like, you're basically pushing against the hype wave. You know, you're trying to, like, implement some sense, some wisdom into this. Say, like, guys, okay, the models are getting better. Yes. But at the same time, let's not lose the obvious, you know, optimizations. The obvious things that has always been true. Maybe like if you had a better harness, you could support it even to the previous generation model. Or maybe you didn't have to spend $2,000 on API tokens, maybe only 200, you know, stuff like that. So, yeah, I completely agree with you there. You're trying to be like one thing

**[40:51] Speaker A:** just to finish there, which is that what is this thing that you've learned from Fable? Looking at your code and spotting a security issue, what you've actually learned. Sure. You've learned that Fable is good, definitely. But you've also learned that there are security issues in your code, right?

**[41:06] Speaker B:** Yeah.

**[41:06] Speaker A:** And you should probably have something that runs and checks for more. More security issues in the future. We need to build loops into our.

**[41:14] Speaker A:** Loops into our. I mean, we can talk about that as well if you've got some opinions there. You need to build these systems that just check your. Like you need. What am I trying to say?

**[41:30] Speaker B:** You need to figure out why it happened, like why it even got to this place. You know, it's like if someone keeps stealing your bike, maybe buy a lock.

**[41:38] Speaker A:** Yes, exactly. Maybe we need to be designing systems that are self improving over time. Right.

**[41:46] Speaker A:** And this is something that we've been doing as software engineers for a long time. We write test suites so that we can test our own code. We do human reviews so that we can make sure things are looking the way they need to. We refactor so that we can change code better in the future. And sure, a model has uncovered that we need to do a bit more of that.

**[42:04] Speaker A:** So let's do a bit more of it. But we don't need to use the fancy model in order to get insights.

**[42:08] Speaker B:** See, that's one of the things I would put on the list is like the thing that really separates the people who are going to go super fast with the AI and build better and more software versus people who are not. Like most people in that situation, they would just say, oh yeah, Fable is great. Fix the bug. It fixes the bug. But like the people, I don't know if it's like 10x developer, it's almost like 10x AI builder, you know, because everybody's becoming more of a builder. But it's a designer background. Developer background is like that person would look at the underlying issue is like, how did that even happen? How did I have this bug for so long that I didn't notice it and try to patch the underlying issue? You Know, whether it's a new skill, a new system, better staging, process, whatever that I think I would put as one of the things on the list of your human capabilities or things you should have to get the most out of AI.

**[42:56] Speaker A:** Totally agree.

**[42:58] Speaker B:** All right, so you mentioned loops. This was super viral on Twitter. Maybe it still is, but, like, you know, a week ago, I think it started with Peter Steinberger, if I'm not mistaken.

**[43:07] Speaker B:** But basically, people are like obsessing over agentic loops. Half of it, I would say, is like the research labs selling more tokens. Basically, you should be running loops to pay us more endless tokens. Stop prompting your agents. Figure out what loops it can run forever, permanently.

**[43:21] Speaker B:** Half of it could be useful. What's your thoughts?

**[43:25] Speaker A:** So what we're essentially talking about here is the difference between human in the loop work and AFK work, right? Human in the loop work being the human you are there with the agent, talking together and like, figuring out something. So really useful for planning, really useful for some kind of more complicated implementations, really useful for unscoped work. You know, stuff that you just need to figure it out locally with the agent. And then we're talking about AFK stuff. So AFK away from keyboard, you ping off the agent and it goes and does something. Now I think that, I mean, the moment that I discovered AFK was the moment I really got into AI coding, and the moment I was really able to massively increase my output. Because then instead of me having to sit in the loop, handle all the permissions requests, handle all of the, you know, anything the agent needs to ask me, the moment I can just remove myself from the equation, I've parallelized myself.

**[44:20] Speaker A:** Suddenly there are two of me, you know, three of me, four of me, five of me, able to go and produce so much more code that I then go and review. This idea that loops are the only way to do it is crazy. You know, like, we're essentially talking about the history of this goes back to Geoffrey Huntley. Where is it? G. Huntley. Ralph. Goes back to Ralph. You remember Ralph? Yeah, I was talking about Ralph in January. I think the original article comes from 14th of July last year.

**[44:48] Speaker A:** And essentially it's a loop. So this is the idea where you have a while loop that says, okay, pass this prompt to CLAUD code, and then eventually you'll be done. Now it's essentially just running Claud code again and again and again. That's the idea of the RALPH loop that I was talking about for a while. And what I realized is I don't really need to run this as a loop, right. The only thing I need out of this is the AFK agent to take on a specific task and do that task the way. I mostly think about these things as queues, okay? Queues, not loops. The queue is really the backlog of tasks that I need to complete. I'm looking at the sandcastle issues right now. These are bug reports coming in about sandcastle feature requests, things like that. I need to scope the item.

**[45:38] Speaker A:** Let's say it's this, for instance. So I've done a bit of triage here. It's sort of explored. Okay, is this trivial? Is this possible? This was done afk, right? So this item has been picked off the queue. It's been explored, been put back on the queue.

**[45:53] Speaker A:** I might then need to go and actually implement this looks like. Yeah, this looks pretty good. I'll actually add the agent implement label and I'll go and implement this in my GitHub action sandcastle setup that I was talking about earlier. Now, this isn't a loop really, like, it's sort of just. It's a queue that eventually gets resolved.

**[46:12] Speaker A:** This will come off the queue once it gets. Once the pull request gets merged. And that's all development is really. You just have a queue of tasks that you need to get done. Project managers add more stuff to the queue. You complete the tasks in the queue, like that's how we've always done it. And there are multiple nodes picking stuff off the queue, multiple developers. And so an idea that there's a single loop that just sort of goes and completes all the tasks doesn't really match with how like, you developer teams generally work when it's all sort of inside GitHub. Actions like this, anyone, any developer can add one of these labels, can trigger something and can just get work going. So, yeah, I think the idea of the loop is useful, but it's not the whole picture.

**[46:58] Speaker A:** And I think an idea of a queue where you're picking tasks off is. Is better. But mostly it's just sort of nonsensical, really. Like when people talk about you need a loop prompting your agent. We're really just talking about AFK agents.

**[47:10] Speaker B:** Yeah, I guess when you talked. I don't know why, but the image that came to my head is like a medieval king managing a kingdom with like some ministers or whatever. And basically assuming, you know, the king knows the best, has the most context, not like a king that just like randomly got inherited empire, right? So if you deployed a minister into some region, far region, and you never heard from him, never gave him commands. He would be running on a loop. And that could go wrong or could go right, depending on, you know, how complex the issues are in that region, how smart the minister is, whatever. But ultimately, as the king in that medieval kingdom, you want to do the queue approach. You want to have people come to you and say, like, we have a problem, upcoming invasion, you know, or there's a famine in this region.

**[47:55] Speaker B:** And, like, you have this queue of problems and you are still in charge. So that would be the equivalent of a human here with a bunch of agents, bunch of AIs.

**[48:04] Speaker B:** Still, you would be prioritizing. Okay, we have these 50 bug reports. Only three of them are critical. Let's fix those first. Okay. We have these resources, this brand deal, this company wants to work with us, check their reputation first. Is that a good way to think about it?

**[48:22] Speaker A:** Totally. And what we're doing here is like, you're still able to build tons of automation into here. Let's say that I had some kind of telemetry setup for Sandcastle or like an observability tool like Sentry or something.

**[48:34] Speaker A:** I could get a bug report from a live application, create an issue from it, immediately tag that issue as, like, explore the issue. Maybe the agent could return some structured data from the explore, saying, can we fix this immediately? Or does this need a human in the loop? It goes and implements it, it goes and reviews it, and then maybe it has a little tag on it saying, can we automatically merge this? Or does it finally, like, ping the user to go and do it?

**[48:57] Speaker A:** Like, I see these systems as you need human in the loop checkpoints, and you need to push those further and further, right? Further and further towards the final thing as. Or the final output as you can. So you would essentially get these, like, instead of, like, seeing the bug reports, you would see the bug reports, you would see the exploration of the code base, you would see the fix, and you see, like, can we review this? Yeah, just like that's. That's what you get as the human instead of seeing the bug reports. And it's just so much richer. And it means it's one button click away instead of a whole debugging session away. So that's.

**[49:36] Speaker B:** I mean, so then the question is where.

**[49:40] Speaker B:** Yeah, yeah. So the question in that situation becomes, because it's not a loop, right? It only runs when the bug comes. There's no point for it to running infinitely, just paying OpenAI or anthropic infinitely. But my question was like, again, as the AI gets more powerful where, because you mentioned you push yourself further, further to the right to last step is pushing to production.

**[50:03] Speaker B:** When does it cross the threshold where these type of things, whether it's like a small UI change, user requests, a new color scheme, whatever, it could be approved automatically. Right. And then maybe we go more and more. So how does that look like? Do you see what I'm getting at?

**[50:17] Speaker A:** Oh, how do you remove human and loot checkpoints is what you're saying?

**[50:20] Speaker B:** Yeah, like, where do you decide basically where it's trivial enough for you to not even look at. Right? Like maybe all the agents you have, which again, you set up the harnesses, they have your skills, you use a good model, and all the agents are like, okay, this is a small bug. It was just a misaligned UI element.

**[50:38] Speaker B:** There is no, you know, harmful intent from the user. The user isn't trying to hack the application. We're just going to merge it into prod right away. That will presumably grow, like the scope of things that could be merged to prod right away. So how would you think about that?

**[50:53] Speaker A:** Well, what I'd say is, like, what do you gain from review? Right, sure. You gain, okay, like you gain the ability to gate things, gate dangerous things from going into production. So prevent security, bad stuff happening, you know? Yeah, prevent, you know, let's say Claude code, source code being leaked to the world, you know, you, you prevent that bad stuff.

**[51:17] Speaker A:** So, but you also gain insight into your own system, into the, into the plumbing, right? So you're watching the thing do its work and you're assessing, did it do a good job? And so that second one, you don't want to lose that because like, again, we're talking about the harness, right? You want to improve your harness over time and you want some observability into it. Now, you could remove some human in the loop checkpoint. So you could say, okay, this PR is just an internal refactor. It just moves some code around, it doesn't actually change any behavior. And you could have an AI that kind of says, okay, you don't really need to review that one. But then who reviews the AI that's doing that? Right?

**[51:57] Speaker A:** How do you give feedback to that over time? You probably do need to check some of the PRs that the agent says are fine to review, to check if they are actually fine to review view. And then you improve that over time. And so we need to think about this. We're not just reviewing the code, we're also reviewing the system that produces the code.

**[52:12] Speaker A:** And that is important and useful. But I agree, the goal is to remove human loop checkpoints where possible. Definitely.

**[52:20] Speaker B:** So maybe the better way rather than like, okay, let's say in an average day for this application, AI autonomously fixes 20 things and pushes to production right away because they were super small. At the end of the day, instead of you like reviewing all these because I'll be boring and slow, maybe you get a custom, you know, teachskill HTML file and say like, okay, this is the common patterns in the bugs that were fixed, right. So like instead of you having to go through all of the GitHub commits, PRs, whatever, which is not really optimized for this agentic era, I mean again, GitHub was created a long time ago. It would be a custom software, a custom HTML file, whatever. That's, you know, knows you, your learning style, your common mistakes. It has a history of the bugs in the past, you know, whatever. And it will be more optimized to helping you improve yourself and the system.

**[53:09] Speaker A:** Totally. I mean one really cool, like what we're talking about here is in making review seamless and taking, taking the human effort out of review, one thing that I've seen people do, which is crazy, is on any front end change, it gets the AI to record a video of itself walking through the code and like the thing that changed it then calls a text to speech API and overlays some speech on top. So it's like the AI is talking to you while it walks through the code and you just have a video on the PR of the thing working. Like that sort of richness is something that we should be building into everything that we do and trying to optimize for human review and make human review faster.

**[53:52] Speaker A:** Because everyone's sort of moaning about, you know, like, oh man, we've got so much code to review.

**[53:56] Speaker A:** But probably you could be using AI to help you review the code. Right? Like in all sorts of interesting ways that I think we're just scratching the surface of.

**[54:06] Speaker B:** Absolutely. So a lot of people want to build something with AI, right? Whether, like you could start with some personal tools, some, you know, something for your team. But a lot of people want to build a business, whether it's a startup, whether it's some other business. How would you think about that? Like, you know, a lot of people, there's, there's a group of people who say like, oh yeah, SaaS, subscriptions, they're going to be more valuable than ever because you're going to be adding more seeds for the agents. There's a group of people who say, like, SaaS is dead. How are you thinking about building a business building software in the age of AI?

**[54:38] Speaker A:** Well, I don't think that much has changed about it, to be honest. Like, again, I'm not a pundit. I don't really watch markets, I don't really like, care whether SaaS dies or thrives. Like, if you're building a business, what you need to do is the fundamental stuff. You need to go and talk to customers, you need to figure out what they need and then you need to build stuff. Like you need to build prototypes that look like what they need and solve their actual problem. I don't think anything has changed there and I think you can learn to do that and be better with it. But I don't think AI gives you any particular advantage there because what you need to do is go out in the real world and have conversations and figure out what it actually is people need. So I think all of the classic product design books will still make sense here.

**[55:20] Speaker A:** It's just you have a massive leg up when it comes to actually implementing it and the procedures they talk about, you can start delegating them to AI too. So mostly though, it's just about having the right idea and building the right thing. And that's not something that AI can help with if you're not also talking to actual people and figuring out what they want. As soon as you figure out what people want, you could scale.

**[55:43] Speaker B:** Yeah, I think that's actually the thing that AI is notoriously bad at is like the original ideas out of the box.

**[55:50] Speaker B:** And yeah, like that would be probably one of the main pieces of advice I would give to people is like, you need to be choosing the features that get added. Right. If you see somebody who's like delegating all of that, it's like, what's the next big thing we should add? It's like, no, you should be in charge of the product. Yeah. Obviously you don't have to learn the exact syntax or whatever, you have to read every file. But like, you cannot be asking the AI to build your app. You need to have the vision, you need to know why you're building it and what problem it's solving.

**[56:17] Speaker A:** Absolutely. You should be asking AI what thing you can remove from your app. Basically you should be asking, how do I make this simpler? How do I improve the ux? How do I actually focus in on what people want instead of ending up like, you know, one of those dreadful VC funded apps that we've all seen where there's a thousand features and you can't find the thing that you want to do. So again, this is just product design fundamentals.

**[56:40] Speaker B:** We mentioned that senior Devs get like 10x improvement and you know, speed up.

**[56:46] Speaker B:** How do you. Because from my experience that's true, but only if they actually use the AI tools. There's a group of still developers still that are kind of refusing to believe it or AI is not that good. They tried it a year ago, two years ago, they were disappointed. But obviously tools, harnesses, models are much better.

**[57:02] Speaker B:** But my counterargument, or maybe it's not a counterargument, is like, what about just hiring the true. If you were hiring, hiring young people who are true believers in AI who like know these tools inside and out, they use them all the time, they know what's the best model, what's the best skill, what's the best, you know, agent in each situation. And obviously they need to have some technical fundamentals. But like, how would you reconcile this tension of like, these are seniors who have 10, 15, 20 years of experience and they get a TEDx versus these are like true AI believers who might not have as much experience as the seniors, but like are better operators at using the AI.

**[57:43] Speaker A:** Well, hiring great juniors has always been the goal of any company, basically because if you find a great junior, then anyone who's enthusiastic will do a better job than someone who's more experienced. Basically, like enthusiasm beats experience just in pure output. And because they, they develop so much faster and they learn so much faster. And so people who are really excited about this new age and know a lot about this stuff, if you can just pair that with a little bit of software fundamentals with. Because what we're talking about here is I think of there as being a difference between DX developer experience and ax, right? Agent experience.

**[58:19] Speaker A:** And so agent experience is the experience that the agent has working in the code base. And anything you can do, whether that's better skills, you know, increasing the power of the model works, of course, you know, improving the harness and improving the code base as well is like, that's amazing. Often people forget about improving the code base actually for better ax, you know, improve about. They forget about all the edges you can get with like good software fundamentals. And so that's where the senior will be useful because the senior knows how to build good dx, right?

**[58:54] Speaker A:** They know how to. If they're a good senior, they know how to build a code base that can work well with humans. And there's a huge Overlap between good DX and good ax, but they're just coming at it. Like the junior who's great at AI is just coming at the problem from a different point of view. From the senior.

**[59:12] Speaker A:** What was your original question? How do they get hired? Or like, how do you. Or like, would you hire out of both of them?

**[59:18] Speaker B:** Sure. But not, like, who would you hire? But like, who will maybe get more alpha? Who'll be more valuable? Like, is it like the senior who has a lot of these experiences, you know, the right way of thinking about software, but maybe isn't as true of AI believer and versus somebody who's like fully embracing AI to the maximum and knows how to use it to the fullest?

**[59:37] Speaker A:** I think if you have an experimental mindset and you're excited about AI, then you're going to get a ton out of it, whether you're junior or senior.

**[59:44] Speaker A:** And I think again, if you're intrigued by the harness, first of all, and intrigued by improving AX everywhere that you can, then you're going to, you're going to thrive and love it. Now, there's obviously a lot of, like, good reasons that people have for not wanting to get on the AI train. You know, they might just be a bit squeamish with the ethical stuff, you know, anthropic, stealing everyone's novels and just sort of pumping them into Claude. But like, it is here and it's. That's how the job is now. You know, if you're just a tactical programmer just plumbing away, doing your work, you're gone, right? Like, that's out, you know, you can't be a code monkey anymore. You need to think strategically. And so seniors can absolutely make the most of that. But juniors can learn that too.

**[1:00:33] Speaker B:** All right, my closing question is going to be practical for the people watching. If you could take the average AI enthusiast and give him like one or two action steps to do today to either improve his setup, improve his harness, learn something. What would those one or two things be?

**[1:00:49] Speaker A:** First thing I would do is I would delete every single skill, every single plugin, every single MCP server. I would go back, I'd delete your Claude md, delete your agents, md go back to absolutely nothing and then observe the agent, see what it does.

**[1:01:02] Speaker A:** In my experience, everyone bloats up their context window with too much stuff, with too many instructions. Go back to a blank slate and see what the agent does. Once you're seeing what the agent does in that basic sort of mode, then layer things on top of it and make sure Those things are procedures, procedure, skills, not ability skills. Layer things on that you yourself decide. And my skills Repo is is a great place to start there.

**[1:01:31] Speaker A:** If you really miss something, if you really miss like brainstorming from superpowers, then bring that back. If you miss this, if you miss that. And make sure that you install them in a way that you can customize these. You can play around with them and experiment. You know, if you're noticing problems, then try to find solutions to fix those problems.

**[1:01:48] Speaker A:** And try as much as you can to delegate the implementation to an AFK agent. AFK is just incredible way to work. It just takes a little bit of setup. But once it's set up, it's just goes crazy.

**[1:02:02] Speaker B:** Right? Matt, appreciate your time. Where should people find you?

**[1:02:06] Speaker A:** Find me on Twitter. Find me@aihero.dev and I've got a newsletter where I post about all this stuff. So aihero.des especially if you want to learn about my skills and learn about updates to them, then go to aihero.dev skills.

**[1:02:18] Speaker B:** All right, I'm gonna link all of that below. Once again, thank you for your time, Matt, and have a great day.

**[1:02:23] Speaker A:** No worries, David.