Lesson 5: Building Forms & API Endpoints with AI đź“ť

Welcome to Week 3! Last week, you learned how to read data from the database and display it. This week, we're going to learn how to write data. This means building forms for users to input information and creating API endpoints to save that information to the database.

🔄 The full-stack flow: Form → API → Database

Creating a new piece of data in a web application involves a few steps that work together:
  1. The Form (Frontend): This is the user interface where a user types in the information. It's what they see and interact with in the browser.
  1. The API Endpoint (Backend): When the user submits the form, the browser sends that data to an API endpoint on the server. This endpoint's job is to receive the data, validate it, and then interact with the database.
  1. The Database (Backend): The API endpoint takes the data and tells the database to create a new record.
This week's tickets will have you building all three of these pieces. You're going full-stack!

🏗️ Building a form with AI assistance

Building forms used to be a tedious process. You had to write a lot of HTML and manage the state of each input field. With AI, you can do this much faster.

âś… Exercise 1: Prompting for a form

Let's say you're working on the frontend part of the "Create a New Post" feature. You need to build a form with a title input and a content textarea.
  1. Create a new file components/NewPostForm.tsx.
  1. Open the Codex panel and give it a detailed prompt:
      2. "In components/NewPostForm.tsx, create a React component for a new post form. It should have an input for the post title and a textarea for the post content. Use Tailwind CSS to style the form elements cleanly. Also include a submit button."
  1. Review the code. Codex should generate the full React component for you. Notice how it applies Tailwind utility classes to style the inputs and sets up the basic structure.
  1. Refine the prompt. Now you need to manage the state of the form. You can ask Codex:
      2. "Now, modify this component to use React's useState hook to manage the state of the title and content fields."
Codex will add the useState hooks and connect them to the Input and Textarea components. This is a huge time saver!

🔌 Building an API endpoint with AI

API endpoints are the backend logic that powers your application. In Next.js, you can create an API endpoint by simply creating a file called route.ts inside a folder in the app/api directory.

âś… Exercise 2: Prompting for an API endpoint

Now let's build the backend for our form. You're working on the API endpoint for the "Create a New Post" feature.
  1. Create a new file app/api/posts/route.ts.
  1. Give Codex a prompt to generate the basic structure:
      2. "In app/api/posts/route.ts, generate a Next.js API route handler for a POST request."
  1. Review the code. Codex will create the POST function for you. Now, you need to add the logic to it. You can do this with a series of more specific prompts:
      2. "Inside this POST function, first, get the body of the request."
      "Next, extract the userId from the request body. In our app, the client sends the logged-in user's ID when it submits the form."
      "Now, using Drizzle ORM, insert a new record into the posts table. The title, content, and authorId should all come from the request body you just parsed."
By breaking the problem down into smaller steps, you can guide Codex to build the entire API endpoint for you. You are still the director, planning out the steps and reviewing the code at each stage.
How to self-validate: After your form and API endpoint are built, run your app (pnpm run dev). Fill out your new form in the browser and click submit. Then, open your Neon database dashboard or look at the community page — if you see the new record appear, your full-stack flow works!

🔄 Adapting the pattern

You just built the Post form and API. But your ticket this week might be for Events or Resources instead. The pattern is identical — the only things that change are the field names, the database table, and the API route path.
When you start your ticket, try a prompt like this:
"I just built a form and API route for Posts. Now I need to build the same thing for Events. The Events table has fields for name, description, startTime, endTime, and location. Can you adapt the pattern?"
Note for Event features: If your ticket involves date or time fields, try this prompt: "What's the best way to handle <input type=\"datetime-local\"> in React and convert it to a format that Postgres accepts?"

♻️ Refreshing the data

You might notice a bug: after your form submits successfully, the page still shows the old data! You have to manually refresh the browser to see the new post.
The simplest fix is to tell Next.js to refresh the page data after a successful API response. Ask Codex:
"After my form submission succeeds, how do I call router.refresh() from next/navigation to update the page data without a full page reload?"
How to self-validate: Submit your form again. The new item should appear in the list within 1–2 seconds automatically!

🎟️ Your tickets for this week

This week, you'll be working on tickets that involve these "write operations":
  • Ticket #4: Build full-stack 'Create a New Post' feature
  • Ticket #5: Build full-stack 'Create a New Event' feature
  • Ticket #6: Build full-stack 'Create a New Resource' feature
Notice how every ticket this week is a full-stack feature. You will build the frontend form, the backend API endpoint, and connect them together. This is what it means to be a Full-Stack AI Engineer!

đź““ Before your standup: prompt reflection

You’re halfway through the BuildLab. By now, you’ve written dozens of prompts — some brilliant, some… not. Before your mid-week standup this week, take five minutes to look back at the prompts you wrote while working on your ticket.
  1. Find your best prompt from this week. The one where Codex delivered exactly what you needed, or where you felt most in control of the output. Screenshot it or write it down.
  1. Find your worst prompt from this week. The one that led to confusion, unexpected code, or something you had to throw away and redo. Screenshot that one too.
You’ll be sharing both at standup — not to be graded, but because your team will spot patterns together that make everyone better.
While you’re looking at them, sit with this for a second: What made the good one work? Was it the specificity? The context you gave? The constraints? And what was missing from the bad one? (Think back to the “directing vs. hoping” idea from Lesson 2.)
One more question to chew on: if you had used a completely different AI tool — ChatGPT, Cursor, Copilot, whatever — would your answers change? Would the good prompt still be good? Would the bad prompt still be bad?
Good luck with your second sprint! You’re moving from just reading code to actually creating new things. This is a big step, so don’t hesitate to lean on your teammates and your facilitator. You’re going to do great!