What Does AI Integration Look Like In Your Development Workflow?

Transcript is auto-generated and may contain errors.

Hey folks, we're going to the Experience Dev subreddit. It's going to be an AI topic, which I try to do periodically, but this person was asking about it in their Reddit post, trying to get perspective from other engineers about in their development workflow, like what what does it look like to integrate AI into that? And so I figured I'd talk a little bit about that from from my perspective. Uh this is outside of work. So, as an engineering manager in my role, I'm not actively committing to the code base. Um, cool thing is just a bit of a tangent is that um especially now if I needed to like one of the limiting factors is like by not spending time in the code, if I needed to go make a code change, it's going to take me a lot longer than anyone else who's familiar with the domain of the codebase to like to go find the right spot, blah blah blah.

um put in a proper change. Uh now with AI at least and my years of software engineering experience if I needed to especially in a pinch um I feel a lot more confident that I could uh talk to co-pilot about you know figuring out like I know the repository or repositories uh I know enough of the um domain terms without maybe specific class names or method names and that I could work with co-pilot to go find you know spots in the code and and work through a design. So, uh that's pretty cool. Um it's just that from my the perspective of my role, uh my time's occupied doing other things. So, for me, uh as a developer outside of work, I build uh brand ghost, which is a uh social media crossing scheduling platform, and we build uh blog automation for uh helping companies with their SEO.

That's a platform I build. And then I build a couple of uh like open- source libraries that I use across my projects. And so I can talk through what that looks like. And I'm going to try to touch on um sort of like spinning up a project. I'm going to talk about uh large feature changes and then small like uh small features and bug fixes and then sort of like my my little meta loop on top of that and try to get through all of that on my drive home here. Um so to kick things off uh set of tools I use uh primarily copilot CLI now um I'm a net developer and so spent years in Visual Studio uh start of this year probably the last 5 months or so just really shifted completely out of Visual Studio into uh in in PowerShell uh with Copilot CLI and this is someone as a you know very longtime visual Visual Studio user.

I I find myself rarely touching Visual Studio now. Um I still like Visual Studio for navigating code. So if I want to like even to review code, I would rather look through Git extensions to see the deltas and then jump into Visual Studio to like get a better feel for things. Um but in terms of like writing code uh you know mostly just uh AIdriven now but copilot uh visual studio uh for git I like I was just saying I use git extensions. I like having a visual for for looking through my git. Um my projects outside of work are all in GitHub. So um GitHub GitHub actions for CI/CD and then uh host things in both Azure and Railway. So just to give you an idea of uh some of the the stack um and then ASP.NET Core I have some stuff in WPF and uh Avalonia for the UI framework.

Some Blazer stuff. Yeah, primarily ASP.NET Core at this point. It's like most of my my development stack. So that's a bit of background. Um, okay. So let's start with some of the small things, right? So if I wanted to do like a a feature, I should have mentioned I want to talk about debugging too. Um, if I want to do like a feature, a bug fix, this is the situation where I actively, you know, I I have a code base. It's established. You know, things are running. there's tests like it's not from scratch. So have a product or service and I'm going okay cool I need to either fix a bug and I know like what I want to do or I need to I want to build a feature right to to add new functionality or change functionality.

Um, my flow is generally that I I hop into co-pilot CLI unless I'm doing something that's like very similar to what I was just doing in my my session, I will generally just start a new one, right? Sometimes if I'm like delivering features back to back and they're like they're related things, I actually like having some of the prior context from the session because it's like I as a as a human know that, you know, the work I'm going to be doing next is very related. There's a lot of like relevant context that's just worth having. And so sometimes I'll just continue on the session, but more often than not, you know, slash new in the terminal. And uh I almost always operate on uh like yolo. So uh I because a lot of the time I'm babysitting my PowerShell sessions. Um not like yes, they're running autonomously.

Yes, I'm flipping between PowerShell tabs, but I I'm not I don't have like uh production databases exposed or anything like that. Um I think the the scariest thing right now is that uh it could push to my remote repository. And the reality is that like if it even if it tried to force push um I wouldn't lose anything. And uh even if that triggered a deployment, the the build job takes long enough for the things that I'm doing that like I would have time to to stop it. I'm not concerned. Uh now I'm not recommending that everyone does that. Uh I think that if I sat down and went through more fine grain permissions that would be better. I just haven't. So, in in a session, I would basically uh I like doing a couple things. One is that I like describing to co-pilot like what I'm trying to do.

And then the other thing is I like asking it like if I know that there's a spot in the code that I want to be integrating with. I like asking it to go like uh to find certain things, right? Like hey cuz I build a lot of plug-in based architectures. Can you find the plugin or the feature project for you know for this and like tell me about like what you see there like something sort of like that. And the idea here is that I like getting it to I like making sure that I can see the areas that I want to go focus on because if it identifies something else and it's like, "Oh, here's here's the thing you're talking about and it's not what I'm talking or what I want it to talk about, then I can steer it from the beginning." Um, and then like making sure that it understands what I'm asking for uh high level, right?

like can you basically can you repeat back to me in your own words like what you think I'm asking about and that just gives me a bit of a litmus test to see like what kind of uh language and framing I need to use uh for the the next part of the conversation. So that's pretty brief by the way. We're talking about like a couple of minutes to like do that exchange and then from there uh I jump into planning mode uh for for most things. Sometimes if the feature or the bug fix is so what's a good way to put it like so simple like if it if it feels so straightforward to me that um that I think that it can do it then often I will just do that otherwise it's into planning mode. Um the there's a trade-off. Obviously, if I don't go into planning mode, I I'm consciously saying like if this thing builds the wrong thing, I can't be mad at it.

That's kind of the the story that I have to tell myself because I have this opportunity to literally go into planning mode and make sure that it lays out a plan step by step that I'm okay with. Sometimes the features and bug fixes are so simple that I'm like it's it feels like more overhead for me to go plan it. I would much rather just like tell it to go do it and I will come back and check it out after and if it's wrong, whatever. I'll just scrap it and then correct it and just do it again. Um the reason for that is like it's a It's probably not like a good strategy long term. I think I think this is still probably some learning like uh admittedly on my part, but it feels like going through the planning for something that's so simple is actually just not a good use of my time and it feels like it's actually less of my time.

Even if I have to correct it later to be like that was wrong, do it again. focus on this is less of my time. Now, that's that's probably not true if you were to measure it when it fails. Um, but I don't know. This is probably something to to reflect on over time. Maybe the models continue to get good enough that, you know, they can the statistically they're oneshotting features and bug fixes the way I want uh a lot more regularly and then it all kind of works out. But bit of a balance there. In planning mode, um I like making sure that it's highlighting uh depending on the complexity of the feature, the bug fix, uh different options. So, it's part of my like my user level prompt and like my my agents MD file or I guess at that level it's uh the co-pilot instructions that uh it needs to act like an engineer.

needs to propose multiple options, do pros and cons analysis. So when I go into planning, I'm expecting multiple options. Uh and then I try to make sure that as part of it, it's talking about um tests. And so depending on the scenario, um, if it's like if I'm building a new feature, I often don't try to force it down a TDD path, but I do make sure that it's like highlighting what scenarios it plans to test. And um, if it's doing a bug fix, um, I very heavily push on TDD. So, for example, you're about to go fix this thing. Number one is make sure that we have tests in place that assert the current behavior. Like you're not touching any code until we have tests that assert the current behavior. And I don't care if it's wrong. If the behavior is wrong, you need to assert the current behavior.

Cool. Like, so now we have we're making sure that there's test coverage. And then the followup is like um depending on what the fix is like now make sure there's a test that checks for the new behavior that we want and it should be failing right it should be failing cuz we haven't put the fix in and then after um you know commit the fix and then make sure the test is passing and there's varying degrees of this like I don't have the prompt down perfectly um but conceptually it's kind of like I need it to be honest with me that if it's making uh the change and like so it's doing TDDV and then it fixes the code and the test should pass. Sometimes the reality is like when it has to go implement the fix it ends up breaking the API that it would have wanted to use and then as a result like it has to actually touch the test again.

But I I need to make sure that it's being honest with me and provides evidence because if it has to touch the test again because the API changed or whatever and like I can tell that uh you know conceptually it's fine. It's not like it's not like it's fixing the test um to you know to assert a different behavior then I'm okay with it. But there's some back and forth on like you need to prove this to me that you know you didn't break other things. That's why we had the initial test go in. Um and that you know you you truly do have a test that covers this behavior. Um sometimes it cheats depending on how I end up going through things. Um and what I'll do is I'll ask it. Um cuz I don't want the agent to confidently tell me there's test coverage on something without proof.

Um, and what I mean by that is the behavior because sometimes it will say like, "Hey, I wrote the test, right? The test name says whatever or there's part of the setup that says it's doing whatever." And so I'll say, "Cool. I want you to go revert the fix." Right? Revert the fix and show me that that test still doesn't pass. Right? The idea being that this test that you're that you're creating, this new one or this updated one, buddy, it's a green light. Come on. What are you doing? uh this new one better be like asserting that behavior change that I'm looking for. So really all of this just to say that there's um I don't know some rigor around making sure that there's good test coverage for bug fixes. But this is all in the plan, right? And so then we agree to the plan and then I'll I'll fire it off.

Uh I'm trying to use work trees more. This is something that literally before this year, probably as of a couple of months ago, I was not using git work trees ever. I had never in my life used a git work tree up until a couple of months ago. Um, and so I use that a lot more now. This was something when there was more and more terminal development going on, I was kind of sitting there going like, "This seems crazy to me." Because if I compare it to some of the repositories at work, I'm like, some of these are enormous. What do you mean you have multiple agents running on your computer, like they'd all be sitting in this repository like nothing would work? They'd constantly be, you know, conflicting with each other and then duh, like I didn't know about git work trees. Um, if you don't know about git work trees, look into them.

uh basically allows you to have uh what's a good way to say this like different branches uh beside each other in folders that you can work on and that uh you can basically still like from the perspective of git you can still see across the folders like if you wanted to see a commit in one of your other work trees you could see it which is cool um it's not like the entire history is completely separate from each other. So that means I could be in a work tree and if I was like, "Oh crap, I actually want to cherrypick that that commit over and like get it on the main line even though it was just part of a feature branch." Like I can do that pretty easily. So I like having um a couple of agents at least in across some work trees so they can do things in parallel.

Um, primarily because mo like for a lot of the stuff I've been doing the I felt pretty comfortable that my local builds and basically like test loop is pretty solid. Um, I've been mostly just like running stuff locally and if it's good then I'll I'll push it up to main. It still goes through CI/CD before it deploys like so all the tests and then deployment run and that's been pretty good but more and more I've been noticing that like I keep getting burned by I feel really good locally and then go to run it and CI/CD in the in like GitHub actions and something breaks and I'm like man like like why am I dealing with this? So, I'm starting to shift a little bit more to just having like pull requests, which feels like a little bit heavy. So, I'm kind of in between right now.

Um, I don't know what changed recently, but when I started using Opus 4.8, 8. I feel like this might sound weird cuz I don't I don't know why the model itself would be doing that necessarily, but I started to notice that Opus was actually like the model maybe it was it's in co-pilot, maybe they changed their system prompt or something, but uh I started to notice that it was suggesting like I'll go open up a pull request for this and it it didn't used to do that as of a couple of weeks ago. So something seems like it changed. But anyway, kind of got me thinking maybe I should be using pull requests more. Uh that way not running on my machine, it's running like the actual pipeline. So, uh doing that for a better feedback loop. But basically go through that kind of planning session, let it run, and then uh pull request goes up.

The that flow has been working pretty well. Of course, if something's not right, like it builds something and it diverges from the plan or like whatever we spec out just actually uh isn't going to work. That's it's more and more rare, which is great, but that unfortunately happens. We have to go back to the drawing board. Um I took way longer on that than I was hoping um cuz that was just for simple features and bug fixes. If it's architectural changes, it's a similar loop, but there's a couple things that happen that are different. Uh, one is the conversation up front in planning is a lot lengthier. Uh, like from, you know, two up to two to 10 times as long. And so that's a really big thing.

I I definitely force it to use code examples back and forth in uh in sort of that upfront planning because I'm like I don't just want to compare conceptually different architectures like show me code examples right this is the kind of thing that historically I'm I'm just imagining conversations even I don't know like a few years ago 10 years ago where there's like architectural vision for where a product or service should go. Part of the code base and people are debating them. And it's like the the challenge is that and until you have some code, we're kind of speculating what that's going to look and feel like. And for some people that maybe have more experience or can visualize what that system would look like, you have a bit of an advantage because you can you can sort of like visualize and uh imagine navigating the codebase when it's set up like that.

Um, and for people that aren't able to do that as effectively, you're definitely at a disadvantage because you're you kind of just have to go based on vibes and hope that what's being said actually pans out in practice. And so I think it's really cool now that even in a conversation with an LLM, I can basically be like literally just, you know, um, give me code examples converting parts of my codebase into this like on the fly, right? We can we have options A B CDE E and like let's talk about option A. Show me what that code would look like, right? Because I do a lot of plug-in based things like show me with a couple of examples. Oh, you're going to do the left turn from back there. Okay. Silly, silly, silly person. Um, that that's such a crazy cool advantage that we have now.

And it's cheap, right? For me, the value of just having examples of code like that from an architecture perspective is wild because what that without that imagine that I had to tell it go run build this whole thing out and like cool now I have something that's working but there were like four other architectural variants that I'm like hm maybe we should explore that too. Do I have to go tell it to go build all of those out? Like that would suck. It's just so nice to be able to have it up front, show me the the different flavors. So, I lean into that a lot uh for architectural changes. Um I think the other thing that I'll mention too is especially for really big architecture changes, not that not that you can't or shouldn't do this for feature delivery. I think it's actually a good idea for feature delivery.

Oops. There we go. My tire went over part of the driveway. Um, I think that for big architectural changes, the agent always seems like very motivated to go write a lot of code. And so I will try to make sure that we can break it up into stages that I can land. Now, there's pros and cons to everything. If I break up the architectural delivery into smaller chunks, if I change my mind later and I'm shipping the chunks and say, I'm just making this up. Say there's five chunks to deliver in total for a really big architectural change. I land one of them, I land uh the second one, so there's three more to go. I start building other features that might be touching some of this. Then I land, you know, the third and then I keep mixing and other things. If I get to the end and I'm like, man, this actually maybe wasn't the right way to go.

Now I have to unwind more pieces, which is a bit of a pain in the butt. But I think the the benefit is that as I'm incrementally landing things, ideally that gives me a better sense of like, is this the right direction? I can catch issues earlier. So I like doing that with my architectural planning. I'm not going to get to I'm sitting in my driveway at home now, so not going to get to talk about debugging, but um just to briefly mention it. Really liking using um uh MCP tools for Graphfana and Loki in particular for looking at logs. It's super super helpful to just like sit in a chat and talk to an agent about like look for logs talking about this thing or like these patterns and then having that surface them versus me trying to sit in the UI crafting queries for my lo like no I don't want to do that.

So um that's made debugging and investigations like very very interesting. Um, it just seems way more effective to be able to have that kind of conversation where something else can go figure out the query syntax and the right parameters and stuff and I can think more about like what the heck we're trying to do. So, hope that helps some of how I've been approaching development with agents, but let me know your approach. Share it in the comments. Okay, see you next time.