Copilot CLI is Replacing My Entire Workflow

Transcript is auto-generated and may contain errors.

Hey folks, figured we'd do a little AI chat. It's the weekend. I'm just driving back from CrossFit and I'll give you a little update on things I'm trying out, things I'm doing, and uh if it's working or not. Um so for personal development stuff, uh been still sticking with Copilot CLI. Um no particular reason other than that right now it is the thing that I have tried that is getting me glued to it. And I think I've mentioned in one of the previous videos and uh you know like the the sort of the fascinating thing for me right now is that uh for forever right I am a diehard like user interface kind of developer. I'm a net developer right so I really like being in Visual Studio like the classic one not the the fancy new blue one for VS Code. Um, I I'm just at home in Visual Studio because it's where I spend uh the overwhelming majority of my my time building software.

And so, uh, I like having a UI. Uh, I use Git with a UI, right? Like, uh, am I able to use a command line? Sure. But I I much prefer to have like a visual of the tree working through stuff. It's just how my brain works. And I'm not here to say it's for you or for not. It's just that's what works for me. And um yeah, like I've over the past year and I I don't even know like in 2025 I don't know when it uh was more like super regular for me. I just can't recall but you know VS Code, Visual Studio, Cursor, Claude, uh all these things like I have been using them and trying them and uh it's been good like GitHub uh co-pilot with agents uh that do like your poll requests in the cloud and stuff like was using that extremely heavily last year.

Uh, I've shared that's been that has been my go-to for a huge part of last year just because I could get so much done in parallel. Like my overall productivity was so much better because I could just go cue up work and then check on it whenever. Like it was truly gamechanging for me. And I found that like uh you know, not it's not that like Claude or anything else couldn't do that, but the just the interaction for me was so much better. Um I didn't like having to sit and have Claude, you know, chew away at things on my computer. Um just yeah, wasn't the pattern for me. And now that I fast forwarded to now, um, you know, you're hearing me say co-pilot CLI and I realize an overwhelming majority of people would say, "Well, that's, you know, that's Like, we hate Microsoft and like just just use Claude.

It's better." Um, I don't know. Like Claude Claude never got me to to to truly be glued to it. And uh, Copilot CLI is is doing that right now. And I'm not saying, please don't uh assume the intention of my words. I'm not saying that it's because Claude is worse or Cop-lot is better. It could very much just be a timing thing for me that uh coming back to a CLI tool as uh all the other integrations have improved. Um maybe that's just it's clicked for me now in a CLI and it's uh finally, you know, matching a productivity perspective that works for me. It's finally at the point now where like I'm not going into Visual Studio, which is such a bizarre thing for me to to even say or rationalize because that's just how I've spent my life programming. So, that's sort of the tool of choice right now.

I've been saying for a couple weeks now I got to get myself out of it to go try uh codecs and some other things. Uh, but it's like it's hard cuz it's got me glued in there and uh the pace of features coming out. And again, I'm not just saying this for Copilot CLI. This is going to be the case for for any of these tools. But the pace of features coming out means that like when I'm finally like, okay, like I should I should go switch, I should go try, there's something new. Um, so one of my sort of uh concerns lately, I don't know if concerns the right word, curiosity slash concern is around like how we manage things like skills and prompts and MCP servers and all this kind of stuff. And I say this because the mechanisms are pretty cool. Like a skill is super handy.

MCP servers are super handy. Uh having a custom agent that it's a prompt basically, but it has like some some structured guidelines is handy. Agents MD files are handy. Like all these things are helpful, all useful tools. Um there's some oddness around the fact that like you could use a skill that does the same things as an MCP server. You could use an MCP server just like a a prompt. Uh so some weird things there that uh I think we have to I don't know like more formalize the best practices and expectations for. But the the part that's really been getting me is like this this concept that they're repoentric and like it makes sense for some things like you might want a skill that's very much like I do things this way in this repository or you have a set of uh I don't know like agent definitions that are very specific to something you're doing in a repository.

um your agents MD file or whatever you're using might have very specific guidance for your repository, but like I don't know, I I suspect I'm not the only one who works in multiple repositories and completely different projects. And even when things are completely different, you have like guiding principles that are mostly the same. like uh regardless of what you know.NET project I'm working on, I like enforcing certain things or having uh design patterns done a certain way. That part's very consistent for me. If I was working in a different language, I still might say like, you know, I would prefer that you try to use composition over inheritance if it's an object-oriented programming language. Like these are just things that I would want across everything I'm working on.

And uh I think like I don't know based on the time you're watching this I mean by the time this is even filmed you might say there's already a hundred things that solve this just the rate things are moving but we're for me I'm finally starting to see like um some plugin or marketplace systems for for organizing this stuff like I think over the past few days uh with VS Code now they kind of have like a plug-in marketplace sort of system and Uh, I think that's moving in the right direction. It It's like we're still so early with this stuff that to me that's a good move. It just feels a little little clunky still. But I I actually don't I don't know how to solve this problem. It's a very bizarre thing. Uh so just to share with you kind of this this experience for me, we'll take a couple of projects that I that I have like uh going on at home, right?

So, I obviously have Brand Ghost, which is the uh the social media crossing and scheduling platform that I have. Oh, I should I had to make more videos on some updates there. There's some there's some things happening and it's super exciting finally. Um more on that another time. So, I have brand ghost that I work on. That is my primary, you know, thing that I work on outside of work. I have uh especially more recently and especially with some of the brand go stuff I'm actually doing a lot of updates to my blog. So that's a blazer based website. I have a lot of development going on locally for that. Um I have Neidler which is uh a dependency injection uh scanning library that I have. Brand ghost uses that as well. It's something that I kind of use as a standard across my projects. So, I have that that I build in.

Um, I was building out a handful of like little MCP tools and, you know, just little helper projects vibe coded to to help me out. So, a bunch of repos for that. And then I mentioned the other day that I was uh purely vibe coding the game framework that I was building up over like the past 20 years and just having it get recreated purely out of vibes on the side because why not? So I have I have these different repos and um what's happening is that while I'm working on something with co-pilot my my tendency now I'm trying to force myself into this habit of like if I did something and it worked well with co-pilot uh maybe maybe it was kind of painful to get there but I got to a result and I was like hell yeah like we got it. Um, if I stop and I go, is this something that I want to do ever again or plan to do ever again?

Because if the answer is at least maybe, then I'm asking myself, should I ask C-Pilot to make a skill out of it? And it's cool because as I'm doing this, it's not like literally everything, but I'm trying to like bring the conversation up with myself more regularly. Um, as this is happening, like future iterations are more streamlined, right? So uh to give you an example of one that I should be doing is I was trying to do this like this test migration for for a bunch of tests and brand ghost. There's some performance problems that I want to address. And so I had it doing some exploration around like hey like uh we have some concurrency problems that when I want to scale the tests running uh it's it's just not working well. So, I had it try to do like this analysis across the codebase, try a bunch of things out.

And the like the unfortunate part is like it didn't solve the problem. And I I really didn't think it was going to. I was, you know, part of me was hopeful, but I'm like there's it's just it's too complicated to to go do a sweeping thing like that. Um, and by the end, it's like, hey, I tried these things. These things didn't work. like I can't solve this problem this way, but you know, here's some interesting findings. Okay, so now I'm I'm I looked at those results and I'm like, okay, I know what to not do. I'm going to go do a different approach. So, it was doing too much at once before. I'm trying to write uh a plan with it to go do changes incrementally like very very uh incrementally for a very small refactor because that previous investigation actually highlighted to me that um I saw I thought something was being cached in tests and it's not.

So I said you know what let's let's go address this problem first because that changes like that broken assumption for me. Let's go change this first. So, now that that's happening and it's it's running right now while I'm driving, hopefully we get to a result with that. Now, I have two different overall scenarios that we're trying to refactor test for performance. And um what I'm not going to do is repeat the same first mistake. And the second thing I did, I think is a better approach, but I need to tune it to go actually do the next kind of fix. So, through some iteration, I might I'm hoping that I get to a point where I can make a skill. And I have to think about this more. I might need some more work at it, but I'd like to make a skill that's like the next time I want to go do a sweeping refactor like this.

It's not just, you know, do a search and replace and co-pilot's going to go try running like thousands of tests and hope it works. Like, no, that's chaos. And I I knew it was going to be chaos. So, so how do we structure that? like can I make a reusable skill so that when I go to ask co-pilot to do something like this, it structures its approach in an iterative fashion, uh, reports on things consistently, um, allows it to chew through a bunch of stuff to make progress and then call out the outliers. Like, can I make a skill that does something like this? And like, the answer is maybe not. I don't know, maybe that's a a shitty example for one, but I'm just trying to explain like that's where my head is going because I know I'm gonna have to do something like that in the future again.

So, that's been a big part of what I've been doing. So, uh now that I have a bunch of these repos that I'm actively working on and development feels crazy now because I have all of these co-pilot tabs open. I don't I'm trying not to look at my like token usage um because it's not okay. Um, but I have all these tabs open and I have like sometimes, you know, two or three co-pilot sessions for one of these projects. But there's at any point there's probably like I don't know like at least three to like eight co-pilot sessions going churning through stuff. And so right now my bra it's I don't know if this is probably a bad long-term thing for my brain but like just context switching right like checking in on this session. How are we doing? What do we got to do we have to go back to planning?

Do I have to like redirect it? Is it um like am I now um checking the results? Like what are we doing at this phase for this project? And then I go like you know ceue it up go to the next tab. Okay like where are we at with this one? uh and just keep cycling through them and uh yeah I don't know like the the progress feels really really really good. Um, is the is the like okay let's let's put it this is like the quality of the work that's being done is that the highest I actually I don't know right like that's a good question to ask for this vibecoded game framework thing um I I hit a typical scenario that I I generally do when I let things vibe code for too long over too many like sessions or iterations which is there's It's too much drift.

This is an example of a project where I am purposefully not reviewing the code. I'm just trying to get it to build and put um sort of like guardrails and harnesses in place. But what happens just to give you an example, I said I wanted to split some of the sort of like the test. It's not test like unit test but like um I don't know like think about it like a a very very lightweight game editor or like a a debug console so that you can see what's happening. Um it took a shortcut in the beginning and said well you know the the game framework allows us to have it's a client server kind of setup but you know one of the modes that we can do this is that we can have the server you know running locally right like if you wanted to do single player um you don't have to be online for it.

So it's like cool no problem I'll just I'll put the server in the same process as the as the client it's fine right the transport that you pick in between those things can be you know done in memory or through method calls instead of like going over a socket whatever you want to do um but I'm not looking at the code so it got to a point where I said hey this this uh this debug console tool is cool it's it's definitely helping me like run these scenarios and get like even in a console an idea of what's happening. But I said there's enough going on now that I need like a I also need like a visual and I'm not ready to like slap a a game engine integration on it. I'm just playing with some of the the framework mechanics. That's really all I care about.

But I need to start visualizing what's happening and the the terminal is kind of a a shitty solution for it. So I said, I want you to now split this terminal application up and uh we're going to also have a I don't know like a React front end. And it sat there for hours, because it was so convoluted for it to pull it apart in what should have been what should have been designed from the beginning. And it's my fault, but it was so coupled with the client and server together in the same process that it didn't put like the right layers of abstraction between them. So when it started pulling them apart, it was like I might as like literally might as well have told it, forget that any of that code exists. Write me a terminal UI to debug things and then write me a whole separate app and they should connect to a server.

And then the game framework was the only part that was kept uh separate for some of the game mechanics. But it was so convoluted that it just took forever to pull it apart. So vibe coding stuff like this is absolutely for me showing that like the architecture of the software is falling apart completely. I expect that to happen. So I when I talk about like side projects and stuff that I've done in the past um even like this role playing game is a perfect example of it. I have always my entire 20 plus years of like coding I have always used side projects in this case in particular this role playing game to try different things out. I take patterns and approaches almost to an extreme so that I can learn about them. This is going to be a situation where I'm going to let AI build the whole damn thing.

And that's going to be an extreme pattern. It's an extreme approach. I'm sure it's going to be painful along the way, but I want to force myself to go learn about how to put the right guard rails in place. How long does it take for things to get completely mangled before I'm like, "Oh, shit." Like, we have to pause and undo a week's worth of work here. Oh, that person's not very smart in the left turn lane with their right signal on. Like, you're you just you missed it. It's okay. like just so yeah, with this it's just it's going to be a learning process and it's on purpose, right? I'm not selling this. I'm not trying to it's not like there's customers lined up to pay for it because that wouldn't be the right time to go try this kind of stuff out, but it's on the side for me so that I can learn about it.

So, when I had it do this thing, it finally pulled these pieces apart. Okay, it took hours. It was ridiculous. And it's not that it took hours because I built the coolest, biggest game framework in the world. Like, no, not at all. It took hours because it was such in terms of how it was coupled. So, I finally got it and I ran it and it worked. So, like, kudos. That's really cool. But then there were a bunch of scenarios where it would just crash and it was seemingly on similar things. So it had serialization problems. Okay, just to give you an example, it had this serialization problem where it was crashing and um I was like, okay, like here's the stack trace. Go fix it. Right? I'm literally vibe coding this thing. Stack trace, go fix, go fix. And again, it spent literally hours trying to fix this one issue.

Insane. And it's just JSON serialization. It could literally could not figure it out for hours. Finally got it. Okay. So, I asked it and it's like, okay, well, you know, I it got really lost because these serialization things, blah, blah, blah. um what it told me I was kind of like it's I don't know like I think we're pretty good here like now that you've addressed it and then sure enough 2 minutes later I have another exact same issue serialization problem and I go okay we got to think about this and uh there was an iterative process there where what I ended up discovering was that how it was building these objects to get serialized Um, every time this was happening, it was so there's two major issues. The one was the serialization of objects and it's because these objects had like a bunch of different constructors on them and these are just like data transfer objects, right?

So they're they're only meant to like show the shape of data and carry the data and uh they had sometimes like three or four constructors. And what was happening was that that's like the exact wrong approach for for this situation because the serializer was trying to guess at what constructor to use and always breaking every single time. And so it spent literally hours on it the first time. The second time also took way too long. And so once I realized what it was doing, I said, "Well, go okay. Number one, go make a Roslin analyzer so that you can't do that. It is not allowed to compile in the code. Then go fix those issues and we'll see. And sure enough, issues cleared up. And then there was one more pattern just like that where it was like, oh, JSON serialization's uh freaking out because of uh something else.

Uh I can't remember what it was off the top of my head, but it was another thing where I'm like, look, Roslin analyzer in place. we don't do this pattern. This pattern that you're using is contributing to you writing code that ends up sucking. It's not because it's wrong. It's because when you're doing it in bulk in volume like this, it's just ending up with shitty patterns. So like, let me stop you from doing that in the first place. So just an example of like running into something, hitting some roadblocks, spinning its wheels, put the guard rails in place. Let's continue. Um there was something else with dependency injection too that was related to this. Uh oh it was it was getting confused like um what was it saying?

It can't resolve collections of things like it needs to use I innumerable and then it was I could see in the chat scrolling through as it's thinking it's spending so much time being confused about whether or not it can use an I innumerable or not. And like the funny thing is the way that it's set up. It can use an I innumerable to get a collection of uh of services. It can use an I read only list, I read only collection, an array. It can use all of them, but it's like it keeps thinking that it can't. So I put a ro I said stop. Put a Roslin analyzer in place. You will always use an I readon collection. It won't work if you do anything else. And add an instruction to say this is how we do it. Right? So going forward hopefully it's not wasting time noodling over this.

It's just like that it knows or should hopefully know what to do and then it's also enforced if it tries anything else. So um my goal with all of this is to see if I'm monitoring what it's doing. Can I over time build up the right guard rails? I don't know how I'm going to do this well architecturally. That's going to take time to learn. But that's sort of the the thing I'm playing with. I don't know how I got here from the the skills and stuff. I was going to focus on the skills, but um I'm trying just to wrap up this video because I'm in my driveway. The skill part I am trying to now go put those into uh like a shared repository for myself because now there is like a VS Code plug-in marketplace kind of interaction. So, I'm trying to refactor my my project specific skills into a common thing and then only keep the project specific ones in the repo and we'll see how that goes.

So, curious to hear from you folks if you watched all the way to the end like what are things you're trying out? Anything working really well? Anything that totally sucks? Uh, be curious to hear. Thanks. I'll see you in the next one.