daBongo LMS AI Training Courses

← Back to Course

Claude Code in Your Development Flow

Lesson 5: Multi-File Changes and Project-Scale Work

Lesson Objectives

By the end of this lesson, students should be able to:

  • Apply the plan-before-edit pattern for multi-file changes
  • Use feature branches for Claude Code-assisted work
  • Track and review multi-file changes incrementally
  • Define scope boundaries for Cowork/Agent mode tasks

Lesson Content

Multi-file changes – the scale problem.

A single-file change produces a diff of manageable size. A ten-file change produces a diff that is ten times harder to review. A Claude Code Cowork task that touches twenty files with a vague goal produces a diff that is effectively unreviewed by most developers in practice. Scale increases the risk of undetected errors – and review discipline must scale with it.

The plan-before-edit pattern at scale.

For any multi-file change:

  1. Ask Claude: "Before making any changes, list every file you plan to modify and describe the change you will make to each."
  2. Review the plan – verify the scope matches your intent
  3. Flag any file in the plan that should not be touched
  4. Approve the plan, then apply in batches: request changes file-by-file or in small groups

The plan step costs seconds. It prevents the moment of discovering Claude changed twelve files you expected it to change three.

Feature branches for Claude Code work.

All Claude Code-assisted development should happen on a feature branch. Benefits:

  • The diff against main is always the complete change surface for review
  • Git reset provides a clean rollback if Claude takes an unexpected direction
  • The PR review process provides a second review layer beyond your own

Do not use Claude Code in agent mode directly on main or in production branches.

Incremental review for large changes.

For changes too large to review in one pass:

  • Review by concern: all security changes first, then performance, then structure
  • Review by subsystem: service layer first, then controller, then tests
  • Review file-by-file with a checklist per file

Incremental review prevents "it's too much to review carefully" from becoming "I'll trust Claude and ship it."

Scoping Cowork/Agent mode tasks.

Cowork mode tasks should have:

  • Specific, measurable goals ("add created_at and updated_at timestamps to every database model" – not "update the data models")
  • Defined scope ("only modify files in src/models/")
  • Defined check-in points ("after listing the models to be changed, pause and wait for confirmation")
  • Defined stop conditions ("stop if you encounter a model with existing timestamp fields")

Scope definition is what makes Cowork mode powerful rather than risky.

Practical Example

A developer asks Claude Code in Cowork mode to add input validation to all API endpoints.

Unscoped version: Claude finds twenty-three endpoints, adds validation to all of them, touching thirty-one files in a single operation.

The diff is effectively unreviable.

Scoped version: the developer asks Claude to list all endpoints without validation first – confirms the list and removes three that already have external validation – then asks Claude to add validation to the first five endpoints, pausing for review after each batch of five.

Five reviews of six files each: manageable.

Each batch reviewed in ten minutes, full change in under an hour, high confidence in the result.

Safety Notes

Cowork mode with broad scope and write access to a large codebase is a powerful but high-risk combination. Before using Cowork mode on a complex multi-file task, ensure: you are on a feature branch with no uncommitted work, your test suite covers the affected code, and you have a clear rollback path (git reset –hard to the branch base). A Cowork task that goes wrong on main with no test coverage and no rollback plan can create significant cleanup work.

Log in and enroll to access lesson quizzes.

← Back to Course

Scroll to Top