Is Loop Engineering Is Converging On How I Like To Build?

Transcript is auto-generated and may contain errors.

Hey folks, I'm just driving to CrossFit here. I'm going to do a little AI recap um because my in-laws are visiting and I'm probably not going to be recording much over this week coming up. So, just on on the weekend here, it's Sunday and uh I like doing these on like a Monday morning or something just because I've had the full weekend to kind of go through um mess around, kind of try new things out, see what's working, see what's not. Um so, um let's get into it. So, I think I've been talking a lot about like uh I guess like agent orchestration. every I know everyone's talking about we got you know loop engineering now like you don't prompt the AI it's it's all loops and um you know if you're still prompting AI you're so you know last month and you're falling behind

and you're obsolete uh you know it's uh it's rapidly evolving but it's cool I think um I think this kind of stuff the way that I see things going currently is sort of aligning with like when I'm playing around with AI and I'm like okay like if I if I want to get more out of this like what what's the next step? Some at least for me some of these patterns seem to be emerging and so uh like I'm not saying I like I'm I'm inventing this. I'm saying that my own kind of uh challenges and things that I'm uh facing when I'm trying to be able to do more with AI seem to to line up with um you know what people are saying in industry around like loop engineering and the harness and all this kind of stuff. But I think the I don't know.

I think a lot of people have different interpretations of what that means, how it's implemented and all that, which is I think it's exciting because I think it means we're going to have a lot of different a lot of different things kind of come out of this. But with that said, um I was talking before about how I was putting together like a a for fun like orchestration of of agents. And uh the disclaimer I always give is like I'm not I'm not sitting here going like hey I'm building a better orchestration framework than anyone's ever done. It's just like I'm doing it so I can learn. And uh yeah I think that I think that it has been good learning so far. I'm still kind of chipping away at it and trying to get it to the point where um I can have it basically like resolve uh its own issues and self-improve.

So mostly like what I don't want it or need it to do is like just sit there autonomously like making work for itself and then solving it uh and inventing new features. That's neat. But like it's more like if I have an idea and I'm like I want some feature built that I can just open it up um with as much or as little context as I need to or talk to the agent to to create uh the issue and basically uh it will split up the work into proper work items, delegate them across agents, go resolve it, go update itself and then there we go. Kind of wait for the next set of work. But then of course the idea is that I can run uh the backend for this not just sort of like the dashboard and orchestration for different repositories I have because that way I can do the same thing.

I can say hey I want to go add this feature in to one of my little open source things or a side project and just have it go uh delegate the workout. So um that's like what I'm trying to build with that. But also like I said I it's not the only thing that exists that's kind of like similar to this even doable mostly with GitHub. So I think actually this weekend there was a lot more just messing around with like truly what's available in GitHub and I feel like I'm always kind of scratching the surface of what's there cuz I don't spend a lot of time doing like DevOps types things. DevOps types of things. I don't even know how to say that. And so there's a lot of stuff that's in GitHub that I'm just not even aware of.

And I think I'm uh over the past few days in particular, there's been a big shift for me in like how I've been using agents and their own little uh workflow cycles that kind of is moving to more towards more of this like sort of loop engineering uh approach. And so for what it's worth, how I was doing things before is I wasn't really leveraging poll requests at all because to me that was it was just more ceremony than it needed to be. And and I mean that's where I'll kind of leave. But I guess I'm like why do I need a pull request if I'm just having an agent do the work locally, build the thing, right? It can run the tests and then push it up and I have CI/CD run anyway.

uh where I can sanity check things and it's the same set of tests that's run locally and again I keep coming back to these uh sort of like patterns in working with agents back to like working just with people right replace agent with person and so really the pattern I was breaking there it's a pretty obvious one is like yes like even forget AI imagine that agent is just a developer and so yeah the developer can run the test locally and those tests should be the same as what runs in CI/CD should be. Um so I am now trusting that someone is running those locally pushing up and um really like I was even putting like commit gates and stuff. So okay, someone's got to write up like why their you know their commit is good and then they can push it and then continuous integration runs anyway on on the main line.

But so and for transparency and clarity there, the the continuous integration part wouldn't deploy something if it was busted. But if a human was doing that, I would be like, whoa, whoa, whoa, that's kind of silly. Like, why wouldn't you, you know, um do whatever you kind of want locally, like make sure that you're getting enough stuff like covered and you have confidence. get your your pull request open, run, you know, run your uh regression suite on your pull request and then when it's good, like technically you get a green light, you should be able to merge. You shouldn't even need to run more tests. Like why are you running tests on the main line, right? Like why why are you testing your feature once it's merged into main? I'm like so I'm kind of sitting here going like duh.

like uh I've just been kind of repeating this pattern across all of my code bases because I've been um you know in the loop so to speak with the agents prompting them to build the feature when it's ready. They've basically proven it to me locally and then and then I push it up. So now what I'm trying to do instead is um go to a model that would be closer to what I would actually do with people, right? The difference is that when it comes to the code review on the poll request, um like if I'm doing stuff that's not in a team, so I'm pushing up code, I'm still going to use a pull request now, but it's just going to be on auto merge. So for my own things that I'm building, if it passes continuous integration checks, great. It'll just automerge. But that way I can go run them off my computer, which is proving to be a bit of bit of a bottleneck.

I'm going to come back to this hopefully before I get to CrossFit. So I can get that running off of my computer, which is cool. And then if AI agents are building stuff, same thing. instead of them running tons and tons and tons of checks on my computer, like great, you think you're done. You've done you know what what is adequate. Go open up the pull request, put it in draft, right? Run the tests when they all pass or whatever. Like get it ready for review and basically once I sign off on it, it will automerge, but at least I have to sign off on it. I might have some repos where I'm like maybe I don't need to sign off on it, right? Like that's the the ultimate goal for me is I don't want to have to sign off on it. I do for now, especially for like things like Brand Ghost where I'm actually like shipping like uh production code for uh where people are paying money for it.

I'll be absolutely reviewing, but you know, the goal is that ideally I don't have to because it's built things in a way that are how I like to build. It has the test coverage and the types of tests that I would want, right? Like that's that's the goal to get there. And I think there's already probably some side like for Neidler for example which is my dependency injection like type scanning package that's open source. I've done so much with needler like from uh agent sorry agent build code that like most of the time I don't really need to review it at this point. uh except for some more advanced things where I was like maybe a little uncertain how it might get implemented. So you know anyway some options there. So that's kind of shifting to again like less on my machine more in GitHub and that's not that nothing about that's revolutionary.

That's just mostly how people build software. like I've been kind of doing an ass backwards locally on my machine just because that's where agents are running. So as I move this way, what's really interesting is now I can mix between like um if you have watched a bunch of my videos last year, I was talking about how I was using co-pilot agents in the cloud so much um because it was just offloading a lot of work and it was cool. I could trigger them from wherever. But I can kind of mix and match that now. I can pick to run some things locally on my machine locally on my machine where I want to like supervise uh what the agent's doing. Maybe there's some more open-ended discussion and building. Um and then otherwise come on light. There we go. We chirping a little bit. Um yeah, otherwise like if it's well split up work, just like delegate it to agents in the cloud, like get that off my computer.

Um so this, you know, since Friday night, Saturday, and a bit this morning, just been really kind of doing that um that transformation and it's like it's unfortunate because across a bunch of repositories I have, it's still like a fragmented pattern. So I'm trying to unify that a little bit more. Um like some of the automerging constraints and stuff are done slightly different on some repositories versus others. And uh so that's like making it a bit of a weird experience. But you know uh it's just kind of using Friday, Saturday, and today to to align on that. And then it's probably going to take me all this week to really get I don't know to feel like that's the pattern I need to use. Um what else?

So anyway, what bringing that back to like the maestro package I have and the orchestration like I think to me the the difference there is really just that I'll have something that can watch GitHub or you could point it at some other you know source of issues and it will automatically assign and delegate things. But I also learned that you can basically do this in GitHub already. So, GitHub has uh GitHub agent workflows like I think the command line's gh space aw you can essentially do this like trigger agentic workflows as a first class thing in GitHub um and probably do something like this right like you assign you make an issue right and you assign a label and you can have a workflow that runs okay so maybe I could have an issue um so I open up a new issue and give it

a label that's like needs needs PMing or something and then have a workflow that takes a you know a silly oneliner and actually like builds out a real requirement and then that could change the label to something else and another workflow could run that's like needs to um you know needs to spec it out and then so now changes the label again it's been specked and then how do okay now that it's been specked out. We know the pieces we want to deliver against the functional requirement. Can we um you know do like task split and then once the tasks are split, GitHub also has the issue um dependencies and whatnot. So you could organize your work in a way that has all the dependencies and blocking and everything set up and then start assigning the workout. So again, this is not it doesn't have to exist.

Um, like I'm sorry, I'm kind of thinking about if I were to build this all in GitHub, could I do it? I think so. Um, but also like can I still play around with Maestro as a first class kind of offering? And I think the answer is still yes because I could do some or all of that in GitHub or some of all of that with Maestro. So maybe I could make it so that in GitHub um I don't know maybe it does everything up until the um you know the issues are all split out and then for me I would assign like a maestro ready label and then agents would pick up uh like maestro would be running somewhere and pick up the the work that's ready and then delegate it right so I think these pieces can interact um Maybe at some point I'll just give up on it and say like that was a fun experiment and just ditch it.

Maybe by the time I'm even close to having this working, Microsoft just has it as a first class offering or other companies do. I'm sure some already have it or people have built open source things I'm just not familiar with. So anyway, I think it's pretty cool. Um I was mentioning a little bit earlier that getting stuff running off of my machine. So, my my desktop, I was streaming a couple weeks ago. I was showing what it's like on my on my desktop, but um I can I only stream like one quarter of my monitor cuz it's like a I don't know like a 48 in monitor or something stupid. And so to get 1080, I only show one quarter of it. And if you were to look at the whole monitor, I have split out into sections. I have uh seven different like groups of co-pilot windows and each one has uh at least two tabs on them.

Um some up to like seven. So I run like a lot of different co-pilot sessions across things. Uh they're not all active all the time. Uh but sort of for me the it's kind of like the options there if I want to be building things. I would like to be in a position where I can just give it the minimum amount of input to get done what I want and have it go do it right. This is the goal. I'm not saying that it's there. I'm not saying that if it could do it right now that it's going to build what I want. I think it's going to be kind of kind of across the board if it were to just blindly, you know, take the minimum amount of what I say. Um, but that's the goal is to be able to give it as little as possible and still have it do what I want.

So, the challenge has been that like I I like just don't have enough resources on my computer to go run this stuff. Uh, so it's a mix between like when it comes to agents running like what agents do I really need to have running on my computer, right? Cuz sometimes it's like for research and discussion like I actually want that locally so I can engage in the conversation. Um, there's sometimes like agents are debugging build stuff and I'm like I I don't want that running on my machine because I don't want to be part of that conversation. Like go figure it out basically. Okay, you guys Someone's got to move over. One more. Come on. Oh boy. Um, and then what else? Uh, builds are the other thing. So, my goodness. Uh, of course, as agents are building things, like writing code out, they try compiling, they're running tests, and I've just noticed that like my machine is like grinding to a halt.

like I I cannot do that much in parallel. Um and like it's already like cognitive overload to try and like balance all the things that are going on. But what's what's interesting is that when you have to spend less time thinking about the specific details about how to implement it because you've already laid out the patterns you want things to follow generally. Um, it's kind of neat cuz you the cognitive load isn't it's not so much per thing because I don't have to sit there designing all the implementation details. I'm like I I know of patterns that will solve things like this. I've tried to document them. I've tried to in put the instructions in front of agents in a generic way to follow them. So, I can afford to do more um like across a wider surface area. But still like some cognitive load, but the amount of building um you know CPU usage and memory usage is just like kind of nuts at this point.

So, one of the things I've been doing to um try making up for that, I think I was talking about it in a recent video was saying I did like a a little a little local runner setup uh so I can run GitHub actions locally on one of my older machines. And so I have two of them set up now. And that way I can just delegate like builds and things. Are these people crossing? Come on. Oh boy. There we go. Um, and so yeah, now I can like uh offload that from the box that I'm working on to other other machines to do the building, right? And the reason I'm not just doing that in in GitHub is just cost. Um, which is fine. like if that's going to be the price to pay. Buddy, buddy, buddy. Brakes, brakes, brakes. This guy's rolling into the intersection looking the other way.

What is going on here? It's like a There's so many cars. It's like a Sunday at 400 p.m. Um, yeah. Basically, if that's going to be the price to pay where I need like more action time for GitHub actions, then it's fine. That's what it is. But I have these machines at home. So, if I can just run on them, then like why not? Because they're sitting idle doing nothing anyway. So, I put together this thing called Pit Crew, which is just an open- source thing for running uh local GitHub runners, and then a little dashboard for it. So, that's been kind of fun. Um, again, just having this opportunity where it's like something I want go kick off AI to go build it for me. So, I have that running and now now I I just have flexibility in some of my workflows, right? So, um I can tell agents, hey, like you should try to prioritize the local runner because it's free.

So, do that. Um, if not, you can fall back to GitHub actions. Okay, if I'm at my budget for GitHub actions, then like okay, queue up on the on the local runner. Sorry. For um for cloud agents, it's like if I have really bite-size work that I can just delegate out to to agents where like I don't really personally give a about having to review the code in depth. um I don't have to worry too much about dependencies because I've worked with an agent to kind of split up the work into small you know parallel deliverables things like I don't know like uh get you know make sortable column headers on this page great like just someone go do that I don't I'm not going to sit there and like review the code and whatever else I don't want to have to if I need to sit there reviewing code for like column sorting, then something's wrong in my opinion.

So, you know, carve that out, delegate it, uh, and so now I have this mix where like I can delegate that out to a, you know, to a GitHub cloud agent, it can go run it, and then when it's time to go build it, I'm not like consuming tons of action minutes because I can just have that run on a local runner. Um, and so I can kind of get this mix of like getting things offloaded from my machine, but I'm not tied into any one of these patterns. It's just flexibility, right? If I wanted to run it on my machine, I can, but now I have the option where I don't have to. So, um I think that's been sort of the biggest sort of shift over the last few days for me is just like trying to include this flexibility into uh all the things I'm building and then trying to make that more of a unified pattern, especially around that like automerging thing I was talking about.

Uh cuz what's happening now is I have a bunch of, you know, small bite-sized parallel things and I'm like, I don't want to sit there reviewing. You're in the middle of the intersection. Keep driving. You don't need to stop because you see me stop at the stop sign. Uh I don't want to sit there like manually merging all these little bite-sized things now. Like that's not that's not in my best interest of time. So So no. So if I can get that stuff automerged because it's passing CI/CD, then let's do that. So anyway, that's mostly it. Um, in another video I'll probably talk about some of the things that I'm building the state that they're at. But yeah, that's been kind of the shift in my workflow uh overall just to get me further further along and closer to this uh reality of like I want to say what I want built.

And I understand the more detail and more specific I am, the closer it will be to truly what I want. But um I don't want to have to think about like explaining the implementation details. I don't want to say like, oh, make sure you're using these patterns. Like, it should just do that because I've set it up in a way where it can um, you know, that it can merge things and I can feel confident in the fact that it built the thing the way that I want. It built it uh with behavior that I expect and it has tests and that nothing else broke because that's already tested, too. Um, it won't be perfect. There will be that breaks along the way. I acknowledge that, but that kind of stuff is also going to be revealing as to where it needs more attention. So, trying it out.

Um, one last thing is that I want to acknowledge that like trying to spread attention across a bunch of little projects and stuff is distracting, right? Because you're literally putting more time and attention to various things. One of the nice things about doing that is that it gives me an opportunity to see patterns emerge across a wider surface area. So if I only had like one project I was ever building on. So say it was brand ghost and that's the only thing that I was focused on, it doesn't give me enough of an opportunity to see like is this a pattern that's brand ghost specific? Is this a pattern that's C specific? Is it a pattern that's you know applicable to how I work? if I have more examples to play with, I can see like how these patterns emerge and uh where they overlap. So, um it's been helpful to have a handful of little things like this and especially when they're like I don't know like some MCP servers and stuff like that.

Like no one's paying for them, so it's I'm like if they're not perfect, it's it's okay. I'm not going to lose sleep over it. But um yeah, just uh enough variety to see patterns. Yeah. Thanks for watching. I will see you in the next video. Take care.