{
  "video_id": "efctPj6bjCY",
  "channel_slug": "indydevdan",
  "channel_handle": "indydevdan",
  "title": "My 4-Layer Claude Code Playwright CLI Skill  (Agentic Browser Automation)",
  "duration_seconds": 1636.0,
  "url": "https://www.youtube.com/watch?v=efctPj6bjCY",
  "upload_date": "",
  "transcript": "What's up engineers? Any Devdan here\nwith the right skills your agent can do\ntons of work for you. You know this, but\nby engineering the right stack of\nskills, sub agents, prompts, and\nreusability system, you can automate\nentire classes of work. If you don't\nhave agents for these two classes of\nwork, we'll break down in this video,\nyou're wasting time doing work your\nagents can do for you. This is the name\nof the game right now. How many problems\ncan you hand off to your agents in a\nreusable, scalable way? In the terminal,\nJ automate Amazon. We're kicking off a\nClaude code instance in fast mode. This\nis going to run a different type of\nworkflow. This is going to run in\nagentic browser automation workflow.\nNow, this is a personal workflow that\nit's running. You can see here it's got\na whole list of items that I need to\npurchase, and it's going to do this for\nme. This is browser automation. As\nengineers, there's a more important task\nthat we need to focus on as well. So,\nwe'll open up a new terminal here and\nwe'll type J UI review. This is going to\nkick off agentic UI testing. You can see\nhere we're kicking off three browsers.\nUh this is going to be a mock user test\non top of Hacker News, and our UI tests\nare effectively going to operate a user\nstory against Hacker News. You can have\nagents do your UI testing. Now, there\nare several benefits to this over\ntraditional UI testing with Jest or\nVitest that we're going to cover in this\nvideo, but you can see here, you know,\n40K tokens each. They're completing,\nthey're summarizing back to the primary\nagent, and you can see here these user\nstories have passed. Why is agentic\nbrowser use so important? It's because\nit allows you to copy yourself into the\ndigital world so you can automate two\nkey classes of engineering work, browser\nautomation and UI testing. Whenever I\nsit down to automate a problem with\nagents, I always ask myself, what is the\nright combination of skills, sub agents,\nprompts, and tools I can use to solve\nthis problem in a templated way for\nrepeat success. In this video, I want to\nshare my four-layer approach for\nbuilding agents that automate and test\nwork on your behalf. Let's break down\nautomating work on the web.\n[music]\nBowser is a opinionated structure using\nskills, subagents, commands, and one\nadditional layer we'll talk about. And\nthe whole point here is to set up\nsystems for agentic browser automation\nand UI testing. I don't just want to\nsolve this problem for one code base. I\nwant a system that I can come to that's\nbuilt in an agent-first way to solve\nbrowser automation and UI testing. So,\nlet's start with the core technology.\nSo, you can see here the Amazon workflow\nis of course using Claude with Chrome.\nYou can activate this by using the\n{dash} {dash} Chrome flag, and it's a\ngreat way to use your existing browser\nsession to accomplish work with agents.\nThere are pros and cons to this\napproach, which is why I needed another\ntool so that we could scale UI testing\nwith agents. That is of course the\nPlaywright CLI. Now, this is super\nimportant and the developers know this.\nYou want to be using CLIs, not MCP\nservers. MCP servers chew up your\ntokens, and they're very rigid. You have\nto do it their way, however the MCP\nserver is built. This is why we always\nprefer CLIs. And CLIs give us the\nmassive benefit can build on top of it\nin our own opinionated way. So, these\nare the two technologies that Bowser is\nbuilt on. Couple key things to note\nhere. We ran three agents that QA'd\nspecific user stories, and they all\nresponded to the primary agent with\nsuccess. You can see each of them has\ntheir own number of steps, and they all\nhave their own screenshots. This is\nsuper critical. You can see the\nautocomplete already picking up on what\nI want to do. I'm just going to hit tab,\nenter, open the screenshots directory,\nand let's go ahead and see what happened\nthere. You can see that every step of\nthe way our agents created a screenshot\nof the workflow. View top post comments.\nWe can walk through exactly what our\nagent did and how it validated\neverything. This is a simple mock\nexample test, but imagine this running\non your brand new user interface that\nyou're building up with agents deploying\nvery quickly. If one of your workflows\ngoes wrong, your agents now have a trail\nof success and a trail of failure\nbecause they're taking screenshots along\nthe way. I want to show you different\nways you can layer your architecture.\nIt's not just about skills. Everyone's\nvery obsessed with skills. I want to\nshow you how you can stack it up and\nlayer it properly to get repeatable\nresults at scale. So, let's jump into\nthe code base here. So, we'll start with\nthe skill. So, in dot Claude skills, we\nhave two key skills, right? Claude\nbrowser and Playwright browser. Let's\nstart with the more interesting one,\nPlaywright browser. If I open this up,\nyou can see we have the structure all\ncollapsed and you can see all the\ndetails of this skill. Now, the key\npieces are here. This is a token\nefficient CLI for Playwright, runs\nheadless, supports parallel sessions,\nand we have named sessions for stored\nstate. All right, so if we open this up\nhere, you know, you can see we have just\na bunch of details on how this works,\nand this is directly using the\nPlaywright CLI. You know, the nice part\nabout building your own skill is you get\nto customize it however you want, right?\nSo, they have their own opinionated\nskill in here. You know, I always\nrecommend you check out how other\nengineers are building their skill.\nThere's reference files here, and then\nthey have a skill that MD kind of just\nbreaking down what the help command\nwould do anyway. You know, you can see\nthat's how they broke that down. Inside\nof this, I'm breaking it down my own\nway. I'm setting up defaults that I want\nfor repeated success for the way that\nI'm going to be building applications.\nan important thing to mention. Code is\nfully commoditized. Anyone can generate\ncode. That is not an advantage anymore.\nWhat is an advantage is your specific\nsolution to the problem you're solving,\nand that boils down all the way to how\nyou write your skills. So, you can see\nhere, you know, the big advantage we get\nout of this is headless by default, we\nget parallel sessions, and we get\npersistent profiles. So, if you are\nrunning some type of login workflow with\nyour Playwright testing agent, you can\npersist the session, which is really\nimportant. So, that's great. We also\nhave the Claude browser skill. There's\nnot much to document here because when\nyou're using Claude with the --chrome\nflag, essentially what it does is it\ninjects a bunch of additional tools that\nallows Claude to access the browser. And\nso, the only real checks we need to add\ninto the skill is just to make sure that\nthe flag is turned on. And then we have\na couple, you know, opinionated pieces\nhere, resize the browser and then you\nexecute these requests and return. So,\nvery simple. This skill isn't ultra\nnecessary, but I wanted to build it to\nshowcase how we can stack up the skill\ninto different workflows. So, that's\ngreat. We have our two skills, right?\nThe skill is the capability. This is the\nfoundational layer. The next piece of\nthis layer to approach is going to be\nour\n[music]\nagents. So, you can see here we have\nthree agents. Let's start with the\nsimple one. Let's start with our\nPlaywright browser agent. Now, check out\nhow I'm prompt engineering this. This is\na very simple sub-agent that we can spin\nup to do arbitrary browser work with the\nPlaywright CLI. So, we've activated the\nskill in the front matter and then we're\nmentioning it just one more time inside\nof the actual workflow. So, you can see\nhere this agent is very simple. All\nwe're doing is scaling the skill into a\nsub-agent. We can prompt over and over\nfor UI testing tasks. And really just\nfor any browser automation tasks. It\ndoesn't have to be for UI testing. It\njust happens to be that it's great for\nthat. Okay? And then we have the Claude\nbrowser agent. So, we can use the Claude\ncode Chrome tools inside of a sub-agent.\nThe big problem with this is that it\ndoesn't really belong here. We can check\non our workflow right now. If you open\nup the terminal, you can see that our\nAmazon workflow is still working,\npurchasing things for us. Let's go ahead\nand open up Chrome. You can see it's\nbuying some blue light blockers for me.\nIt's got a couple other things inside\nthe the cart for me here, including, you\nknow, flowers, Valentine's Day right\naround the corner. Got to pick up those\nflowers for the GF, right? It's fully\nautomated and it's doing this work on my\nbehalf. The big problem with this using\nthe --chrome flag is that you cannot run\nthis in parallel, okay? So, this is one\nof the big limitations, 14 minutes\nrunning AK tokens. It's just going to\ncontinue running my browser automation\ntask for me. And let's move to our most\nimportant agent, the Bowser QA agent.\nAnd so, here's where things get\ninteresting. This is where we're\nactually building out a concrete\nworkflow. This is where things get more\nspecialized. This is a UI validation\nagent. It's going to work through user\nstories. It's going to do it in a very\nspecific way. This is where we start\ntemplating our engineering into a system\nfor repeat success. All right? These\nagents can do a lot more than we give\nthem credit for. It's time to start\npushing them hard into specific\nworkflows to automate classes of work.\nSo, let's understand how this agent\nallows us to do that exactly. We have a\nclassic agent workflow here, classic\nagentic prompt, purpose variables,\nworkflow, report examples. If you've\nbeen with the channel, you understand\nthe structure very well. Let's jump into\nthe workflow, right? This is where the\nwork actually happens. So, this agent is\ngoing to parse a user story into\nspecific steps, create a directory for\nit, work through the workflow, take\nscreenshots, report pass or fail, and\nthen actually close the browser. And so,\nhere we have an opinionated workflow\nwith a few variables where agent is\ngoing to be recording its journey along\nthe way and saving screenshots. Very,\nvery powerful. You can see we have a\noutput format. This is very important.\nWe are specifically telling our agent to\nrespond, and we have examples of some\nstep-by-step workflows that this agent\ncould actually execute, okay? And so, if\nyou wanted to, we could do something\nlike this, right? We can just copy one\nof these examples. We'll use the\nexample.com, you know, we'll just copy\nthis out, and it's going to turn this\ninto a series of steps, fire up a cloud\ncode instance, and then we can just use\nthe agent reference with @bowser-qa.\nThere's this agent, and then we can just\nfire this prompt off. So, we're giving\nit that step-by-step workflow, and this\nis going to kick off a headless browser\nagent to actually validate this workflow\nto make sure that everything works, all\nright? And so, this is just a random\nexample. Uh example.com doesn't actually\nhave, you know, any input field to enter\nanything into. So, this workflow will\nlikely come back failed, right? Because\nthese steps don't really exist. Failed\nto go to example.com, reserve domain,\nparagraph of text, no login, exactly.\nSo, we got screenshots of the journey\nsaved along the way. Now, this is the\nimportant piece that I really want to\nshare with you here, right? We layered\nan agent on top of a skill, and then we\nbuilt an agent to use that skill, right?\nWe can see that Playwright browser skill\nhere. And we built a concrete workflow\nfor repeat success. This browser\ncodebase, it isn't like a standalone\ncodebase. It's a codebase that I and you\ncan reference to pull a consistent\nstructure of skills, subagents, prompts,\nand one additional layer I'll share in a\nmoment here for reusability, and it\nallows you to take this and apply it to\nany problem, any codebase with a\nconsistent structure, okay? And so, the\nagent is where we start to specialize\nand scale, where the skill is just our\nraw capability, okay? And so, I think if\nyou're just looking at things from the\nangle of the skill, you're not using all\nagentics as well as you could, right?\nThere are many other pieces that you can\nadd to this to really expand what you\ncan do with your agent, all right?\nEveryone is just spamming skills right\nnow, and that's great. I understand why,\nbut there's layers to how you can build\nthis up for repeat success, especially,\nand this is an important thing to\nmention, especially with these new agent\norchestration features coming out of\nCloud Code and other agentic coding\ntools, knowing how to build these\nspecialized agents that you can scale is\ngoing to be all too important. I think\nsubagents got a massive buff, and\nthey're going to be a centerpiece as\nagent orchestration becomes the primary\nparadigm of agentic coding. I'll link\nthe previous video where we talk about\nthe powerful new agent orchestration\nfeatures coming out of Cloud Code. You\ncan see here the Amazon workflow has\ncompleted. It's walked right up to the\ndoorstep of making the purchase, and if\nwe open up the terminal here, you can\nsee here that it, you know, set\neverything. This workflow took 20\nminutes to run, but it did it all\nwithout us, all right? And so, you know,\nyou can see this is a this is a risky\nworkflow because it walked right up to\nthe doorstep of the purchase and it has\neverything we asked for. This is one\nexample, browser automation has many\nmany uses, many many things you can do\nfrom support workflow automation, from\ngathering documents from, you know,\ndifferent resources. There are many many\nways to use browser automation and you\ncan see here my agent emphasizing this,\nstopping here, not placing order, very\nimportant. The adherence of this Opus\n4.6 model is really fantastic. It's\ngreat with directions and you can see\nthat it, you know, completed this entire\nworkflow. Definitely took some time\nthough. And if it took time, that means\nit took tokens. So, that's great. Let's\ncontinue to the next layer, right? So,\nyou can see here we're starting to build\nopinionated, reusable agents on top of\nour skill, right? We're not just relying\non the skill, although if we want to,\nwhenever we want to, we can kick off a\nbrand new terminal, fire up Claude, and\nwe can activate any one of these skills,\nright? So, if we wanted to, we could do\nClaude browser, kick the skill off, or\nPlaywright browser, kick this off. So,\nwe can hop into any layer we want to.\nThis is a huge advantage that makes it\neasier to test and scale up your agents\none step at a time as you add layer by\nlayer by layer of agentics. But, you can\nsee here we have a couple prompts, so\nlet's go ahead and get into the third\nlayer of this stack, which is the actual\ncustom slash commands. And I'm calling\nthis the orchestration layer now. Let's\nbreak down why.\nOnce you have the skill and once you\nstack agents on top of your workflow, I\nthink the next thing you're going to\nwant to go for is a command. A custom\nslash command also just known as a\nreusable prompt. You can see we have\nthat UI review prompt that ran. This is\nwhere things get a little more\ninteresting, a little more complex. So,\nUI review fires off parallel story\nvalidation. So, you saw how this works\nat a high level, but you can see here we\nhave stories glob. So, we have a bunch\nof variables set up here. So, if we open\nup AI review, you can see we have a\nsingle simple user story for Hacker\nNews. And if we open this up, you can\nsee this very simple file format that is\neffectively a user story for your\napplication. It has the name, the URL\nyour agent's going to visit, and then\nthe actual workflow. If this isn't\nclear, the true purpose of these\nworkflows is, you know, you copy all\nthese, you go localhost, you know, blah\nblah blah/your\npage, and then your agent validates\nagainst that specific page. Obviously,\nthis is a very agent-first approach to\ntesting, but you know, another great\npart here is that you can do things like\nthis, you know, your staging.incom/your\npage, and then you can test against that\nas well. And if you wanted to, you can\neven modify this workflow so that, you\nknow, you have multiple pages that\nyou're going to test. Again, I want to\nemphasize this. This isn't just a random\nskill, right? I think of skills as\nlow-level capabilities that you give\nyour agent. After you have that, it's up\nto you to compose it into something\nuseful and valuable in a repeat scalable\nway. And a great way to do that is by\nbuilding out sub-agents so that you can\nscale, and then commands, which gives\nyou that real power, that real control.\nAll right, so more and more I'm thinking\nabout commands, you know, prompts as the\norchestration layer. So, you can see\nthis is the user story we built out, and\nof course, you can have an agent as\nyou're building your application. You\ncan have them very, very quickly spin up\nnew stories to test that workflow, all\nright? If you want to, you can take this\nand add that next piece. This is what I\ndo when I deploy this Bowser system into\nmy applications. I'll take this workflow\nand actually add additional agents to\nit. So, let me explain that part. In UI\nreview, this is our orchestration\nprompt. And of course, it looks just\nlike all of our other prompts, very\nconsistent prompt structure. You add the\nsections when you need them, when you\ndon't, you remove them. Here we have a\nlot of them, right? Purpose, variables,\ncode structure, instructions, workflow\nreport. What this does is, it's going to\ncreate an agent team. We are leveraging\nthe new orchestration feature coming out\nof Cloud Code, coming out of a lot of\npowerful agent-to-code tools now, right?\nYou can create teams of agents that work\ntoward a common goal. In this case,\nwe're creating a team that does UI\nreview, all right? So, you can see here\nin the instructions, kind of breaking\ndown how we'll do this, but the most\nimportant piece is the workflow, all\nright? So, we're going to discover all\nthe UIs and set up the output directory.\nWe're then going to spawn our agents,\nright? This is a team of agents and\nwe're actually breaking down how to\nprompt each agent, right? So, for each\ntask call, use this prompt. So, we are\nmeta prompt engineering in a different\ntype of way here. We're teaching our\nprimary agent or the orchestrator agent\nhow to prompt the sub agents. All right,\nand we're being very explicit here, so\nyou can be very, very detailed with the\nresults you're getting out of your sub\nagents. Then we have collect after every\nteammate finishes, they're going to ping\nback via the task list, as we've covered\nin previous videos, and then they're\ngoing to clean up and report. So, we're\nactually using this powerful UI review\nprompt, right? UI review, as a\nconsistent way to test our UI over and\nover, and all we have to do is just\nactivate this prompt. And our entire UI\ngets tested by agents. And so, you know,\nyou might be thinking, why would you use\nagents instead of a consistent, you\nknow, UI testing framework? There are\nmany reasons for that. I think the\nbiggest one is that at a drop of a dime,\nif we open up our user stories, we can\nhave our agent quickly build arbitrary\nworkflows and, you know, [laughter]\nvery, very, very easily and seamlessly.\nIt's just, you know, walk through\nstep-by-step exactly what happens, and\nour agents will just validate against a\nURL, right? To me, this is the big\nadvantage of agentic UI testing. They\njust operate on the thing like a user\nwould, okay? No sea of testing\nconfiguration for your Justs, your\nVitests, your, you know, whatever tests\nyou're setting up. They're acting like a\nuser would. You know, I understand that\nwe're always playing this game of\nbalance between are we going to build a\nagentic non-deterministic solution, or\nare we going to build a very\ndeterministic code solution for things\nlike this, right? And I think more and\nmore the answer is, you know, all the\ntop. I think all the best agentic\nengineers, they're going to be doing\nsome combination of both, but they're\nalso going to be leaning a little extra\nagentic, all right? And so, this is one\nmanifestation of that. We're setting up\nuser stories that have a specific URL\nthat we spread across multiple agents to\nrun it in parallel. And now at any point\nin time, and we can just kick this off\nagain, right? There's no cost here to\nus. And actually, I'll kick this off in\nheaded mode, so we can all see this. Any\npoint in time, we can then just run the\nworkflow to test our new application or\nto test whatever thing that you're\nworking on, right? And so, you know, in\nthe world of trusting and deploying\nagents, I think this is going to be more\nand more valuable because we can just\nquickly add user stories and have our\nagents run through them very quickly.\nYou can see, once again, they're\nspinning up their own headed browser\nusing the Playwright CLI. They're\nworking very, very quickly. You know,\nthey're operating with pretty great\ntoken efficiency because we're using the\nCLI instead of the MCP server, so\nthere's great token efficiency. We can\nsee all of our agents have completed\nalmost here. And they're all going to\nclose their page. There we go. Done. And\nthen they're going to merge the results\nback here. There it is. UI summary\ncomplete. This is us moving all the way\nup to that prompt level. And so, the\nprompt controls the sub-agents. The\nsub-agents use the skills. Okay, so very\npowerful. Let me show you the Amazon\nworkflow. So, if you're doing browser\nautomation work, Amazon add to cart, we\nhave a very, very simple workflow. I\nthink for browser automation, you know,\nthe automations themselves are best\nwritten as an actual reusable custom\nslash command for testing purposes, but\nalso so that we can scale them like\nthis. So, some engineers on the channel,\nyou may have come across patterns like\nthis where you have something I call a\nhop or a higher-order prompt. Okay, so\nthis is an interesting type of prompt.\nThink of this like a function that takes\na function as a parameter. All right?\nThis is exactly what this does. So, you\ncan see here, argument one, this\nactually takes another prompt as a\nparameter. Why do we do this? We do this\nbecause we want to wrap that prompt that\nruns in a very consistent workflow.\nOkay? And so, here's the workflow. This\nis the automate browser workflow. We're\ngoing to save browser automation\nworkflow inside of this directory, so I\ncan just store a bunch of automations\nhere, and then I can change the workflow\nthat actually runs. Okay? So, the\nconsistent pieces go in the higher-order\nprompt, and then the details, right, the\nsteps that you want to run, go in the\nlower order prompt or just the prompt\nthat you want to execute. As you can see\nhere, very simple, we have a, you know,\nAmazon add to cart, that's what we ran\nbefore. And so, at any point in time, we\ncan run, you know, Amazon add to cart\nlike this, or we can run, you know, our\nproper higher order prompt to automate\nand then pass in the workflow, right?\nSo, we would do something like this, and\nthen we would execute it like this. And\nso, this will kick off that purchase\nworkflow, and the idea is, you know,\nrelatively simple, but very powerful. I\ncan now run these automations, right?\nWe're going to parse, we're going to\nload the workflow, and then we're going\nto execute the workflow, but we can\nsave, repeat instructions for every\npiece of this workflow that runs. Okay?\nSo, that's what this hop automate does,\nand this is us automating browser task\nin a repeat way, okay? We're not just\nrelying on skills, we're scaling it up\ninto sub-agents, into reusable\norchestration prompts, and then we have\none more layer I want to show you here.\nThis is a tool that I'm using on the\nchannel, and for all my private\nengineering work as well. After you have\nall these different ways to execute with\nyour agent, you're going to want a\nrepeat single place to call all these\ntools, and that's what you saw here in\nthe beginning. If we close up this\nagent, in the root of that directory, if\nwe type J, or if you type which J, so\nyou can see my actual command, you can\nsee that I have J alias to just. Just is\na powerful and simple command runner.\nLet's break this tool down.\n[music]\nSo, just is the cherry on top for a lot\nof the workflows that I like to run.\nOpen up this file here, justfile, you'll\nsee all the commands we just ran, all\nthe permutations of how we want to\nexecute and kick off our Claude agent,\nand you'll see all the workflows with\nvariables we can pass into override\nthem. This allows you and your team and\nother agents to build repeat solutions\nand then to quickly access them, okay?\nSo, this is my reusability layer at the\nvery, very top. So, we have skills\ncapability at the bottom, we have\nsub-agents to scale. You can give each\none of your sub-agents a different skill\nor the same skill. And then you want\ncommands to orchestrate. And then right\nat the top, I use just or just files for\nreusability. And I'll go ahead and add\nmy just file. We type just here, you can\nsee I have a skill, of course, built off\nto quickly configure, set up, and adjust\nyour just files. So, I'll add this to\nthis code base for you here as well. And\nthe idea is simple. We want to be able\nto customize and specialize our agents\ninside of our code bases. Great. So, how\ndo we do that? After you have all of\nyour agentics built in, how can you\nquickly call these in a reusable way,\nright? So, that you, your team, and your\nagents know what is even available. So,\nI like to use just file as a reusability\nlayer. And it is just a task runner. If\nwe type just, you can see all the\ncommands available. At any point in\ntime, we can kick off one of our agents.\nLet's just kick off a couple agents here\nso I can show you exactly what this\nlooks like. So, if we have our Let's\nfind our Chrome browser agent here. And\nlet's just use the top-level just paste\nthis workflow here, test Chrome skill.\nWe can then override this default\nparameter. And the default parameter\nhere is default prompt, get current\ndate, go to Simon Wilson, find his\nlatest blog, summarize it, give it a\nrating out of 10. Okay, so we can just\nkick this default off, that's fine. And\nyou can see we're opening up a Claude\nCode instance to do that work exactly.\nYou can imagine this is anything, right?\nWe could be, you know, looking for\nupdates from our favorite blogs. We want\nto collect them into some resource. We\nwant to do some actual data entry. We\nwant to run support. We want to do some\ninformation gathering. You can have your\nagents do that. And Claude and Chrome is\na way to do it. You can also set up\nsomething like Playwright CLI to\nquickly, you know, build your own\ncustomizable skill that does things in a\nspecific way on your behalf. But I like\nto use the just file here as that final\nlayer of reusability on top of all of\nit. In the beginning of the video, we\nran this just this workflow. At any\npoint in time, we can come in, automate\nAmazon, or we can come to the workflow,\nand we can build a brand new browser\nworkflow. And then we can pass this and\nto the automation workflow. That's the\nidea here. And notice here that I'm\nsolving the class of problem, okay? And\nthat's the meta theme of what I wanted\nto share with you today. There are\nentire classes of problems that you\ndon't need to solve anymore if you teach\nyour agents to solve that problem. And\nso, in this browser code base, I have a\ntemplated repeat solution for solving\nbrowser automation and solving UI\ntesting. Now, you know, there's tons of\nthings in here we want to tweak, change,\nmake our own, make fit the mold of your\ncode base, but the way I'm thinking\nabout solving problems now in the age of\nagents is template your engineering into\na repeat opinionated solution that you\ncan deploy over and over again and\nspecialize, right? This is just a mold.\nBowser is just a mold with a great\nfour-layer architecture where you have a\ncapability, which are your skills, that\nyou then roll into your agents, which\ngives you scale, right? You can add them\ninto teams, you can parallelize these,\nand then you have commands at the top,\nwhich are effectively the API layer for\nrunning all of these in a more\nopinionated, more specialized way,\nright? this is the orchestration piece.\nThen at the top of it all, you can\ncreate what are effectively functions\nfor your commands that you can run over\nand over and over. This is my four-layer\napproach for browser automation and UI\ntesting. I highly recommend you build\nsomething like this out for your own\nwork. You can see here we finished\nlooking at Simon's blog. Shout out Simon\nWilson, always sharing top-tier ideas\nfor engineers. And, you know, you can\nsee here just a nice simple breakdown,\nright? But, that was all done with\nbrowser automation. You can imagine we\nhit, you know, five or 10 top blogs to\ngather information from engineers giving\nus the greatest signal, and that's the\nbig theme, you know, once again, we're\nstriking on that. You want to be handing\noff more and more work to your agents.\nYou want to be solving classes of\nproblems in a repeat way. Every time you\ngo to tackle that specific problem, you\nare doing less, and your agents are\ndoing more. You're scaling your compute\nto scale your impact. That's a a theme\nwe talk about on the channel all the\ntime. There's one more idea that I want\nto discuss with you here. You know, you\nmight be thinking, \"Dan, why are you\nbreaking things down so much like this?\nSkills, commands, agents. Why aren't you\njust throwing agents at the problem? Let\nthem take care of how all of this looks.\nJust automate everything, right?\nAutomate this stuff away.\" Don't\noutsource learning how to build with the\nmost important technology of our\nlifetime, agents, okay? If you're\noutsourcing your skills, I know a lot of\npeople are using plugins now, your\nagents, your prompts, how will you\nimprove? How will you build unique\nsystems? How will you even know how to\nbuild powerful agentic layers around\nyour code base, all right? And the\nanswer is you won't. You won't be able\nto. You'll be limited by what everyone\nelse can do because you'll be dependent\non what everyone else is doing. You'll\nalways be using plugins, you'll be using\nsomeone else's prompts, and you know,\nthat in itself is super dangerous. We\ndon't cover security a lot, but prompt\ninjections are one of the most\ndangerous security vulnerabilities to\nexist for engineers because you can\nwrite and command anything. More on that\nlater. I really want to emphasize this\nidea here. You know, if you can't look\nat a library, pull it into a skill,\nbuild it on your own, scale it with some\nsub-agents, and then orchestrate it with\na prompt, right? If If you can't really\nbuild it up, stack up these layers, you\nwill constantly be limited. And this is\none of the big differences, once again,\nbetween Vibe Coders and agentic\nengineers. Agentic engineers know what\ntheir agents are doing, and they know it\nso well, they don't have to look. Vibe\nCoders don't know, and they don't look.\nIf you master the agent, you will master\nknowledge work. Don't outsource\nlearning. Check out the link in the\ndescription, pull some ideas from this\ncode base. The organization here of the\nfour-layer architecture is the most\nimportant piece here. Take this, make it\nyour own, roll it into your own skills,\nright? Create your own sub-agents,\nspecialize your repeat solutions with\nyour AI review directory or your AI docs\ndirectory, with your commands, right?\nMake it your own. Specialization\nmatters more than ever. Specialization\ncombined with scale and agent\norchestration is where the big nugget of\ngold is right now in the age of agents.\nLink in the description for this\ncodebase. You know where to find me\nevery single Monday. Stay focused and\nkeep building.",
  "transcript_chars": 31722,
  "ingested_at": "2026-05-15T04:46:34.935992+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 27259,
    "like_count": 870,
    "channel_id": "UC_x36zCEGilGpB1m-V4gmjg",
    "categories": [
      "Science & Technology"
    ],
    "tags": []
  }
}