How AI Changed Our Dev Jobs FOREVER - Interview With Brian Jenney

My guest today has one of my most favorite career change stories and I have interviewed Brian Jenny before on a different podcast, but I could never get tired of hearing his story and hearing the different outlook that he has on software engineering. In this conversation, we got talking a lot more about AI. We got to see how we're both using it and leveraging it in our work and how it's working well for us and how it's not working well in some other situations. So, I think that you're really going to enjoy this one. So, please sit back, enjoy, and I will see you next time. Brian, if you don't mind kicking us off, do you want to give us a little bit of background for how you got started into software development and you can kind of go back as early as you'd like? >> Yeah, absolutely. So, my path was interesting. I actually wrote about this on LinkedIn recently. My my coding journey started with an intervention from my mother. Um, I was addicted to alcohol, drugs, doing bad stuff. And my mom had an intervention. I had a small child at the time, my second one. And my I was going really nowhere fast. And that intervention freed up a lot of my time honestly and I didn't realize what I didn't know what to do with time. And I I had an addictive personality. I was in the San Francisco Bay area. I kind of stumbled into coding through a mix of um I I got a like a regular job at around the time and part of that regular job was doing some basic website updates using a CMS. And between that and my job driving people for Lyft and Uber, I was doing both these jobs. I would meet software engineers and then I'm like, "That sounds like a cool job." And then I'd do this CMS thing. I'm like, "This is kind of cool." I I got introduced to HTML and CSS for the first time around like 30. And I was like, this is nuts. And that just sparked this like interest in me. I'm like, I can't believe I didn't know this. Like how this is how the internet is. This is all this stuff on the internet. It just made no sense to me. And then I wanted to learn it. I saw how much of a lucrative career it could be. And then the fact that if somebody would pay me to write code at all, I thought I've made it because that that would be like me basically getting paid for a hobby at this point. So I started I just my addiction switched into coding and that took me into a much different career. And then fast forward now 11 years later and I've gone through just multiple companies in the Bay Area, startups, Fortune 500s, gone to up to engineering manager and now I'm a senior engineer and I work and I also own a coding mentorship program called Parsity. >> Awesome. Yeah. And I'll make sure before we wrap up and stuff in our conversation today, I want to make sure we can shout out Par City and get people information on that. So, uh I will make sure to do that. Um but I I love your story because um and by the way, thank you for sharing because uh I know like this the starting point there is probably like a difficult time. Um, but the >> I think sharing that like I I could think about the audience listening to it and being able to to see you talk through that is like >> it's almost like there's so many different career paths, right? And it's almost like >> where you start doesn't really matter, but in your case it was like discovering something and being like, "Holy crap, this is super cool." um >> I'm not able to obviously speak to the details about um sort of that transition for you but um it's just incredible that you know you know later in life compared to maybe what other people might see for their career journey like it's absolutely possible and you can be very successful so >> I appreciate that and yeah it's weird I I really didn't like to share that part of my life for a long time and I I kind of regret that because I I waited till I was like you know solidified in my career before I shared it but I realized like that's the kind of story I would wanted to hear when I was dealing with it because I really thought like is anybody like me in this career at all? Like is this or is this just some secret part of my history I'll never be able to really share and I'm like that's fine. But um but yeah, it's cool to be able to share that because I've met a lot of people that are going through similar issues. >> Yeah. And yeah, so thanks again. I do really appreciate that. I'm sure there are listeners and viewers that will as well. Um in our little pre-hat we were discussing some AI things. Um >> Oh yeah. And I I think that's probably a super hot topic for a lot of folks. Um >> I don't think we came up with like a starting point for where to kick this off, but maybe I'll just kind of uh launch into it. But um we're both trying to find ways to effectively use AI instead of just completely avoiding it and saying like nope, this like it's not happening. It's not a thing. Um, so I'm I'm curious from your perspective like what are ways that you are either starting to use AI or things you've been trying that are working or aren't working. I just kind of love to hear like what that's looking like for you. >> Yeah, I feel like collectively we've all gone through this massive change in the last like 12 months or so where we went from like okay autocomplete into being like oh my god I'm writing full files of code and scaffolding features. So I was actually working at like an AI company and we were building out uh essentially something like a chatbot but it was um but but it was using retrieval augmented generation which is something I had heard of and then it introduced me to vector databases and how to basically leverage LLM in a full stack application. And I'm like and that was one of the coolest things I've ever learned. I'm like I did I didn't know anything about vector databases. I had to learn some basic linear algebra to understand how words are combined into vectors and all stuff. So I was like learning I think a just just underneath the shallow end and I'm like this is where the real cool work is. Now I'm at a company where I think I'm doing more what most engineers are doing right now which is saying you're going to use AI. We're going to try to build out prototypes. I'm at a really small startup again and we're building a prototype. And I saw the thing that shocked me the most was that the CEOs no coding experience at all. Went to Verscell used a used Vzero which is an AI generative tool kind of like lovable or one of the other tools out there that that craft you know apps right from a prompt and they built an amazing something better than I could have built honestly with a prompt and I was like this is nuts. I'm like thinking maybe there is something behind this hype like maybe I'm not like paying close enough attention because I'm a little skeptical. Um, and then we started using the prototype, right? And then like, so I'm using this and I'm using cursor for sure like daily. I'm I'm trying my best not to actually write much code. And that's changed. I went from like trying really hard not to write much code. Then I realized once you get past these prototypes and like mostly front end stuff and you're doing backend things or things that like really can't break that are mission critical. >> I've actually gone from using cursor like 80% of the time to using it like 50% maybe less depending on the complexity of the task. I'm starting to get a little jaded to be completely honest with you. But I still like use chatbt for like um things like planning documentation. I use cursor for actually writing code. I use Vzero for prototyping rather than Figma. So I can just prompt and get something cool on the screen. That's kind of my daily workflow. And I've tried like Claude Code, Cursor, >> um, Gemini. I'm just trying I'm trying everything out like everybody else is. >> Before we move on, this is just a quick reminder that I do have a course on C refactoring available on dome train. Refactoring is one of the most critical skills that you can learn as a software engineer. And this helps you continue to build upon applications that already exist, making sure that they can scale and have extensibility. I walk you through a bunch of various techniques and give you some examples that we walk through together to see how we can apply these techniques to refactor the code. Check out the pin comment and the links in the description to get this course. Now, back to the video. That's awesome. And yeah, it's it's super cool. Um, definitely similar experience to what I've been having. Um I think in terms of it's funny like I don't do a ton of like uh front-end web development at all. Um >> I you know I use C I love working in the back end and there are some things in C# that are front end like we have Blazer and stuff like that but >> um >> you know I build an app on the side and it is it has TypeScript in the front end. It is you know React and Nex.js and so I I do have to use it. >> Uh just not something that I'm like super in love with in terms of coding and frameworks and stuff like that. personal preference, nothing against it in reality, but um >> sure >> I know that from using Vzero like it has been crazy where >> right >> I'm not I'm not very good at designing like UIs that look good. I think in terms of functionality and user experience, I I I'm like I can think about what would be helpful. >> But if you wanted it to look good, like I am not your person for that. And you can just describe it to Vzero and it just makes user interfaces. I'm sitting there like I would never have done that. Like it's impossible that I could have done. >> I'm blown away. >> And it must be even more magical to you because you're mostly a backend guy. So I can imagine for you it's like this is like a godsend. >> Yeah. So the funny thing is I know like so you see it everywhere right? Everyone's talking about vibe coding and um >> I'm you know one of those people where I'm like yeah you probably shouldn't do it like by you know the the definition that's out there where it's like basically cover your eyes copy paste it doesn't work >> accept all >> yeah I'm like I shouldn't do that but then I use something like v0ero or there's times where I use you know either chat GPT it could be copilot and doing similar things like hey go change this in the UI >> and it's in you know it's in Typescript and nexjs and stuff and and I basically am vibe coding and it's magic. >> It is totally >> It's uh it's pretty incredible. So I I don't know like I I realize I'm being a hypocrite when that happens, but at the same time um there's there's certain guard rails where I'm like, "Okay, if it's changing a little bit of code, like it changed some CSS and now everything looks awesome, I'm I don't care." >> But if it's like, "Oh, I had to go like rewrite like these four screens." that I'm kind of like >> even though it's working, I probably want to go understand that. Yeah. >> So, some guard rails make me >> That's my biggest thing. It it seems incentivized to almost write more code than is necessary. That's like my biggest issue with these things. And it's great for front-end code because honestly, let's be honest, like your front end code, if it's a little messy or it's not it's not going to hurt anybody really. If you do that in backend code, like I'm writing like data pipelines and I'm thinking you're you this kind of works, which is kind of scary because it works just enough to fool somebody and then but you've like written four different files. You've added a rate limiter where I didn't need a rate limiter. Why would you do that? And then you've made these weird assumptions about what I'm doing. And I thought if I put this out and we're collecting like, you know, millions of uh rows of data per 15 minutes and this is wrong. this is going to be wrong on a really big scale really quickly. Not like front end code where it's like, "Oh no, the button sucks." Or, "Oh, the page broke. Let's fix it." It's like that that's where things get a little freaky for me when it comes to like vibe coding beyond the trivial. >> Yeah. Uh 100% agreed with that. And I guess, you know, from my bias of working more in the back end when I'm trying to use AI to to scaffold things or even to refactor like there's that exact experience where I'm like this it like it almost almost works just enough. Yeah. >> And like uh even there's times where it builds something and I'm trying it out and I'm like okay like it seems to work but I'm so skeptical because I'm like there either there's parts of it that or sorry parts of code where I'm like I don't know why it went that far to go build it. Uh or I'm reading through and I'm like, "Oh man, like there are so many either edge cases or sometimes not even edge cases where I'm like >> maybe there's like kind of two happy paths and we've completely ignored one." Like I'm just sitting there going, "Yeah, it's scary that if you're not paying attention and you're like, "Hey, look, seem to work." Uh >> seems to work, right? >> Yeah. >> I have images of me cussing it out now. I got pretty pretty upset at C. You can't do this to a human. Obviously, HR would be really upset, but I was like, it made up um it made up properties um on an object that I was trying to access. And I told it, I wrote out detailed instructions. I can already hear people saying, "Oh, you got to prompt it better." I was like, I had like basically you could almost think of it like a PRD. And I I sat with the data scientist and thought, "Here's the exact columns and tables we're going to need. Here's the property names of the values." And I put them in there. And then it after just a series of refactoring, it just made up names. And I said, "Why did you make these up?" And it says, "Oh, I apologize. You're right. that doesn't exist. Like, well, you can't. Why would you do that? And the hallucinations are are are a little terrifying sometimes. Um because you think, like you say, it's subtle. It's so subtle that like one thing is off. You say, "Why is this thing breaking now? What happened?" Oh, you put like you snake cased this instead of camelcased it. Why would you You can't just make these assumptions. It's crazy. >> Yeah. Yeah. And that um it's it's hilarious, right? Because yes, there's going to be I can guarantee there's people that will listen or watch this and they have more experience with prompting and stuff and oh just your prompt is bad or but the sort of the meta point for because I'm sure this will come up more and more in our conversation but the meta point for people listening and watching is like we understand that we can be prompting better. Our prompts will improve. It's just going to happen as we're working with it. But the reality is that if you have to spend so much time perfecting a prompt and handholding an agent all the way through, at what point is it just better for you to go code it yourself >> at some point, right? Um, but these things, they'll get better. Like our our prompting skills will get better. We'll have more guard rails in place. The models will be better. Um, so we're so early with this stuff that I'm not like part of me is like, oh man, like I sometimes I expect more. Why is it being so stupid? But at the same time, I'm like, okay, it's pretty incredible and we are early, so like >> this is a good point. Like I I don't want to bash it all because like I find I mean I pay for all these services, right? I'm I I pay for cursor outside of work. Um, I love it. I think it's an amazing tool and it has changed the way that I write code. At the same time though, I guess I'm just I I'm getting a little tired of the online like AI bros that I feel like are you am I just that dumb or are you guys really 10x more productive? Because I don't believe it. Just straight up like I don't think you're 10x more productive. I don't believe it. >> Yeah, I am also skeptical. And plus the um when people throw the numbers out like literally 10x, I'm like I don't know if you actually understand how much more productive 10x is to make a like >> Google, right? the CEO of Google was saying that Google is 10% >> 10% right yeah >> more productive and that's like ridiculous because it's Google it's a huge company 10%'s a huge improvement for a developer to say 10 times more productive like >> I don't know I know the number sounds nice but >> it's a nice sounding number it looks good on LinkedIn posts but yeah when I saw that uh Sundar said that in an interview and I thought and they're meticulously tracking this and he's probably incentivized to give a larger number the fact that he said 10% was was sounds like the reality of what I think what what we all are going through but it's so weird because I think like talking to you and you're a principal level manager at at at Microsoft right and so you're experiencing what I'm experiencing and I I don't consider person I know you're I know you're a smart guy and so if you're not 10x more productive and I'm not 10x more productive and nobody I know in real life is and then the CEO is saying no that's not true it just makes me think I don't think we're all prompting wrong I think we're doing it right and I think that the expectations are just way higher than reality and reality is awesome. That's the that's the funny thing. I think reality is actually really really cool uh with these tools as they stand. >> Yeah. And it's not like you know something like 10% let's assume as individuals, you know, we are hap we happen to be a little bit more productive than Google overall. Let's say we're 25% more productive. That's still ridiculous to be 25% more productive. Like I I will take that any day, right? Oh yeah, right. For sure. >> So, yeah, it's just the numbers seem quite exaggerated, but the you know, the the capabilities are are certainly fascinating, but I'm trying to think on on workflow and stuff like that. Um, you kind of talked about some different tool usage. Um, I think I I mentioned you before we started recording. For me, like my my flow's been evolving a little bit, but I think it's probably similarish to what you're doing. So, uh, and this is all outside of my professional career. So like at Microsoft I can probably touch on this a little later but everything I'm about to say has nothing to do with actually coding at Microsoft. So just answer. >> Okay. Okay. >> Um so because I I like building software outside of work, but at work I'm an engineering manager and my role does not um the expectation of me writing code is not there. >> But um or maybe you know what, let me reverse this. I'm going to say at Microsoft because this is sort of uh newer for um you know within the team. So like our the engineers on my team, they have co-pilot and stuff in Visual Studio to be able to code with and we have co-pilot as an internal tool obviously because that's Microsoft product. >> That's right. >> All good and great. Engineers can use that. Um certainly within my team I don't have people that are like freaking out doing like you know ridiculous agent swarms or it's just like co-pilot to help them with designing things to help them like with autocomplete plus agent mode on top of that. But there's nothing where you know the one engineer on the team has like replaced all the other engineers or something like that. But um one of the more recent things is uh GitHub co-pilot with agent mode launched and GitHub is owned by Microsoft but >> Microsoft in at least uh I work in substrate. So that's office 365. It's not Azure. >> They are different organizations. >> Um but we use Azure DevOps. We don't use GitHub. And so we have this feature that launches with GitHub where you have agent mode and you can assign it, you know, issues and it makes pull requests. So we recently had this enabled in Azure DevOps. And so I had to tell my team cuz I want to be very transparent. I'm like I have access to using basically C-pilot in agent mode to do pull requests. Now, I don't want them sitting there thinking, "Crap, our manager can now just go fire off poll requests to AI. Like, do we need are we needed?" Right? I don't want that fear to come up cuz >> I haven't said this to you yet, but like I don't have the belief that AI is just going to replace all of the jobs. I I'm a strong believer that it's an augmenttor and it's going to enhance people's productivity. >> And I genuinely believe that. So I'm trying to be transparent with my team like hey look I'm going to be using this. The first case that I'm using this is I'm doing package upgrades. >> So we have like security things that will come and say hey these packages need to be upgraded like you know they haven't been because no one is going to go through all the projects every day and try to upgrade them. But so I told people on the team I'm going to use AI to help with this. And I said if you enjoy this kind of work just let me know. I don't think that anyone does. >> Yeah. Right. If you if you do, I'm happy to go give you work like this if you enjoy it. But I said, I'm going to be trying to use AI to go tackle all the stuff that you don't want to do. >> That way you can spend the time doing the good stuff. >> Cool stuff. Yeah. Yeah. Yeah. Totally. >> That's been my guy at Amazon did that too. This guy I was speaking to from Amazon, he said they like reupgraded all their Java packages or something like that with just strictly AI. I'm like, that's that's a perfect use case. That's cool. you're doing that too. You're make because I'm sure like if I heard that too, I'd probably be a little freaked out to be honest with you. Like my manager was doing like oh no, like they're going to be just >> firing off requests, you know? >> Yeah. And it like it's interesting internally at like within my team and stuff. I don't have engine like my I I feel like I can say this, but like I feel like my team trusts me a lot. They'll talk to me about you know things openly. Uh but no one has talked to me about like hey is AI like going to take our jobs? like the conversation. Maybe they wouldn't approach it directly like that, but the conversation hasn't come up. >> Um, so I it's I don't think that they're just not thinking about it at all, but I don't know if they're actually afraid or not. So, I just wanted to make sure that when we start seeing it more and more that they're not automatically building the sphere cuz I we talked about this when you make YouTube videos or post things online, people feed into the doom and the gloom >> and I don't want to propagate that. >> I I'm Yeah, I'm really glad to hear that. That's really cool that you're taking that stance because I feel like a lot of us um I mean I'm an IC and um individual contributor for people who don't know. uh it it feels like you're kind of being pressured to use AI and kind of this expectation you're going to be so much more efficient with it and having a technical manager like you that's using the tools. I think it it creates the like the you're you're aware of the reality, right? And and I'm assuming you're managing probably mostly senior engineers. >> Yep. >> Yeah. And they're probably like actually coming against the reality too. I'm like, okay, this is a really cool tool. Like like you said, it's an augment. But yeah, I just don't see at this point I don't see any even even a little bit of hope that it will replace a full human software engineer. Unless you unless maybe you're like a really really junior person that only does the most basic front-end webdev stuff, then I could see that being a onetoone replacement. But I don't think those jobs really exist anymore. I mean, do you remember when people were HTML email developers? Like when that was a thing? >> Yeah. like those kinds of jobs which don't really exist. I mean, you know, yeah, you could have AI do that for you all day. >> But that's just the thing, right? Like they don't really exist because you didn't even need AI to be like starting to replace those jobs because there starts to be more tools that are like, you know, you can set up your email configuration this way to like, you know, more low code or no code solutions for that kind of stuff. And but it didn't need AI to go replace it. And for for transparency and clarity, I'm not trying to say like uh I don't know like only like only unskilled people would do that kind of thing, but there are like in all things in development, we're always looking for ways to try and you know make these things easier to do. Um there like if we think about website development, if you were to go back 20 years compared to now, how many solutions exist that are basically like one click, you name your website, pick a theme and like you got something that looks awesome, right? like there's so many things like this. So >> yeah, good point for sure. >> So that's always evolving. Um I on Okay. On the outside of Microsoft stuff for software development for me though. Um I think I mentioned this to you before we started recording, but the sort of I still use chat GPT a lot especially for like designs and conversations. I think you were saying a similar thing though. So do you >> Oh yeah, for sure. in terms of tooling and like design and stuff like chat GBT like do you use do you find using um LLMs inside of your IDE for that kind of thing is also helpful or how do you balance that from like a design and like I don't know like a strategy kind of perspective >> for strategy it really helps me out I mean lately I've been doing like some what I would consider data engineering which is not my is not my domain of knowledge so I'm trying to learn and one of the things that I that I really like to do is I spend a lot more time thinking now um a lot more time planning because which I should have done anyway, but now that especially if I'm going to be offloading a lot of the actual implementation to an agent or some sort of you know coding bot uh I want to make sure I really clear on what I'm building so it doesn't go off and do something awful. So oftentimes I'm checking against chat GBT to just verify what I'm thinking. I noticed that the more generic the problem the better it is, right? But I actually had a student and like c in certain things I'm like okay that's a pretty generic way of approaching this but like that's good. So, if I thought this and this is confirming that this is a a a traditional approach, that's a good thing, right? But I did notice that um sometimes it gives these ridiculous responses and and that's the hard part. And and sometimes I'll have to just kind of go quote unquote old school like Stack Overflow or something like that and kind of make sure that I have a plan that that makes sense because uh I'm just getting less and less trustful of uh of the LMS. But it's but it's helpful. I'll use like chatbt to like plan out something like okay here's the flow I want to have like let me just talk it out and I only use the speaking mode in chat GBT now too I never really type in there >> I only use the microphone and I'll just like talk through my whole plan and I'll like make this you know kind of walk through my thoughts and then it will organize all that for me and then I'll say hey now can you make that into a format that I can give to cursor and then I'll give cursor that and then I'll have like a a notion document that a checklist so I have like all my workflow really out there and it gives me a really good starting point. So that that is one of the most like magical flows that I've I've come up with so far. That does feel kind of like magic. >> That's really interesting because um I've noticed that mo probably mostly with chat GPD because I think I do use other tools and things like that. But from a I don't know like strategy or like design kind of like my my pre-work where I'm like trying to think through problems. you the more tools I've been using like this typing and like trying to get everything organized and I'm sitting there like >> I wish I could just speak this out like it would be so easy and it's almost like every time this happens I get like I'm writing like all this stuff and I'm like wait a second there's a microphone I can talk and it's not yet >> I don't know when this is going to click for me it's not my go-to thing yet but it needs to be because I spend I'm now wasting more time typing >> when I could just speak it out. But so you've you've naturally made that shift like consciously where you're like I'm ready to go like speak and you're just going. >> I'm I'm a frantic individual sometimes and I tend to do this. I tend I overthink. I'm a little neurotic maybe more so than the average person. I have like high anxiety I think. I don't know. So a lot of times I I'll talk to myself a lot. Um especially when I'm stressed out and I will talk to myself. Um, and I do this a lot. And so it kind of came naturally. And when I saw that this is the perfect thing for an LLM to do because I could summarize all these halfbaked thoughts and fill in the blanks for me with uh with with information that I can then interpret. So like this is great. This will trip you out. You should you should check out this tool called Whisper. Uh I'm not sponsored by >> People keep talking about this. And so tell me tell me everything about Whisper because my I'll just tell you my genuine concern >> is that I see tools they exist and people are like, "Oh, you got to try it. You got to try it." I'm like, "Look, man. I can press a keyboard combo on my keys right now and it records." What's What is the difference with Whisper? Uh and and I don't mean to be skeptical. I just would love to know because people keep saying really good things. I think I think it may end up being a skills issue then on my part because because if that like I just want something that easily integrates with like all my tools so I can just hold a button speak and then it records and it dumps that text from what I just said into wherever. So whether I'm in cursor or um you know even like just writing a piece of text I can talk into the microphone and then boom it's there. Now, I don't know how to do that natively, like without that tool. And um the one the one issue is that you know it's it's yet another subscription and I'm not paying for that right now. I'm using the free version. But because I pay for chat GBT and the pro version or whatever the the plus version, I can I speak into that all day long. And then I when I don't want to speak into that and then drop it into cursor, I'll just go to cursor and use whisper to immediately just start talking to the agent in there. >> Interesting. I think I like you're I don't know how many people have mentioned whisper now and to hear it from you like I should at least get the free one and try it and and see because I need to practice speaking more because I keep like I said I keep finding I'm doing all this typing and then when I'm done I'm like oh I should have been type all that out >> and if you're working from home it's even better. Now if I was working in an office again it'd be a little awkward because then it's like you're just kind of you know bumbling and mumbling around trying to figure out your thoughts and having people there. But it's great for people that work from home. >> That's a really interesting point though. Yeah. And I I'm curious like will we start seeing even more of this? Like the fact that this ended up being sort of a natural progression like I'm kind of going through this progression right now where I'm like I really need to to go from like coding everything to using an LLM to like I'm typing instructions to like I need to speak to an LLM to get it to do things. That's been my progression. I'm still going through it. Sounds like you're already kind of going past that with the speaking part, but I wonder if this will become more and more common for people in their workflows. >> I I wonder that too. You know, it's it's so it's interesting because I'm also getting a little bit of fatigue from all the things like even like now you've been introduced to a new tool and you're going to think, "Oh, maybe I should use this tool." And then we every week it feels like there's something like Cloud Code. Oh, Gemini. Oh, well, now there's cursor, but cursor is not that great, but now there's a tool you can add on top of cursor. And then I'm like, geez, like when are we gonna like give us one tool to rule them all? The nice thing about GitHub copilot is that it was like cool, I got VS Code and C-pilot and boom, I'm done. There's nothing else. Now it's like, oh no, you got to use cloud for this. Oh, you use Gemini for that. No, use this tool for that. I'm like, I don't want to do all that. >> And then Yeah. Oh, but by the way, you probably really need the pro subscription for each one of these tools. And it's only $200 a month for each one individually. >> Yeah, exactly. Oh, okay. So, now I'm paying $1,000 a month. I'm essentially paying for like like a person in some other country to to do my coding work for me. And then the moment that they break down, which is more often than I thought, like cursor has gotten slower than usual. And this seems to be I don't know, who knows? But it also went down last month um for hours. And so, if you're really relying on these tools and you're paying all that money per month and it goes down, I mean, you're kind of screwed. >> Yeah. I was um I don't think there was an outage for me when I was doing this, but this uh today's Saturday. Yeah. So, uh last night I was or maybe it was Thursday night. It's a blur now, but um I was using cursor for something and it must have been last night. I was getting it to code and making progress and like it's doing the typical thing where it's screwing up a little bit and I'm like, "Okay, I got to refine things a little bit." And I am like, "Okay, I think I got it now. I'm going to explain, you know, what to not do and like give it examples of what to do. Cool. Fire it off. And then it starts and then it's just like I'm watching the, you know, how it's thinking and I'm like, why is it still like is it frozen? >> The spinner still going >> and then I'm waiting and I'm like I should stop this about to stop it and then it goes to the next step and I'm like okay, it's running. Maybe >> maybe that was a complicated task for some reason. No, it was just for some reason it was I don't know if I was being rate limited and it wasn't saying, but I'm watching it going like I need to stop this thing because I can definitely go code this faster now. Like this is not okay. >> Dude, I'm having that same thing. I think we all are. I've been seeing this on Reddit, too. It feels like are we all collectively being like kind of pushed a little further into like, hey, maybe you should upgrade, you know? >> Yeah. Yeah. By the way, if you just get the the next tier up, you can actually get >> Exactly. >> Mhm. >> So, okay. The from a tooling perspective, chat GPT, a little bit of cursor on the on the planning front. Um, do you find I'm curious about like context windows and things like this, do you find that getting into the IDE um like using cursor or if it's C-pilot or anything else, how are you finding that's working to like I don't know control what you want it to get done? So just what I mean by that is at a high level if you're in cursor right you technically have access to your whole codebase that should be indexed technically do you go into it being like hey go solve this problem and like here's the codebase I want you to go discover or do you go the exact opposite way where you're like tagging all the files or the lines you want it to touch or is there some hybrid that you're that you're finding is working well. Yeah, that's that's that's interesting because um I always give it context. I really try to tighten the scope um and I want it to be like because I see that it will sometimes like use GP and be like let me look for you know and it will it'll kind of get it wrong and so I want this file like >> yeah I'm like don't please don't do that one time. That's funny because I actually made like one time multiple different button files in different folders cuz I had like a cursor rules doc which was a little bit different than my folder structure and it like was just duplicating that was it just drove me crazy. So yeah, I always give it lots of context. I'll try to tell the function names. I'll try to be as like verbose as I can be almost because I'm like I really want you to not screw up because when it does screw up it's really frustrating. And luckily it has those checkpoints you can go back to and you can say okay well we screwed up. Let's go back to this checkpoint. But um but yeah, without that I noticed that it will it will often do things and I'm like you've touched now 10 files and that's a lot of work for me to try to go into and figure out and I I really don't want it to do that. >> Yeah, that's interesting. Right. It's uh great point that you can like you get kind of checkpointing like you can undo file changes and stuff but you said this earlier that it's almost like a lot of the the agent work ends up just like creating code, right? Again, there's someone watching who will say, "Nope, just add this into your prompt and it's going to refactor." Like, >> okay, I hear you. But >> it seems like the the bias is to create more code, but to your point, if you if you let it go off the rails even a little bit and the next iteration is just lots of lines touched across many files. Um, it's not that you can't undo that or you're screwed or something, but the amount of work and effort cuz we're thinking about this from a productivity perspective. Now that you've generated a bunch of stuff, it's like you have to go check that, you have to go make sense of it. >> Unless you're just, you know, vibe going don't care. You really don't care. >> But then you've created more work for yourself to review and and then statistically without guiding it a lot, it's probably going to make mistakes more often. So now there's more time to review, more time undoing, and then more time I guess reprompting to give it the better guidance. Has that kind of been your experience then? >> That has been and even yet Thursday I I turned it off. I I had to just say I have to go back to manual coding because this is this even with really clear instructions I felt super clear instructions and saying I only want you to touch this one file follow single responsibility principle make these functions composable please don't add more this should be a simple implementation that I could fill in later and it still made like a thousandline file I'm like this is way too much like I got it down to like 300 lines of code and I'm think that's fine that's all I needed to do you know it's doing way too many things and having these weird guard rails and things like that. So that that's my beef. But I think and I think the the weird thing is do have you ever noticed it doesn't just take away code. It always adds code. And I think most software engineers know that code is a liability. And if you can remove code, that's often a really good thing to do. If you can remove code, that's great because now you you've decreased the surface area for bugs to to to fester. And and it doesn't seem to to do that. And I don't know if that's like because of, you know, they feel like, well, you're paying for this thing and we want to um, you know, >> generate lines of code. >> Generate line. Yeah. Right. Generate lots of lines of code. So, I I would love to see how these companies are or what what's under the hood sometimes with with how they make these tools, but I mean, yeah, again, like they are magical, but I do feel like sometimes I'm like that's just too much. >> Yeah, I I totally agree. Um, in terms of it just, you know, huge bias for generating code. a quick example from this week. Um, so in our front-end application that we're building this again outside of uh outside of uh Microsoft, but uh so I'm building something called brand ghost. And in the front end, there's aspects to that where I'm like, hey, I want to I want to make sure that there's more test coverage. And so uh what I'm trying to do is get it to go write tests. And I had found >> that if I was not specific enough and I said write tests, it's like no problem. Makes hundreds of tests. I'm like this is amazing. this is so cool cuz I don't want to go write them. >> Then I started looking at code coverage because I was trying to refactor things and I need those tests for helping catch regressions. >> I was literally fixing bugs >> and then running the tests and they're passing and I'm like, "Okay, interesting. I could I could revert the change and like basically no tests are breaking when I revert." And I'm going through the tests and it was like it's even leaving comments that was like, "Ah, this component's a little bit too complicated. I'm just gonna mock it. And I'm going through all these tests and everything has been mocked out. There was some cases where it didn't take any dependency like at all on real code >> and was like, I'm going to set this up and then >> toggle it. Like it's basically setting up some boolean flags, toggling them, and then saying yes, the boolean flags were changed. >> And I'm going through these tests, and I'm like, >> I can't believe that this is in here. >> This is so funny. I did the same thing. I had the exact same thing and I was like, "Wait, you can't do that. You just It's like saying, "Does false equal false?" I'm like, "Well, yeah, you just wrote it, so of course it's going to equal what you wrote." Like, "What? What kind of test comment is like, replace this with a real implementation?" And it's like, >> "This was supposed to be the real implementation." But so I had been having this experience and over the past few days, something I've been focused on again, this is absolutely this is my fault. I'm taking full responsibility because it generated the test originally and I was like, "Hell yeah." Like, I'm seeing green check marks. >> I should have read through. Um, now I'm paying the price, but what I'm doing is going back through and I'm trying to, you know, improve my prompting for test writing and trying to get it to use the tools. Like, for example, if I just tell it, I need you to cover all of the behavior on this component for for something in Typescript. For me, I'm not a Typescript expert. I can read through the code. Don't love doing it, but I could figure out like, you know, different conditions to go check for and stuff. It's not rocket surgery necessarily, >> but I don't want to go writing the test for that. So what I if I tell it just to go write the test, I'm very nervous now that it has this behavior we just talked about where it pretends or it either mocks everything out and so it's not testing anything real or it's like let me simulate, you know, these flags, that kind of thing. >> Yeah. >> So what I'm doing now is trying to, you know, improve my prompting to say you need to go, we're using justest, right? So it's like you need to run just with coverage and I need you to go look at the coverage result and make sure that it's going up >> because now it needs to actually have something that's exercising the real code. without that it's just like I'm covering the behavior because it it's almost like by writing the scenarios out it's thinking >> I I don't I don't know I don't want to you know personify it too much but like it's um you know it it believes or it's making it appear that the behavior is covered when in reality the real code is not being exercised. >> Yeah. That that is that is the really creepy part because it because you didn't even know right like you could and it's one of those things we don't want to do. No one likes like, "Oh, I love writing tests," you know? So, it's like one of those tasks you're like, "This is perfect for an LLM." And then when it screws it up and then it looks like it's right. Imagine a junior engineer on their like first or second test and they're like not used to writing tests and they think this is normal and they see the green marks and they're thinking, "Oh, great." And then they start making lots of changes and like, "Oh, cool. My changes work just as I expected." And then they put it out there and it blows things up. >> But this is real, right? So, the reason this is so real is, and I'm not saying like I'm the best programmer in the world, but I've been programming for over 20 years, and I'm not familiar with Typescript as much as like C or something, >> and I do know how to write tests, but to your point, I don't want to spend the time writing the test. We have some parts of our code, not that it's terrible, but we have some parts of our code where I'm like, I need to fix this bug. I need to go exercise it and prove that it works, like by clicking through. Now that it's working, I don't want to touch the code. I want to go write a like a test o over it and make sure that that test is, you know, exercising the behavior. Now I can go refactor this like I can go clean it up after. >> Mhm. >> But when that test is being written and it's not actually exercising the code, it's a very false sense of confidence because if I go break that code and I still have that test passing, what was the point of the test? >> What was the point of the freaking test? Exactly. Yeah. >> Yeah. So, that's been something I've been playing with a little bit more. Um, I guess a question for you in terms of like your workflow and stuff. Have you how have you been balancing like kind of doing the pair programming in terms of like uh like an ask mode versus an agent mode? Uh, do you have things where you're just like I'm going to I don't know if I can call like outsourcing like you outsource it to AI to be like I'm not even going to pay attention to you doing this like go run that in the background. like how do you balance these different types of things? >> Yeah, I've been I've been my kind of rule of thumb right now is for front end and prototyping I I kind of don't care as much especially at the stage we're in at the company I'm at. The front end code at this stage is still very green field. It's it's almost certainly not going to live past the prototype stage. So, it's essentially a glorified prototype and it's perfect for that. And I honestly don't care so much. I'm just checking do things work. If they're not working, great. that's I'm actually okay with that. It just needs to look good and kind of surface the data >> on the back end where it's more mission critical. I'm doing a lot more asking like uh we have some Python code in there that I'm familiar with. We have like I've created a repository with the data scientists and all the things they're doing that are complete blackbox to me. And so that's been really helpful to be like what what are the mathematical calculations they're doing to get these numbers and that's been really really helpful because then I can explain like oh that's how I got this number. Oh here's what it's doing. Okay. And and that's cool because now I can understand code that I didn't write that is that is really long and and way outside of my uh dome knowledge um and I can understand it and then then I can have and then while I'm doing that my little agent is running in the background, you know, creating the UI that's going to surface that data. And that that to me is a is a pretty good flow. Now the moment when we move past prototype, which we which we're moving towards and we have our quoteunquote real app, >> that's when I think that I'm going to have to I got to figure out a new flow. I really do because I I I don't want to just do file by file changes, but I also don't really like the whole idea of agent mode. Go out and do your thing and I'm going to kick I'm going to kick back because then I don't like also going through all the different changes and checking them all because then it's it's a lot of cognitive overload. So, I'm trying to figure out what's the sweet spot and I'm sure somebody out there will know. But what I'd ultimately like to do is figure out where I can give a lot of context and say let's just focus on like where I think you need to make the changes. Let's just do these two files only or something like that. And I'm sure I can probably do that through better prompting like like we've spoken about the show that that I think I'll need a new workflow because I I'm just super skeptical and don't trust the the whole like agent do whatever you want mode. That's just not that's not uh not going to work. >> Yeah, that's that's interesting though. Um I like your your kind of take on the fact that you have a flow especially with prototyping. Like I I feel like it's a very good fit for this kind of stuff. I spent a lot of my career especially before Microsoft doing prototypes like even as an intern I was basically I had six internships that lasted like two years in total and almost always on those internships very coincidental is doing a lot of prototypes and um >> the like having that plus in my career like a lot of people the fact that you're doing this you definitely understand but a lot of people don't understand with prototypes it's not just oh you get to work on the new shiny thing prototypes are about answering questions Right? Like >> yeah, >> if you could if you could basically answer a business question without even writing code, that is the best prototype. If a prototype could be, >> you know, could be a onepage like PowerPoint that just has a mockup UI that someone, you know, just drafted up super quick. If you could do that and then answer a business question that's like, does something like this even resonate with you? >> Just as an example, right? No code written, that would be ideal. Like the less code we write for prototypes the better and often prototype code dies. We just need it to be able to go answer business questions. Now if you happen to make a prototype and it can live past, you know, existing as a prototype, >> cool. But you should probably expect that your prototypes are going to die. So um your your take on the flow that you're using being something that's very conducive for for prototyping, super cool. Um, to your point, hey, it's making changes in the UI. If it's not the most perfect code or like maybe a button's doing something a little weird, but it's still functioning, >> who cares, right? Like it's it's serving the purpose in that scope. >> For sure. >> I think that's super interesting. And then again, how do we refine that process over time? Like I I agree even for me there's things I'm building where I'm like it's like it's uh it's passible right now but I know I'm keeping note like I need to go make this process better. The testing thing was the most recent example where I'm like it's not just about adding test cases. I really need to go make this more robust in terms of how I'm prompting to get better results. >> Yeah. More more thinking. And I think that's the the scary thing I think for for more junior people. I hope they're not offloading all this too quick because if at some point you need to have to fall back on like what do you think is the right thing to do? And uh how sure are you of that? And if you're always looking to AI for the answers, >> I you're just not going to have a good time. You're going to get bit. >> And you said you said it earlier, right? You said, "I'm doing more thinking now." Like that's I think that's the thing that needs to happen, not not the opposite. Um Brian, I'm doing a time check. I want to make sure I wanted to hear more about parsity. I wanted to make sure you could you could talk to folks about Parsy and where they can find you, what you're doing at Parsy and all that. So, I just wanted to completely shift gears and and get you to chat through that. >> I appreciate it. Yeah. Um, Parsity um you can go to parity.io by the way. It's a coding mentorship program. I can like an anti-boot camp that I run with ex Google engineer Zuben who I think you know as well. >> I know Zubin. Yes, Zubin's awesome. >> Zubin's awesome. And uh we've completely really revamped the way we do parsity. We see coding getting a career is is way different. We see the boot camp model is not working to be completely blunt uh for many people for most people especially career changers. So we have a very different approach which is part obviously technical but we spend the first eight weeks now with people not touching code >> and interesting. Okay. Yeah. And I've seen how powerful, how much of an impact that's made because now we have more people that are sticking with the program and actually going in going through completion because we take time. We realize if you're over 30, which most of our mentees are, and you're learning how to code and you don't have a background in it, you can't we can't just give you curriculum and expect you to execute it. That's that's fantasy, right? You can get all you can get all the information you want online. If you want to learn to code, you can find everything online you want to. There's a huge gap between learning that and getting a job. And we're in the business of helping people actually change careers and we see that involves so much more than coding. So we have a a very unique approach that that is that is very effective. So if people want to go yeah we have you know we're we're we have less than 100 people we'll help per year. So it's a very unique boutique program. Check it out at pars.io. You can follow me or Zuben. We're both on LinkedIn. Uh Brian Jenny and Zuben Ptop. >> Awesome. Yeah. And like uh thanks for sharing that cuz uh I I know from from being online seeing all of the boot camps I I have talked to people who have done boot camp successfully for sure. It's not like it doesn't happen. Absolutely. Um, and I know you're not saying that, but I I do think statistically there's a lot more. It's almost like I hate to say, but like boot camps a lot of the time feel like predatory because it's like the whole the whole marketing for them is we will basically we can guarantee you jobs in like the shortest amount of time possible, >> but it isn't a realistic expectation and especially now it's even less realist. I don't feel like it was never realistic, but >> it was never really realistic. Yeah. I mean, I went to one and and uh in in like the the golden era or whatever, when people like almost been super easy back then, like it wasn't it's never been easy there. There's a reason why people go to four-year schools, really top-notch ones, and still have a hard time. So, if they spent four years learning this and they and they're getting out doing internships and all that, still taking time to get hired, >> then why would you think that going to somewhere for three months would get you a job like that? It's just it's fantasy. And it can work. I've absolutely seen it work, but but I think that's more anomaly than than normal. >> I've been programming for nine years before I had my first professional job like outside of school. Like >> I and I I went to a school and I already said this on this show, but like I had six internships like I feel like without that I like six internships and nine years of programming and then started work. But and I'm not saying like it's not uh sorry I'm not saying that it's easy now. I'm just saying like I I don't believe that it was ever like easy, but >> it was never easy. There's some weird myth on Yeah, I could go on that about that all the time. Yeah, we spend like we we tell people like give us a year of time with you to to get you to get you close to getting that job or into the job. >> And that that's how long we're going to need at a minimum because it's not going to be a three-month process. But that like I can imagine like I'm not I'm not there running the business with you, but I can imagine that when you're when you're trying to approach things that way and you have all these boot camps that are like no no we can do it in like two weeks and you'll be you know you know a million dollar salary like >> you're you're sitting there going like look like you you have people that come to you and they're like but all these options and you have to be able to convince them like look this is this is the way that it's going to actually give you better odds >> and and honestly that we've we've because of that we've gotten better quality people to be completely honest with you cuz I I did try running ads at one point and I'll just be frank. We got we got lower quality people that were looking for get-rich quick schemes. We're really small. We don't plan on expanding or getting really really big. And so the other boot camps that kind of use those tactics, they're I think they're speaking to different people. But you're right, it it'd be a whole lot easier on us if our marketing was, hey, three months and get a bunch of money. You'd probably get a lot more business. But that's just not something I'm willing to do at this point. But >> yeah, no, that's that's super cool. Thanks, Brian. I will make sure I get uh links from you. Um and I'll have that in the the description and all that. So, thank you so much for talking through your AI fun, man. Yeah, this is fun. >> Yeah, it's really cool to hear that some of your workflows and stuff are mirroring mine. Maybe I'm not totally crazy, but um maybe we're both crazy. I don't know. >> Maybe. Yeah, that that might be the be the case. Thanks a lot. Okay, thanks again, Brian.