Get out, and stay out, of Git hell.

Cleaned from the video's own audio. Student and client names are replaced with [student] and [client]. Times match the video, and the chapter chips above jump to them.

0:16 Welcome

0:16 Hello. What's going on? Hey. Happy Tuesday, everyone. Happy Tuesday. glad we sorted that. Where did [student] go? He was here a second ago. Okay. I was talking to [student] and he disappeared. No, he's there. Oh, is he? Okay. Yeah, so I'm here. Oh, okay. I was just saying I'm glad we sorted out your access issue after, you know, a little bit of patience from you. So thanks for being patient. All good. I was just worried I was the only one in the beginning. no. I think we had a lot of things like moving pieces for sure right wade yeah I think there's still a lot of moving pieces for sure on several fronts but yeah we're process of elimination for sure you all have done a lot it's amazing oh thank you [student] thank you so just so that I'm clear the invites for this master class there was no invite for this master no we need to we're in because traditionally all the invites come from maven right but this is a completely it's not a course so it's a membership program so it's just outside like maven so yeah that's on the docket another thing in the docket for mr wade over here yeah all the lessons and calendar stuff will live in the lms from here on forward so that'll be like your one centralized spot to always know what's going on.

1:50 Amazing. and like we, I mean, this is our first lab session. So this is cool. I mean, this is awesome. This has been a long time coming guys. And I'm excited to kick it off with Michael and the topic that we're going to talk about. But as you know, we're, we've got the LMS. We're going to have a space for it in the lab. Hunter, do you want to mention a couple of things about that? So that, cause you're, that's your baby. I don't want to take the yeah you did just call me hunter but oh did I say I was like looking for hunter like is he here everything's a blur for me right now so that threw me so what was the question do you want to talk about the lab space in the lms yeah I mean I can show it yeah I wanted to quickly do that because it's new to everybody so yeah

2:37 A tour of the Lab in Learn

2:37 So I won't show it from the dashboard everybody knows where those program tiles are and everything but this is the lab home as it currently sits I'm sure it'll change just because we're constantly looking for new things to add but right at the start again very inspired by youtube amazon prime netflix kind of thing because this is going to be a living breathing kind of thing that changes all the time so like right there front and center you can see oh I have people drawing on my screen I must not have that on the zoom thing off but so that is not on my design on these lines here but long story short there's a slider here for featured sections so you kind of know what's going on as you scroll down there's the tool of the week so like tyler last week and jeb is like all the rage right now so you can always stay on top of like what tool that we have our eyes on what's next in order so we have all the sessions outlined here that are on the docket for season one I guess you could kind so you can come in here I'm seeing this yeah the team hasn't even seen this so yeah there's stuff here this is the season one at a glance so you can always see just with this little legend exactly what kind of sessions are going to be going on here it just it connects to this spot right here we have the vault so we have some in here that kind of were tyler has been premature in releasing some of these back in the day but they were part of the agent native os and they were originally for the lab to begin with like that's what the whole idea of blueprints and everything was for so you can come in here grab those whether you were in the agent native os or you're just coming on board like we'll definitely have more it's just these ones were originally for the lab when we released them and then as you scroll down here we have their little perks page ticker and I'll show you some of these other things again this is a section for tyler's 8d eighth dimension stuff some of the fun stuff that we talk about like the eighth dimension just so you know our terminology when we say like Tyler mode and some things like that and then one thing that Tyler had a good idea about was kind of outside of the main sessions that we have here in the lab more like dedicated clips and more fun stuff that we could add down here that's more punchy that you don't have to watch maybe a 90 minute video to find those gold nuggets or things like that so we can add that here sessions page so if you want to like filter through exactly what sessions are going on.

4:57 All of them will live here when you click into them. So here's the GitHub masterclass today. This is what the sessions will look like. Videos will be here. You can see who hosted them. You can join on Zoom, add it to calendar, and then the transcripts will land here too. We will have decks too. With Michael's deck, we'll have the decks in here so you can grab those. A whole write-up based on the transcript that the session is so you can just read through if you prefer to see things that way. request. That was a thing that I came up with that I think is going to be really cool for folks. So think of it in two ways, whether you'd like to host a session, because we're having alumni sessions as part of the lab, or that you would just like us to throw and speak on some topic or have a dedicated session. Think of this as an upvoting kind of thing that you can use. And you can also post anonymously. We'll see it, but if you don't want to share that you were the one that posted it, we were always about trying to hide things if you don't want to be public kind of look like this down here. You can upvote everybody's in the community. We have to get that wired in a little bit more because we don't have it in our Supabase.

6:00 So that will be coming. It's already built out. We just got to get the back end for it. Vaults, we have blueprints, agents, and skills. You can just click in these. Again, it's a little sparse for the launch of the lab, but we'll have skills, agents, and blueprints in here. So you can just come in here and read all about those. And then the perks page too that we've showed off on orientation. These are all 598 different deals and some very up-to-date ones. In camp, we use something called Agent Mail. It's in here. There's a bunch of deals here. There is a little bit of some prerequisites that you have to adhere to for startups and things that the companies require their vendors to adhere to, literally. You can come in here and read it. There's sometimes even a few different options in here. Then it tells you what you need to qualify and you can claim these deals. so that is the quick rundown I am going to stop screen sharing and see if maybe we can figure out how to get these lines off the screen but other than that I'm excited for the lab it's going to be a living breathing thing that I think really matches the territory that we're in with ai where it's always changing and I think it's going to be exciting too for the community as a whole so I'm very excited for it this is so cool wade when do we get access to all that good stuff Realized after I just stopped my screen share, there was like 40 people in the waiting room.

7:24 So that was awesome. You want to make me co-host? Yeah, I'm doing that right now. Should have done that. [student], I think that we can make this live. I mean, Sara might say no, but I think we can make this live because it's already all built here. And I don't think there's any. I think the permissioning stuff that Tyler's been working on is kind of it's universal for all our programs. evil that we're going through right now. It's the hardest and the worst it's ever going to be. Once we get this tagging and everything in there, we won't have like all those access issues and everything. So it's pretty much just once this is in there, we flip a switch and it should be available to everybody. We'll put it in the announcements, right? Yep. Let's do that. Okay. Well, Michael has a life outside of AI Build Lab. I don't know if you guys know that with a job and everything. And so I don't want to like, I know we've booked him for the hour, now. But those of you who just wondered, and Wade gave us a tour of the phenomenal work he's done with the lab.

8:29 So when we send out the recording, make sure

8:31 Get out and stay out of GitHell

8:31 You watch that. But let's get started with our first lab session. So I was like, I think there's no better way to start the lab with something that I actually called a session, Get Out and Stay Out of GitHell. But Michael I didn't even know that you named it that. Okay. But he's going to make sure we never get into GitHub after this session. And as you guys know, Michael is part of our team. And he's the Git boss. We call him the Git boss. So there's no better person to teach this. And as you all know, now you're in Agent Native Essentials. With this whole big switch up we're doing, GitHub is a core part of how we and our agents are going to be working going forward. So we think it's really important that we have the foundations and the fundamentals and we understand why, especially because a lot of us in the room are non-technical and we hear GitHub and we freak out. But I like to think it's like a fancy Google Drive for nerds and for agents.

9:35 But maybe Michael will tell a better story than that. So, Michael, do you want to kick off, basically? Oh, I should probably say, sorry, guys, we will keep questions till the end. we're going to do like maybe 40 minutes off a Michael teaching and then we'll do 20 minutes we're trying not to make these sessions go for three hours like we normally do because we're going to bring outside experts and we have to be like you know respectful of everyone's time as well okay yeah well I'm gonna yeah so I guess my goals are a few things so I'm pseudo technical which means I have done some coding but I'm not like a software engineer or someone that's super like in that in-between space. And what I want folks to sort of understand at a high level is what GitHub is for usually, which is, you know, in general, it's used for software engineering projects and not for the kinds of things that we're doing. But there's a reason why we're adopting it. And so I want you to understand that reason. And then we're going to walk through sort of like some of the different setups that you might do, depending on whether you're coming in through Essentials and Agent Workforce, or if you're doing it through Camp, those scenarios look like and how those repos might get set up.

10:49 And then we'll get into some of the granular things about how GitHub actually works and some of the things your agent might be telling you about GitHub that you don't necessarily understand and I want you to sort of understand at a high level what those things are about so that you can steer your agents properly on what you want to do.

11:10 Git, GitHub, and why agents use it

11:10 Let me just make sure I can change my slides. Sweet. GitHub really is used for software engineers and software engineering teams. And, you know, when you think about the software development process, right, you have a product owner, which is usually like a product team. You've got builders, which are The engineers and the product team usually, like, reviews it, and then it's deployed as a service somewhere. And GitHub basically enables you to manage... Is that changing? Thank you. allows you to change that process. So one thing to understand immediately is that there's a difference between Git, which is a program, and GitHub, which is an online service that allows you to manage Git repos. So Git you can use on your computer. You never have to use GitHub. And that, you know, it has the mechanics of the version control and other aspects of that for maintaining repositories.

12:15 And then GitHub is a place where teams go to all look at the same Git repo and there's tools there. So now why is that always changing? We're going to get there. All right. So if we take like a broad look at the software development process, there's a planning stage, you know, like PRDs, things like that. There's a creating or building stage files get built in. For us, agents are doing that. For engineers, historically, engineers have been typing that code, but now they're using agents. There's a review stage where you look at the original code and the changes to that code, or for us, the original file and the changes to those files, and we have an opportunity to make sure we want to adopt those changes. When we're building things, there's often testing that goes into that, and GitHub has some ways to test. And then there's an actual, for software, there's an actual deployment stage where you're deploying that software as a service and then you get feedback from customers and that process repeats.

13:22 And for folks that don't understand how GitHub is free, it is because they offer services, some free, some paid, at each of the stages of the software development process, right? So for the planning, they have issues and projects and discussions and ways to collaborate and talk about the project that they're doing. For the creation phase, you've got repositories and history. You've got pull requests, which we're going to talk about, which is basically the merging of changes. And then they've got a bunch of things for the checking and deployment and their services that they charge for in that process that we don't have to use. but you should understand that that's how they make their money is from large engineering teams. And so just to give you a sense of how embedded GitHub is in the software industry, if you were to go to a VPS provider and often you will see that it gives you the option, like if you want to create an application that you can specify a GitHub repo that you have built And it just deploys from there sort of like a one-click deployment because GitHub is so ubiquitous across the software engineering industry that they just have these kinds of tools built in.

14:46 So if you're ever in a situation where you need to build some kind of application that you want to deploy, know that if you host that on GitHub, there are services that will deploy it for you directly from your GitHub repo. and so agent work really follows this same set of steps right and we have the same kinds of needs we need to be able to collaborate we have different work products we're not necessarily writing code but we have a bunch of different things that we make we need to make changes to that you need to maintain version control of and you know we're going to use some of the tools on GitHub, but not all. And so I just want to walk you through like what this may look like. And so this is obviously not really Claude Code. It's the image that my agent came up with, but it approximates what Claude Code looks like, right? And so for most of us, we do go through like a planning stage. And in both Cloud and Codex, there's actually a planning mode, which I use extensively where I'm giving it the context that I have.

15:56 I give it the goals that I want to accomplish, and it creates a plan, a detailed plan on what it's going to execute. And once I agree to that plan, I tell it to go ahead and start to execute that, and that's when it starts to generate the files and starts to build the files that we're going to be using. And so that might look like something like this. we got a folder of client research and it's generated a bunch of files for us. And if we were to go and look at those, we could actually see what's in those, right? So for us, we're usually generating some kind of like knowledge work and it'll generate many files. It'll run checks on that. So especially for people that are in camp and they're building, you'll notice that it does a lot of tests, right? And so just like in the software engineering process, we're doing testing, and so the agent will do those tests. And then we want to be able to deliver and look at that and improve it over time.

17:04 Your workbench and your repos

17:05 So now I just want to look at how we may set up GitHub from the perspective of the agent workforce, and then we'll get into how this looks for camp. And Wade, you should feel free to chime in at any point if I'm saying something that reality because I'm not as close to that as you. But the way that I understand it is that there is an installer that is going to set up a private repo called My Workbench Template, which then selects the agent workforce as the course that's available to you. And it's going to create that repo on your machine. And you'll have the opportunity to review and approve any additions to that. And that basically is setting up your home base where you're going to be doing most of your work to start with, and you'll have the courses available to you. And so that may look like something like this, where you've set up a folder under GitHub, under my workbench, and then there should be a folder of course, and then you should see workforce in there.

18:07 And Wade, that's actually one thing I want to check with. Is that actually true? Is that how that's set up? Yes, it is. Very similar to how the Agent Native OS was set up. So one of the questions that has come up a lot is, should I be doing my work inside my main repo, or should I be starting a new repo? And so I've tried to create sort of like a little bit of a decision tree here for you because it isn't a one or the other. It could be, you know, depending on what you want to do, you may want to do that work inside the main My Workbench repo, or you may want to do it in a separate repo. And I think the main thing is like, you know, do you, are you using, what's the best way to describe this? So for me, when I have my main repo, I'm the only one using it. So I don't have any collaborators. For AI Build Lab, we have a bunch of repos where we are collaborators. And so that's like a separate repo, again, because of that collaboration piece.

19:10 So if you are doing work by yourself, the decision may matter less from a collaboration standpoint. If you are going to do a project where now you are adding collaborators, you may want to have a different repo because now you can have different sets of permissions where multiple people can read that project, repo. And then there's also reasons of, you know, is the context different? Meaning like, are the projects truly separate? Do you actually need to keep them separate from a privacy security standpoint? Do you want to ensure that there's no bleed over from one project to the other? Those would all be reasons to start a new repo for a different project. Yeah. And so this is what this can look like inside your, I just want to give you a sense of like how this actually plays out on your file system.

20:13 Right. And so like if we go back to that original idea where you've created my workbench as a repo in your GitHub folder, then under say like the work folder, you have a subfolder called client research, and that would be one project inside of my workbench. And then if you had another project, let's say like I had a project with Sara. And so I said it's like Sara's project. That would be another folder inside the work folder, right? All contained within the My Workbench repo. Yeah. And so this is just describing the process of like, so if you did want to do a new project in a new repo, you would again use the My Workbench template and you would give it a different name and it would be a new repo inside of your larger GitHub folder. And then you could personalize that specifically to that project, which includes, by the way, not just context, but you could have different skills, different hooks, et cetera.

21:16 So this would be another reason to have a different repo is that they have just different needs for that. I'm missing anything. No.

21:32 Global skills and project skills

21:33 Yeah. So this is one thing that Sara asked me to add and I told her it was a whole world. So I wasn't going to do it, but I decided to do it anyway. So the piece here is what I was actually just describing is that it's possible to have skills and agents and such that are global agents, right? So like if you were in the context of workforce, if you're installing agents into Claude directly, those may be global agents. So that no matter where you're working, no matter what repo you're working out of, those agents or those hooks or those skills are always available. example of where you might want a global skill would be, let's say you had a particular way that you liked doing planning documents and you wanted to use that planning skill no matter what work you were working on, that would be a good candidate to have as a global skill. Conversely, you can install agents and hooks and skills as local to a specific project.

22:38 So for example, if I was working for a bank or had a project with a bank and there was a specific report that they needed for that particular workflow, there's no reason for that to be a global skill, right? Because I'm only going to use it when I'm working on their project in their repo or their project folder. So in that case, it would make sense to make that more local. yeah I just want to peruse this and make sure yeah so this is what this may look like right so you know github being the main folder and like one thing to understand is just by just because you have a folder called github doesn't make it a git folder each of these subfolders, my workbench and client research have been, there are Git files that get included in each of those folder sets that makes them using the Git application. And we can show you those if that's a question.

23:41 The other thing to be really clear about is that GitHub, and then especially if you're using Git with GitHub and then pushing things online, GitHub is your backup and you don't want to be installing your GitHub folder in, say, like your Dropbox folder because they basically start to interfere with each other. The other piece is that, and we'll, did we talk about that next? We don't. So one other piece that will, that I'll show you later is that you don't necessarily want to upload everything from one of these folders online. And so there's a mechanism to like, so for example, if you were using a file that had all of your API keys in it, want to upload that to GitHub, you wouldn't want to upload that to Dropbox. And GitHub has a mechanism to basically keep certain files out of it online, whereas Dropbox doesn't. So anything that's in a Dropbox folder would be online.

24:39 How camp sets it up

24:39 And now we just sort of like go through the same process from a camp experience. And again, you know, so for me, I'm going to talk about the way that I have mine set up. For my agent OS, I have a repo just for that, for my systems, for everything else. I call it the personal agent foundation. And anything that I'm doing that is related to my operating system, I do out of that repo, but I don't do any projects out of that repo. All my projects are separated into different repos. And so, like in the case of my Hermes agents, it has the ability to go read the systems repo, but it also has the ability to go read the other repos that I have. And so this is a question that you want to ask yourself is that if you know, you are in a camp set up and you have, you know, Claude or Codex running as your interactive session and you have Hermes running as your always on session, like how do you want to organize your OS and your operating system repo, and do you want to have that separate from your project repos?

25:48 And that's how I tend to do it. I think you've heard Wade and Hunter and Tyler say that they tend to work out of the same repo for a lot of their things. So there's just a choice to make there. And I believe that the setup kind of works very similarly. And Wade, again, I'm kind of counting on you to tell me if I'm saying something crazy. But the installer is going to look and see, and it's going to ask you what class you're taking. And if you're in camp, it's going to create a destination for that context repo. And then you'll be able to review and apply the changes so that anything that you're changing, it's going to keep. And anything that's new that the class is applying gets updated without interfering with your own stuff. And again, this is just how this might look. So you can see here for me, like I actually have a personal agent foundation repo that is separate from the agent native camp, which is the class, which is separate from, say, like a client research project.

26:49 And all of these repos are operating in parallel. And my agents have differential access to those different projects. And again, it's the same kinds of questions that, you know, should you use the same repo? Should you use a different repo? of conditions or questions that you would ask yourself, you know, who's collaborating on it? Is the context or the information, do they need to be, does there need to be a hard boundary between it or do I want them to kind of be closer together? And I don't think there's one right answer to that, but it's something that, you know, to think through for yourself and, you know, you can kind of like look through these slides on your own and try to help you decide that if you're wondering about that. Oh, is there anything I really want to say from this? I don't think there is. So again, new project, you can use the template repo to start a new project in camp the same way that you would have done it from Workforce.

27:52 You start the new project, you add the skills and hooks and agents that you want from the different courses and into that so that you have those available. in that repo and you just kind of work from that place. And we kind of talked about this already in terms of having the user scope versus the project scope and how that gets, basically that gets put in different places, right? So for the user scope, it gets, the main thing to pay attention to is this top line here where it says users, students, which would be your name or my name and then .clad. agents and skills and hooks go into that subdirectory that is a global skill or hook or agent. And when it goes into a specific project folder under Claude, so you'll notice it's .claude in both cases. In one case, it's like the macro place where Claude always looks. And then in the project scope, it's within the project itself.

28:57 And so it's like additive. So the user scope, all those things are always added. And then if you're in the specific project, those additional agents, skills, and hooks also get added. So there's no scenario where you need both agents in both places because if you have it in the global place, it's always loaded. And then in the project scope, it's sometimes loaded if you're operating out of that project. And that's sort of the main idea there. Yeah, so the, do I really want to say anything here? I mean, I think the main thing is that this is going to follow the same process that it kind of always has in terms of updates to the courses. Those updates are going to flow down. There's going to be a process to make sure that it's only updating the files that we are supplying and is not, you know, overriding any of your work. and there's a mechanism to like disseminate that across the different things that you're working on.

30:10 Yeah, and that's, we don't need that, that's redundant.

30:13 Branches, worktrees and commits

30:14 Okay, so now I want to get into sort of the mechanics of Git and the version control. And so this is like one of these diff things that people look at all the time. But let's just sort of like back up and like start to think about version control. And so, you know, back 10 years ago, if people were using Microsoft Word a lot, I know that I have a whole bunch of folders from my history that have file names that look exactly like that, where I've got V2 and then I've got Revise and I got Use This One. And, you know, I'm never quite sure which one is the most recent version. And I have to look at the date modified and everything. dilemma. And so if you go to like using Google Docs basically solves very similar problems. So what we're trying to solve with Git is solves collaboration and that multiple people can work on the same document actually at the same time. And you see all those changes happening live. And it also maintains a robust version history.

31:19 So I don't know if you've used this feature or not, but if you go look, you can actually save specific versions as a name and go and look at the version history and you can see all the updates that have happened over time by different users and it's actually quite nice and that but it only solves it for you know google docs which is like one document so what do we do when we have many different kinds of documents many different kinds of files and so like this is kind of like what a knowledge work folder might look like. It's got sort of like the traditional work folders like research and assets and drafts, but it also has agent folders now, right? So you've got agent MD, you've got the agent skills, you've got, you know, hooks files, you've got ENV files, which are environment files that have API keys sometimes. And we've got files that are related So there's a lot of different files and how do we manage the version control for that?

32:26 And that's really what Git enables us to do. And so you can sort of see here, right, this idea of a Git history is just like in Google Drive or Google Docs where you can go and look at all the changes. If we go and look at the Git history, we can see all the history of all the changes that have ever been made inside of that. And again, your agent is going to do that, but you should know that history does exist. So let's say that you made some commits and you wanted to understand what changes have actually been made since yesterday. Your agent could go find that because that history is actually written. All right. So this is a key question, right? So how does this actually work? And so there's two main ways that this happens. One is the first thing to understand is that when you have the current copy, when you go to make a change, it always makes a copy of that main branch.

33:31 I mean, for a second, we're going to get to that jargon. But the entire repo basically gets copied. And it gets copied in one of two ways. It either gets copied as a duplicate and it's then called a branch and that branch is now local. So like if you were to go and look, if you're on the main branch, which is usually what we call the most up to date branch, and then we give our copy branch a name, which in this case is revised brief. If you switch back and forth, what you see is that your local copy is actually changing back and forth and it happens pretty instantly. But let's say that you went in and you changed one file. You just wanted to see this in action. What you would see is as it went back and forth between the branches, that file would change in real time. Just go back and forth as you change it from main to revise brief. And that is fine and used a lot if you are doing one piece of work.

34:34 Now, agents tend to work in parallel. right so they may be changing you may be having like three four or five threads of different types of work all happening at the same time and so if they're all working on that same branch they could interact and collide with each other in ways that aren't useful and so the alternative way is to create a work tree and the only difference between a work tree in a branch is that instead of replacing your main branch with the, you know, revised brief branch, it creates an entire new directory on your hard drive. And so then you will see three, four, five directories of the repo on there. And each of those are being worked on by a different agent thread. And so just that idea to keep in mind, it's not that different, but it is in the sense that you work trees and within work trees there are also branches but the main thing on your computer is that you'll see either one location or you'll see multiple locations and the main reason you have that is just to keep the changes that are being made from interfering with each other so that you can kind of work in complete freedom on each body of work without worrying so much about conflicts.

35:56 And to kind of go through this idea of like how these branches work, right? So the jargon is it's called the main branch or it's the current, you know, it's basically the most up-to-date version. And you create a copy and that's like, that's that branch off the tree, right? That's a copy. And you give it a distinct name. You're able to see the differences between and the changes that you've made, when you save those changes or quote unquote commit those changes, that's creating a checkpoint. So for anybody that use cursor, you know, you'll see those things where there's like a checkpoint where you can go back to the previous spot. That's basically a commit, right, where it's a safe point. So if you make a mistake, you can go back to that checkpoint. And you only, you know, it's like the more checkpoints that you have, the more you can time without losing a bunch of work. So like if I did a whole branch and never committed it to the end and I wanted to, you know, I realized I made a mistake, my only option is to go back to the beginning or to try to like rework it.

37:06 I didn't, because I didn't create any checkpoints. So checkpoints can be very valuable.

37:15 Push, .gitignore and pull requests

37:17 So once you have made these commits and let's say that now where you've done everything that you want to change for that session, what you would do is then you would quote unquote push that change to the online repository and you would create a, well, yeah. All right. So this is where we're going to talk about not everything. You may not want everything to be online and maybe the slide should be somewhere else. But the idea is like When you're pushing things from local to online, not everything should go online. And there is a file called gitignore, and you can see that here where it's the clientresearch .gitignore. And in that file, you can list specific files. You can list directories. You can list whatever you want that you don't want to go online. And this is deterministic, right? So anything that's listed there will not be sent online. So, for example, if you have an environment variable that have all your keys, you don't want that in there.

38:21 And you can either have your agent set up that file, depending on how you create your repo to begin with. You know, there's actually example or default git ignore files, depending on the kind of application that you're using, et cetera. So that is definitely something that you want to be aware of, that that's possible, and you should be using that, especially if you have things in your repos that you wouldn't want online. So once you push that online, you want to be able to review the differences. Usually your agent will be doing this, but this is like what a pull request looks like. You'll, you know, it'll have a description of what it is. it'll actually you know then you can go in you can look at the differences in the files themselves and you can check these you know all this is what software engineers spent an inordinate amount of time pre-agents is that they would literally go and check like all of these different changes to confirm that these are the changes that they want to make and there were whole processes around this right so if I wrote a whole bunch of changes I wouldn't go get I would not get to go check engineer would actually check my work to make sure that it all aligns, right?

39:36 And so what we're finding is that even the engineers now, because they're generating so much code with agents, they can't possibly review all of these anymore. So now they're having to have agents do the reviewing as well. But I want you to at least know that this process exists. And so when you're telling your agent, first, you're going to be telling your agent, you know, make sure you're committing this, right? Because those are your checkpoints. When you feel like you're ready to either like you want a colleague to review it, or you feel like the changes are done for this process, you want to quote unquote, push it and create a pull request. And the reason it's called a pull request is that it's a request to pull the changes into the main branch. And that's sort of the idea, right? You're going to pull those changes in. And then once you quote unquote, merge those changes. Now those changes become a part of the main branch and this process can repeat. So the next time you want to make a change, all of those previous changes are now just a part of the main branch.

40:38 You create a new copy and you make changes again. Talked about that. We talked about that. And we talked about that. Yeah, this is, I mean, this is just seeing the multiple copies, right? So when you have a worktree, you've got multiple copies of the same thing.

40:59 The words your agent uses

41:01 So some other jargon to know about, right, that you'll hear your agent talk about and you're like, I don't have any idea what it's saying to me. So like when it says like there's dirty changes, it means that files are changed, but they haven't been saved or checkpointed, right? And so it's basically just saying you should be committing these changes or discarding them. And usually it means that the agent forgot to commit it and you should just be asking it to commit those things unless like the situation where I've discarded dirty changes is when I made some change three weeks ago and now it's obsolete and I just get rid of them. But for the most part, dirty changes just need to be committed. Sometimes files get added to the repo that the Git system hasn't picked up yet to track them and to track their version history. And so when you see untracked files, usually that means that you just want it to start tracking them. If you are ahead of origin, so the thing to understand about origin is that there is the repo online, which typically is considered the origin, and then there's the local copy.

42:12 So if you are ahead of origin, which is typical if you're creating changes, right? Your copy is ahead of what's online. Sometimes what's online is ahead of you. And so like, for example, when we're doing the update course, right? And you want to do that before you start doing work, it's because the course is ahead of what your local copy is. And so you're working with outdated information. So that can go either way. And we explained pull request already. And then every once in a while, you're going to find that there's a merge conflict. So especially if you're working with work trees. And so let's say that you did two bodies of work that seemed separate, but one file actually was shared between the two projects and they both changed that file differently. And so now you've got two versions of the file and there's no obvious way to align them. So if you have an merge conflict, what historically had to happen is an engineer would have to go figure out how they're different and how to align it.

43:16 What you would tell your agent to do now for a merge conflict is figure out, given these two bodies of work, how can we make this file work for both? And it will go and figure that out. But if you see a merge conflict, that's what's happening. Yeah, when to pause. Two edits disagree. Basically, that's the merge conflict. If it doesn't know where to send stuff, you want to think that through and make sure you're sending information to the right places. And you can go. These are things that can come up, but it's rare. So we will not spend too much time on that. And I just talked about that. Yeah, I mean, this is really just getting at, you do need to steer your agent. And so, you know, if you do get to a place where you're sort of stopped, ask it to explain to you what the issue is, where the conflicts are, and use it as an opportunity to make sure that the objectives that you have in mind are going to get met.

44:28 And don't just say, just fix it. Because if you say, just fix it, it's going to make conclusions, which sometimes may be right. So it may seem like that it's like you can just do that. But sometimes it'll go astray. And do I want to talk about that? I don't. This is the problem with having agents make your slides is that they don't always, they're not always as synthesized as they need to be. Yeah.

44:57 Q&A

44:59 Open up for questions. Cool. I think we're unmuted still. Is that true, Wade? Yeah, I've just been manually. I think everybody has the ability to raise hands, unmute, just the standard song and dance. All right. [student], you go first. Yeah. Hi. I'm just wondering this way of using GitHub with agents. Is this sort of a new practice or is this an emerging practice out there? I guess what I'm trying to get at is would Claude and all those sort of understand this, we got stuck somewhere, we're wanting to set up GitHub, could we use Claude to step us through this agent sort of way of using it? Claude will definitely know how to use GitHub. So, you know, the real shift here, right, it's like if you think about the history of Claude Code was built for coders, for software engineers. of tooling inside of Claude Code that's specifically geared towards GitHub. The actual shift here is not using GitHub with agents.

46:04 It's the shift from software engineering to knowledge work. And so what is, so that, you know, Git will work with Codex, Cloud, they don't know how to use those things. There's actually, there is a natural progression or a natural alignment between the development of code and knowledge work, but there are differences. And so I think at some point we're going to see, I think Buzz is an attempt at this, but there's going to be some service that comes out that is more designed for the version control collaboration, for knowledge work that's happening between people and agents and the different kinds of work that is done in knowledge work versus coding. It's just not there yet. So it's good enough. Some things that may feel hacky about it are not quite right, and it's because the whole thing is so new. But the real shift is from coding to knowledge work. Yeah, and I was just wondering if, like, the models themselves understand this new world, and if we get stuck somewhere trying to figure, oh, how should I set up GitHub for this new world?

47:13 They don't 100% know how to help you navigate GitHub. Yeah. Okay, cool. Yeah, 100%. Yeah, I think [student] was like that was a lot but like we have super intelligence at our fingertips this is complex yeah but the point is like this is complex having enough of a understanding to be able to give you know your judgment to when around things as well you know like we can lean on ai obviously but then you always also have to understand how the parts work to be able to make the judgment calls So I wanted to give you some idea of what's there. You are not going to have to do really any of that. The thing to understand, right, is that when you make changes, it is creating a copy. Right. So just like you would like with a file, like, oh, I don't want to mess up my original. So I'm going to make a copy of it and make the changes to my copy. And then if I like those changes, that becomes the new original. That's all that's happening with GitHub.

48:16 It's just doing it in a way that multiple people can be making changes. And it keeps track of all that change history. And that's primarily the thing, right? And so then there's like the jargon that goes with that. But that's all that's really happening. You make a copy, you make changes. The changes become the new original. Yeah. And I know our team all obviously work together with different GitHub repos and things like that. And, you know, some people in our team spend a lot of time or more time in GitHub and other people are just like, Claude Code, give me the like, what is happening? You know what I mean? So, [student], do you want to? Yeah, sure. I guess I'm just, you know, looking at confirmation on my thinking, Because, you know, I'm looking at continuing on and I love what you guys do. Like, you know, what you guys. But it also gives me a tremendous respect for what you guys do and the amount of knowledge that it takes.

49:24 And I explain this to my experts when I'm managing a TurboTax. Like, a lot of them come from all different states that the gig's up without Claude. It's as simple as that. Without Claude, you know, I mean, you've got people today, vibe coding, that's never took one class. And it's almost insulting to a PhD engineer who's been doing this for 20 years. And sometimes I feel like it's like, hey, become a surgeon in five weeks instead of five years. Brain surgery, add another two-week course on, you're all good to go. So I got tremendous respect, and I'm good at asking Claude. So if I'm, like, I'm telling you right now what Michael went over, probably 10% sunk in and whatnot. But I've now got these screenshots, okay, and the slides that you make. I put that into Claude.

50:26 There's nothing I can't get Claude to tell about something. I don't understand this. 12 whatever and so continuing on it's never been I've never gone to a point where it says hey I can't continue I'm stuck now Claude says you know there's always a way to coax it out it's now writing a program now for me that on my QBO MCP server it's now rewriting tax codes not even close to my specialty. I'd be sunk without it. So realistically, as we continue on, is that a good thing as long as I can run? Because if a clock goes tomorrow, the gig's up. It's a shop stand. [student]'s AI model's gone. If I try to ground this in something that everybody knows, right? It's like, this is really a question about scale, right? So everybody understands the problem of a Word file and trying to keep track of like what's the most current version.

51:31 Everybody knows kind of like how to wrestle with, well, should I keep this in the, you know, should I keep this project in the same folder or should I create a new folder for it? And so if a folder is a repo, it's kind of the same, it's the same thing. It's actually not new. It's just new in the sense of like there's additional scale. It creates the ability to collaborate. it creates the ability to have it online you know there's more things that go into that folder but in essence a repo is a you know do you want a new folder or do you want it in the same folder you know do you want to you know how do you keep track of version control across many files you know get basically helps you manage that so it's not really new it's just happening at a scale and you know there is more complexity because there's more files and there's the file types are new and we're not used to thinking about skills and hooks and agents and like where do they go and but it's not you know it's not you're not having to code right it's kind of more like a mental tracking and understanding how to track the different things and what's happening as opposed to having to be particularly technical because you know Claude and Codex can handle the technical part of it yeah I think awesome thank you understanding that like mental model right michael in terms of like these are the pieces how they work and stuff like that and then we rely on you know ai and agents a lot to the execution and the reasoning and stuff like that as well work how are you I'm good hey michael nice to meet you nice to meet you so I have a question that really is pertaining to just the architecture of this, which is if I have a practice and I serve different clients, and today a simple model would be I have one agent.

53:28 It has a master knowledge base with a lot of my own frameworks and details, and then it gets replicated into a client folder that has a client knowledge base and all. And so I can keep client work separate. I don't have one agent or one workforce that's crossing and dealing with or mixing up multiple client work. And so what I was trying to figure out is do I, if I build this workforce and one repo, am I replicating that repo for each individual client and giving or, somehow giving it access to different client knowledge base like for the for is this for like my workbench yeah if I were in workforce correct yeah so the way that I would think about that and you know in opinions may differ so it may you know if wade's still here or hunter they maybe they work differently but the way that I would think about that is anything that I want to be global, meaning like if I have a framework that I like to, like I said this in the example, right?

54:40 So if I have a framework how I like to plan projects and I want to use that everywhere and any project that I'm working on, that would be like a global skill. So any kind of global agents or global skills or like the secrets guard for example, so that you don't put secrets like API keys into your cloud chat or whatever. Anything is global I would have in my workbench and then anything that is going to be specific to that project I personally would put those skills and those hooks and those agents into the project folder that are only loaded when I'm working out of that particular project that's how I would do it and I can jump in I'm here for a minute and then I actually have to scoot but I was like oh Ooh, this is a very important question. So I'm glad you asked. Hunter likes this question. Yeah, I don't know if I like this question, but I spent a lot of time. You spent a lot of time thinking about it, yeah. I like [student]. I don't know if I like the question, okay?

55:45 Here, let me bring you up so I can see you, my friend. I'm going to pin you for a second. Okay, cool. So yeah, so this is very important, right? So there's a distinction I'd like to make here about when you're talking about different client projects. So, and this is a question for you, for everybody because there are client projects that you're maintaining and then there's client projects that maybe they you're maintaining that are running solely for them right because that's different if you have a workforce that you've set up for them and it's their agent fleet that you've set up on a vps or whatever that you're either hosting on their hardware or a cloud thing that they're renting from you, that you're premium, whatever, that is different than you maintaining different client projects that you're working on, right? So this is a very important distinction, because this is when you start to have, well, am I cloning the same agents for different things, but then so that they only are contained over here, right?

56:46 I would say, once you're hosting for a client, those obviously, they need to have their own fleet, their own workforce, that's bound in their client work, right? So similarly, as an example, and this is an industry-wide thing that you're on the cutting edge of because this is a brand new problem, right? Because it's a brand new idea. So for example, what we're literally building right now, it is unfinished, but what we're building for ourselves is because we started to develop, we're like, oh, Hunter has a fleet. Tyler has a fleet. Wade has a fleet. They're all separate fleets, right now is a team fleet. And so the team fleet coordinates between our fleets. Here we go. This is the thing about scale that we're talking about, right? So the team fleet is on a VPS that then has company knowledge, because what we're also untangling right now is Tyler's five years of IP that we're turning into a shared company, right?

57:48 For years, it was Tyler and Sara, and then they brought in Wade, and now they're scaling. Now we're, I could say, scaling up. I'm part of the team. Michael's part of the team. We're like, we want Gigawatt to do what we want, but it's in Tyler's stack, right? So how do you solve this problem? So the way we're looking at it is you build this team fleet that then has its own access to its own knowledge base, right? So there's the company data that it's connected to. And then there's my stack, which has its own repo, which has its own knowledge. I'm working on my own client stuff. I am spending full-time hours with AIBL. Somehow I'm doing other client things. Who can say how this is possible? But that has its own knowledge basis, right? So then my fleet is connecting to the AIBL chief of staff. And then my fleet is like, hey, I want to do this. I want to do that. And then what we're experimenting with right now, again, cutting edge stuff, is then we're talking about governance and permissions, So how do you make sure that the right agents have the access to the right things and not the things that they're not supposed to have and connect to other agents that do have the correct permissions to then delegate and touch the files that they're allowed to touch?

59:04 Right. So for yourself, depending on what you're working on, this is just one example. Right. So another example could be like, oh, [student] is building out these different things for different clients, but it's in [student]'s stack, right? So [student] wants the chief of staff or his main operator agent, whatever you're calling it, to be able to speak to [student] on the different things. So you have your chief of staff that understands the pyramid of the knowledge base that it's allowed to touch. Potentially, it's allowed to read everything, but maybe it shouldn't have access to write anything, right? So this is where you start to get into those permissions that then each one of those clients' things has dedicated agents that can then read and write to that thing. So this is where, like Mike was saying, this is a scale question, right? And then it also depends on, like, are you working solo? Do you have a team working with you? Are you connecting to those? So, right, so this is where it really gets into spaghetti.

1:00:06 So I'm happy to talk more about This is probably a whole thing we could do in a whole lab thing, Sara, because this is like bound to what Michael is talking about. But then it's also like it's like I've been thinking about GitHub. Like Michael said, we're now using in the way it wasn't designed to be used for. Right. And so repos used to be like code bases to ship to things. we're using repos like knowledge bases. We're using them as like mini micro services. It was not meant for any of this stuff, but we have somehow worked our way in to do this stuff, right? This is the stack we've been given, literally the stack of cards we've been given. So we're figuring it out. I hope that helps and not make it more complicated. I hope that's somewhat useful. Please DM me. I'm happy to talk more about this stuff. I think people are asking for that session. And also I know Hunter that we're, a lot of you are in workforce and obviously a lot of you are in workforce to build your own workforce, but also then be able to productize and scale it to other companies, people, whatever.

1:01:19 And so part of what we will be, you know, gradually kind of like sharing and workforce is, it's how you do that with the repo structures and everything like that. so like we are gonna cover that but just don't feel like you need to jump right to that right now because you're just it's literally day two yeah because you gotta do it for yourself before you can do it for other people it's kind of like the oxygen mask idea now I'm gonna be really rude and I have to go to another call but I wanted to jump in drop that grenade and leave so but I will be back my pleasure I will be back I'm just gonna try to go get Amazon web services to give me money. So that's cool. Michael, how are you for time? Because I know we haven't had a couple of, we're just, okay. So we do two more and then like [student] and [student] and then call it. Yeah. Cool. [student]. Hey everybody. I'm really glad you're doing this session. But my question is about skills.

1:02:22 And what Michael said earlier is that if it's a skill that you're going to use ubiquitously, like the planning skill, put that at the global level, or if it's something related to a particular project, leave that within that project. So back when, just after OS, the Cairn skill was shipped as part of the OS repo. So those weren't skills that I had before, skills that I then wanted to use in a completely different project. So the first time around I did it, I did that. I pushed those, I copied those skills at the global level. So then my Claude said to me that if OS ships an update, which could include an update to those Cairns skills, the global copy I've got wouldn't then sync. And those skills were very valuable to me so it alternatively suggested creating sockets now I don't know what the architecture of those sockets actually is but that's the way that it's now built everything it relies on sockets and it's constantly telling me skill sockets gone stale we need to update it and I follow it but that's the way it's now allowing my skills that you ship let's say for example in these repos allowing me to use them ubiquitously, selectively, only the ones I want.

1:03:41 But that's the way it's navigating it. So is that a durable, solid way to keep building? I'm not sure what the socket method is. I'd be curious to dig into that. The way that I've done that is instead of doing a socket, I do a symlink. And what a symlink basically is that it just points to the original file. So if the original skill is in the agent native OS and that gets updated, there's a, you know, and then you have a symlink from your Claude global skills repo to that place. It's just always, it's just tells it to go read the original source. So there's not two copies of the same skill anywhere. It's all one copy. And then anything that needs to read it just has a link to go read it from there. I've solved it for myself. So I haven't solved it from a global local level, but the reason that I started to use that was because I use Cloud, I use Codex, I was using Gemini for a while, and I didn't want to have three versions of the same skill in all three.

1:04:52 So I would install the skill once, and then I would have the other services basically just symlink to that place. I think, Michael, what you're saying in terms of symlink, I think that did come up. I just didn't understand the vernacular, but the SIM link and the socket almost were sort of the same thing. But what's interesting is you're saying you can SIM link outside of the clawed environment as well. That's right. So just have anything that you want to use that. So in the case of the class, you could have all of your systems basically have a SIM link to that folder and file. So then if we send you an update that's updated that skill or hook or whatever, it's just pointed to that same place. And you only have to worry about maintaining that one. Super. So I think my methodology is right. But what's new to me is that Codex can inherit live up-to-date copies of that same very useful. It's not a copy.

1:05:53 It's a pointer. And by a pointer, the symlink is basically just think of it just like as a link. It just links to the original file. Yeah. OK. All right. Super. OK, brilliant. with my methodology then thank you so much great well I think we got everybody's wheels turning for sure michael I think we will probably end up doing a couple of like reviews or deeper dives into github and stuff like that because I think that you know it's something that we're continuously working with and needing to understand. But for now, Wade, can you let us know about the LMS? Like, is this recording going to go into the LMS or we could post the Fathom links for now? In terms of when the lab is going to be ready, basically. I think Tyler has it pre-dialed in, but that is going to be more of a Tyler question. I mean, the plan is for sure to get this stuff in the LMS as quickly as possible. I know we have a lot of stuff, like a lot of plates that we're spinning right now so it might not be there right now but long term the goal is to have these as part of like an agentic workflow that we have ourselves where the decks the zoom chats the transcripts and the videos all land in the lms immediately afterwards so for today I'll probably just drop the fathom link right now just as an intermediary kind of thing but that is a long-term vision it's just that way the lms will be your home for everything is the goal.

1:07:22 Yeah. And if there's places where things were not well explained or still seem complicated, you know, feel free to DM me and I'll either just answer the question right then, or maybe I'll make, you know, some addendum slides to try to address some of those things so that it, because the real goal is for you to just be able to have awareness around how all this is working as opposed to you having to be able to, you know, go do it. So if there's still places we'll try to like fill those gaps. How about instead of like people hammering your inbox, we just start a thread in the lab channel and then that way we're consolidating it all in one place. Great. All right. I was thinking out loud, would it be possible to get some kind of shared sessions while you're on GitHub and navigating around so we get that visual view kind of sunk into our brains? Would that be easier for you, Michael? Maybe. we should talk about it. A hands-on version like you're driving, you're showing us how to navigate around, move things around, maybe break a few things on purpose to show us how to fix them.

1:08:28 We can do a V2 of this session down the road. Cool, thanks. Amazing. All right. Okay, everybody. Great start to the lab. What are we doing next week? Oh, [student] is doing her session next week. So one of our... Oh, there she is. She's waving. I'm really excited about her 23 or 27 agent fleet that she's got built out for her home and work life and everything like that. So cannot wait to see what you're up to next week. Next Tuesday, same time, guys. Hopefully we'll have our schedule and everything up on the lab by then for sure. Thank you, everyone. Thank you, Michael. And we also have the 8D Friday session with Tyler this week, too. It will be like the all mixing pot of all the programs, which will be really cool for the Friday stuff. week, every day. I know. Do you guys have a life right now? I feel like several of you have just been on Zoom with us all day. Just come hang out all the time. Yeah. All right, guys.

1:09:30 Bye, everybody. We'll see you soon. Ciao.