Practice: Shipping production code with Claude Code and other AI coding tools
Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.
Main tool: Claude Code · Claude Code runs in the terminal against a real repository and exposes every part of this lesson (plan mode, instruction files, permissions, worktrees, subagents and headless runs) as something you can drive and inspect on a laptop. · Alternatives: Cursor is an editor-first agent that lives inside a forked IDE rather than the terminal; OpenAI Codex is a comparable terminal and cloud agent built on a different model family with its own sandbox and approval model; GitHub Copilot started from inline completion and adds an agent mode tied closely to pull requests and the hosting platform.
Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1
Setup (one time)
1. Check the prerequisites: a supported terminal, an account that can sign in to Claude Code, and a small Git repository with a pytest suite to practise on.
Every later step needs a real repository with runnable tests so the agent has something to verify against. A throwaway repo keeps mistakes cheap while you learn the controls.
Explained in: Quickstart - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: You have a local Git repository whose test suite passes when you run it yourself, and an account ready for login.
2. Install Claude Code with the installer recommended for your operating system.
The native install gives you the claude command that every step of this path uses.
Explained in: Quickstart - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: Asking the claude command for its version in a terminal prints a version number.
3. Start your first session from the root of the practice repository and complete the login flow.
Claude Code treats the directory you start it in as the project, so starting at the repo root decides what it can see and edit.
Explained in: Quickstart - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: The interactive prompt is open in the practice repository and shows you as logged in.
Steps
1. Ask your first questions about the practice repository: what it does, how it is laid out and where the entry point is, without requesting any change.
Exploring first is the opening move of the explore, plan, implement, verify workflow, and it is how you get oriented fast in an unfamiliar customer codebase. It also shows you which files the agent reads on its own.
Explained in: Quickstart - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: You have a written summary of the repo structure that you checked against the actual files and found accurate.
2. Switch to plan mode and create a plan for one small feature or bug fix, then revise the plan until you agree with it before any file is edited.
Separating planning from editing lets you correct the approach while it is still cheap. The engineer who merges owns the result, so the plan is your first review gate.
Explained in: Common workflows - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: A reviewed plan listing the files to change and the checks to run is on screen, and the working tree shows no modifications.
3. Write a failing pytest test for the planned change, then run the implementation and have Claude iterate until the whole suite passes.
A test gives the agent an objective target to verify against, in place of its own claim that the work is done. This closes the implement and verify half of the core workflow.
Explained in: Common workflows - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: The new test failed before the change and the full suite passes after it, as shown by test output you ran yourself.
4. Configure permissions: cycle through the permission modes, approve and deny a few tool requests, then rewind an edit with a checkpoint.
In a customer repository you must decide what the agent may run and edit without asking. Checkpoints are the safety net when an edit goes wrong, and you should know their limits before you rely on them.
Explained in: How Claude Code works - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: You can state which mode you are in, a denied command was not executed, and a rewound file is back to its earlier content.
5. Write a root CLAUDE.md with the build and test commands and coding standards, then add a nested instruction file or a path-scoped rule for one subdirectory.
Instruction files and rules are how a customer's conventions reach every session without retyping them. Choosing between per-directory files and path-scoped rules decides what loads and when.
Explained in: Set up Claude Code in a monorepo or large codebase - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: A fresh session follows a convention you wrote without being told, and the subdirectory rule applies only when files under that path are involved.
6. Create a skill in the repository that packages one repeatable task, such as running the test suite and summarising failures, and invoke it by name.
A skill turns a prompt you keep retyping into a reusable command that the whole team gets by checking out the repo. Its location decides where it is discoverable.
Explained in: Set up Claude Code in a monorepo or large codebase - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: The skill appears in the list of available commands in a new session and running it produces the expected summary.
7. Run the context command in your own session after a long task, compact the conversation, and compare what is loaded before and after.
Long sessions in large codebases fill the context window, and the agent gets less reliable when earlier instructions drop out. Knowing what survives compaction tells you what belongs in instruction files rather than in chat.
Explained in: Explore the context window - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: You can point to the context breakdown before and after compaction and name one thing that was kept and one that was summarised away.
8. Run a local code review of your uncommitted diff, read each finding, and fix or consciously dismiss every one.
Generated code needs a second look that is independent of the session that wrote it. Reviewing the diff before it leaves your laptop keeps defects out of the customer's pull request queue.
Explained in: Code Review - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: The review output lists findings against your diff and each one is either fixed, with tests still passing, or dismissed with a reason you can explain.
9. Start two Claude sessions in separate Git worktrees and give each a different task on the same repository.
Worktrees give each session its own checkout and branch, so parallel work does not overwrite itself. This is the standard way to run several agents at once on one repo.
Explained in: Run parallel sessions with worktrees - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: Listing the worktrees shows two extra checkouts on separate branches, each holding only its own session's changes.
10. Delegate a research question to a subagent, for example finding every caller of one function, and continue your main task with its summary.
A subagent explores in its own context window and returns only the result, which keeps the main session focused. That matters most in large customer codebases, where exploration is noisy.
Explained in: Common workflows - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: The main conversation contains a short summary from the subagent, not the full file reads, and the summary matches what you find by searching yourself.
11. Run Claude Code non-interactively in print mode with a fixed prompt and a restricted set of allowed tools, and request structured output.
Headless runs are how the agent gets into scripts and pipelines, where nobody is present to answer permission prompts. Structured output lets another program check the result.
Explained in: Run Claude Code programmatically - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: A single command exits on its own and prints machine-readable output that a script can parse, and running it again does the same task without prompts.
12. Configure a production-style CI job for Claude Code following the manual GitLab CI/CD setup, with the API key as a masked variable and limited permissions. This needs a hosted project and API credit, so the closest local substitute is to run the same headless job in a local container against a clone.
A production setup differs from a laptop session in that credentials, permissions and triggers are fixed in configuration that others can review. This is the form in which a customer's security team will judge the tool.
Explained in: Claude Code GitLab CI/CD - Claude Code Docs (code.claude.com), checked 2026-10-11
Done when: A pipeline definition is committed with no secret in the file, and a pipeline run or the local container run completes the task and leaves its changes on a branch for human review.
Back to Shipping production code with Claude Code and other AI coding tools