The way we code just changed You used to work on one thing at a time Finish it Move to the next thing Thats over Now you can launch multiple AI coding agents simultaneously each one building a different feature autodeploying test environments All while you review the work from your phone Youre not coding anymore Youre managing a team of AI developers The people who figure this out first will move at a completely different speed than everyone else

Today, I'll show you the ultimate vibe coding setup that lets you seamlessly code on your computer, launch multiple agents, and even pick up where you left off on your phone so that you can keep coding anywhere you go. I've been building tech for over 30 years and just earned over a million dollars with AI. In this video, I'll show you the most modern, productive coding environment using Cloud Code, which can also work from your mobile phone. So if you're looking for the most efficient coding workflow, this video is for you, let's get into it. So before we get started, you will have to have these free tools set up on your computer. They're just linking to the main install page. There's nothing crazy about these installations. So just go ahead and go through them. You don't have to have Visual Studio. It's basically a way where you can review the code. And then you'll need to set up these different accounts. You'll need Cloud and you'll need the ProPlus. You'll need a GitHub account. You're also gonna wanna set up SSH keys. To do that, you're just gonna go to your profile. You're gonna come down to settings and you're gonna go to SSH keys. And there's instructions on how to set up these keys here. And you're gonna wanna set up a Purcell account, okay? So we're gonna get started with just setting up our environment. And I'm gonna create a new SaaS from scratch to really demonstrate these different things. It's gonna be a very simple SaaS. It's more to demonstrate the development environment versus some flashy SaaS. So the first thing I'm gonna do is I'm gonna go to the terminal. I've already got something running here. I'm gonna open up another tab here. And if you're not familiar with the terminal, it's nothing to be scared of. It's just another way of accessing your computer and your files. So right now, if I do an LS, which is a way to list all the files, you can see here, I'm just in my main directory. You can see all the same files that I have here are the ones listed here. So I'm gonna go into development. And let's just make a new project. So we'll call it Cloud Code Demo. So this is our new project. This is the way a lot of SaaS projects will start, right? Like you have an idea, you sit down at your computer, you create a new project folder, you go into that folder. If you were in your Finder, it would be, I go to Steven G Pope and I go to development. It's right here, right? So this would be a normal way of starting a project. Now I could type Cloud right now and go in there and say, hey, build me a SaaS. However, a lot of times when you do that, it does initiate some of these initial commands and you don't even know it. So it'd be better if I just execute these as if Cloud was. It will also give me an opportunity to explain these two commands in a little bit more detail, which will help highlight why this is so cool. So this first command I'm gonna run here is nothing more than a command to create a Next.js project. The reason why Next.js is cool is because it's a framework that includes not only the client, but the server. So when you have a web application like School or Google Docs, there's a program that's running on your browser and it's talking to a backend server. A lot of times when people develop these applications, these web applications, they're developing these two things separately. Well, Next.js is convenient because it creates one framework and it takes care of the client code and the server code for you. So when you run a build, and I'll show you that, it creates a little client package, which it can send to the browser when the browser says, hey, if you go to school.com, then school is gonna send you this little package so that your browser can run. So we set up the site. Now, the next thing that we do here is we run a build. It's essentially doing what I was just saying there, right? So you've got the client and the server. And when we run this build here, it's building that client. It's actually taking all the code and it's creating the little packages when we run that build so that we can send it to the client. And then when we run npm dev, run dev, this is actually gonna run a test instance of this new application on our computer, okay? So if I come up here, we run this, we've got our Next.js site. So it's not a fancy landing page yet, but we have the beginnings of our SaaS application here, but it's running locally. So we have the cloud and in order for people on the internet to, you know, someone's at home here, in order for them to access our application, it has to be in the cloud. Right now, our application is running locally on our computer. So there's no way for this person to go into the cloud and then access it here. It's just not how the internet works. So we need to take the code that we're developing locally and actually deploy it into the cloud. And this is gonna give us a chance to talk about some more interesting things, okay? All right, so now I'm inside of Visual Studio and I'm inside of the folder that we just created. So here's our SaaS application. And here's the file. So if we wanted to access things, we could, but the next thing we need to do is if we want to actually deploy this, I'm gonna go ahead and create another tab here. So if I wanna deploy these things, I have to get them into the cloud. So this is where we're gonna start to talk about Vercel. So Vercel is a place where we can launch these Next.js applications in the cloud so that other people can access them. It's as simple as that. And the easiest way to deploy a project on Vercel is to commit it to Git, to GitHub. Vercel will work with GitHub and it will download the code and it will do these actions that we did here. Or we did an npm run build and then we did an npm run dev, right? So Vercel is gonna take that code from GitHub and I'm gonna show you how that works. And then it's gonna compile it and then launch it so people can view it. So I'm gonna go ahead and open up an additional terminal. And we talked a little bit about GitHub. I have it open here. So again, GitHub is a hosted version of Git. So Git is also running on my computer here locally. I asked you to install this. So I have Git running here. If I do a git status, interesting. So I'm just gonna do it real quick here. Hold on a second. It's interesting that it already seems to have set up Git. Let's pause here for a second to clear up any confusion. When Steven ran the git status command, he was surprised to see he was already on the main branch. He dug a little deeper and realized that the next .js installation process actually initializes a Git repo for you automatically. Pretty cool, right? Make directory test, cd test. So I'm in this empty directory here. If I were to do a git status, it's gonna say that there's no repository here. And I would have to turn this into a Git repository, taking the directory that we have, and it's creating all of the files that we need in order to manage those files and check them into a repository. And so GitHub is acting as our remote GitHub repository, but we also are running Git locally, right? So Git is running locally. It's also running in GitHub. I'm gonna show you this in just a second, but we're able to check in our code so that we're managing the code, right? So we're gonna make changes all the time, and we wanna be able to track all those changes. So that's what Git is gonna allow us to do. So we're gonna run this locally, and then we're also gonna be able to check that code in over here. That way, other developers or Cloud Code or other, or Vercel is gonna be able to deploy it. So they'll be able to communicate with GitHub to do all of the other work, okay? So other developers, Cloud Code, are all gonna be able to work with GitHub in the cloud, and then we are gonna work with it locally, and we'll be able to push our stuff. And so normally, in order to do that, we would do Git, and we would type in it, I believe. So that just initializes this empty directory to be a Git repository. Again, if I go back to do a Git status, there's nothing to commit. We have all of these files here, but nothing has actually been added. So first things first is we're gonna do a git add dot. It's just gonna add all the current files. If I do a git status again, it might've already committed all these files. So let's do a git log. So it already did an initial commit of all of these files here. So what I was gonna do here is I was gonna do a git add, and then I was gonna do a git commit. So git add stages them to be committed, and then when you commit them, it actually is like checking them into the code base, but it already did that for us. So now this Git repository only exists locally here on our computer. So we also need to have a place to actually push it to. So I'm gonna come up here. I'm gonna create a new repository, and then we'll go ahead and we'll call it the Cloud Code Demo. I'll go ahead and leave it public. We'll create the repository. And now this is the important part. My local Git repository for Cloud Code is not connected to this yet, okay? They're basically two separate repositories. So what we need to do is we need to connect our local to the remote. So we're gonna use this link here. We're gonna do a copy, and then I'm just going to add a remote origin. It's just a fancy way of saying we're gonna connect our local repository to a remote repository. We'll grab this again. Cool. So now we've connected it. So now if I do a git push origin, gotta run this command here, and it's asking for my passphrase for the SSH key. Now it pushed all these changes here. Awesome. So here's our Cloud Code Demo project now. It is checked in on GitHub. To be clear, if I were to make further changes here, like if I was to go into the README here, let me just make a change, change, right? I'm just gonna write that and I'm gonna save it. Now if I come back to Git here and I do a git status, it's gonna show me that a file has changed, right? So let's pretend I updated my homepage. So now we would be in a situation where we updated the homepage. Now I could do a git add, and I could type README. Again, it's gonna stage it for being committed, right? And then I could do a git commit updated README file. And then if I do a git push origin, it's gonna push that new change. So if I come back up here, the latest change has been updated README file. Perfect. And now other people can check this out, and then they can make changes to it, and they can update it, whether that's other developers or Cloud Code or whatever. And so now it also gives us the opportunity to deploy this code. So now we're gonna go over to Vercel, and I'm gonna show you the power of hooking these all together. So we're gonna add a new project. We're gonna type Cloud. Now it's not gonna show up. So I've linked Vercel with GitHub, but I'm only sharing specific repositories. So when I typed Cloud, it didn't show up. So we're gonna have to click that. And then we're gonna link this new project, scroll down, select repositories. Here's the demo. And now we can import this. And you gotta make sure you pick Next.js because this is what's going to tell Vercel what framework we're using so it knows how to deploy it. Now typically you might also have environment variables, but because our SaaS application is super simple, there are none. And now we can go ahead and deploy. So what we've done there is we've set up a connection between GitHub and Vercel. As stuff comes in here, Vercel will know that, and it will automatically come over, it'll grab it, and it'll deploy the site for us so that we can actually access it. And then beyond that, we can set up development environments, and then we'll be able to do all sorts of other cool stuff like branching. And I'm gonna show you all that in a second. But I wanna make sure you understand the fundamentals and why this is so cool. All right, so now we have our site, right? So continue to the dashboard. And now here's the public site. So now I could give you this URL and you could access it. You wouldn't be able to access the version that's running on my computer, wherever that is right here, localhost. Localhost means it's going to my computer. So now just to demonstrate, I'm gonna come to Cloud Code here, go to public. Oh wait, here it is. So we got our app page. So this looks like our homepage here. So if I come over here, so I'm on my local machine, right? So to get started, so if I come over here, I'm gonna change this to get started. If I just put like a, I'm gonna put an exclamation mark and then I'm gonna save it. So you can see the exclamation mark came. So when you make changes locally, it automatically restarts the site, which is kind of convenient. But if we look at the hosted version that's on Vercel, the exclamation mark is not there. And if we come back to GitHub here and we do a get status, you're gonna see another file has changed, right? So get, add, we'll just give it the exact file. Get commit. This is where you give a message, updated the homepage. Let me do a get push origin. And again, origin is that remote we added, right? So as soon as we did that, GitHub is now updated. And then you can see right here, pending, if we come over to Vercel, it's now building that change, updated the homepage. And then when it's done, we'll be good. And we can check it out. So let's take a look. All right, so now the exclamation is there. So even now we have a pretty powerful setup. So what we did there, we set up our local environment, we created the SAS site, then we created the repository, we connected the two, and then we connected Vercel to the repository. And now Vercel can just auto update as we make changes to the site, which is great. So now this is gonna be the production site. So something you might not know in GitHub, the main branch, it's the main branch. Like you might link main to production. There's other different configurations that you might have, but just imagine if you're running a SAS, you're gonna have a production where all your subscribers go, but then you and your developers or Cloud Code are gonna be developing in the backend. So you might want a development server where you guys can test and not interrupt the production users. So this is where things start to get really cool and it'll all start to make sense. So if we come to Vercel and we go to the settings, you can see down here in build and deployment, we've got some commands. Actually, I think the best one to look at is environments here. So we've got a production branch and it's connected to the main branch. But what we could also do is we could create another, like they call it staging. We could call it staging. People have different terms for things. So we don't necessarily need to use this. I'm gonna show you that in a second. A stage site to test new features. So we can create that environment and we'll come back here, no branch configuration. So really what we want, here we go. So branch tracking, we do need that on and we're gonna track the staging branch. So now one thing I'm gonna do is before I enable this, I'm gonna show you what I'm talking about. So if I come back to git here and I do a git status, you're gonna see we're on the main branch. So we're working on production essentially. So what we're gonna do instead is we're gonna create a new branch. So we're gonna do git branch staging. When you commit stuff into git, it's keeping track of things. So we had the first commit, that's from Next.js and then I made a change and I made a change. So git is tracking these changes. Right here, what we're doing is we're saying we're gonna take a branch. We're gonna branch off to staging and we're gonna do some development on the side here. While production continues unchanged, we're gonna do stuff on staging here and then when we're done, we're gonna merge it back with main. But in the meantime, we need another way of viewing our work. And so now we're gonna do a git checkout staging. Now we're actually switched to that branch. So if I do git status, see we're on branch staging now. So now if I make a change, in this case I'm gonna come back to Visual Studio and let's just revert the exclamation mark. Just put it back to a period. And then if I come back here, we're gonna do a git status. Notice we have a change, but on this time it's on the staging branch. So we'll do a git add, add it. Git commit fixed homepage. And then we'll do a git push origin, except this time we're pushing to staging. Cool. So now if we come back to GitHub here, if we look at the main branch, look, nothing changed. The last update was five minutes ago. If we switch to staging, so we're on a different branch now, we can see we just committed this change here. And so now if we jump back to Purcell and we do the branch tracking, the branches, staging, save it. So what we'll do here is we'll just commit something to staging again. I'm just gonna write staging like that, save it. Come back, I'm just gonna execute those same commands. And we'll push it to GitHub. So we're in staging now, fixed homepage. You can see it's pending. So it's now actually pushing the code for staging. So now if we come back to our builds deployments, we've got staging build here. And if we click into it, you're gonna see we actually have a different URL to access it. Okay, so we've got staging here running right now. And then we have our production. So you really get to start to see the power. Now we also have this preview here. So what this is gonna do is it's gonna create a new build for every commit, every new branch. So these are special branches for production and staging, but we're also gonna have this preview branch, which is gonna create a new build for really any commit on any branch so that as people are developing, as Cloud Code is developing, it's just gonna create a new build for every commit. So we're gonna have this preview branch, as Cloud Code is developing, it's just gonna create these new environments so that we can test them, right? Because if I'm building a feature locally, I might not even be ready to push it to staging yet. I wanna test it before I move it to staging, right? Typically what you do is you work locally, you fix it, you do whatever you need to do. Then you wanna deploy it, make sure it works on Vercel. So this is local. Then you wanna test it on Vercel, but not mess anything up. You don't wanna mess up staging. Other people are using staging as well. So you have this other deployment, which is just a build for your local. And then once that's good, then you push it to staging. And then when staging is good, then you push it to production. That's kind of a typical basic flow that people follow. So you'll see how these other branches work here in a second. So once you have your app deployed locally, it's running locally. We set up Git, we set up Vercel, we set up all the integrations. The typical pattern for developing your app would then be to come back to your terminal. We're in our Cloud Code folder here. Let me just clear everything out that's here. Just gonna make sure I'm, yeah, so I'm on the main branch. So I'm working on the production branch. The typical thing would be to open up Cloud and we're gonna start adding features, right? If we look at our local development here, this isn't really a great landing page. So we might start to update the landing page. I actually have a prompt here that we're gonna run. And so we would just start running our prompts right here. But what Cloud Code has done, they've given you the ability to develop code in the cloud. We can launch instances from our local and we can actually launch them in other places as well. Let me get to it. But we can actually launch background tasks and have Cloud Code work on them outside of our computer itself. Cloud Desktop allows you to run code from the cloud. So just as an example, I'm gonna come here to the terminal and we have this here. So let's just update the landing page. So if you type this ampersand here, you can basically type in a prompt, create that background task and have it start working. And then you can monitor it from the web, even your cell phone. And I'll show you that in just a second. Hey, it's me again. Let me explain this feature one more time because it's really powerful. When you put an ampersand before your prompt in Cloud Code, it sends that entire task to run in the cloud. This means the work happens in the background, completely separate from your local machine. So you can close your laptop, switch to something else, or even shut down your terminal entirely. And Cloud keeps working on your task. When you come back, you can pull up that session and see all the history, all the context and all the results from everything Claude did while you were away. So let's update homepage to, say, your first SaaS startup. Update homepage title. Okay, so if we run this, it's going to initiate this session here on the web. And so if you think about it, we could start a bunch of these. So if I was working on three or four or five different features, then we could just start them here and monitor them on the cloud. So if I come to my desktop tool here, notice we already have it running. So it's making that change in the cloud. And now I could come to my phone as well. If I open up Claude on my Android and we go to code, we can see it's running here as well. And it's already done, okay? So now from my phone, which is really cool, is you can see that it's actually made a commit, but it's pushed those changes to this repository here. If I were to actually just go to the web and we were to go to GitHub, I've got to get to Claude Code demo. You can see at the top there, just one minute ago, right here, Claude Code just pushed this here. So we're not even on our computer anymore. I'm on my phone just walking around. And so I can come in here and I can actually see that the commit has been pushed to GitHub. And what's also cool about that is that, again, remember the way we set up our dev environment, that also pushed a update to the web. So if I go to Vercel and I go to Claude Code demo, you can see this preview here. It was just created. And if we click on it, we can actually click into it and you can see we've got your first SaaS startup and it's live, okay? So we started it from our local computer. It did all the work, pushed it to Git, and then created a place where we can actually test it, which is really cool. And so if I wanted a more fancy webpage, I can just come back here to Claude Code. I've got this. And we'll start another background task. So that one's starting. So let's come back to my mobile and there's a few different ways you can access this. I'll show you. So now we've got the more complex landing page that we're building here. So you can imagine here, we could launch as many different feature requests as we want all at the same time. And then we could be out and about actually developing this stuff on our phone. Not only that, but it's committing these changes to GitHub automatically for us and then deploying so we can check it out, which is pretty cool. If we come back to Claude Desktop, and by the way, so you can access Claude Code like this in a few different ways. You can access it on Claude Desktop, which you've seen me do, Claude Mobile, and there's also this Claude AI. So there's a few different ways, but since we have the desktop app and the mobile app, they seem to be the easiest. But the other cool thing here is if I come back to Claude, this one's still working. This is a bigger prompt. It's building out an actual marketing landing page. But if we come here to the one that just updated the homepage, I'm gonna show you these two features here. First, I'm gonna show you the open in CLI. So remember, we started this process from our local Claude. But now, if there is some reason, let's say that something is happening here and for whatever reason, we wanna bring it back to Claude Code. We wanna work on it locally. So right here, you have this open in CLI. You come back to the terminal. If we come back here, we can just type in that command we got from here. So I just, again, I just grabbed that link from here and we can run that. It's basically gonna bring the session back. So it opens Claude Code back up. I've brought this back to local. So if I look at my local install again, notice that the title has changed to Your First SaaS Startup, which is what we started here. This is what we typed here, update homepage title to say your first startup. So you can basically ping pong these tasks from your local to the cloud, and you could have 10, 20 of these running at any given time. And then at any time you want, you can take Cloud Tasks. There's certain reasons why you need it. Then you can bring that back to your local and continue developing, which is really cool. So for instance, I think in this one, I said create a landing page. That's like blue and purple. I think that's what the original prompt said. But if I wanted to try out a few different ones, I could have launched several of these with different color configurations, just to test them all out at the same time and just speed it up. And here you're gonna see at the top, these are the commits that Cloud Code itself is creating. And then I'm gonna show you what a pull request is. So every time we start a background task, or every time you prompt it here, when it's done, I'll go to this one, when it's done, it's always gonna check this code into GitHub. And that's how we're able to basically switch our development environments around. Because when Cloud Code in the cloud finishes something, it's pushing that to GitHub. And then when my local needs it, it's able to just grab that specific branch. Let's see, where's this? Okay, it's just finishing up here. Okay, cool. So that means that this should be live. So if we come to GitHub, say 21 seconds ago, and then if we go to Vercel, deployments, here's the preview. So here's the nice landing page. But again, it's all on the cloud now. So people could access this. You could be on your phone, you could just load this up and it would work. But just so you know, what's kind of cool is that because it's committed here, if I'm in my local, there's just a few different ways. I'm just trying to show you how dynamic this is. There's a few different ways. So I could leave Cloud Code. I could go to Cloud Desktop, and I could reopen this in the CLI, and it's gonna bring me back here, just like we did before. So right now we're running this one, right? So if we come back here, I'm gonna run this here. So now locally, it moved right here. But keep in mind, if I were to exit out of Cloud Code and I were to just do a git fetch origin, which says, give me all of the recent check-ins to GitHub that we have had, okay? So it's gonna download all these locally. So this is just using a more traditional tool like Git, just gonna show you the possibilities here. So if I do git fetch origin, let's see here. Should have pulled down those recent branches. Cloud Code might have already done that. That's why it's not pulling anything down. So git branch, let's see what we got. Got it, so the reason why it's not showing up is just because Cloud Code, when it was kind of moving things around, when it was doing this stuff here and pulling down the recent branches using the OpenCLI teleport, this is what it's called, it's called teleporting. It already did what I just tried to do. But you see here, here are the different branches that we just created. So if I were to go here, this is the commit that just changed the title a little bit. So I could do a git checkout, and we'll do this one. Think this is the one, we'll check it out. Notice if I come back to the local, it changed. So what's really the difference between switching commits like I just did and using Cloud Code? Well, there is quite a bit of difference because this doesn't bring the context of what we're doing. If I use the OpenCLI here and teleport from the cloud instance to my local, it's bringing this whole context here of what we've been doing, and so it starts from there. Whereas if I just switch from git, it's not bringing any of this context. So it just brings all that context with you, so it's very powerful. Now, one other important thing that I want to talk about here is this concept of a pull request, create PR. That's what that's talking about. As you make commits, right? So we've been making these commits. I want to explain what the difference is. So we have these different commits from Cloud Code that are coming in as it builds out our different features, and it's committing that as a history to the GitHub repository. And Vercel is using these actual commits to build those previews. But in order for it to actually come into the mainline, if you remember earlier, we had the main branch and then we had the staging branch. None of these branches here, they're all just for testing. They don't do anything. If we actually want to bring them into staging, remember we talked about how a normal development environment might start on local. In this case, it might start in the cloud, not with Cloud Code. But then it ends up going to a test environment where we can just test that one branch, right? And that's these. And then typically it's going to go into at least the staging where it's kind of like the test environment where everybody can test. So if you're working by yourself, that's just you, but let's say you worked on a team, you worked on a bunch of features, then you're going to push them to staging. Everyone's going to test them there. And then when everything's okay, then you're going to move them to production. And in order to get these types of commits into staging or into your main branch, that's what we use pull requests for. So if we come back here, of course you can do this here, or again, I just want to highlight this. You can do this here as well. So you see down here at the bottom on my phone, we've got the create PR. But what that does is it creates a pull request. I guess the name just doesn't really do it justice, but all it's doing is it's taking that commit, that little branch we made, and it's pushing it into main or it's pushing it into staging. So you can imagine here, if I had all of my components here from this landing page and I pushed it into staging, we do a bunch of testing, then you can imagine we might create another pull request that goes from staging into main. But you can really see the power of Cloud Code and really just being able to launch multiple features, have them all running. You can test it all from your phone, commit everything, actually push it to production without even being on your computer. Or you can be working on things and when you get home, you can bring certain things back. So I think that the decision point where you decide, should I spend these off and working in the cloud or should I be working on these locally? On Cloud Code, you're gonna have a little bit more flexibility. So when you're working on something really important or very difficult where you have to put a lot of attention, then you're gonna be working in the terminal. If you're working on smaller bug fixes or features, it's gonna be very easy for you to spin up multiple features here and just develop them all at once. Now, if you want access to these resources and the new Vibe Coding course I'm building out in the NoCode Architects, make sure to jump into the community. I've got a course on making money with AI, a course on N8N with a bunch of cool templates and the Vibe Coding course I just told you about. I'd love to see it inside the community. Either way, I hope you enjoyed this video and I'll see you on the next one.