Building For Reusability - How I Am Trying To Scale My Development

Transcript is auto-generated and may contain errors.

Hey folks, we're going to just talk about some software development stuff primarily around uh AI guard rails and just kind of my current thoughts on uh some observations for some stuff I think I kind of like want to catch up on for my own development I guess. And so more recently, I've been talking about like building skills for for co-pilot and Claude and then um some some challenges and opportunities with like sharing these things. So the fact that we have like aentic marketplaces and stuff for for plugins like I think that's all in the right direction. So, I've been giving more and more thought to like, okay, um, across the different repositories that I have for my own personal projects, here's skills that I'm building. Here's like maybe ones I want to share, maybe ones that are more specific to repositories, things like that. And then on top of that, started talking about these um like uh instruction files that are basically doing pattern matching on on the file paths that you're working on.

So, this is something that is very new for for me in terms of like how to how to get the most out of that. And so, it's still pretty early for me in like genuinely understanding how effective it is. Cuz like conceptually, I'm like, "Oh, yeah. this this would solve a lot of problems for me, but I'm not yet sure um if some of the stuff I'm doing is having a huge positive net effect that way. Like I think it should. Still kind of early for me to figure that out. So, just to briefly catch up if you're not sure what I'm talking about with all these different agentic harnesses, we have things like, you know, claude.md. We have the co uh co-pilot-instructions.mmd. I can't remember what the cursor one is, but like all of these different tools have their own uh instruction files. And then there's sort of this more generalized standard forming around like an agents.mmd file.

And so these are the sort of the global instructions that get loaded in for your for your LLM when it's doing work. And then beyond that, you know, there's like this hierarchical concept where you can have like user level settings like that. Then you can have them for like particular agents. You can have them for particular directories. So these things can layer on top of each other. But like, does every tool currently do this the exact same? I think the answer is no. Um, will they probably continue to move in a direction where it's similar? I think the answer is yes. But beyond that, there's also this idea that instead of just having to have a agents MD file in a given folder, uh, you know, to to be leveraged hierarchically, uh, not only can you do that, you can have instruction files that basically have a header and then like a like a glob, right?

So, it's like this regular expression concept where you can match on the file path. And so the cool thing about that is that you can have more targeted instructions and these automatically get picked up by the harness if you have a harness that supports it like Copilot CLI and Claude and I'm sure there's others. Um then you get more targeted instruction files for when you're working on particular areas. So, as I've been building that out across repositories, as one might expect, it's like I am repeating myself a lot. And I don't yet know if there is a great way to share those types of things. Like you could argue, sure, like I should just put them at the user level. And there are actually probably a lot of these that would make uh make sense at that spot for me. But um that would also mean that if I have some teammates that are working on these repositories with me, they don't get that.

If they're at my user level, then if I push stuff to to co-pilot to be done in GitHub in the cloud, it doesn't have them. So, it's like it's a it's a mechanism, but it doesn't feel like it's necessarily the right one for like a long-term kind of perspective. So, I'm I'm like playing around with this and trying to figure out like what I should be doing and what's going to be more optimal for me. And that got me thinking that like I've never really done this and maybe I should start to invest into it. Um what I to start with what I have done historically is like I will make libraries for myself. So I have one that's a little bit older now. It's not super well maintained like arguably like I have my own result type that I work with. Um oh my god this guy is not going the speed limit.

Buddy, buddy, what are you doing? Holy This is crazy. I can understand if you want to like get off the highway here, but we're going like 20 m an hour below the speed limit. Um, so I have one that's like got a result pattern some other things and like because I haven't maintained it super well and it gets used a lot in my projects like I I probably have some some like painful catch up to do there. I have Neidler which I more recently uh started putting together to invest into like how I do dependency injection and type scanning. But what I don't have are like like project templates. And I probably should do this for myself.

have a repository with some some templates uh so I can start like a you know new new solution in like C or something that pulls together a bunch of uh I don't know like common things that I always use like um depending on when you're watching this like it might not it might seem like it's uh ancient news to you but like moving from the old school SLN files for solutions to SLNX to doing uh central package management to enforcing some like analyzer settings and stuff like that. Like I should just have this and one of the kind of tricky things with that is that like say I make that it doesn't automatically, you know, sync to all of my projects that are that I currently have. And that's fine. But I think what I should be doing is um over time as I'm like, "Oh crap, like that's definitely a pattern I'm using everywhere, trying to make sure that I have it in sort of like my my template repository, right?

And then not only could I do solutions that way, uh I could probably make like literally Visual Studio project templates for myself. Um, and I wonder if there's like, you know, these these instruction files that I'm talking about, if there are patterns that I always do that I should just make consistent, right? So, I'll give you just a couple of examples like uh one is because I use Neler, which is my dependency uh scanning and automatic dependency injection registration framework. uh because I use that like for everything because that's just genuinely what I end up building by hand anyway. Um I should have uh you know glob instruction files for matching on plug-in files, right? Because one of the things that happens is that the LLM goes, "Oh, like you're doing a plug-in based architecture. Um, let me go make a new plug-in file." And then it is there's enough Neler documentation that like if it read it, it would do the right things.

but it is so familiar with the built-in patterns innet that it like makes a plug-in file and then ignores all of the benefits that needler would give it. So it makes the plug-in file and then it automat or the LLM manually registers all of the dependencies and it's like you you literally don't want to do that. That's the whole point with needler is that you don't have to. So, uh, if it read the documentation, it would do it. But what I could do instead is like have, um, you know, a pattern match on a star plugin.cs file. And then anytime it's going to write a plug-in file, it's like, wait a second, like here's what needler does. Here's where I should be manually registering things. Um, and this is going to be consistent across everything I build anyway. So, my thought is like maybe I should be putting something like that into this shared repository.

Um, again, it makes it kind of weird because there's not like a a good syncing pattern for these things, but maybe that's solved with a skill. So, Maybe I have a skill in the repository. Um maybe I split out my, you know, instruction files into their own dedicated repository and I use a skill to to periodically sync them, right? So I can just keep putting my my common instructions that I want to use across everything. I can have a dedicated repo for them. Um, I already do have like a sort of a private marketplace for my agentic skills. So maybe I have a skill that's like sync sync common instructions or something, right? Come up with a better name, I don't know. And uh then I can have that skill pull from that repository and if nothing's changed then whatever. uh and if things have changed then at least it will go update those files.

Um so it makes it a little weird because it's like you know spread across repositories but maybe maybe that's a good solution. That approach would still let me have my own repository specific instructions. It would let me uh you know maybe in a bit of a clunky way kind of sync down uh shared ones that I want for everything. But my my sort of meta point here is like I am I am solving similar problems across code bases I own. And it's cool because we have you know these types of guard rails and uh sort of prompts and instructions and and guidelines and whatever however you want to frame it for these agentic harnesses. So it's all like moving in the right direction and now I'm like cool. I want to I feel like I need to kind of refactor my my approach and uh find ways to to stop duplicating and rediscovering if that makes sense.

I think there's a lot of benefit to especially in the beginning when you're exploring like um it's almost like if you're thinking about code I don't want to prematurely optimize by by trying to pull everything into a common spot and then I'm like oh wait but that's not actually how I want to do things across all my repositories like I kind of did that prematurely right it's we see the same thing in code I think I think there is some benefit into repeating yourself in the beginning because you're you're sort of discovering the patterns that do work. You will see the variations. You will have time to kind of figure out a better idea around what's working, what's not. And I feel like only until you've seen things a few times in maybe some different contexts that you can make better decisions, right? Like I would love to get it right the first time and do it perfectly, but I have never seen that ever happen in software development.

It's always like you wait a little bit and you're like, "Oh shit." Like that that pattern, that approach doesn't apply here. And I kind of assumed or worked worked in that it's always going to. So I I think I'm starting to get to a point where there's probably some some common ones I can pull in. So plug-in files are one example. Um I use Mass Transit and Quartz for for jobs. uh so mass transit for uh sort of doing like communication across logical boundaries even if it's all in in memory but I have like consumers right that's like a concept from mass transit okay so if I want to build consumers in a common way like let me do a dedicated instruction file for that all of my quartz jobs end in like a suffix job I don't use job for anything So make an instruction file for a job.

Um this kind of thing and then automatically the LLM will be uh writing things in a way that follow my patterns. I've talked before about using Roslin for analyzers, right? So I can uh at compile time enforce that like if you're not following my pattern won't compile. And that works pretty well. The pro uh the problem with only doing that is that the LLM seems to want to write the way that it thinks it should write. So it writes a ton of code and then it's like oh time to build goes to build and it's like oh like all of these analyzers fail. Okay. And then it like using some of the guidelines from uh the analyzer descriptions using then it's like oh I should go look at what else is using this in the repository. Um even though all of my instructions are like don't make up new patterns.

Uh so it's it's like it catches it which is great but it would be good if at writing time it's already doing the right things and the analyzers are just there as a stop gap. So kind of catching it not only at the end but up front before it wastes time later. So I'm I'm hoping that by doing some of this the the observed effect is that less time wasted correcting itself. So just to give you an example, if it took 10 minutes to write the code, it's taking 10 minutes to go like fix itself. So 20 minutes to go do a task. Whereas if I could get it to do mostly the right thing up front, maybe it takes 10 minutes to write the code and a minute or two to fix it up, right? And that will be much more effective. The other thing is I don't have analyzers on everything.

There's some stuff where I'm like I don't care enough to go break like compilation, especially because I myself haven't abided by all of those patterns throughout the entire repository that I'm working on. But I also don't want to perpetuate the problem. So it would be cool just to have a bunch of those things where it's like it's not continuing to introduce some like variance and patterns and a bit of slop. It would mostly stick to uh guidelines I have. I have felt that just using an agents MD file is not sufficient for that. So, if I put all of my guidance that I'm trying to do in an agents MD file, it's kind of like at some point it's just falling off, right? And probably depends on the model, its context window and that kind of stuff and maybe the harness too. But I'm hoping that by doing the more targeted instruction files, uh, it can do a better job, right?

I can have in my agents MD file more I don't know like general operational things like for example don't be agreeable with everything make sure that you're doing pros and cons analysis like really like defining how I want my harness to work as a a developer companion and then trying to push all of these like programmatic rules and syntax and guidelines into these uh these globased things. So that's kind of my thought process. I once I have more of that kind of formalized, there'll be more videos that follow on my main dev leader YouTube channel. But that's kind of some stuff I'm thinking about. So curious what you guys are doing. By the time you watch this, maybe every pattern with agents and harnesses is uh already completely different, but we'll see. So thanks for watching. I will see you in the next video. Take care.