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:

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.
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.
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.

Give Codex a prompt that includes where the file should live:

"Create a new file at components/NewPostForm.tsx with 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."

Check your file tree. Find the new file in components/ in the left-hand sidebar. Components live in their own folder to keep things organized — you’ll be creating more files here as the program goes on.
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.
Refine the prompt. Now you need to manage the state of the form. You can ask Codex:

"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.

Let’s have Codex create the file for us. Like you did in Exercise 1, give it a prompt that’s specific about where the file should go:

"Create a new file at app/api/posts/route.ts and generate a Next.js API route handler for a POST request."

Check your file tree. Before moving on, look at the left-hand sidebar in VS Code. Can you find the new file Codex just created? It should be nested inside app/api/posts/. That folder structure matters — in Next.js, the folder path becomes the URL path, so this endpoint will be accessible at /api/posts in your browser.
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:

"Inside this POST function, first, get the body of the request."

"Next, extract the authorId 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 you commit: Review and Refine!

Every prompt should be part of the, "prompt, review, and refine" cycle we covered in Lesson 2. Additionally, each commit should be preceded by a birds-eye-view code review and, if necessary, refinement and refactor step.

So, before you commit, make sure to do the following:

📖 Review the code for correctness, maintainability, and readability. Do variable and function names make sense? Why did the AI coding companion insert a null check at a particular point in the logic flow, and does it handle the null case in the way you'd expect?
🧪 Run and test your code, including edge cases. Try weird inputs, empty states, and anything a real user might break.
🔍 Trace the logic end-to-end. Follow the data through the code to confirm that nothing slips by or gets missed.
🧹Simplify where you can. If something feels overly clever or complex, make it easier to read and maintain. You can do this by hand, or with the help of AI.
🧭 Make sure it solves the right problem. Double check that the code actually matches the original goal. Look at your ticket again and step through each of the acceptance criteria, verifying that they've been addressed.

📓 Before your standup: prompt reflection

You’re halfway through the BuildLab! By now, you’ve written dozens of prompts. Before your mid-week standup this week, look back at the prompts you wrote while working on your ticket.

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 copy it somewhere to share later.
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, consider: 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…say ChatGPT, Cursor, Copilot, etc., 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!