Coding is Changing… The Most Advanced AI Tool Yet

Key Takeaways

I just found an AI agent that doesn't just read your code, but it spends days understanding it and then spits out a 200page technical spec before touching a single line. Now, I've been messing with it for the past few days, and it's been able to generate over 130,000 lines of code from a single prompt. Anyways, let me hop over to the computer here and show you how it works. So, the tool that I'm talking about here is called Blitzy, and it works a lot differently than all of the other AI code editors or models you've probably seen before, and it's actually designed to work with them, not against them. Now, the philosophy here is rather than doing all of these small iterations and kind of minor changes one by one. Blitzy can actually generate hundreds of thousands up to actually 3 million lines of code changes based on a single prompt. And it's able to do this by deeply understanding your codebase and generating really in-depth technical specs and documentation before it actually goes and makes these changes. Now, this works in a few days. So, I'll send a prompt and then I'll wait, you know, one or two days and I'll get the result back depending on how many files are being changed. It's not a super fast agent like something cursor where it's, you know, modifying the code in a few seconds or a few minutes. And I want to walk you through the platform because it's really interesting. Now, full disclosure here, the Blitzy team did reach out to me about a month ago to sponsor a video. Since then, I've been messing around and playing with the platform. And while they did want to sponsor this, it is genuinely very unique. I've never seen something like this. They do have a free tier, so you can mess around and play with it. And genuinely, I think this is extremely interesting, which is why I want to show it to you because it does something I've never seen before, specifically around the really deep context and the technical specification, which is pretty mind-boggling. Anyways, let me hop over into Blitzy here and I want to show you how I've been using it, the code that it's been generating and give you kind of a platform overview so you can see how it works. So, I've just signed into my Blitzy account here and you can see that I have an existing project which I'll go through in a second. From here, you can also make a new project and you can either start from a new product or from an existing product. In my case, I'm much more interested in the existing product because a lot of the current AI tools work to go from like zero to one or a quick MVP or an idea, but they fall apart when they need to understand a really large codebase. So, the way that I've been testing Blitzy and the stuff I'm going to show you in this video is actually on the code base that I generated for my previous failed startup. You guys might know about a year and a half, two years ago, I was working on a tech startup. I wrote hundreds of thousands of lines of code to build a mobile application which was kind of like a cognitive training app for athletes. I'll put a few kind of screencasts on video so you can see what the app looked like. That startup ended up failing. But I wanted to see how this tool would perform on that codebase, something that I obviously understand very well and if we would be able to jump in there and start being productive right away on a very massive codebase, not something that's, you know, a quick YouTube tutorial project. So anyways, I'll dive into that in a second, but I want to show you the flow on creating a new project. So if I go here and I select existing project, I can give this a title. Let me just call this, you know, startup app or something. And I'm just going to show you what actually happens when you do this, you can see the flow. So you can add this directly from GitHub. So in my case, I'm going to select my organization. So just for demo purposes, I'll choose this online chess game. I'll select the master branch and then go ahead and press continue. Now what it's going to ask me to do after this, so it's just loading the codebase here, is give it some context on the project. So you can see that it's prompting me here just to give a bit of additional information. So obviously the more data we provide about the project, the better the result is that we're going to get. We don't have to put anything here, but we can insert files or code blocks or mermaid documents or we can do all kinds of formatting or tables. And what I'll do is I'll just give it some really quick context and we'll go from there. So, I'm just going to say something like, "This is an online multiplayer chess game made with Python, Pygame, and websockets. I made this during a 12-hour coding live stream. There's definitely a lot of messy code. There's no testing, and this was meant to just be a demo project. Okay, so we'll just give it a little bit of context here so it kind of knows what I was building. And then what I can do is go directly to build the text spec. So, this is the important part of Blitzy. I'm going to approve this prompt and press on continue." And now what it's going to start doing is ingesting this codebase, understanding all of it and writing an extremely detailed technical specification that outlines everything that's used, the tech stack, the files, the testing coverage, the uh what is it, the back end, the front end, like it generates literally a 200page document, which I'm going to show you in 1 second. And you can see that this will take a bit of time. Usually it takes between 1 to 3 days. In my case, it took about a day for the previous project. And I want to show you for my startup codebase cuz I just wanted to go through the flow here what that text spec looks like. So I just opened up my existing project in Blitzy. And this is the tech spec. Now the start of the tech specs. So all of these kind of 0 whatever is the most recent change that just made because I just got it to actually add some advanced testing which I'll show you in a second. But if I scroll through here, you can see and I'll go into a few sections smaller in a second. It's literally like this extremely detailed um technical specification that also includes all of these different flowcharts. So it explains like how my app launches which I verified is correct. App launch user authenticated. If no, go to the authentication system. Select the provider Facebook, Google, OOTH, whatever. Uh validate the token. If there's no token, go to the display error. Go back here. Otherwise, Firebase O profile setup. Enter the name. Right? So I have these kind of onboarding steps in my application. And then it has all of these different kind of decisions that we go through. And it's very useful to actually see this, right? And something that a lot of devs are not going to make themselves. Then it says the daily training workflow and that explains exactly how that works and all of the different events that we have and how this is set up. Same thing here in terms of like the workout complete and how we actually uh calculate the scoring because our app was called velocity and we had like a velocity score for all of the users. And you can see there's all this stuff here. We had like an anti-cheing thing there. We have the social actions. So following user, workout post, like post, view profile, etc. We have all of these sequence diagrams in terms of all of the different architecture and components that we have like fire store, cloud functions, cloud messaging, firebase analytics. Like it's insane just how detailed this specification actually is. And it includes things like our firebase services, our ooth providers. I'm not going to go through everything, but this was really interesting for me to read through because it showed me in, you know, a lot of detail and visually what the architecture of my application actually was. And even though I probably should have made these diagrams myself, obviously I didn't when I was coding this out as a startup. And now I have all of them here. And this is how the app is able to understand and have this really deep context. So I mean, I can keep scrolling here and you guys see it's kind of just neverending context and documentation. And keep in mind obviously this is a lot because I built you know a really large application. I spent about 2 years coding this out and that's why we have all of these different diagrams. Okay. So that's that right? So it took you know a day or so to generate this um what do you call it document and what will actually happen with Blitzy is while you're adding new features and generating new code it will continue to update this document for me so that it always has the kind of most recent state of the application. So let's say we've got the technical spec out of the way. Right. Again, it takes a bit of time, but I've already done that for the video. What we can do next is we can obviously start coding stuff, right? And generating features. So, for example, we can go to build here. And then from here, we have the ability to do these six things or have a custom kind of feature. So, we can add a feature, refactor the codebase, fix vulnerabilities, etc. I've used most of these. Again, I did this previously. I was working with this tool for about a month because it does take a bit of time to actually generate this code. So, for example, here I went to build and then I pressed on document code. And then I gave this a really detailed prompt asking it to actually document all of the features of my codebase that I didn't have documented. Now I don't have the prompt on hand with me because this was a while ago, but I want to show you the pull request that Blitzy actually made on my repository. So you can see what it looks like. So here's the pull request that I was talking about. You can see it happened 2 weeks ago from when I'm filming this video. And what is it? I asked it just to document the main features I believe of my backend. So, if I go here to files changed, we'll see that it actually generated all of these different specifications for me. We can view this in the uh what is markdown editor in a second to see what these diagrams look like. But we have, for example, in my feed, you know, a new readme file that was added. If we keep going, we have inside of profile a new readme file. Inside of notifications, a new readme file. It's not showing it because it's too big. And it has all of this in-depth documentation explaining how all of these features work. Again, I thought it would be more important to document the back end. So that's what I asked it to do first. Now let me just open this up in the markdown editor so you can see what it actually looks like. All right. So this is a bit better here and you can see that it explains for example how my feed system works using a fan outright design that includes daily timebased buckets. We have advertisements a content system how we fetch the feed the feed fill system. This was a pretty complex um system that I had to build for this application. Gives me the sequence diagrams gives me what happens when a post is created and essentially how we do this. again the real-time update mechanism in terms of how we're doing the reads and the writes and the real-time components and breaks all of that down. If we continue and we go to like profile for example again we have another readme file gives us the nice table explains all of the uh what do you call it features of the profile exactly how we update the profile I'm not going to go through everything but the point is that this worked quite well for the documentation and then it added all of these individual files that I wanted for all of my backend features again we have one here for social we have read me and we have these kind of in-depth charts that we can navigate through download look at etc okay so that was the first thing that I did with Blitz Now the second thing that I did with Blitzy was a little bit of refactoring and fixing all of my types. So I did this project in Typescript and as you probably know if you work in Typescript a lot of times the types can be very complicated and we oftent times skip them and we just go and put like the any type for example to kind of avoid the type checking and oftent times you're going to get some linting errors and you'll have some eslint problems etc. I definitely had that in this codebase. So I wrote a very detailed prompt. I'm going to show you some tips on how to write the prompt in a second. By the way, that asked it to essentially fix all of the TypeScript compilation errors and do a little bit of refactoring for me. So, you can see that in this pull request that it generated, it did 24,000 lines of code, right, or additions and 16,000 deletions, which is a lot. And then, if we go to files changed, we can see everything that it fixed. So, again, it redomented everything, gave me the project guide. If we click into an individual file, you can see we have all of our exports defined and all of our modules for the typing system. If we go here, we're importing the correct components, right? So, we had, you know, text from the wrong thing. So, it fixed that for us. Again, same thing. If we go here, it's fixing all of our types for us. And it's just making kind of all of these changes within all of these different files. Again, I can't go through everything for you, but you can see that it is fixed now. So, that we didn't get any of those errors. And that's the next task that I asked it to do. Now in terms of generating the prompt the approach here with blitzy is that when you do this right so once you give it action blitzy will complete probably 80% of this but there is going to be some kind of bugs there will be some errors there are going to be some things that you need to do as a developer and this isn't meant to replace the development team it's just meant to augment all of the kind of annoying work that should be able to be handled by an AI agent in fact if we go back to the original poll request you'll actually see that there's always some kind of commit here that adds a project guide. Now, if I go to this project guide, which you can see inside of the Blitzy documentation folder, this is something that's included in all of the work that Blitzy does to tell you as the developer what it actually did. So, what it completed and what you need to do next. So, if we scroll through here, you can see we get an executive summary. We get a breakdown of the development hours. Tells us essentially that this is 94% complete. And if we keep going, we can see all of the completed work. We can see this matrix where it tells us for example the functions timed out. So that's something that we would need to fix. And we can keep going all the way down to the bottom and it will tell us first of all all of the key achievements as well as what the next steps are for the human developers. So this is very helpful as a developer because it's telling you what the current status of the project is and what you need to immediately do next in the immediate term, shortterm and then medium-term, right? In some cases longterm, etc. So you can see we need to resolve the cocoa pods configure production environment. You get the idea. But this is a document that you should look at when you use this tool because again it gives you a very quick and accurate snapshot of what's been completed and what to do next and where you need to step in as an experienced developer. So Blitzy takes the approach that 80% of the work can be done by this and then the other 20% can be done by you. So what you would do is you would then open up the application after it's done all of these changes, right? You would obviously review the code just like you would for any other pull request. You could open this in a tool like cursor. You could fix some of the bugs, any of the runtime errors, etc. And then you would be good to go. So that's kind of the approach they're taking. I just want to make that clear. I know a lot of people see this and they get really scared. Oh, you know, my job as a developer is gone. But the thing is, you need to be a developer to really be able to use this tool effectively, to know what to ask for, to know how to review the code, and to fix all of those bugs that inevitably will come up when you use something like this. and they admit that which I think is great and they work in tandem with some of the other AI code editors like you could import this into cursor for example and debug some of the smaller components. Now in terms of how I generated the prompts blitzy actually has this GPT um I think it's literally called a GPT yeah in chat GPT that is the Blitzy prompt engineer. So what you can do is you can just go here. You can essentially say your kind of crappy version of the prompt which is like you know refactor everything and fix all of my TypeScript types and then it will generate a proper prompt for you. So actually let me show you how we do that. Okay. So you can see I put my you know crappy version of the prompts like refactor my codebase to make sure we're using the correct TypeScript types that we don't have any linting errors. All right. And then I'm going to go ahead and press enter. And then it will actually generate a much better version of this based on the best practices for prompting. And Blitzy also has a bunch of documentation you could go through on that in terms of talking about how to prompt properly, where to put the emphasis, things that you should include, things that you shouldn't include, etc. So, let's see the result that we get here. Okay, so you can see from that, you know, pretty crap prompt. I obviously should have given some more details here. It gave me this whole detailed prompt that goes over all the best practices on how you should prompt this model because you should spend actually a good amount of time here generating the prompt. Considering you're going to wait for a day, 3 days, you know, sometimes longer than that depending on how many files this is touching, you should spend a few minutes at least reviewing the prompt. Make sure that it specifies all of the correct context, all of the important information. So in this case it says you know you must do all of this. You must not do all of these things. Here's the technical approach on how to go about doing this. And then here are you know critical code areas that you want to avoid or be careful with. Here are protected areas blah blah blah. You get the idea. Okay. So obviously you would review this adjust it make sure that it makes sense for your codebase. But that's how I did this. When I generated the prompt I used this GPT which they provide. Now, the next thing that I did after I did all of the refactoring is, let me pull up this is I actually got it to make a new feature. So, again, this is another pull request, 13,000 lines that it modified, and I asked it to complete a feature that I never finished, which was my activity feed. So, essentially just a feed feature that showed what everyone was doing, what scores they got, what games they were playing, etc. in the app. Unfortunately, I can't run this for you because of some keys and issues, you know, with this being, you know, two years old essentially. But we can look at all of the files that it changed. And if we go here, you can see that it was working on the feed, working on the modules, on the notifications, registration. Makes sense because it needs to change quite a few things on the back end in order for this to actually work properly. Now, it also went ahead and made some code quality changes as it's specified in the PR. And you can see that it fixed some of the indentation levels and stuff for me. And if I didn't want it to do that, I could have specified, hey, you know, don't do that in the prompt. But obviously in my case, I didn't do that. So went through here, built the feed feature, and you can see all of the changes that it made mostly on the back end, which makes sense to me. Again, I don't want to go through this like super in-depth because it's not going to make sense to you considering this is not your codebase. But the point is that it's able to make a lot of changes. Okay. Now the last thing I did with Blitz Cy was I wanted to give this a real true test and see okay how many files can this actually change and this is where I asked it to essentially test my entire codebase. So again I use that GPT that you saw before. I asked it to do comprehensive test coverage essentially and then if we go here you can see that it changed 300 plus files which is actually a little bit laggy here in GitHub. It added all of the GitHub actions test flows for example. If we keep going through here, you can see that it created the test files for the back end, for the front end, test.tsx, welcome screen.t test.tsx, etc., etc. And then it actually made sure that all of these tests ran and worked properly. And there you go. Right? I mean, that's what it was able to do. Again, I can't scroll through all of this is literally 300 plus files. Anyways, the point is this was able to do a massive amount of code changes, which is kind of the last thing that I wanted to test with this tool. This particular one, I believe, took four days because it was touching a just massive amount of files. You can see it literally did 385 commits on this branch. Um, and then we were good to go. So, those are just a few examples of the use cases of this. Obviously, I did some simple stuff. I did some complex stuff. I wanted to test it out in different areas and see how it actually performed and worked. And then, if you go to build, obviously, there's some other stuff that you can do here, although I did cover most of it when I was testing this and for this video. Now, overall, this is extremely impressive to me, especially just the really deep context and understanding is very valuable. I mean, it's actually just interesting to read through the technical specification and see how you designed this, what architecture you used, all of these kind of visual diagrams, especially when you've been working on software for, you know, years at a time. And the fact that it can do that is something that I haven't seen pretty much any other AI tool be capable of. And this is really taking a different approach where it's, you know, be more methodical, think through the prompt, ask it something where you're going to expect that it takes 1 2 3 days to complete. And that means that you have to be a lot more careful in the way that you're prompting and a lot more precise. And then ultimately, you get a better result that is just significantly more work done. Similar to as if I had an engineer on my team and I said, "Hey, get this done." I would have to be specific in what I wanted them to do. They would go out and do it and then in a few days they would come back to me, right? and I would have the result. That's kind of the way that I view this tool. Anyways, this is super cool. Definitely recommend you guys check it out from the link in the description. With that said, I'm going to wrap up the video here. If you enjoyed, make sure to leave a like, subscribe, and I will see you in the next one. [Music]