How I AI: A Beginner's Guide to Coding with AI—Build Your First Project Hub

"I’ve never coded. Where do I start with AI-assisted coding?" I get that question constantly, so I recorded the full process of going from an empty folder to a working local app, including the parts where the workflow failed and had to be reset.

In this episode of How I AI, I build in real time and keep the false starts in. A first attempt in v0 balloons into a much more complicated product than I asked for, complete with extra infrastructure and sandboxing features, so I stop the run and restart in Cursor with much tighter instructions.

The finished project is a small personal hub with one section for PRDs and notes and another for lightweight interactive prototypes. Everything runs locally. The workflow is intentionally simple: describe the project, let the coding agent scaffold files, run the app, inspect the results in a browser, fix problems, and commit working versions to Git so you can always roll changes back.

Starting with a PRD before touching code

I almost always start with a requirements document, even for tiny side projects. It gives the coding agent a target to aim at and makes it much easier to notice when the tool starts inventing features I never asked for.

Generating a lightweight product spec with ChatGPT

For this build, I wanted a very small hub for product work: one area for AI-generated docs and another for little coded prototypes. I opened ChatGPT and used a straightforward prompt describing two left-navigation items, Documents and Prototypes, plus a simple Next.js app that could display Markdown files and prototype pages.

Help me write a requirements document for a minimal personal project hub with two sections:

1. Documentation, PRDs, and ideas.

2. Small interactive prototypes.

The web app should have two navigation items on the left: Documents and Prototypes. Build it as a Next.js app that displays Markdown documents and small coded prototypes.

ChatGPT generated a usable PRD with goals, features, and constraints. The audience was basically one person: me. That sounds overly formal for a personal tool, but the document became a reference point for every later step. When the coding tools drifted away from the original scope, I had something concrete to compare against instead of relying on memory.

Why the first v0 prototype failed

My next move was to try a vibe-coding platform to generate the UI quickly. I picked v0 by Vercel because the interface quality is usually polished and exporting into a real editor later is straightforward. The plan was to get a visual starting point fast, then move into Cursor for the actual coding workflow.

This is where the workflow broke down. I pasted the PRD into v0 and it immediately started building far more than I wanted. It added file management systems, coding sandboxes, extra application layers, and all kinds of complexity that had nothing to do with my original "minimal simple hub" idea. The output looked polished, but it was solving a much larger problem than the one I actually had.

The more an AI coding tool tries to build an application end to end, the more scope it may invent. v0 produced a polished-looking result, but it was not the minimal hub I had specified.

After about 10 minutes, I stopped the v0 build entirely. That was still useful. It clarified an important tradeoff with newer AI coding tools: the more end-to-end autonomy they have, the more likely they are to invent product scope on your behalf. For this project, I needed fewer abstractions and much tighter control.

Building the app directly inside Cursor

I restarted from scratch inside an empty Cursor folder. No starter repo, no generated UI kit, just a blank directory. That made the scope visible again and let me ask the agent to explain each setup step as it worked.

Creating the local project environment

The setup was intentionally minimal so beginners could follow it without needing prior coding experience:

1. Create a new, empty folder on your computer. I named mine cvo.
2. Open the empty folder in Cursor so the editor has a completely clean workspace to scaffold into.
3. Open Cursor’s Agents view. At the time of recording, that interface kept the instructions and generated file tree visible at the same time, which made it easier to understand what the agent was creating.

Using Composer One to scaffold the app

I pasted the PRD into Cursor and asked it to build the app from scratch while also explaining the setup process. At the time of recording, I used Composer One because the project was small and the model responded extremely quickly. The exact model matters less than the capability set. You want a coding model that can edit the repository, install dependencies, and run terminal commands.

I want a very simple next JS app set up where I can keep a repository of markdown docs, PRDs, and. Code in different directories, little, um, prototypes that will be displayed in the app
Here is A PRD, but keep it super basic. We're starting from scratch. So give me all, all the steps I need to set up and run this.

The agent scaffolded a Next.js application, installed Tailwind CSS and other dependencies, created the folder structure, and generated the first pages. Compared with the earlier v0 attempt, this version stayed much closer to the original brief: two sections, simple routing, and a local-first workflow.

Running the app and checking the result

Generated files are not the finish line. They are just the first checkpoint. Once the code existed, I asked the agent how to actually run the app locally.

Cool, but how do I run this?

It returned the exact command needed for Cursor’s built-in terminal, including the standard Next.js development server setup.

npm run dev

The local app opened with working Documents and Prototypes sections plus a very basic interface. That browser pass matters because it shifts the workflow out of abstract code generation and into product judgment. I could immediately see what was too complicated, what was missing, and what needed refinement. For the complete setup, follow the workflow for building your first local web app from scratch with Cursor AI.

Adding version control before larger edits

Before making bigger changes, I initialized version control with GitHub Desktop. For beginners, the visual interface is much easier to understand than learning Git commands in a terminal on day one. You can see changed files, review diffs, and revert mistakes without memorizing syntax.

1. Open GitHub Desktop and add the local project folder as a repository so changes can be tracked from the start.
2. Review the generated files carefully, exclude secrets such as .env files or API keys, and create an initial commit that captures the first working state of the app.
3. Publish the repository to GitHub if you want a remote backup or plan to continue iterating across machines. For personal projects and internal notes, a private repository is usually the safer default.

Once AI tools start making larger edits, reversible history becomes essential. A good commit history lets you experiment aggressively without worrying that one bad generation will destroy the working version.

Creating reusable PRD instructions inside the repo

Once the app was running, I added a repeatable documentation workflow. The goal was not just to generate one PRD. I wanted reusable instructions stored directly in the repository so Cursor could create future docs in a consistent format.

Defining a custom PRD-writing agent

I created a new folder in my project called agents and inside it, a new file named prd.md. This Markdown file would contain the instructions for my PRD-writing AI agent. I then asked Cursor to write the instructions for me:

Can you fill out @prd.md. This is a blank file to be agent instructions to write a great PRD in the @docs folder. PRDs should be in markdown and the instructions should be less than 500 lines long for our AI agent to follow.

I created an agents folder and added a prd.md instruction file. Cursor generated a structured template with a role definition, core principles, PRD sections, and a checklist. I then edited the instructions to focus more on technical implementation details and less on executive summaries or corporate planning language because this repository was for fast experiments, not stakeholder reviews.

Generating a PRD from the reusable instructions

With the instructions saved in prd.md, I referenced that file in a new request asking Cursor to create a neighborhood task scheduler PRD. The idea was intentionally simple: a lightweight scheduling tool for neighborhood chores like weeding, sweeping driveways, or taking out trash cans.

Great. Now write me a PRD for a little scheduling app where my kid can have our neighbors schedule help with weeding, taking out trash cans and sweeping their driveways.

Cursor used the instructions to generate neighborhood-task-scheduler-prd.md directly inside the docs folder. After refreshing the local app, the new document appeared automatically in the Documents section. The first draft was functional but noticeably too long, which immediately exposed a useful improvement opportunity for the instruction file itself.

The reusable document-agent workflow shows how to keep those instructions in the repository, invoke them for new documents, and tighten them whenever the output drifts.

Turning the PRD into a clickable prototype

With the documentation workflow working, I moved to the second half of the hub: prototypes. Instead of building a production-ready app, I used the scheduler PRD as the basis for a lightweight clickable interface that demonstrated the interaction flow.

Generating the first prototype

Still inside Cursor, I asked the agent to use the PRD to create a simple prototype in the prototypes folder that was clickable but intentionally incomplete.

Great. Use this PRD to create a prototype. Clickable, but does not have to be totally functional, with database, etc. In the prototypes folder. So that I can show a little of how this might work.

I explicitly told Cursor not to add a database, real authentication, or full backend functionality. That constraint mattered. Without it, the tool would likely start scaffolding infrastructure instead of focusing on the interface and interaction model I actually wanted to evaluate.

Fixing issues through screenshots and iteration

After refreshing the app, the new Task Scheduler prototype appeared with a simulated sign-in screen and task dashboard. There was no real authentication or persistence behind it. It was just enough UI to click through the experience. One issue was immediately obvious though: the form fields had low-contrast gray text that was hard to read, so I dragged a screenshot directly into Cursor and asked it to fix the styling.

It seems like the fields have gray text. Please fix.

Cursor patched the CSS and regenerated the interface. Using a fake email address in the simulated login flow led to a working dashboard for creating and viewing tasks. It still was not production software, but it was more than enough to evaluate whether the interaction itself made sense.

Making it "prettier and cuter"

The final pass was almost entirely aesthetic. The homepage looked extremely plain, so I gave Cursor a deliberately vague instruction to make it prettier and cuter. No design system. No component specifications. Just a lightweight visual direction.

I don't like the baseline design of the home page of this app. Please uplevel the design to be prettier and cuter. Rename it to 'CVO Personal Hub' and make it less basic.

The result added gradients, warmer typography, and a friendlier feel. The visual iteration workflow captures the same screenshot-and-revise loop. I committed the changes, updated the README, and left the project intentionally small; a useful prototype does not need production infrastructure on day one.

A practical first AI coding project

The project started with an empty folder and ended with a working local hub for documents and prototypes. Along the way, I generated a PRD, abandoned an overbuilt v0 attempt, scaffolded a Next.js app in Cursor, ran the app locally, added Git version control, created reusable AI instructions, generated new documents from those instructions, and fixed UI issues from screenshots.

A low-stakes personal project is one of the best ways to learn AI-assisted coding because the feedback loop is immediate and the consequences are small. Keep the first version local, inspect generated edits before accepting them, avoid committing secrets, and remember that production software still requires human review around authentication, data storage, testing, and security.

The most useful part of this workflow is not the generated code itself. It is the discipline of keeping scope small and forcing the agent to stay inside clear boundaries. This approach works especially well for PMs, designers, and non-engineers who want to learn the mechanics of AI coding without immediately managing cloud infrastructure or backend systems. What still requires human judgment is deciding what the product should actually do, when the AI is overcomplicating things, and when a prototype is good enough to stop.