Most people meet AI coding tools as a novelty: a smarter autocomplete, a chatbot that happens to know some syntax. That framing sells the tool short and, worse, teaches the wrong habits. A capable agent like Claude Code does not just suggest code — it reads your project, writes and edits files, runs commands, installs dependencies, and verifies its own work. The skill that matters is no longer typing code faster. It is describing outcomes clearly and deciding where your attention is worth spending.

We built a workshop series to teach exactly that, end to end: from an empty folder to a production application with a real backend, automated deployments, and finally the working habits that separate people who use Claude Code from people who direct it. This article walks through all ten parts so you can see the whole arc before you commit to any of it.

Each part stands on its own and can be read or presented in about ten minutes. Together they form a single path: build → provision the platform → ship → add a backend → connect with events → automate → direct.

Part 1Build a Web App with Claude Code

The premise: you describe the purpose and the vibe in plain English, and Claude Code makes the technical choices and does the typing.

Part 1 takes you from nothing to a working application running on your own machine. You install a small set of tools — Node.js, Claude Code, and Git — and then hand Claude Code a single, well-formed request:

Create a new Next.js app in this folder using TypeScript and the App Router. Build a one-page personal site with a hero, an "about" section, a list of projects as cards, and a contact footer. Clean dark theme, blue accent. Then start the dev server so I can see it.

From that one sentence, Claude Code scaffolds the project, installs dependencies, and starts the development server — running the same commands a developer would type by hand, and asking your permission before each one:

npx create-next-app@latest . --typescript --app   # scaffold the project
npm install                                        # download the libraries
npm run dev                                          # start the dev server
# ➜ Local:  http://localhost:3000

Crucially, the goal is not just to produce a page. It is to demystify the machinery you have always been slightly afraid of: what npm, yarn, and pnpm actually do, what lives in package.json, and why folders in a Next.js app/ directory quietly become URLs. You learn to read your project rather than memorize it.

Two ideas pay dividends for the rest of the series. First, design is a prompt, not an afterthought: ask Claude Code to use its design skills or build on a proven template. Second, a good prompt answers four things — goal, context, style, and constraints. Vague in, vague out.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 2AWS Cloud Platform Infrastructure

The premise: before any app runs, something has to create the base it sits on — and you must decide which tool owns which piece.

This is the infrastructure chapter. It separates the platform — the shared, stateful, long-lived resources (VPC, subnets, security groups, S3, RDS, the EventBridge bus, IAM/OIDC) — from the services that plug into it. The rule that keeps it clean: stateful + shared → Terraform; per-service compute → CloudFormation / SAM. Terraform publishes every shared id to /platform/* SSM parameters, and each service template reads them with {{resolve:ssm:…}} — so a service never hardcodes an id, and deleting a service stack can never take the database with it.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 3Platforms: Vercel, Supabase & the AWS Alternatives

The premise: every web app needs two things — a place to serve the frontend and a backend to store data, sign users in, and run logic the browser can't be trusted with.

• Vercel is your deploy platform — it delivers your site to browsers over HTTPS, fast, worldwide. This is what "hosting" and "deploy" actually refer to.
• Supabase is your backend platform — a managed Postgres database with auto-generated APIs, authentication, realtime updates, and Row Level Security so it's safe to talk to from the browser.

The most useful part of this chapter is the translation table to AWS. Every job the managed platforms do has an AWS counterpart — S3 + CloudFront for static hosting, Amplify for full deploys, Lambda and ECS Fargate for backend logic, DynamoDB for data, Cognito for authentication. Understanding this mapping means you are never locked into one vendor's vocabulary.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 4Backend Option A — A Node.js API with Route Handlers

The premise: the simplest backend is the one that lives in the same codebase as your frontend.

This is the fullstack-JavaScript path. You build a small Notes API using Next.js Route Handlers — server code that sits right inside the app you already have, with no separate service to deploy. Along the way you learn a swappable data layer (in-memory today, a real database tomorrow), dynamic routes for single resources, and validation and error handling so bad input produces a clear response instead of a crash. It's the right first backend for most people: one repository, one deploy, one mental model. It also covers the production concerns every backend shares — a pooled database connection, secrets kept out of the browser bundle, per-request user/organization context, background work, and how to add the next resource without breaking the shape.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 5Backend Option B — A Python API on AWS with SAM

The premise: when you want a standalone, independently scalable service, you build it as infrastructure-as-code and deploy it with one command.

This is the professional-grade path: API Gateway + Lambda (Python) + DynamoDB, declared in an AWS SAM template. The centerpiece is layered architecture — the discipline that keeps a service from turning into a tangle:

handlers  →  services  →  repositories  →  models

Each layer has one job. Handlers deal with the web, services hold business logic, repositories talk to the database, models define the data. The result is code you can test, extend, and reason about months later — the same structure JunctionNet uses in production. It goes past the happy path too: the database connection under Lambda, secrets via SSM and Secrets Manager, multi-tenant org_id scoping, an EventBridge event bus, and how each new service is the same skeleton again.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 6Backend Option C — Docker + AWS ECS Fargate

The premise: some applications need a real, always-on server — not a function that spins up per request.

This is for workloads serverless functions handle awkwardly: long-lived frameworks like NestJS, Express, or FastAPI; background workers; and infrastructure such as Redis or Kafka. You containerize with a Dockerfile, run the whole stack locally, push the image to ECR, define an ECS Fargate task and service behind a load balancer, and deploy from CI. It's the container-native option: full control over the runtime, and a deployment story that scales from a side project to a serious platform. You'll see it in both Node.js and Python, with a long-lived database pool, ECS-injected secrets, a background worker from the same image, and a clear rule for when a module should become its own service.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 7Event-Driven Development with EventBridge

The premise: as a system grows, services shouldn't call each other directly — they should announce facts and let others react.

This is the architecture chapter. On Amazon EventBridge, a producer publishes an event — a fact in the past tense — and any number of consumers subscribe by pattern and run in their own Lambda; the producer never knows they exist. You learn the conventions that keep it sane (source as a stable dotted namespace, detail-type as {Entity}{PastTenseVerb}), when and where to publish (from the service layer, after the state change commits), and how a new feature becomes a new subscriber instead of an edit to the producer. Finally you forward the whole stream to OpenSearch — turning the same events that drive your services into a durable audit trail and analytics dashboards.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 8Stop Chatting with Claude Code — Start Directing It

The premise, and the thesis of the entire series: you are not prompting a chatbot. You are directing an agent, and the whole game is deciding where your attention is worth spending.

The other parts teach you what to build. This capstone teaches you how to work. The core loop it advocates is plan → ultrathink → auto → remote → ultracode:

• Start in Plan mode, always — let the agent show you the plan before it touches a file. This one habit prevents most wasted work.
• Spend reasoning where it matters (ultrathink) — hard problems deserve deep thinking; trivial ones don't.
• Execute on autopilot (auto mode) for work that's mechanical once the plan is right.
• Get work off your screen with background and remote sessions.
• Go wide with ultracode and multi-agent workflows when a task is big enough to fan out.
• Close the loop — never accept "done" on trust; the /run → /verify → review cycle observes real behavior before you believe it.

It also dissects the single highest-leverage file in any repository: the CLAUDE.md, the standing brief that tells the agent your conventions every session, without being reminded.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 9CI/CD & Releases with GitHub Actions

The premise: once you can build and deploy anything, automate it. A git push should become a safe deploy without you babysitting it.

Part 9 wires one GitHub Actions pipeline to every stack in the series, in the three tiers teams actually run: a dev ticket environment per pull request (named from the JIRA ticket, torn down on close), an automatic deploy to Dev Integration + Staging on merge to main, and a Production deploy triggered by publishing a release — gated by a required reviewer. It authenticates to AWS with OIDC (no long-lived keys), builds each artifact once and promotes that same one, and documents the concrete workflows we run (infra → migrations → deploy → API mappings → e2e). Every build is a tagged, reproducible release you can roll back.

The same pipeline covers all four deploy targets: the Vercel frontend, a static S3 + CloudFront site, the Python SAM service, and the ECS Fargate container — building each artifact once and deploying that exact thing everywhere.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

Part 10API Security: Authentication Headers

The premise: HTTP already defines how a client proves who it is — and every deviation from the Authorization header has a cost.

This is the security chapter. It walks the real authentication choices by who is calling: browser users get cookies (HttpOnly / Secure / SameSite), service-to-service uses short-lived Bearer JWTs with an audience claim, third-party developers get static API keys (hashed, revocable), and webhook senders are verified with HMAC signatures (constant-time compared). You learn why a custom X-API-Key header quietly costs you caching, CORS, and tooling that the standard Authorization header gives for free — and how the platform's Lambda Authorizer resolves all three credential types into an org_id.

📖 Full article  ·  ▶ Presentation  ·  📝 Quiz

The Through-Lines

Read across all ten parts and a few principles recur — the actual curriculum hiding behind the topics:

1. Describe outcomes, not keystrokes. The quality of your result tracks the quality of your description — goal, context, style, constraints.
2. CLAUDE.md is your standing brief. Conventions written down once are applied every session.
3. Verify, never assume. A change isn't done because the agent says so; it's done when you've watched it work — and, in Part 9, when CI is green.
4. Choose your platform with your eyes open. The AWS map and the three backend options exist so "which stack?" is a decision you make on purpose.
5. Own your infrastructure as two layers. A shared, stateful platform in Terraform; per-service compute in SAM/CloudFormation — connected through SSM, never hardcoded — with services that talk through events, not direct calls.
6. Attention is the scarce resource. The leverage isn't in typing — it's in directing: knowing when to plan, when to think deeply, when to automate, and when to step in.

Where to Start

If you have never built a web app, start at Part 1 and stop where it tells you to — a working app on your own machine is a real milestone. When you're ready to put it online, Part 3 gives you the vocabulary. Pick one of the three backend parts based on your project, automate it with Part 9, and read Part 8 whenever you want to get dramatically more out of the tool — many experienced developers would benefit from reading it first.

The tools will keep changing. The discipline won't: describe clearly, capture your conventions, verify your results, and direct your attention where it counts. That is what this series is really about — and it is what makes building software with an agent feel less like gambling and more like engineering.