Bulk-refactor a 1M-line codebase for stricter compiler settings
When you change a single setting in the IDE to make something more strict and you have 1M+ lines of code, you will get 30K items to fix, via red/yellow/blue squiggles in the IDE. Task: The author uses Claude to bulk-refactor a 1M+ line .NET monorepo to satisfy 50 stricter compiler settings, generating ~200K fixes. Claude processes error classes via custom skills or generated scripts, avoiding IDE instability. Work is split into business logic, performance, and cosmetic buckets, with bulk refactors limited to performance/cosmetic changes to protect complex domain logic. Human developers review outputs, as the author notes manual bulk refactoring is near-impossible for humans.; tools: Claude. Human role: The original post does not say how a person stayed involved.; limitations: Prerequisites include a monorepo with clean project boundaries and strict analyzer configs checked into version control. The workflow relies on Claude not bypassing compiler barriers, requiring explicit prompting. IDE-based quickfixes are avoided due to crashes and half-baked refactorings. Human review is critical for business logic changes, which are excluded from bulk automated refactors to prevent breakages in complex domains..
Tools
Published on Agent Work Atlas:
Overview
When you change a single setting in the IDE to make something more strict and you have 1M+ lines of code, you will get 30K items to fix, via red/yellow/blue squiggles in the IDE.
Workflow
The author uses Claude to bulk-refactor a 1M+ line .NET monorepo to satisfy 50 stricter compiler settings, generating ~200K fixes. Claude processes error classes via custom skills or generated scripts, avoiding IDE instability. Work is split into business logic, performance, and cosmetic buckets, with bulk refactors limited to performance/cosmetic changes to protect complex domain logic. Human developers review outputs, as the author notes manual bulk refactoring is near-impossible for humans.
Reported result
The author reports successfully porting all code to .NET 10 LTS with clean project boundaries, enabling effortless dependency upgrades. They claim the approach eliminated meeting friction regarding linter settings and reduced mental load. However, no quantitative metrics (e.g., time saved, error rates) are provided. The author asserts the system still functions correctly after changes, but admits proving behavioral equivalence is difficult.
Human role
The original post does not say how a person stayed involved.
Limitations
Prerequisites include a monorepo with clean project boundaries and strict analyzer configs checked into version control. The workflow relies on Claude not bypassing compiler barriers, requiring explicit prompting. IDE-based quickfixes are avoided due to crashes and half-baked refactorings. Human review is critical for business logic changes, which are excluded from bulk automated refactors to prevent breakages in complex domains.
Try it
Act as a senior .NET engineer. I have a monorepo with [replaceable: number] projects and [replaceable: lines of code] lines. We are enabling [replaceable: number] strict compiler/analyzer settings. Your task is to bulk-refactor the codebase to satisfy these settings without changing business logic. 1. Analyze the error output from [replaceable: build log or IDE export]. 2. Categorize errors into: Business Logic, Performance, and Cosmetic. 3. Generate scripts or apply fixes ONLY for Performance and Cosmetic categories. 4. For Business Logic errors, list them for manual review; do not auto-fix. 5. Ensure all changes preserve existing behavior. Deliverables: - A summary of errors by category. - The generated refactoring scripts or patch files for Performance/Cosmetic fixes. - A list of Business Logic errors requiring human intervention. Safeguards: - Do not modify files in [replaceable: critical domain folders]. - Run a dry-run on [replaceable: sample project] first and show me the diff before applying to the whole repo. - If a fix requires changing logic, stop and ask for clarification. Measure success by: Zero new compiler warnings in the sample project after applying cosmetic/performance fixes, and no changes to public API signatures.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.