Is Vibe Coding Real? with James Montemagno

Maybe you've been involved in a Microsoft 365 migration, optimizing your environment, maybe prepping for co-pilot, and then you've probably heard the name Sharegate. IT rarely gets the spotlight, but everything runs on what they build. Mergers, restructures, tenant sprawl. IT figures it out as they handle everything from migrating data from tenant to tenant to making sure that AI and Copilot is

ready to be rolled out securely and responsibly. They make chaos feel like business as usual. And Sharegate, it's the sidekick that helps them do it. Sharegate is an out-of-the-box tool that simplifies the chaos that IT faces. Assess, migrate, optimize. It's that simple. Now, whether it's tenant to tenant, Microsoft Exchange, Google to M365, or getting visibility on your data hygiene in order to prep for copilot rollouts,

ShareGate helps IT migrate quickly, cleanly, and with minimal drama. Go to ShareGate.com. It's one tool, fast migrations, and copilot ready.

Hey, I'm Scott Hanson. This is another episode of Hansel Minutes. Today, I've got my good friend James Montemagno, podcast professional, also works with me, and you have like a couple podcasts, don't you? Do you still do the Nintendo one? no we don't want to do the nintendo one merge conflict going strong uh with frank krueger and we got work podcasts and a bunch of stuff at one point i had like 28 podcasts and there's just too many

You know, someone's got to put a tariff on those because there's too many guys with podcasts. And I'm the worst of them. to be sure. I actually should probably pay up front. In fact, I've got a show I'm doing with Mark Racinovich, and we did a two-part series we didn't even mean to do on vibe coding. And what was going on is I was trying to explain to him what was going on. And he's like, yeah, we could probably vibe that. We ended up vibe coding a...

HLSL shader in the shader language of games and of 3D rendering. We rendered a shader for Windows Terminal. And it was pretty cool. It was impressive. I don't think we use the latest features and all the different things that are available to us. But you blew my mind a couple of weeks ago, and that's why I wanted to have you on the show. Because I've always vibe-coded prototypes, and I've vibe-coded toys.

And my opinion, and I think it's strong opinions weekly held, is that I would not want to vibe something into production. But you did. And that concerns me. So what did you make? Did you become a convert? I only vibe. Funny story, though, is actually my very first job when i was in college i was interning at a game studio and my first job was developing shaders uh for i should have had you there and you would have fixed it and for people that don't know about shader technology it is

Not easy. It's very mathematical, very complex, and very hard to debug and do stuff. So it's very, very awesome that you're able to kind of go through that flow. That being said, shaders and that type of technology has been around for a long time, which I assume by the models did fairly good. And I think, yeah, I wish I had the agent modes and the things back then that I do now.

with my knowledge that I have, but I have built up and I've been developing professionally for, say I'm about to be 40, so I guess like 20 years or so, right? So 18, 17 years or so doing mobile apps for a long, long time. but not necessarily like web development. So it's kind of like not my strong suit, but I'm really good at like backend services and mobile applications and client applications.

But in the last, and I'll be honest, I really want to say four months, three months is when it's really transformed how I developed. So maybe what you are experiencing is a lot of the... ghost text, the asking, the editing, sort of reviewing, like, hey, I am asking a question, prompting questions, going back and forth, and the AI.

let's say, get a copilot inside of VS Code or inside of Visual Studio is giving me recommendations and I'm applying what it's selling me. I'm doing a lot of chunking, I would call it. Like, I need this function. Or take a look at that and make it more secure. There's a lot of conversations. But define vibe coding in your mind.

Well, the thing that I wanted to build, and this is where the vibes come in, and I've always been a vibe person, me and Pierce Bogan. We're at Dead Xamarin for a long time, and our vibes go up and down. When you think about vibes, it's like a glucose. It goes up and down all the time. The vibes are high. The vibes are low.

I feel like we need to define this for people who have English as a second language. If the vibes are good, then you're having a good day and things are cool. It's your emotional state. It's the atmosphere. hey, James gives off good vibes today, or wow, this restaurant has bad vibes. It's just kind of an ethereal thing. It's your feeling, right? And actually...

Funnily enough, when you vibe code in quotes, think of it as normal development. I was talking to someone about vibe coding. What's the difference? I'm like, you know, when you're developing software and you're debugging a problem or you're writing and scaffolding code or you're creating a new class or implementing a method.

sometimes you are in a flow you are in a vibe and sometimes that is going really good like you when you are on a on a spree like you are on a good flow and you're coding you're jamming to some music like you're just you have this back in front of you you're implementing you're implementing everything's going right until the sun's popping up you're like yes this is good this is good

And then you're debugging your app and everything's working. Like that to me is vibing in a different way. That is me vibe coding is me in the flow. And sometimes, If I'm debugging a problem or my code is not working correctly and I'm trying to tweak the CSS for the eight thousandth time, the vibes are a little bit lower. I'm a little bit frustrated, right? I'm struggling through it.

So what? If you apply the same concept of how we've been developing software to working closely with our AI counterparts, to help us get that code completed, then to me, that is the vibe. Now, the traditional vibe coding definition is forget the code. The code doesn't exist. Be one with the AI. That's not my vibe.

Scott. And I think everybody has their own interpretation of vibe cutting. I was just talking with Ashley over at GetUp. She's like, what do you think about this? What do you think about this? I was like, listen. The definition of vibe coding and just coding in general is going to transform and continue to evolve as all of these tools. our toolbox like you remember the first time

You were in Visual Studio or some other IDE or code editor, and you got IntelliSense for the first time, you did something dot, and you're like, whoa, my God, it's amazing. This thing worked. Then you got IntelliCode, and it's like, oh, it's guessing what I'm doing. Yeah, but that's spicy autocomplete. ah it is so imagine that but plus plus plus right and this is where I am defining what I want to accomplish and it just doesn't The difference is that I work with it.

So when I think of it as a pair programmer, not a peer, but a pair programmer, me and you sitting here, instead of you sitting next to me, I've get a co-pilot and we are working through evolving an application or evolving something. adding a feature, evolving a new concept, or like restyling an app or working through a bug, for example. So that's kind of the difference.

I want to challenge you, though, because I don't want... This is not an ad for Copilot or for... cursor or any of these different tools out there. There's a lot of them. And I want to kind of challenge my my assumptions and i want to challenge yours as well because you know you and i are both enthusiastic people like when we discover a thing we spread the word and we're like oh this is so cool There's, you know, the computer scientist and a co-founder of OpenAI, Andrade Karpathy.

is the one who is generally the one who is believed to be the one who invented or coined the term, rather, vibe coding, which is not an old term. This isn't going on for years. This is like six months old.

He said that New York's hottest new programming language is English. And he said this in 2023, saying that at some point LLMs would get to the point where humans would not have to learn specific programming languages. But I've always felt like programming languages strength is specificity.

If you can write English so well that English could compile, that would be a programming language but with vibe coding if i understand correctly you're letting some of the specificity go away and if you truly vibe code something Maybe this is a worthwhile hair for us to split. If you don't understand it all, it was Vi. But Simon Willison, who is a very well-known AI researcher, says if an LLM wrote every line of code, but you reviewed it all and you tested it all and you understood it all,

That's not Vibe coding. That's just a typing assistant. So where do you stand? Do you see the difference? I do see the difference. The difference is

To me, somewhere in between, I would say. I believe that when I'm in a vibe with the AI that I'm working with, it is... Happening at the same time the AI I am prompting the AI. The AI is generating code. As it is generating code, I am actively reviewing it. I am actively seeing how it is responding and telling me what it's doing. And I am working with it in real time to make modifications.

And I can almost, like if I was about to write some incorrect code or create some data structure in the correct way, I can... sense what it's about to do because it's going to tell me what it's going to do and i can stop it i can pause it i can correct it in real time and i am flowing with the ai so maybe my vibes are more of a flow and a jam But to me, that's how I look at vibes of it. But you can do both.

So I'm working on There's two things. One is I have a production vibe coded. I wrote 20 lines of code. I actually wrote 20 lines of code. I had to correct some really hard JSON parsing from Reddit. How many lines of code total in the entire app that you made? I added according to the PR that I sent David Fowler, I think it was 17,000 lines of code.

And you wrote 20 of it. I wrote 20 of it. That is correct. Meaning that you needed to stop and say, no, no, I'm going to drive for a while. And you wrote that yourself. Yeah, and I was very proud of that very complex JSON parsing because it was a real problem.

it could not figure out and could not solve. So this is a sentiment analysis tool. I'm really trying to still understand how do I... do something with AI as far as like integrating AI into my applications that's meaningful.

And something we do at work all the time is interact on Reddit and create YouTube videos. There's all these comments and I want to do sentiment analysis. David Fowler wanted this and he actually had a bunch of command line applications that would go talk to these different services. grab their comments, and then

spit it out to a text file. And I said, well, that's garbage. I'm not a command line person. I don't know what to do with these files. I will create backend services. I will create a web front end with Blazor and I will use, you know, Azure AI. to do sentiment analysis and add on these different services. And I took his original library, which was very small, just a few files, and I refactored all the code. And by I, I mean I told...

the co-pilot to go do it. And I told them exactly what I wanted. I had to create new projects, had to do everything for me. Then I added Azure Function backends, then I added a Blazor frontend. And then... I started figuring out how to work best with it and I started to create prompts. to basically add new features and functionality. I created a spec of how to create something, right? And I worked with it. And in fact, I didn't write the spec.

What I did is I vibed a feature and I said, go create a spec of everything that you just did so I can implement a new feature. So I had it write the spec of what it did. So that way it can follow itself as it's going.

So all of these things to me were in the flow and the vibes of me coding this application. So now, and when I say this, when I'm implementing this, by the way, you and I are in about a thousand calls a day. I would send a prompt. It would go do stuff.

How long does it take? Because most people are used to seeing that demo where they type something and the AI agent or the copilot does some ghost text like they start typing for and then a bunch of gray appears and they either like the gray or they don't that's one perspective then there's a way i use it which is a lot of chatting basically i use it as a

I'd get out of my writer's block by talking to the mirror. I'd rubber duck. So I'm a rubber duck. Stephen Tobe tends to do ghost text. Sounds like you and Fowler are more agent-based. i'm yeah so there's like ask edit an agent and ask is exactly what you're saying rubber deck edits more like I... It's not going to go outside the box. It's like somewhere between this safety box.

And edit is like, I want you to do something that's going to give you recommendations for you to review and you apply them.

Agent mode is I'm going to just do it. I'm going to call tools. I'm going to look at the error messages. I'm going to install NuGet packages, NPM packages. I'm going to create files. I'm going to just go. Here's what's fascinating about this too. When you ask, how does it do it? How long does it take? It depends on the model. Some models, they like to explore. They're exploratory.

Claude, super exploratory. Sonnet, it just likes to take a look around. Oh, I changed this thing. What else can I change? What else can I? And it'll just do it.

And sometimes I want it to do that, but then sometimes I just want you to do the thing. And that's when I slipped to like GPT-4-1, for example. I'm just like, do the thing, go. Using the self-driving car analogy, it feels like... maybe it's generational, maybe it's stylistic, maybe it's just experience, you're trusting and letting go of the steering wheel maybe more than I would.

I'm a little parent. Yeah, you have a finger. I have a finger on the steering wheel. It's only the sensor knows that it's there. Yeah, but you know what I mean? Like, there's still, I think there's just still fear there that it'll swerve.

at some point on my part. So here's the difference with code is that we have this magical capability of get And the cool part about this is it has transformed how I commit code and how I look at code. You're committing more often than I am. I am committing all the time. In fact, Pierce... has it, so his custom instructions, their rules, basically. Piers Bogan. Piers Bogan, who leads. Bogan. Pied Bog, as I like to call him. Pied Bog. Pied Bog, 13 years. Our co-worker, our co-worker, Piers.

Very good at this drive coding, by the way. Very good. So he has this custom instruction that when a prompt is complete, it commits and tells you exactly what it did. So it's always... Wait a second, he can do that? So he can tell the agent to commit for him?

Every single time. Yeah, he has it, so it does a little ding when it's done, and it commits the code when it's done, and you can tell it exactly what to summarize in these custom instructions. Custom instructions.md is a thing that a lot of people don't know about.

Yeah, and that's really the key. So as I've been evolving, I've been vibing, as the AI does something that I like, I update my instructions to tell it to go do that. For example, put all my CSS in a razor.css file. if it does something i don't like doing i tell it don't to do that like write tests i say please never write a test unless i tell you to write a test and if you think i even say this in my custom i said if you think i should write a test ask me if you

test. That's my vibe. There's no testing. And I'll say, we'll go and do it. So as I'm working with it, I am, for all intents and purposes, crafting and making it better. So now I'm implementing features in, you know, not that much time at all, like 10 minutes to add a new service, 20 minutes to add a new service. So what I've been doing is I'm in meetings, is I'm giving it prompts, I'm working on stuff, I let it go. And to your original question is, how long does it take?

Depends on the model. Depends on the feature. but it's doing all things live, right? So sometimes it can be 30 seconds, 10 seconds, sometimes it's a minute or two. I recently had to restyle the entire application. I said I want modern rounded corners. I want drop shadows. I want pastel colors. I was in a very pastel mood. And, you know, that took me like 30 minutes to do. And that was me back and forth, right? That was me back and forth, maybe 15, 20 prom.

as it was going it's like that doesn't look right that doesn't look right i like i don't write any code i'm not css tyler i go that doesn't that doesn't look right go do this go do this and it's the communication aspect of it that I have enjoyed doing. And the app is running. It's a real thing. It's a real thing that's in Azure, right? It's on the interweb, which is scary, but it works.

So we have to respect and understand that a lot of people don't buy this. They don't think that this is a good idea. They think that they don't believe you. Like even our own co-worker. would say, it's garbage, it's awful. You know, like... I'm not trying to sell anyone anything because there's so many options. There's free options. There's $7 a month options. There's ChatGPT itself. There's Copilot. There's Cursor.

I'm trying to understand how I should think about and what it means for early and career development.

because you know what you're good at. You said at the beginning you're a very good mobile developer. You've been doing mobile dev since phones. I remember when mobile was still getting started and you were on windows phones you were on iphones before anybody you know you work with miguel at xamarin so you were ahead of the curve on mobile and i acknowledge that i'm a web person from jump i've been on the web since the web was invented Ciao.

I'm trying to put it in my head. I think I would be afraid. Maybe afraid isn't the right word. I would be conservative if I were to vibe code a mobile app. And I would probably pause and explore it. Are you pausing and exploring the CSS? Or are you just trusting I hit F5 and it looks good so it must be fine?

Yes. Yes and no. So let's take the Blazor example and the function. Blazor is the web framework you're using. That's the .NET, the C-sharp front end that I'm using. So it's got, you know, HTML and C Sharp and things like that. And HTML and CSS. It's very mixed. There's CSS, there's HTML, there's JavaScript. There's a lot going on. All this stuff.

All sorts of things that are in there. And I'm not a traditional web developer, but I can do back-end development quite a bit as well. So in this instance, here's what I'm good at. The HTML and the C-sharp code, good at. What I'm not good at, Bootstrap, CSS, JavaScript. Centering a div. No, and I will never have to center a div ever again. That is for sure. So the things that it is generating... as far as the code, where it puts the code, if I want interfaces, if I want

classes, if I want services, if I want dependency injection, I'm in control. I'm telling it what to do and I'm reviewing that code and I'm looking at it and I'm working to morph it into what I want. The CSS, The JavaScript stuff, hands off. I will work with it. for an hour if I have to, to make that CSS look absolutely amazing. I will not write any CSS, because I'm just not... Is it an amazing CSS? But it's also something you enjoy. For you, it's toil. It's inconvenient.

It is 12 compared to if I'm in mobile app dev. So imagine I go to a mobile app, I'm doing .ml, which is our C-sharp front end, or maybe I'm doing Swift development or something like that. I'm very confident in all aspects of it. Right? Very confident. So in that instance, where it will do extremely well, and I can... do and apply the same approach

is I will most likely be reviewing a lot of the UI work, the thing that the users are seeing. But when it comes to classes and view models and the services,

I'm just going to let it do its thing. I'm going to let it go because that's a lot of boilerplate code. I don't need a review. And remember, If you already have a project, so if I already have a project or I've been working in a project and vibing in a project and I've been working on these best practices, it's going to follow my best practice.

So if it uses a style and I've told it about and it knows about it, it's going to generate code that is similar to my mind that I, because I've taught it in a way to go do that. It has the context from our context.

Context is what's really important. So feed it to context, right? Feed it to problems. Give it the text. If you load up your website and it gives you an error, copy that, shove it in it, it will fix it. Now, on the flip side, really quick, I'm working on a React app. for this build demo that I have. I don't know nothing about React. I've never used React a day in my life. I went from a...

blank folder to a fully... You saw the app. I showed you this application. I wrote zero lines of code, didn't review any of the code, and it's a full... prototype. That's a prototype. That was true vibes. That was a definition.

Are you a fr- I keep coming back to Simon Willison because I really think very highly of him. that vibing your way into a production app is risky. Is this specification-driven development? Because I know that your prompts are very, very, very verbose. And I advocate for yapping at the AI because I very much believe more context is better. You don't say, hey app, make me a master detail app and bootstrap and think that that's enough.

You're going to be typing a lot or talking a lot. I very much believe that we're talking to ourselves in the mirror. You think that you're working with someone, but really you're working with yourself. And by talking out loud, you're understanding what you want and giving it as much context as possible. I've seen your prompts. I think the difference is I'm hearing that you're taking a lot of that prompt and putting it into that custom instructions. It must be very large.

And maybe people who are unhappy are not putting enough into there.

I think it's a mix. So these cool custom instructions get sent with every call. So you kind of want to keep them low. You know, they're with every call to copilot in this instance. It's like an include file.

It's like an include file. It gets every single time. So you want it to be long enough, but not too long. So you kind of want to get those best practices. But there's another instance, which is called a prompt. And a prompt is, for all intents and purposes, instead of putting they're reusable prompts basically so imagine you had a I want to implement a new API. It's like you might have an API problem. Oh, where do you save those?

So the custom instructions are inside the .getup folder, and then these are inside of a prompts folder inside that folder. And then you can, say, run this prompt, and then you can give it. So imagine you had one as... here's how you create an API. So you could define as the architect here in this instance,

The prompt file. Here is how I implement this. Now, of course, you could also have Copilot just generate a prompt for you and how you do it. It knows your code, right? Don't waste your keystrokes. A wise man once told me, you only have so many keystrokes, don't waste them.

You can have it create the prompt file for you. It knows how you create it. So imagine for your podcast, you're like, here's how I create an API. Here's what it looks like. And here are the different files that I need to do and kind of give it best practices around the API.

or a front-end component, or a login definition, or some testing thing. So instead of it just saying, create the test, say, here's a prompt on how I want to create the test that gives it the best practices, and it will go do it. So that's how I've been doing it. So I literally have a prompt And my prompt actually has a decision tree, which is, here's how I create a service. Now the service can be this type or this type. So based on what type it is, some of it, you know, forks at some point.

So ask me these questions and define with it. And this is really fascinating because there's also... this sort of new spec-driven approach, not just to feature development, but to app development. So the whole idea is creating a large spec, just like your product manager would do. And this becomes really important when you think of

how you might add new features is, okay, I can just go start writing code, but let me define actually what I want to do. And you might already have this in JIRA or in GitHub or somewhere else, or just in a text file, like a notepad.

And you might say, okay, well, here's what I want it to do. And here's how I want it to look. And here's all these things, create a prompt, shove it at the prompt. And here's where you want to go. And the other thing that I do too, is I don't type to it. I talk to it. So you, so.

I've worked for Scott for many years, but one thing that he does is he uses in Windows the voice. Windows H, Windows Dictation. I'm always yapping. I don't want to because my hands are hurting after all these years. It's easier just to talk. And you said something really important, which was you have this idea in your brain and you want to get it out. So what I do is in VS Code,

I have the, there's an extension for speech that puts a little microphone button. I tap on it and I speak out in my mind everything that I want until I am happy with it. I'm working through this flow and I give it. give it this huge prompt. And I'm okay with big prompts.

because big prompts for big features gives it more context. So the more context I can give, and I'm referencing files and I'm doing things as well, you got to give it the context. So to your point earlier is like, if you're in the vibe, you're just letting it do its thing. Well, I'm somewhere in between where I'm in the vibe, but I understand the code base. I know where files are. I know where services. So go do this, do this. And the other part too is you can be pretty...

generic, so I'm really bad at typing. Almost as bad as you with our grammar when we typos, like really terrible. Maybe that's why we speak to our computers now. That's fair. You can tell it, oh, go put it in the services folder. And it knows. You don't need to give it like a special thing. It can parse text, right? So it knows how to do that. And to the point that like...

It is good. I was here's the thing is like these things are really smart they're really good they are they've done this for a long time the thing is really getting it to that production level i think what you're saying is how do you massage the code like when do you stop vibing and start code reviewing effectively because vibe coding could also be thought of as like going on fiverr and hiring

young person to go and do this work for you and I want to make sure that we call out these these prompts this dot github folder and underneath it a prompts folder and a workflows folder. This is a convention that is an emerging experimental convention in VS Code that you can go and make whatever dot prompt dot MD.

So you know what this reminds me of? I've got a utils folder that people know about. For the last 20 years, I've been talking about my tools list. I would download an executable. I just downloaded a new one called yedit from Malcolm Smith. I throw it in my utils folder. It's in my path. It's available everywhere. And I carry these around at the command line thinking they make me more useful. I'm realizing as you're talking to me that I'm going to start carrying around my prompt.

My bone best practices. It's like my dot files. except for my AI agent. And maybe I'll carry around MCP servers and MCP utilities and they'll be available as well as I get to a new computer. Just as I set up my prompt and I download my OneDrive or my Dropbox, I'm going to do the same thing with all of my prompts my prompt snippets

That is, you're scratching the right part of my brain right now, James. And that's where the vibe coding evolves, right? We start to talk about best practices as a team. Maybe it's not just you working on the code. What are you developing as your team? not just to scaffold new projects, but how to run the project, how to do these things. The cool part here is you can tell

custom instructions, and you can tell these runners, and you can give it context of how to run your app, what to run the app, do this stuff. It can run your app for you. It can put things inside of many browsers, inside of VS Code. It can, you can just tell it what to do and it will do it right. You guide it. I think some of the problems where you talk back of like,

how people can go down the wrong path is like not giving it the context, not looking at the tools. The tools can do better. The tools can do better at making it better. You know what I mean? Because if you start with a blank folder, And that's it. It has to do a lot more work. And I may not give you exactly what you want compared to I carry around my custom instructions. I carry around my prompt files of how I start new projects and how I want my...

files to be organized, you know, and what type of development I like. And that's a James thing. Um, So those are the things that you'll continue to evolve over time.

when you're developing and these things will continue to get better. So they get better even without these things, but they get even better with it. And it's all about context. That's really what I've learned at the end of the day, whether that's your prompt. or whether you put these in these instructions that are usable. And to me, I start and I give it a lot of trust.

I run the application. I'm constantly checking the work that it's doing. I'm running the application. If it has build errors, I'm telling it about the build errors. I'm having it fix the build errors. I'm having it do these things. I'm checking the work. I'm committing when I'm happy. It doesn't mean the feature is done when I see something. So I was implementing a history feature, so I wanted to be able to save a sentiment analysis on my feedback application.

And I got a history screen, it wrote everything, and it looked terrible. It was just like the worst basic HTML ever. Didn't matter, commit it, because it worked. Now at this point, I'm ready to get back into the vibes and tell it exactly how I want it to look, how I want it to feel, how I want the dropdowns to look, how I want the shadows to look, and the additional functionality, and I iterate through it. I think the other part is...

bigger prompts are really good for bigger features, but I also like to narrow things down to how would I chunk, if you will, like you were saying, pieces of functionality. So instead of giving it a prompt to do multiple things when i said history i scoped it down i said i want you to save it in the browser i want this information i want that information i want a button here

I could have said, I also want you to implement this entire spec and all these other features, and it would have done it. But how I vibe and how I read code is in real time. So I think this is a big switch for me, which was... When I was asking it and in the edit mode, I would stop. I would be more meticulous, like actually looking at what I was writing. When I'm in the agent mode, it's streaming. Now I'm just, I am diving deep with it. I come up from error only when I want.

So how much faster is this making you and... I have two questions as we get towards the end here. First, on this app that you made, and I can attest that I saw you vibe 90% of it, and it's crazy. It's open source. Yeah, it's all open source. You can see this. And I'm sure people will go and find things that they would do differently or whatever. But did it make you twice as fast? Or did it really just...

feel different. I don't like this whole 10x developer nonsense, people saying 10x, 10x. Is it just different or is it faster? It's different, faster. different areas where you're going to be frustrated just because we're also developers of developing things. We've all written code by hand manually where we've been frustrated by what we wrote and how it performs and how it acts. You're going to run into those things.

and then you're going to course correct over time. I would not... One, remember, my day job is not writing code eight hours a day, five hours a day, right? This application, two things. Would not be done. They would maybe have. 20th. like a tenth of the functionality that it has today.

because I have a life outside of work too. For you, it's about saving time. You don't want to toil, so you're trying to remove toil. To me, I don't have a percentage on it, but I don't know if this app... would have gotten done in the last... I went from zero to being deployed in three days. Bye. And that's me and my spare time and my amazing wife and partner that allow me to vibe code until two in the morning. Because again, the different part here is like,

I was enjoying aspects of it. And I was like, I gotta, I gotta, I gotta. No, no, you were having fun. I could tell you were locked in. I was, I was, I was locked in the vibes where, I mean, the vibes were up and down, but there was high vibes and I was doing stuff and I was implementing it. And once I got even streamlined, there was air. So. To me, it was fun. I enjoyed it. I continue to enjoy it. I continue to add new features that I think of. So to me, it saved me from where it's at today.

Weeks, weeks of development, 100%. Now, that being said, remember, I'm not like an expert.

Yeah, but you're a dev, though, of 20 years, and that's my next question. Do the same thing, except you're 22 and you don't know how to code. Well, and then you would ask, the ai to help you code put it into this is the difference uh You tell the AI how you want it to work. You tell it how you want to review it or how you want to learn how to describe things. Something that's very fascinating that I learned about AI is, and especially with Copilot, is the context window. You can create new chat.

So how Copilot works or any of these AIs works, it has the context of the chat and all the changes that it made. I'm constantly committing and I'm constantly creating new chat. Right? Just like a new email, I'm ready to give it new work, not work off existing work. It's the history. So it has the history context. So it could continue to build. And if you start working on other features, it will switch over, right? So I think in this instance,

When I am a new developer to a new code base, I'm going to use some of those early things, which is asking and editing. And then when I'm comfortable, get into agent mode. But I might put it in a different context in my copilot instruction and say, hey. I really want you to describe what's going on. I want you to ask me questions. I want to review. I want you to highlight features. And it will link to code files. It will link to things. If you...

Want to use it as a tool for learning you can just tell it Because it is telling you one thing that's really fascinating and how my brain is like really transformed when the agent mode is going is I am dissecting the words and what it's bolding and what it's doing in real time. It's telling you everything it's doing. It's not just doing it.

It is doing it and telling you exactly what it's doing. You're in like verbose logs mode. You definitely like to know what's happening. And it will tell you. It will also tell you before you do it. So the question to you is like, that you had for me was like, well, if I'm a new developer, should I just be all vibe coding all the time? I don't know. That's not my vibe, I don't think. I think that learning data structures, learning code, understanding things are really good.

However, as developers, we're going to be jumping across JavaScript, TypeScript, C Sharp, Swift, Kotlin, whatever, and these tools can be very helpful. I would feel really comfortable jumping and creating a new Swift iOS app with these tools today. I'd feel super happy. Yeah. Either in VSCode, that'll slow you down. Yeah, there you go, right? I'll do it in VSCode, right? Yeah, yeah, yeah. Install and extend it. But it would be that. So I think that I would feel...

very, very comfortable doing it. Now, the difference would be like long-term maintenance, right? You know, hey, we created something. I created this feedback flow. What about a year from now? What about two years from now? Like, is the code maintainable? Is it this or that? The difference is what I'm doing now is I've shifted my hat a little bit or I'm not like feature complete.

But now I'm in refinement. So now I'm vibing making the code more reusable. And what I did is I used MCP servers or model context protocols, basically tools that the AI can call like... GitHub or Perplexity or Context 7. This is a really awesome MCP server. So if you have libraries you're using, It can go fetch context about that specific library. It's called context seven.

because again, AI is only a point in time. You can feed it context. So a new hot JavaScript or C-sharp library comes out, it'll grab it and feed it the context. But what I did, Scott, is I went in, And two different things. One is I asked it to do a code review. I said, analyze the entire code base. And here's what I'm looking for.

I'm looking for code that can be cleaned up and it can be reusable. It's like not in a good state. Stuff that isn't adhering to best security practices or coding standards, performance improvements. Go analyze the code. And then go create from what you've analyzed the 10 top things that I could do in my application and go create the GitHub issues for. Really? Yeah, just do it. It's on the GitHub right now. You can look at the issues. All of those issues were created. It has the context.

of your entire app. Again, I don't waste keystrokes. I'm not going to go create a GitHub issue. You know what's interesting about this is that consistently you're expecting far more than I am. All my expectations are super high. They're super high. And every single time I am not let down. Surprisingly, I went through, I said this, I gave you this issue. It's the top issue on there because I want to add authentication.

Not an authentication person, that's for sure. But I know that I either want to use EntraID or MSAL or some other service provider. I told it, go do the research. Go figure it out. I have perplexity. Go do the research. Go do the thing. Go do the web search with Bing.

And then go create a GitHub issue. That's the other thing that you're doing. I think it's worth noting for the folks that are listening and kind of like getting your kind of like enthusiasm is you're not just copilot. You're using complexity or you'll get an open AI key. Like these are all servers. MCP servers, right? Model Context Protocol servers that you can use as well. And you can tell Visual Studio Code.

to go and do these things, because you can actually set up this mcp.json, go in there and say, well, I'm going to use my GitHub token. That'll let me use the GitHub tools. I'm going to use Perplexity, which is, you know, Honda, Toyota, whatever. Pick the one that makes you happy. You put in your personal access token for GitHub. You put in your Perplexity API key. And you start building this collection, just like I have my...

path with my list of my command line tools. You're doing the same thing except in 2025 or 2050, whatever year you live in. where you're collecting your collection of MCP servers, which are in your path, where your path is now this mcp.json that lives in the .vscode folder, and it becomes your... Toolkit so it's not a it's not a homogeneous one size fits all thing you're building your team

And that team is going to be different for every app that you're building and every stage of the app as well. And I'll say one more thing here about the early in career is like how I... I've been using these tools for a while, so I'd have a very hard time to say I'm a brand new coder going into VS Code for the very first time. go, right? That's the part. Setup is non-trivial for this stuff, to get it dialed in the way you work. Now, one thing that's very fascinating is I evolved

through the stages as VS Code evolved, right? And the agent mode stuff evolved. So I went from ghost text to the ask, to the edit, to the agent. And I felt that I understood what I was doing and I got better at each step to go to that. So that's how I've been doing it. And you can tell my enthusiasm. I obviously work for Microsoft, right? And I'm very close to the VS Code team. Like no hidden things. There's obviously some bias there. But I'm also a real developer. I built real software.

not only fully with agent mode, but in the past as well. And I am really loving the direction it's going to help me not only just save time, write code that I don't want to write. and then put myself back in the driver's seat to help it generate the code. how I wanted to generate the code, as if I wrote it.

I will work on the real problems. I'll work on the real things. Yeah, you want to work on the hard stuff. You want to work on those 20 lines of JSON. That was an interesting problem that hadn't been solved before. But bootstrap, that's trivial. You don't need to waste time on that.

Yeah, the things that I want to work on give me a lot of pleasure. When I saw that JSON bug, I was like, and I'm going on break. I was so excited. I was over the moon because it was a really hard problem. Yeah, me centering a div, I don't know how to wait. Yeah.

Well, folks can check this out at github.com slash jamesmontemagno. It's in the feedback flow folder. You've got a bunch of stuff. You're super public in the way that you're doing this. You've got this spec-driven app template, which is super interesting, all, again,

totally public like you're very generous with the way that you share this stuff i'm still kind of exploring in there and how you're doing this i think people should make pay special attention at the dot github and the dot vs code folders because they show you how you've basically customized this. You're not doing anything by default. You know, just like our buddy Abel RIP said, don't accept the default.

You're exploring the options. A lot of these are experimental, but they're super fun and super interesting. And I'm learning a lot from watching you and learning. And I got to get my head beyond AI as ghost tech. You know what I mean? It's not spicy autocomplete. It's more... The age and stuff is interesting. But also human in the loop. I'm a very big, strong advocate for human in the loop. I'm always going to have a finger on the steering wheel.

And I appreciate that you feel the same way. You decide how you want to vibe. It's your vibe. Don't let anyone... Mess with your vibe or dictate your vibe. Yeah, don't let them dictate your vibe. I think you code and you vibe code and you flow code exactly how you want to. And I think that's what's been helpful for me because I think if I was stuck in that box of, oh, you got to ignore the code and do this stuff.

Yeah, that's a vibe. That's not my vibe. So I am going to be productive how I want to be. And I think I encourage everyone to do explore, try stuff out. And if you try it today, it's my last point I'll make. and something works how you like it.

Maybe it doesn't work how you like it. Try again in next week. I'm on Insiders, which is like a nightly build of VS Code. Anyone can get it. I'm getting new bits every... I'm getting bits throughout the day. It's going to be changing and evolving. So what we talked about now...

have me back in three months, going to be something different. There's going to be some of the same, but some of the new and things that worked are going to continue to evolve. And that's how I found about this entire thing. And it's fun. It's new. It's like,

new buildings going up around you all the time. I want to go there. Oh, I'm going to that restaurant. I'll try that restaurant. I got a new menu. I don't know what's the specials today. That's how I'm looking at it. So that mind shift for me. made it less scary and more like, ooh, I want to go learn something new. Every time I open it up, I'm learning something new. And that's what I want to do. Yeah. I am cautiously optimistic. I'm not trying to be a hater, but I definitely, like, I wanted...

I want it to work the way I want it to work. You've explained the prompts, the workflows. the way that I can put myself... back in charge you know what i mean always and also you know when it comes to text suggestions and ghost text as we call it the gray text like you can decide where that shows up and how it shows up and some people turn that off maybe turn on just next edit suggestions which are like more like less ghost text and more like recommendations and things like that so

use it to how you would use anything, right? How do you customize your terminal? How do you customize your email inbox? Do you use folders? Do you not use folders? Do you use groupings? Do you not use groupings? Just like any developer tool, you're in control always, and you decide how you want to use it. And I think that is how I've been really enjoying using the tools because, again, you are in control, even though it's doing a lot of work.

You're always in control. There's always a big stop button, by the way. There's a pause button. Do whatever you want. Yeah, that is true. Very cool. Well, thanks so much, James, for getting me plugged in. I'm going to go and clone this, explore it, understand how you're doing this. I see both you and Dave Fowler playing with this stuff, and I appreciate your open mind. Always. Anytime. Anytime, Scott. This has been another episode of Hansel Minutes. A bit of a long episode.

And we'll see you again.