Agent Swarms: Am I Just Building Dumber Code Faster?

Transcript is auto-generated and may contain errors.

Hey folks, we'll do a little AI update. I'm just doing another quick video on the drive into the office. Um, so I mentioned recently I've been using Clawude Flow a little bit. I need to make some videos on my main channel about this so people can kind of check it out and uh and navigate it. Uh, I am a Windows user as a .NET developer. Um, always use Windows though. Um, so it's it felt a little unusual to get set up with Windows, but I think that I have it all kind of working. But the last update I was giving on this stuff is that it it's I don't have a good way to say this, so don't mean to sound insulting when I say it, but uh, if you just get up and running with it, it's kind of like, you know, when you use agents and it feels like the agents are just like really dumb software developers.

it feels like you have a swarm of eight really dumb software developers trying to do stuff. So that's how it kind of started. Um, but I noticed that like when I've talked about agent mode for co-pilot with pull requests and stuff, I'm like that feels like it's it's doing a pretty good job. Not perfect, but certainly better than cursor and co-pilot in my IDE. Certainly better. So Claude Flow has been working like that. So it it's a it's an improvement, but sometimes it's just like, man, like what are you doing? But I started to realize, and this is like why I want to be using these tools more and more and more. It's like it truly is how you're using it that that can tweak things, right? Don't get me wrong, I'm still of the mindset that this stuff has to be so simple and so automatic that you don't have to think about it.

Like you could start using it in a dumb way and it will like kind of force you into the pit of success where you use it in a dumb way and it starts to recognize that you're using it in a dumb way and then you basically have no choice but to take some of these steps. So what are some of these steps? Well, everyone was saying that like you have to put so much effort into your prompts. Really be crystal clear upfront defining things. And all the examples that I could see with this stuff were like a oneliner like go build me a robust app. And I'm like, okay. Like I don't understand how people are seeing any success with this kind of because it's like it's so generic and open-ended that like there's no way. But I started to realize that these are just like bad examples to show you the syntax on the command line.

And um I saw the creator posting on LinkedIn and he had like a full prompt and I was like oh like yes he's using multi-line prompts on the on like in his terminal to be able to go create things and I'm like I feel like an idiot because you know I'm like go build me an app because that's what all the examples look like. So definitely a lot more detail in the prompts up front which that's not you know uh news to anyone I don't think. Um the other thing or two things I guess is like I was saying before that I'm trying to um I don't write documentation for my own projects because I live in the code and I don't want to have docs to maintain on top of that. But when AI can like look at patterns and stuff you're using, summarize that into documentation and to update it, it's just a matter of saying, "Hey, like go review the patterns again and update documentation." It does it, right?

Then you review it, you catch anything you don't like, but it's way less of a pain in the ass than you having to go like stop what you're doing and carve out time to go write all these docs. Um, so I was like, "Hey, if I start doing this more, I'm hoping that LLMs can read the documentation and pick up on this stuff." I haven't seen a ton of success with that yet. Not a ton, but um, like with Claude or with Co-Pilot, like a lot of these things have like a an instructions file, and that seems like, you know, if you can structure that properly, it seems like it's really helpful. So, I've been telling like even before Claude Flo, I was telling co-pilot like, "Hey, you know, you just did something. I want you to do it a different way.

And when you go fix that, I want you to update the documentation in a way that explains the proper behavior that's expected so that you don't mess it up in the future." Like that kind of thing, right? And like I said, not sure if I was really seeing success with that, but one of the super interesting things about using something like Clawed Flow and um I don't think it's like unique to Clawed Flow necessarily, like the concept, but like having a shared memory. Uh, that's kind of what I thought the documentation would act like, but I guess with a shared memory, however they're structuring the agents to go run and like the MCD servers or whatever for tooling, it seems like it knows to go rely more heavily on its memory. And because it's an agent swarm, that memory gets shared.

So to give you one example because it's really set up for working in Linux um or like in a Unix environment I guess like I use WSL so that I have a Linux subsystem kind of uh in my terminal and then I can run this stuff but what happens is because I'm a net developer and it wants to go build things it it basically never builds because it's like I can't find the tools can't find them so It goes and writes code and it's all because it never compiled it. There's no feedback loop that we have as software developers to go build some like to write code, build it and go, "Oh, that didn't work." Right? So, it's like it's obviously like shooting itself in the foot by not having this.

So one example is like when I caught it doing that again I was like hey I've told you this so many times I've told you you know you're running in WSL you have to like understand the pathing to go find wherenet is and you need to build things but what you can do is that and it does it sometimes automatically is you can tell it like you need to save a memory of this and it will summarize what it needs to and write a memory into its memory store so that the next time it goes to build stuff, it doesn't guess and go fumble through the exact same steps. And right now I feel like that's a huge advantage over co-pilot um with pull requests because I feel like every time the agent runs it's like relearning things and I'm like man like if it doesn't if I had to correct it on one pull request it's like I have to teach it again the next time.

So I'm assuming that's what the co-pilot instructions are supposed to be for but they don't seem to like be helpful that way. I don't know why. um some things yes but not other things. So, I'm trying to personally I'm still trying to find this right balance between like the instructions file uh documentation in the repo. Um how how much you truly have to add to a prompt. Like I feel like every prompt I shouldn't have to tell this thing like you're using.NET, you're in WSL, you need to build after everything. Like it should just know that after enough conversations I should not have to tell it. It feels stupid to have to do that. Like I feel chat GBT does a really good job of that. like I can tell it a couple things and then I I just feel like I never have to remind it.

And in all of these other tools, I feel like I'm constantly like, man, I've already told you this. If I forget to bring it up again, it's like it never happened. But the memory store seems to be helping a lot with that. So, um even this morning I was writing tests, uh trying to get more coverage. So, I'm going through the code coverage um kind of looking at personally which tests I want to make sure I have better coverage on. But some of the scenarios I'm like, "Oh, that's going to be a weird one for setting up doing a lot more like integration and functional tests. Um, and some parts of the system are a little weird." like it's for brand go. So I need to make sure that if I'm triggering something I'm like well if that's going to go try to write to social media like I don't want to do that.

So how do I make sure that I can you know get enough part of the flow that I feel comfortable with and how does that get asserted? So some of this stuff is super obvious and other parts not for like a functional test. So I'm like okay like I want to come back to those complex ones later. I'm going through the codebase looking at code coverage and kind of feeding the agent swarm like hey go write tests on this one because this needs coverage and like we I from my analysis we have the right patterns to go do that. Um but it like it would write the tests and then I would go back to Visual Studio and like go to verify them. Uh cuz I'm not this is an obvious one but I'm not having it run the tests. Well, it it started to and that's good.

But my test suite, if it tries to run all of them in the solution, it might it might have some problems. It's why I'm going through this refactor that I'm doing right now is to to kind of move away from this problem. Um, but it wasn't even building them. That's kind of the meta point here is like it was not building them. So, I would go back to Visual Studio and go to run the test and it's just like, you know, like 25 to 50 compilation errors. I'm like, "What the hell, man?" Like, "What do you mean you're done writing tests if this stuff doesn't even build?" And then it would tell me like, "Oh, you're right. Like, I saw like even when it did try to build, it's like, I saw build errors, but they weren't related to things I touched." And I'm like, "Obviously, they were.

You're just like you're misinterpreting that." So you can store a memory that's like you know address all compilation errors even if they seem unrelated and like be honest like it wrote down one of its memories is like to be honest about um compilation errors so that um it's not misleading and saying like I'm all done even though there's errors. So, it's cool because this mechanism with this memory storage seems to be the the thing that I've been trying to to make happen. Um, but I'm still like trying to assess the effectiveness overall of um of these different things. So, before I pull into the parking lot, just a quick note on like like really what I was doing cuz I mentioned I was using Clawude Flow. I was trying to get it to build um like a little sample application just completely like it's not even vibe coded.

It's just like autonomously built and it made something. I don't think it actually works yet, but I'm like I need to start integrating this into my my development process. And so I'm doing this really big refactor on uh dependency injection and how I have my test set up. And the first thing that I started using it for was like once I had a pattern that I was changing, I'm like, "Okay, there's like, you know, 300 spots in the codebase to go touch." And it's not a search and replace. So like I'm going to tell you what needs to be touched, like how to touch it, I guess, and you got to go do it. So, um, had to do a sweeping refactor like that that worked pretty well. Um, couple missed spots, couple compilation errors, right? But I didn't even have that stuff with the the memory for how to build.

So, like overall pretty good. Um, and then I had it doing um this morning I got to the point where it's like I'm refactoring all this stuff to test effectively and I'm like, "Ah, but I'm nervous now. I'm nervous. I touch too much." So, I'm I'm having it go through and the spots where I didn't have code coverage because of um lack of testability. I was fighting dependency injection a lot with my functional tests and like things like mass transit, quartz. Uh so mass transit's like a messaging framework and quartz is a job scheduling framework. These two things I could not have work in sort of like a test environment which is causing me a lot of headache and um now they will work. So now I can go write tests and so I was having it going through and adding a bunch of test coverage.

Um and that's working really really well. Um very happy with that. Um even though it messes up like I'll say go do like uh you know add test for these five classes. Um, it's getting better because it's actually compiling, but there's still a couple of times where I'm like, it's not perfect. Like, one example is, and I got to really put a nail in the coffin for this one, where it adds a test for something and it like talks about the behavior it's trying to do, but then it's like, and the real thing would test this, and I'm like, dude, you are the real thing, so you better figure out how to test it. You can't just say the real thing would and then not do it. Um, so I need to like find a good memory to store for that.

But honestly, it's been so effective that even uh this morning it wrote tests over something and one of the tests was failing and I'm like, "Oh man, like I got to go back to this agent to like tell it what the heck's wrong and like I was getting about to get frustrated because I'm like I already told it to fix this one." But I went and checked the code. I'm like, "Wait a second. It made the change that I told it and it's still not working." And I said, "Oh there's actually a bug." Like the test is is actually right. There is a bug. And I went and looked and how I was doing something in the messaging um sort of infrastructure that gets reused in like 20 different spots. I was like, how I'm passing error information, which I thank God is not the common path.

It's the edge case. But how I'm passing error information around, I'm like, that's actually broken. if I try to call it and pass an error for something that happened, it will throw a different error now and kind of completely hide the other one. So, I was like, "Oh there's actually a problem here." Um, I fixed it. Um, I had it go again. I used it to go refactor all the spots so I don't have to go do that. And then, um, yeah, like basically added test coverage and help me identify a problem area. So, all of this to say making progress with this stuff. still a lot to learn and uh this is a good example of how it's like complementing my flow where um it's not like I can still use my IDE while it's doing stuff but in this case when it's getting that aggressive with changes um like I can't have breaking code changes at the same time or else it's going to try to build and get thrown off.

So, it's not a perfect solution um you know for for me to be working on it at the same time, but it's been it's truly been helpful. Um and I'm just happy that I'm getting through this refactor and actually closing some gaps in test coverage. So, yeah, fun stuff. I will keep folks updated. Like I said, I will do some tutorials on my main channel, so you can check that out and see how to use it. And a friendly reminder, if you have questions you want answered, leave them below in the comments. anything career development, software engineering, AI questions. You guys know I'm not an AI expert, but I am navigating this stuff. And if you want to be kept anonymous, go to codeccommute.com, submit your question anonymously, or send a message to devleader on any social media channel that you want. Thanks so much. I will see you next time.