Build a todos app with login

We build a todos app with email and password sign in, where everyone's list updates live, by describing it to the agent in the VS Code chat. Then we look at what the agent built: the users table in the database and the tests. ## What you need VS Code and Elements installed, and a new app running. [Install VS Code and Elements](/learn/install-vs-code-and-elements-gqvihvas) covers both. ### 1. Describe the app Type into the chat on the right the way you would say it out loud. You don't need a spec. The agent already follows the architecture and guidelines that come with Elements. We typed: ```text Agent I want to create a todos app with authentication. It should have email and password, multiple users, and anybody can see todos update in real time. ``` Press Enter. ### 2. Watch the agent work The agent looks over the app, reads the manual pages it needs, and starts writing code. The page in the browser panel updates as it goes. Keep an eye on **State** in the terminal panel. When it changes to **Error**, the build found a mistake. The agent gets the error as soon as it asks and corrects it, and the state goes back to **Ok**. Ok means your app is in a good state. ### 3. Read what the agent built When the agent finishes, it summarizes what it made. Ours had: - **Accounts:** sign up and sign in pages with email and password. Passwords are stored as bcrypt hashes. - **Todos:** one shared list. Each row shows the email of the person who added it. - **Permissions:** only the owner of a todo can check it, star it, rename it or delete it. The server enforces this, not only the page. - **Live updates:** changes appear in every open tab without a reload. - **Extras:** All, Active and Done filters, a Clear done button and a sign out button. Sign in, the user tables and the todos all live in your app's own Postgres database. No third-party service is involved. Open the app in a full browser at [localhost:4000](http://localhost:4000) to click around and try it. ### 4. Look at the database You never need to do this, because the agent handles it. It is there when you want it. Press `q` in the terminal to stop the app server, then type: ```bash Terminal elements db ``` This opens a Postgres shell on your app's database. The `users` table has columns for the email and the password hash. Type `\q` to leave. ### 5. Run the tests The agent wrote tests along with the app. Type: ```bash Terminal elements test ``` Each test shows pass or fail on the right, and the elapsed time is in microseconds. The agent runs them as it builds, so it can tell when a new feature breaks something you built weeks ago. Press `q` to exit. Type `elements start` to start the app server again. ### 6. Come back to your app Quitting VS Code stops the app server. The project server for your app keeps running in the background for a while, so the build state is ready the next time you start. To open the app again: 1. In VS Code, choose **File**, **Open Recent** and pick your project. Projects live in `~/elements/projects/<name>`. 2. If the terminal panel is not open, press Ctrl-backtick, or choose **Terminal**, **New Terminal**. 3. Type `elements start`. The app opens in the browser panel. A new chat session picks up where the last agent left off.

Next up, let's build a todos app in in Elements, and I know that there's a lot of todos apps out there, but it is a bit of a rite of passage to be able to build one. So that's what we're going to do. And also it shows off a bunch of different features very quickly. So we're going to build a todos app that has authentication so that a user can log in with a username and password, an email and a password, and the todos are going to be real time.

That means that anyone who's connected to the browser to the to the list will see it update in real time as it changes. The way we're going to do that is in our chat window, we just talk normally to the agent and ask it to do various things. Now, you might be familiar if you're coming from another vibe coding platform with having to put together very complicated spec sheets and all that. You don't really need to do that with Elements.

You can just start talking. The agent will already have a lot of guardrails that are built for it and architectural guidelines that are built for it through the Elements tooling and the framework. So I would recommend just start typing.

I want to create a todos app with authentication. It should have email and password, multiple users, and anybody can see todos update in real time. You can talk just plainly like this and press enter. The agent will get to work and it will start to analyze the application, take a look at Elements, read some manual pages that it needs to to get started, and it will start writing code.

It shouldn't take more than a minute or so before you start seeing the user interface updated in real time right here in the browser. If you notice in the lower left, every once in a while that state will change to error, and that means that the agent made a mistake and Elements is correcting it. The errors are sent to the agent in real time in microseconds as soon as it asks, and it will begin to correct those errors and you'll see that state go back to OK. And when it's OK, it means your application is in an OK state.

Great, we're back in an OK state and we're starting to see a user interface come to life in the browser. The agent is claiming that it's done and it's giving me an overview of what it's done. It built a todos app with email and password sign-in. It's running at localhost:4000, which we can already see here, and it gives us a little bit of an overview of the features that it has.

It has accounts with a sign up and sign-in URL. Todos that everybody can see at once, permissions. Only the owner of a todo can check it or star it, rename it. It has live updates so everybody sees everything that's changed all at once and a few extras so you can filter by looking at all active or done.

There's an awful lot of features baked into this, and one of the things you should keep in mind is that it doesn't require any third party services to make this work. The authentication, the user tables, all of that is in your own database running in Postgres. Now on your own application you can open this up in a big browser if you'd like and click around and make sure everything works, but in the rest of this video, let me just show you around a couple of things that the agent did under the hood that you did not see. You've seen the OK error state change that's Elements providing guidance.

If you press Q in this terminal. There's a couple other commands I'd like to show you. One is that you have a database that's running locally. So if you type elements db, that will drop you into a Postgres shell where you can take a look at the tables that you have.

For example, we have a users table here and you can see that it has. Let's look at it in a slightly better view here. You can see that it has fields for an email and a password hash. Now you don't have to do any of these advanced things, by the way.

You can just talk to your editor or you can just talk to your agent, and the agent will do everything for you. But I want you to know that these exist. So if you ever want to drop down and work directly with Elements, get into the database, look at the tables, you can do that, and you don't need a third party service for it. I'm gonna do a backslash q to get out of the database and then I want to show you one more thing, which is elements test. When the agent wrote your application, it's going to create tests. In this case, not too many. It looks like there's three, four, five assertions, uh, really three tests here.

Um, and you'll see a very quick pass fail over on the right-hand side. And tests are very, very fast to query. And if you look up in the elapsed time here, uh, I might get my order of magnitude wrong, but that looks to me like 26 microseconds to get a response and see that all the tests are passing. And as you work on the application, you create more and more features, tests help us to know whether or not the application has regressed over time.

And an agent needs to be able to check that very, very quickly so we can see whether when it built something new, did it break something that you had built a couple of days ago or weeks or months ago. So it's much more likely that you're going to get an application that works and continues to work over time because of these, uh, these very, very fast tests that the agent will absolutely utilize. All right, now I'm going to press Q again to exit out of this. And remember, when you open up your application after having quit VS Code, you can just type elements start and that will boot up your app server again and then you can click around and play with the application in the browser.

Now, if you exit out of Visual Studio Code, that will close the application server and close down your application for the day, but the project server for your project and Elements will continue to run in the background for a little while. And so that way when you go back and you start start up the application again, it'll be very fast and all the build state will be available immediately. If you open up Visual Studio Code, you can open up the folder or open up recent, and you'll find your project in the recent folder list there.

Or if you want to open up the folder specifically, just go to Elements, your home folder, elements, projects, and then find the name of the project there. I'll click this in the recent menu. That will bring up the Visual Studio Code, uh, panels and you'll see a bunch of errors because we have not started the application yet.

Down in the bottom, if you don't see this terminal, uh, panel open, you can, you can press control back tick on Mac or use the terminal menu and say new terminal, and that will bring up a terminal menu. And then type elements start. That's how we always start our application for the day. And when you do that, that will bring up the application immediately in the upper panel in Visual Studio Code.

Over in the right, even if you're starting with a brand new agent and it's a brand new session, it will be able to figure out Elements right away and and left off. It will be able to continue where the last agent left off, no problem. So working with an Elements application is really, really easy and fun, and over time you can continue to build really sophisticated applications without worrying that the old one is, is breaking. The main thing to look at is the state. If it's OK, everything is good, and if it's red error, it means there's an error, and there's something for the agent or for you to fix. And the agent will get those build states automatically, very, very quickly, and it will correct itself as it builds. So I hope this gave you a quick overview of using Visual Studio Code with Elements.

Again, Elements can be used with any editor, uh, but we have some things that make it nice to to use some integrations with the Visual Studio Code that make it particularly nice. I like Visual Studio Code. I'm an old school, uh, uh, code editor and I like to be able to open up the file explorer and see the files there and and edit them myself if I want to.

I think it has a very nice ability to open up terminal windows and it has the nice chat over here on the right. And you can also, you can use a very generous free tier with GitHub Copilot, which is also quite nice. So I will oscillate in our videos between using Visual Studio Code and using other editors and AI harnesses like Claude Code Desktop, but I think VS Code is a really good option.