← The journal

Coding with Claude: A Developer's Playbook

The follow-up to Architecting with Claude: a free, hands-on book for developers using Claude Code, plus Acme Expenses, the open-source app it builds one chapter at a time.

Architecting with Claude: The Principles explains why some AI projects just work and others don't. It's written for the people who decide what gets built. It deliberately has no code in it.

The obvious next question is the developer's: fine, but how do I actually do this, on a real codebase, with a team? That's this book. Coding with Claude: A Developer's Playbook is the hands-on companion: one stack, one running example, and a playbook for each kind of work developers bring to Claude Code.

Coding with Claude: A Developer's Playbook by Daniel Wanja

Quick Links

Both books are free under CC BY 4.0, and the code is MIT. Read them, share them, adapt them.

What's in it

The book follows one small, clearly fictional app, Acme Expenses: employees submit expenses, managers approve them, and Finance signs off on the big ones. The stack is TypeScript everywhere: a React app on Firebase Hosting, an Express API in Cloud Functions, Firestore, and Zod schemas shared by every layer.

Part I, How Claude Code works. The agent loop you're steering, the explore, plan, code, verify, commit workflow, and why context (CLAUDE.md, Skills, subagents, MCP) is most of the job.

Part II, The playbooks.

  • Modernize a legacy app without losing its behavior
  • Build on other people's APIs
  • Build APIs that people and agents can use
  • Tests, where Claude shines
  • Ship the whole slice
  • One business rule, every layer
  • Ship the whole pie: a whole app or a whole migration in one long run, steered by a written brief

Part III, Working as a team. Review and safety (permissions, hooks, the sandbox, prompt injection), then scaling it: shared config, CI, parallel worktrees, running on Google Cloud, and measuring what matters.

Every chapter ends with a do and don't table, exercises on Acme Expenses, and a line tying it back to the principles in the first book.

The idea I care most about: ship the whole slice

Most teams split a feature at the seams. One developer builds the screen, another the API, and they meet at a contract that someone wrote down and nobody kept up to date. Then the bugs live in the seams.

With Claude Code, one developer can take a feature through every layer: the data model, the security rules, the shared business rule, the API route, the client, the UI, the tests and the docs, in one session that sees all of it. Chapter 8 does exactly that for "managers can bulk-approve up to 20 expenses", starting from a one-page slice spec:

A page from Chapter 8: the slice spec for bulk approve

Chapter 9 then adds a business rule that touches everything (over $2,500 needs a second approval from Finance) and shows where it has to live so every path obeys it.

And sometimes, ship the whole pie

Slices are how team code should land. But some of my best results came from the opposite: a full migration in a few prompts, or a new app built from designs in one go. Claude Code might run for an hour, and the result might not be exactly what I had in mind, but it saves a lot of time and sometimes shows me an approach I hadn't considered.

Chapter 10, new in version 1.2, is about doing that on purpose. It works when the job has an oracle: the old app is both the spec and the test for a migration, and the designs define "done" for a new app. The chapter covers the brief you write up front (end state, validation, scope limits, guardrails, a cap and a sign-off), /goal and a Stop hook to keep the run honest, a separate reviewer, and how to land the result as slices instead of one giant pull request.

The code is real

The book's code is backed by a working app. Acme Expenses has one tagged commit per chapter (ch02, ch05, ch08…), so you can check out the state a chapter starts from and compare your work with mine. The unit tests, typecheck and builds pass at every tag. The emulator and browser tests run on your machine with the Firebase emulators.

What Surprised Me

  • The docs changed under my feet. On the day v1.0 was finished, Anthropic rewrote its Claude Code best-practices page. Some advice the book leaned on, like treating the context window as your scarcest resource, is now on the page's "what you can stop doing" list. Version 1.1 followed that evening. That's why the references are dated and the book avoids version numbers.
  • Building the app from the book found the book's bugs. Having Claude implement the app straight from the manuscript's snippets turned up about twenty mistakes: a Firestore write with an undefined field, a backfill that would have invented manager approvals for expenses no manager ever saw, a rule that existed in the text but did nothing in the code. All fixed, in both places.
  • A $500 rule that did nothing. The original business rules mentioned a $500 approval limit that never actually changed anything. It became a much better rule: expenses up to $75 are approved automatically, and about one in twenty is spot-checked. Automate the low stakes and sample them, straight out of The Principles.
  • Real machines find real bugs. Claude's sandbox can't run the Firebase emulators, so the browser tests first ran on my Mac, and failed. macOS AirPlay Receiver listens on port 5000, the Firebase Hosting emulator's default, so Playwright thought the app was already running. And Playwright's default hard kill left the Firestore emulator holding its port for the next run. Both are fixed and documented.

How It Was Made

With Claude, again, start to finish. Claude researched the official Claude Code, Anthropic and Firebase docs and wrote dated fact sheets. Several sessions drafted chapters from one brief. Separate sessions, which hadn't written them, fact-checked every command and snippet against the live docs. Then Claude built the companion app from the manuscript, and I ran it on real hardware. The full story, including what a human did, is in HOW-IT-WAS-MADE.md.

This is independent work. It is not affiliated with, endorsed by, or reviewed by Anthropic.


Daniel Wanja is a developer and founder of Nouvelles Solutions, Inc. When not shipping whole slices with Claude Code, he's turning off AirPlay Receiver so his tests can have port 5000.