Actually Getting to Vibe Code At Work With Copilot CLI

Transcript is auto-generated and may contain errors.

Hey folks, we're going to talk about AI stuff. Uh now, I had a pretty cool experience yesterday for for work. Um, so I know when I'm making videos and stuff, uh, either on this channel or on my main one, I'm always showing like if I am using AI and tooling and stuff like that, I'm I'm talking about my own personal projects, how I build things because my role at work as an engineering manager, at least in my current role, I am not uh I'm not actively writing code, right? I I manage three sub teams uh that are all part of a routing plane. Um and they work in like obviously these things fit together but they are three very separate areas. So um a lot of my time is spent on things that are just not going to enable me to write code. Um there there isn't enough time for all my normal responsibilities.

And then if uh if someone was like by the way we need you to start landing features too. It would be like, "Hey, what are you uh you know, what are you expecting that you want me to drop from my my other things and we can talk about it, right?" So, not that I can't, it's just that it's uh it's not really feasible for me to to do in my current setup. But I love to write code. I love building things outside of work. That's why on on my main channel, I am always talking about, you know, the things I'm building, why I'm building them, why they're interesting to me, blah blah blah. So, this past week at work, um, I said, "Okay, like I I I really need to make sure that I'm trying to carry some of this stuff back into the workplace." Um, not because, how do I say this?

Not because there's been like a pressure on me to do so. It's not like my boss came to me and said, "Hey, if you don't start using AI, like you're out of here." Nothing like that. Um, in fact, there was not even any conversation around trying to get me to use AI or anything like that. But I feel like given that like one of my extracurricular activities is literally trying to make educational content for software engineers, um, maybe I can add some value back in at work uh, a little bit more directly. So I said, "Of course, like I can, you know, uh do talks or do like workshops and stuff and just like walk people through things >> like, hey, generically here's how like I use tools and stuff like that." And I and I do want to do more of that. I think that is important.

I think that is something I can help with. But this past week, I said it's time time to go start installing some of the tools that we have access to um so that I could be more relatable when I am trying to to help people with some of the AI tooling. Okay. So, a lot of the examples that I want to give are things that I am personally building. They're on my personal computer. I don't like I'm not going to go show people brand ghost and be like, you know, here's something in a context that may be completely irrelevant to you. Like it starts to create too much of a gap if I'm trying to get into um more helpful use cases. And so I figured let me get some of these tools installed. Um and you know on Fridays it's uh mostly a no meeting day in our org.

It's not that you don't have you never meet people. It's just that you don't generally put like uh recurring team meetings and stuff like that on on Fridays. Uh which is great for me as a manager because I can catch up on some things and um then I can actually schedule a couple of other one-on-one conversations with people outside of my, you know, direct reports and things like that. So I said, "Friday's coming up. I'm going to get this stuff installing and get it working so that I can interact with it so that when Friday comes I can start playing around. Um, and I had my own sort of list of things to do on Friday. But I said, "Hey, it's uh it's agents writing code and interacting with agents." So like a lot of this stuff I can, you know, set up, run, and then check in on it, which is great.

Now, a lot of people in general have been talking about claude code. Uh, I I do like cloud code. Um, I think and I I think I've made a couple of videos on this or talked about it, but a lot of the um a lot this is going to sound like I'm talking down clawed code and I I am not uh because I think it is great, but a lot of the examples I'm seeing where people are getting completely blown away by clawed code. Um, I think they're actually just getting blown away with having AI work for them. And so when they walk through this scenario and they're like, "Oh, it's because Claude, it's because Claude, no other tool can." Um, a lot of the time I'm sitting there going, "But like yes, the other tools can." And and I and I have seen that. And I'm so I'm actually genuinely glad that you're excited about the thing, but like I think it's false to to attribute it to a specific tool.

Then you could change the narrative. If there was something where someone said cursor or co-pilot is the only one, I would say like it like probably not. It's just that you ended up having a very good experience um and it was more intuitive or it flowed naturally or whatever. And like that's awesome. Like that that's really the win. So because of that I like you know we're at Microsoft we have co-pilot. We have a co-pilot CLI. I've been using the co-pilot CLI outside of work. I think you know I've been talking about this on this channel my main channel um and my goal is to use different tools. So I said, let me let me also showcase co-pilot CLI at work because I think a lot of the examples coming up right now are people going, "Oh, like check out Claude." And like again, yes, Claude is awesome.

But people that I'm interacting with are not using Claude for a lot of the advanced features that really make Claude super cool. So So anyway, um got Copilot CLI set up. uh we have things uh organized in a way uh where we have it's it's really helpful like we can you know visit a URL uh helps us get everything we need to set up in a compliant way um and that way actually we can switch between tools um again in a compliant way. So super cool. I love seeing in my co-pilot CLI and I think it probably says the same thing in cloud code. Uh I just didn't double check, but uh it says unlimited uh tokens and stuff uh or unlimited requests or whatever it is in the bottom right corner. And I'm like, "Hell yeah, this is awesome." Um but I set out to do some things.

And so the things that I started with are uh number one as someone who is not actively writing code. Um in my current role I often find that when I'm doing uh code reviews and things like that. I am not intimate with the code and in my previous role before Microsoft I was writing tons of code with the team. Uh I did that you know for eight years. So a lot of the products and stuff that existed at Magnet Forensics up until the time I left like I had written code in like almost all of them um in some cases had started some of them right like had done the initial coding in those areas. So I was very comfortable navigating all sorts of different code there because I I lived and breathed it. Uh at Microsoft just not the case at all.

um obviously in general because it's a ridiculously big company, but even in my my areas, but when I do a code review, I can navigate at least what's being changed to make sense of it, but I don't have the luxury of of uh of kind of like relying on my my existing knowledge of the codebase to be like, "Oh, yes, I know we have good test coverage here," or, "Oh, yes, I know what the um you know, the architecture is in this spot." It's not um it's not something that I have like I would have to go out of my way. Uh and I and I don't have the the code cloned down. I don't have these repositories cloned down, but I will often go into Azure DevOps and look around and you know, I can search for things. Uh so if I'm going to start building some stuff, I'm like, I don't have the code cloned down.

I actually need um some better tooling. So we have MCP servers and all that kind of stuff. uh and we can you know from from co-pilot CLI you know I can ask it to go to get code and it will absolutely do so connect Azure DevOps um fetch code but I noticed that when I was doing some simple interactions like one of the things I wanted to do was explore how I could uh call some APIs for a service that uh that we use a lot and I'm like I know there's APIs for it. I don't know what they are, but I know they exist. So, what would I do? I would go on to Azure DevOps and try searching. But the tricky thing with traditional search is like if you don't know what you're asking for, like I know conceptually what I want, but I don't know the right keywords to use.

And the minimal keywords I can think of are going to be so generic that like I'm going to be spending a ton of time trying to narrow things down. So, with an LLM, with some of the MCP tools, uh it can absolutely go find uh you know, the right things. But when I was looking at the tool calls and um kind of walking through getting to a spot where I could get the answer I wanted basically was like find the team that builds the thing and then based on the thing I want you to like interpret the API spec for it and then you know out of that like tell me what capabilities we have to work with, right? like I need to know what things I can do based on this API and like talk to me like a human. Huge benefit of an LLM.

So I had to do all of that and then I said great this was um like it worked and I got the answers I needed but I basically said like this is a pretty terrible experience to get to this point, right? Like I it took me I don't know how long and it's only because the tool calls and stuff like asking for approvals or like oh that file's too big let me do it a different way or whatever. It's just like it's nonsense wasted time. Um but it gets you to the right answer right? So I'm not I can't complain about the right answer but if I ever had to do that again I would love for that to be more streamlined. So I took the entire chat context.

I went to another co-pilot window and I said I want you to like in planning mode I want you to help me build some agentic skills so that we can accomplish this task in a streamlined way and then discussed with it like you know uh ideally we can reduce down like the number of tool calls um I don't just want one like uber skill here. So if we can compose a skill of multiple more purpose-built skills, we should do that. Um and so did some planning with it. It came up with some skills and then what I did was new co-pilot instance. Um and then asked it the same exact initial question, right? which was basically like uh the team that has this service, I want you to go like uh explain to me the API service like something really simple like that.

Repeat it and then I would, you know, I would notice the improvements in the chat, but I'm like, it's still it's still doing some stupid stuff that like it shouldn't have to do. Um, and then would take that chat, go back to planning mode, right? And say like, "Hey, here were some improvements. Here's the chat. I want you to go analyze and see where the opportunities are." And just did this loop for a little bit um until I got to the point where like I think it went from calling the skill and like one other tool call or something and got to the answer. So then at that point I had a composable set of skills that based on a very simple input could go find and interpret an API spec from like basically wherever we have uh our MCP server to have access to these repositories.

Um, so for me, super cool. Uh, in the future if I'm designing stuff and I got to see this a little bit later when I'm designing things and I'm like, "Hey, we need to like use this service." um because the skills were composable, it's able to like maybe do like an intermediate amount of that work where it's like I don't need to explain to Nick in human terms all of the capabilities, but if I get this far um calling these tools or these skills, right, then uh then I as the LLM will have the information I need to go like, you know, uh create uh HTTP calls for this service, blah blah blah. So, pretty cool. Um worked quite well. I haven't had the luxury of like trying it across a bunch of different API services, but um seemed to do a pretty good job. Uh and I and I tried to remind it as we were designing it like by the way like we are looking at a specific thing.

So, make sure that you're not like building in specific keywords that only make it work for this scenario uh to keep it generic. So, that was really cool to be able to build a reusable skill that way. That's what kicked a lot of the work off. But now I had the the primary API that I wanted to work with. Great. So, what I ended up spending time doing after that was um was getting a simple application put together. There's a lot of um man, this guy's got to move. Someone's got to speed up or slow down. I'll tell you that. I guess it's me that's got to slow down cuz I got to get over. Give me one sec, folks. lot of rain, a lot of people going at speeds that don't help. Um, okay. So, yeah, a lot of the sort of uh it's not quite busy work.

There's a lot of work that I have to do around configurations and things like that. And so outside of like the the management role I have, I I end up having to deal with a lot of configurations for things and so does my team. Uh but sometimes when there's this kind of work, I'm like I would rather have like engineers on my team do the more valuable work and like I will pick up the uh as much as I can the stuff that like I don't want them to get bogged down with, right? As much as I can do that. But that means that like if it's not an efficient use of their time, it's also probably not an efficient use of my time, right? So I need to optimize my own time. Problem is when like you don't have time, how do you work on optimization?

So once I had this skill and I had my Friday in front of me, I said, "Hey, we're going to start building a little helper application um to assist with a bunch of this stuff." And so I basically didn't write a single line of code uh to go do this. I had it all driven by co-pilot CLI. Uh it was pretty cool. I think Opus 46 came out on Friday or whatever. It happened like I got access to it like partway which is partway through my development which is cool. Um the point of me saying that is not to be like see and therefore we don't need software engineers. Uh, not at all. Because when I was designing a lot of this stuff with co-pilot, um, I got, personally, I feel like I got to do the part that I was actually interested in, and that was like coming up with the design for things, making sure that, um, you know, from the beginning things are, I'm going to use the word architected.

We're talking about a very small application, but things are sort of architected and laid out the way that I wanted them to be. Um because if I just listen to what co-pilot was kind of doing, it's doing like I should have gone. Um it's doing what I would call is just like a a lazy quick path. And like don't get me wrong, uh, for the thing I'm building, it probably doesn't matter, but the way that I'm trying to build this is so that it's doesn't have to be throwaway work, right? What I'm trying not to do is build something to like hand over to my team and then be like, now you have to go use this, right? I built the thing and like it does all this stuff and you you are stuck with it like blah like you must. Instead, what I'd like to do is build it as composable as possible so that if there are parts to it where people are like that's interesting.

Either they can use the code, they can use the whole project, right? Like the library itself, they could use none of it and just take the concepts, but at least it's organized in a way where it's not like, oh man, like I want that, but it's coupled to like 15 other features, right? and someone's like, "How the hell would I ever take advantage of that?" So, a lot of my time was going back and forth with co-pilot on aspects like that, like, you know, break these things out into different um assemblies. Like, they're not related. We need to isolate them. Uh don't make these things have knowledge about each other. Um and then getting a bit of a a framework for that setup. And then I told it like I'm starting with a console application like this thing. If we ever continue with it, maybe we don't want it to be a console application.

But I'm just debugging this like on my my laptop. So for now, console application. By the way, what that's going to mean is keep the console application as thin as possible. It's just UX things. all of the logic has to be pushed to another library. And that's back to the same point. If I want anyone to reuse this or leverage pieces of it, I don't want them to say that part's cool, Nick, but like it's completely coupled to like console printing and like that kind of stuff. So, um, got a lot of that set up and then was in a position where I could bas this was the most fun part. I could sit there and like iterate with it and say like these are problems I have or these are interesting opportunities and like let's you know let's sit back like let's design this so we'll come up with a list of features and I would say okay like I like feature three on this list next um let's kind of dive into that.

This is all in plan mode by the way and um then I would go back and forth with co-pilot. Um, it's really cool because it's it's sort of like having a person there, right? When you're talking with other engineers, other engineers will have awesome ideas. Other engineers might have ideas that you don't agree with. Um, and then I can go back and forth and kind of like debate these things with co-pilot until we arrive at something that feels awesome and then I tell it to go build it. So, I did this a whole bunch and uh had a lot of it running in the background and even like at the end of the day yesterday, I was like checking it when I was building stuff at home and then uh you know checked on my work laptop to finalize a few things and yeah, it was super cool.

Made a ton of progress. I had um a lot of uh you know relatively simple purpose-built tools as part of this application that um one of them that I made literally caught an issue that I caused that was completely uh silent or unnoticed. Uh fortunately that issue technically wouldn't have an impact just based on some other coincidences but like it was uh it was technically wrong. So like it had the potential to cause a bigger issue and this tool was able to identify it whereas historically that's just not the case. There would have been no visibility into it. There are no parking spots. Oh my goodness. Can I have to follow this person? I don't even know if I can park there. Oh, how does this work? Can I park here? We'll find out. I'll ask the gym owner. Hell no. Um, but yeah, honestly, super cool experience.

Um I wrote zero lines of code and um it didn't have uh any like the application itself was not AI driven like AI built it but there was no AI integration and then it is a Saturday right now uh and I went to CrossFit so I filmed a video but um this morning I actually went back on my work laptop and I for the first time got AI integrated into the application itself. as sort of a a basis or framework. Um I don't even know it's yeah I don't know if I can explain the details of what I did on that. Um but now AI is built into it. So when I'm building more features I can sort of augment those features with uh um whether that's like a human understandable explanation of things like so I can have AI explain things or have AI take a human explanation and carry out some work.

So, uh that's just a whole other level of enhancement to play around with. But yeah, really cool. Really happy with the progress on that. And uh I think there's going to be some cool learnings that I can actually share with people at work instead of just like uh more generic highle stuff. So that's the video for today. Thanks for watching. I will see you in the next one. Take care.