Shipping production code with Claude Code and other AI coding tools

Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.

Concept: Claude / Claude Code · also covers Cursor, Codex, AI-assisted development, Writing production code, Software engineering · Step 9 of 34 in AI forward deployed engineer · version 1

Practice this

On this page

Agentic coding tools read a repository, run commands, edit files and iterate on test results, which changes the engineer's job from typing code to directing and verifying it. For a forward deployed engineer the gain is speed in unfamiliar customer codebases, and the obligation is unchanged: the person who merges the change owns its correctness, security and fit with the customer's standards.

Read more

How it is done in practice

A team using these tools well commits an instruction file and a small set of shared commands to each repository, so every session starts with the same build, test and convention knowledge. Engineers begin non-trivial changes in a read-only planning step, approve the plan, and let the agent implement against a test it can run. Pull requests stay small and are reviewed by a human who reads the full diff, with CI as the arbiter of whether anything passes. On customer engagements the tool, account type and permitted data are agreed in writing before the first session, and agents run with the minimum permissions and no production credentials.

Technologies

Claude CodeCursorOpenAI CodexGitHub CopilotModel Context ProtocolGit worktreesGitHub ActionspytestPlaywright

Diagram

flowchart LR
  T[Task with success criterion] --> E[Explore: agent reads code]
  E --> P[Plan: read-only proposal]
  P -->|human approves| I[Implement in small steps]
  P -->|human corrects| E
  I --> V[Verify: tests, types, run the app]
  V -->|fails| I
  V -->|passes| R[Human reviews full diff]
  R --> CI[CI gate]
  CI --> M[Merge]
flowchart LR
  T[Task with success criterion] --> E[Explore: agent reads code]
  E --> P[Plan: read-only proposal]
  P -->|human approves| I[Implement in small steps]
  P -->|human corrects| E
  I --> V[Verify: tests, types, run the app]
  V -->|fails| I
  V -->|passes| R[Human reviews full diff]
  R --> CI[CI gate]
  CI --> M[Merge]

Code

markdown
# CLAUDE.md

## Commands
- Install: pnpm install
- Type check: pnpm tsc --noEmit
- Test one file: pnpm vitest run path/to/file.test.ts
- Lint: pnpm eslint .

## Rules
- Never edit files under migrations/ that are already merged.
- All external responses are parsed with a schema in src/schemas.
- Do not change or delete a failing test to make it pass; report it.
- Keep each change to one concern; no drive-by refactors.

## Verification
- A change is done only when type check, lint and tests pass.

Subtopics

The core workflow: explore, plan, implement, verify

Why the order matters

An agent that starts editing immediately will solve the problem it guessed at. The reliable loop is to have it read the relevant code first and explain how the area works, then produce a plan you review before any file changes, then implement in small steps, then prove the result by running tests, a type check or the application itself. Tools support this directly, for example a plan mode that restricts the agent to read-only actions until the plan is approved. The same loop is the fastest way into an unfamiliar customer codebase: ask where a request enters, how data flows and which tests cover it before changing anything.

Giving the agent a way to check itself

The largest quality lever is a verification signal the agent can run on its own: a failing test that should pass, an expected output, a screenshot to match, or a lint and type check command. Without one, the agent stops when the code looks plausible. State the task with the target behavior, the files or patterns to follow, and the command that proves success. Keep tasks scoped to one reviewable change, and start a fresh session when the context fills with unrelated history, since stale context degrades results.

Project context: instruction files, rules and reusable commands

Teaching the tool the repository

Each tool reads a persistent instruction file at the start of a session: CLAUDE.md for Claude Code, rules files for Cursor, and AGENTS.md for Codex. Put there what the agent cannot infer from the code: the build and test commands, branch and commit conventions, directories that must not be touched, and the non-obvious architectural rules. Keep it short and specific, because long instruction files get diluted. Repeated workflows, such as opening a pull request or running a migration check, belong in reusable commands or skills so every engineer on the engagement invokes the same procedure. Connections to external systems such as issue trackers or databases are added through Model Context Protocol servers.

Reviewing and testing generated code

Failure modes specific to generated code

Beyond ordinary review, watch for the mistakes agents make more often than people do: tests weakened or deleted to get a green run, errors swallowed by broad exception handlers, invented library functions or configuration options, duplicated helpers where one already exists, and changes that drift outside the requested scope. Read the diff, not the agent's summary of the diff, and treat a claim that tests pass as unverified until CI shows it.

Permissions, safety and working in customer repositories

Controlling what the agent can do

Coding agents run shell commands with your credentials, so the permission model matters. Tools provide modes that range from asking before every edit or command to allowing a defined set automatically, plus allow and deny lists for specific commands and paths. Hooks run your own scripts before or after tool calls and can block an action deterministically, which is stronger than an instruction the model may ignore. Run unattended or broadly permitted sessions inside a sandbox or container without production credentials. Treat content the agent reads from the web, issues or documents as untrusted, because it can carry injected instructions.

Customer-specific obligations

Before using any AI tool on a customer's code, confirm that their policy and your contract allow it, which provider and data retention terms apply, and whether the code may leave their network at all. Some customers require a specific approved tool, an enterprise account, or a cloud-hosted model endpoint inside their own tenancy. Keep secrets and personal data out of prompts and out of files the agent reads. Follow the customer's review process exactly, and disclose AI assistance where their contribution rules ask for it.

Parallel sessions, subagents and headless automation

Scaling beyond one session

The remaining points are mechanical. Isolate parallel sessions with git worktrees so agents do not overwrite each other. Use subagents to keep exploration out of the main context window. Run the tool non-interactively in CI for narrow jobs such as triaging a failing build or drafting a review, with a tightly restricted tool list. Parallelism multiplies review load, so cap it at what one person can actually read.

Sources

Related lessons

Practice this
SQL and data systems: schemas, indexing and partitioning in PostgresREST APIs, JSON and OAuth 2.0 authentication