Day 1

Dev environment and Claude Code fundamentals

You ship
A Next.js project scaffolded with Claude Code, and the PR loop run to 10 an hour.

What you'll build today

Every day of this course ends with working software in production, so the first day builds the road that software travels on. You start with an empty repository. By the evening, a change you describe to a coding agent can travel from a branch to a reviewed pull request to a live website in a few minutes.

You install the tools you will use every day: Ghostty, a terminal where several agents can run side by side, Claude Code, Cursor, GitHub and Vercel. Then you scaffold WorkBot, the product you build across all 40 days. You put automated checks in place before the first feature, so every later change is held to the same standard. Finally you ship small features through the loop and time it, because the speed of this loop sets the pace of every day that follows.

At the end of the day the repository builds, CI checks every pull request, every merge to main deploys to production, and you know how long one loop takes.

Every day's steps were written alongside a reference run of the course. Its file names and numbers appear as examples, marked "in the reference run", and yours will differ.

By the end of the day you can

  • Set up an AI development environment: Ghostty, Claude Code, Cursor, GitHub and Vercel
  • Run the full development loop: code, pull request, review, deploy
  • Work toward 10 merged pull requests an hour on small features

Topics

Ghostty Setup

  • Installing Ghostty, a fast native terminal for macOS and Linux that draws with the GPU
  • Tabs and windows: one per project, so you can switch between codebases
  • Split panes: split a tab right, down, left or up, and zoom one split to fill the tab
  • Notifications: an agent in a pane you are not watching can send a desktop notification, through the OSC 9 or OSC 777 escape codes. Ghostty also bounces the dock icon and marks the tab title with a bell
  • Configuration as a file: ~/.config/ghostty/config.ghostty, with keybinds for splits and tabs. Reload it with cmd+shift+,

Claude Code Fundamentals

  • Installation and authentication
  • CLAUDE.md: what it is, why it matters, and how to write your first one for a project
  • Permission modes: what Claude Code asks before it acts, and how to change that
  • Basic commands: prompting, accepting or rejecting edits, interrupting, and going back through history
  • How Claude Code reads and edits your code
  • Codex CLI and OpenCode work the same way (Day 21): instruction files, permissions and MCP (Model Context Protocol) servers. Claude Code is the first one you learn

IDE Setup

  • Cursor installation and configuration
  • Extensions: ESLint and Prettier, so the editor shows the problems your checks will report

GitHub Workflow

  • Branches: one per feature, merged into main
  • Pull requests from the command line, with gh
  • Review with an AI reviewer before you merge
  • The Codex plugin for Claude Code: /codex:review for a standard review, and /codex:adversarial-review to challenge design decisions and assumptions

Vercel Setup

  • Account creation and project linking
  • Deploy flow: push a branch, get a preview deployment, merge, and production updates
  • GitHub integration: a deployment on every push

Build

Features shipped today

  • WorkBot: The web app scaffolded from the template, and its first small features (a landing page, a settings page and a health endpoint) shipped through the pull request loop

Scaffold a Next.js TypeScript project with Claude Code. Then run the loop again and again:

  1. Create a feature branch
  2. Build a small feature with Claude Code
  3. Open a pull request
  4. Review it with Codex
  5. Merge, and Vercel deploys it

Time each loop and work toward 10 pull requests an hour. Keep each feature small so the loop stays fast: a component, an API route, a page.

Step by step

Install and sign in

Everything later in the course runs through these tools, so set them up once and check that each one works before you write any code.

Study first

  • Claude Code's memory page, which explains CLAUDE.md and AGENTS.md, and its permission modes. You should be able to say what the default mode asks you to approve, and what acceptEdits changes.
  • Ghostty's tabs, splits and configuration file. From Day 4 you run several agents at once, one per split, so the layout matters early.

Build

  1. Install Ghostty, Claude Code and Cursor. Sign in to Claude Code, sign in to GitHub with gh auth login, and create a Vercel account linked to the same GitHub account.
  2. In Claude Code, add the Codex plugin with /plugin marketplace add openai/codex-plugin-cc and /plugin install codex@openai-codex, then run /codex:setup. The plugin needs a ChatGPT account or an OpenAI API key.
  3. On the setup page, create your training repository from the template and enter its name, so the course can read it when you verify a day. Then clone it.
  4. Open the clone in a Ghostty tab with two splits, Claude Code in one and a shell in the other. Open the same folder in Cursor with the ESLint and Prettier extensions, so the editor shows the problems your checks will report.

Done when

  • claude starts inside the clone, and gh auth status names the right account.
  • Cursor flags an unused variable in a file you open.
Technical notes
  • At the start of every session, Claude Code loads CLAUDE.md, or AGENTS.md in its place, from the working directory up to the repository root, so one file is enough. The reference run keeps its conventions in AGENTS.md, which Codex reads too, and its CLAUDE.md holds a single line, @AGENTS.md.
  • In the default permission mode, Claude Code asks before it runs a shell command or writes a file, but not before it reads one. acceptEdits stops the prompts for file edits and keeps them for commands. Switch to it once pnpm check exists, because from then on the check catches a bad edit for you.
  • Ghostty reads ~/.config/ghostty/config.ghostty, or config before version 1.2.3. Two keybinds, new split right and new split down, cover everything the course needs.

Scaffold the app and its checks

With the tools in place, you create WorkBot itself. The checks come before any feature: once CI runs them on every pull request, nothing reaches main unchecked, whether you or an agent wrote it.

Study first

  • The App Router's file conventions, on the project structure page. A folder under src/app is a route, page.tsx is its page, route.ts is an API endpoint, and layout.tsx wraps its children.
  • shadcn/ui, whose components are generated into src/components/ui/ and become part of your own code. The library is a command-line tool and a registry, not a runtime dependency.

Build

  1. Ask Claude Code for a Next.js scaffold in the clone, with TypeScript, Tailwind and the src/ directory. Then run pnpm dlx shadcn@latest init and pnpm dlx shadcn@latest add button card, yourself or through Claude, and commit the scaffold on its own.
  2. Add a check script that runs ESLint, Prettier, tsc and next build, and a GitHub Actions workflow that runs it on pushes to main and on pull requests.
  3. Write AGENTS.md, under a page long. Say what the project is, list the commands, and set out the conventions every change must follow: where files go, Server Components by default, and one module that reads process.env. A Server Component renders on the server and sends no JavaScript to the browser.
  4. Import the repository on Vercel. From now on every push deploys, as a preview for a branch and to production for main.

Done when

  • pnpm check passes on your machine, and the GitHub Actions run for your push is green.
  • The production URL on Vercel serves the page.
pnpm check passing
pnpm check runs ESLint with no warnings allowed, Prettier, next typegen with tsc, then a production build. CI runs the same command.
Technical notes
  • create-next-app 16 stops when the folder already holds a README.md, with "The directory contains files that could conflict". Move the template's README aside, scaffold, then write your own.
  • The scaffold turns on Cache Components, the Next.js 16 rendering model. A page then prerenders a static shell, and a component that reads request-time or uncached data must sit inside Suspense, where it streams in when the request arrives. Nothing on Day 1 reads such data, but leave the setting on so later days do not have to switch rendering models.
  • eslint --max-warnings 0 makes any new warning fail CI, so the count stays at zero instead of growing.
  • Run Prettier over the generated shadcn files in the commit that adds them, so the formatting change never shows up in a later diff.
  • setup-node can cache the pnpm store only when pnpm is already installed, so run pnpm/action-setup first. pnpm install --frozen-lockfile fails when the lockfile disagrees with package.json, instead of quietly rewriting it in CI.

Ship 3 features through the loop

Now the loop carries real work. You build 3 small features: a health endpoint that reads a configuration module, a settings page that shows the deployment, and a landing page. Each one goes through the same steps, so by the third the loop feels routine:

  1. Create a branch with git switch -c <feature>.
  2. Build the feature with Claude Code.
  3. Run pnpm check.
  4. Open a pull request with gh pr create --fill.
  5. Review it with /codex:review from the Codex plugin.
  6. Check the preview deployment.
  7. Merge with gh pr merge --merge.

Study first

  • Route handlers. src/app/api/<name>/route.ts exports one function per HTTP method, which returns Response.json(...).
  • Vercel preview deployments. Each pull request gets its own deployment, and the Vercel app posts its URL on the pull request.

Build

  1. Write src/lib/config.ts, which reads VERCEL_ENV and the first 7 characters of VERCEL_GIT_COMMIT_SHA, with fallbacks for your machine. Add /api/health, which returns { status: "ok", commit }, and take it through the steps above.
  2. Add /settings, which shows the environment and the commit from config.ts in a Card, with a Badge for the environment.
  3. Replace the landing page. Give it a header with the product name and a link to settings, one paragraph on what WorkBot is for, and buttons to the settings page and the health check. Remove the starter files from public/.
  4. Before each merge, open the preview URL and check the changed page at desktop and phone widths.

Done when

  • On production, /api/health returns the first 7 characters of the merged commit's hash, and /settings shows the same value.
  • All 3 pull requests have a green CI run and a Vercel preview comment.
The landing page
The landing page after Day 1: the product in one sentence, and links to the 2 pages that exist so far.
The settings page
The settings page shows the environment and the commit the deployment serves, read from one configuration module.
Technical notes
  • Vercel sets VERCEL_ENV and VERCEL_GIT_COMMIT_SHA at build time and at runtime. VERCEL_REGION is set at runtime only, so a prerendered page cannot show it; leave it out.
  • shadcn's Button can render another element through asChild. <Button asChild><Link href="/settings">…</Link></Button> keeps Next.js navigation and the button's look.
  • Compute or fetch a page's data at the top of its component, then return the markup.

Time the loop

The loop works, so the last job of the day is to make it fast. The target is 10 merged pull requests an hour, each timed from creating the branch to merging it, with the review and CI included. Measure your own loop, find its slowest step and change it.

Study first

  • How to brief Claude Code for a small change in 2 or 3 sentences: the file, the behavior you want, and the check that proves it. A short, specific brief is the cheapest way to speed up the loop. Claude Code's best practices show how to scope a prompt to a file and a scenario, and how to give Claude a check it can run.

Build

  1. Ship 5 more small changes, one pull request each: a 404 page, a favicon, robots.txt, page metadata and a footer.
  2. Record the time from branch to merge in each pull request's description.
  3. After the 5, write down the slowest step and change one thing about it: the brief, the check, or when the review runs.

Done when

  • 5 more pull requests are merged, each with a green CI run and a recorded time, and the 5 changes show on production.
Technical notes
  • gh pr create --fill takes the title and body from the commits, gh pr merge --merge merges from the terminal, and /codex:review runs inside the Claude Code session.
  • Merge with a merge commit, so your commits reach main as you wrote them. When you verify a day, the course reads their messages and diffs.

Resources