Design, structure, and refine an app fast - Replit Tutorial

Let's say that the manager of an IT department at a local company comes to you and say that they need to develop a centralized solution for team members to submit their IT development requests. It needs to have transparency into the backlog so that the people who submit the tickets can see the status of each request that went in. Usually, that ends up going into a black hole. Now, in traditional software development, it can often take us weeks to get to a working prototype. But with Vibe Coding, we can develop a working demo in just a few minutes. We have our use case. Now let's jump into seeing what that design process looks like. We're going to go into Replic, and I'm going to enter in my prompt. When I mention my prompt, it really is just an instruction to tell Replic what I want the agent to design for me. I'm just going to go in in a conversational way and say, develop a solution to track IT development requests. Users need to be able to see the status of each ticket in a dashboard. I'm going to hit Start Designing. In the background now, what's happening is the Repl.it agent is acting as my code assistant. It's doing all of the work to start thinking about how is it going to now take my prompt or my instruction and really translate that now into an application. On the left side of the screen here, we can track the status of what the agent is doing every step of the way. We can see that it is configuring the starting of the application, and now it's mapping out those implementation steps. I get to just sit back now and watch the agent as it starts to code the design. We can see that the agent is continuing to work. It's letting us know on the side of the screen that it's creating library stores and it's editing the client source application right now. You can stay and watch the agent do its work, or you can go off and start doing other work. So this is the first iteration of the board. I was quite deliberate that I didn't tell it any color or aesthetic designs. I didn't choose white background, black font. I didn't do any of that. I just let the agent do its own building and this is what it's come up with in the first iteration. Now, the thing about vibe coding is it is iterative. So we don't expect that the first design that we come back with is the one that we're going to use. So here, I can just go through my board and see, did it understand the intent of my prompt? Did it get it right? So let's take a look. We can see that the agent is smart enough that it knows this is the first build, and it's gone and created some sample data for us, so that we can see what this sample dashboard looks like. So I've got six total tickets, It's got my statuses here. I've got two in progress. Two are in my backlog, meaning I haven't started work on them yet, and one is completed. Let's see if it's created the form. Yeah, I've got a button here that says new requests. If I click on that, I can see that this is what the end user is going to go in. They will create this form, which basically means they want IT to work on developing some type of IT solution for them. I've got a title, a type, a priority, and a description, and then there's an assignee. This looks good for a first start, but I'm going to want to iterate on this design because the form did not capture the name of the person who's submitting the form, so I might want to go back and add that. I might also want to make a change because I noticed that I didn't request that any of these form fields were required. If they're not required, As it turns out, when users start submitting these forms, if this goes to production, I'm going to end up with a hodgepodge of information and half of the information that I need to design. It's just not going to be there. I'm going to go back over here into the bottom left-hand side, and I'm going to give another instruction that says, make all fields required, and add fields for the user first and last name. I'm just going to hit the blue button for enter and the agent will understand my request or attempt to interpret my request, and it's going to start building now and start making the updates that I've asked it to do. As we saw before on the left-hand side, if you can read really quickly, it is fast. it's going through all of the code to make the changes that I've requested. We can see on the left here, it's adding the first and last name to the store for the ticket and it's adding fields for the requester's last name. You can also see it's told itself, wait, make all fields required. It's catching itself as it's going through this coding process to say, wait a minute, I need to do this. let me make sure that I do it. So it's continuing to work here. When it's done, the screen will refresh and we'll be able to see, did it understand the intent of our request and did it get it right? So here's the development board. The development board looks the same as it did before, but what we asked it to do was make some changes on the form request. So we can see here that I now have a requester, first name and a requester last name. I can't tell though in a very obvious way whether or not it's made these fields required. I might go back here and say, add a designation to show the user that all fields are required. We can test that later to make sure that the form does not get submitted unless all fields are populated. Again, it's the same thing that's happening. The agent is working in the background. It's making the changes that I've asked for. It's taking a look to see how many fields there are. It's also telling us that it's going to add a small helper or just in line with an asterisk. so we can see the thought process that it's going through as it's making the changes. And then very, very quickly, the changes are made. Let's see. So now I can see this makes more sense when I'm thinking about user design. I wanna make it really obvious to the person who is submitting this form that these fields are required. So this is really great. I'm pleased with where this is as of right now. There's one thing though, when users submit their tickets, they often want to know that it's been received. So let's go back and let's ask the agent to create a confirmation message so that the user knows that this has been submitted accurately. So I'm just going to message the agent and say, create a submission confirmation message when the form is submitted. Again, I'm going to hit Enter, and then sit back and let the agent do all of the work. This is really cool when you revive coding, because oftentimes we have the initial use case from the business user, but we don't have to spend hours and hours and sometimes days, going and then refining and creating technical requirements. Even when we spend that time, sometimes we miss something. This is really neat. It allows me to look at my working prototype, identify what I've missed, and make the changes right then and there. It's not taking me days, it's not taking me hours, this is literally taking minutes. Another thing about Repl.it is, it's going to build the solution for you, but there will be certain places in the code where it's going to create these recovery points, if you will. That's what we see on the screen here. It's going to create a spot where if we wanted to roll back the changes we can and we're not going all the way back to when we started developing the solution, We're just going back to right here. This is a neat feature that doesn't make us have to start all over again from the beginning. Let's have a look and see. We've got the form. We actually cannot see whether or not this works, unless we test it out for ourselves. At this point, I want to test the application and make sure that it works. I want to make sure that we can test the form, see if the fields are required, and if the ticket is not created, if any of these fields are missing. I could go through and do that myself by entering all of these fields, going through the tests, but Repl.it will do that for us. So let's get into that next.