Opus 4.5 is the first AI model I trust to refactor production code unsupervised
Claude Opus 4.5 refactored a 500-line TypeScript module, maintained all tests, and passed review without modification. The bottleneck has shifted from writing to reviewing.
I have been using AI coding tools since GitHub Copilot launched. Each generation improved. Each generation still required significant human supervision for anything beyond trivial code generation. Copilot was autocomplete with context. GPT-4 was a draft generator that needed heavy editing. Sonnet 4.5 was a competent first pass that needed focused review.
Opus 4.5 is different. Last week it refactored a 500-line TypeScript module in our payment processing service, maintained all 47 existing tests, and produced a pull request that passed human review without a single modification request. That has never happened before with any AI tool on production code of that complexity.
I write these AI posts from the far side of the honeymoon phase. It also builds on what I learned earlier in “The Prisma-to-Drizzle migration we almost did and why we stayed on Prisma.” The interesting question is no longer whether the models are impressive. It is where they meaningfully improve decision quality across real systems like portfolio search, aigw, jarvis, and the review loops around everyday engineering work.
What Made This Different
The module in question was our payment gateway abstraction layer. It handled routing transactions to different payment processors based on currency, amount, and merchant configuration. The code worked but had accumulated eighteen months of incremental additions that made the control flow hard to follow.
I gave Opus 4.5 the full module, the test file, and a one-paragraph description of the refactoring goal: simplify the routing logic, extract the processor-specific configuration into a declarative map, and maintain all existing behavior. No line-by-line instructions. No pseudocode. Just the intent.
The output was remarkable for three reasons:
- It identified and preserved every edge case in the original code, including two edge cases that were not covered by tests but were implied by comments in the source.
- It restructured the routing logic from a nested if-else chain into a configuration-driven dispatch pattern that was cleaner than what I would have written.
- It updated the test descriptions to match the new code structure without changing what the tests actually verified.
The Trust Threshold
Trust in AI-generated code is not binary. It is a spectrum based on the cost of failure times the probability of failure. For a utility function that formats dates, I trust AI output after a glance. For a payment processing module that handles real money, the trust threshold is much higher.
Opus 4.5 crossed that threshold for refactoring, not for greenfield development. The distinction matters. Refactoring is constrained by existing behavior. Tests define the expected output. The code review can be mechanical: does the refactored code produce the same results as the original? This is verifiable in a way that greenfield code is not.
- Greenfield code: the AI might solve the wrong problem. You need to verify intent, approach, and implementation.
- Refactoring: the AI solves a known problem within known constraints. You verify that behavior is preserved and readability improved.
- Bug fixes: somewhere between the two. The AI needs to understand the bug, which requires domain context that models still sometimes lack.
What This Changes About Engineering Teams
If AI can reliably handle refactoring, the implications for engineering team structure are significant:
- The bottleneck shifts from writing code to reviewing code. Teams need more reviewers, not more writers.
- Technical debt becomes cheaper to address. Refactoring that used to take a senior engineer a week can be done in hours with AI assistance and human review.
- Code quality standards can increase because the cost of meeting them decreases. You can afford to refactor more aggressively when the refactoring is largely automated.
- The most valuable engineering skill becomes the ability to evaluate AI-generated code. Can you read a 500-line diff and verify that it preserves all existing behavior? That is a different skill than writing 500 lines from scratch.
Where I Still Do Not Trust It
Opus 4.5 is not a replacement for engineering judgment. Specific areas where I do not trust unsupervised AI output:
- Architecture decisions. The model can implement an architecture, but it cannot evaluate whether the architecture is right for the constraints.
- Security-sensitive code. Authentication, encryption, access control. The cost of a subtle mistake is too high to skip human review.
- Database migrations. Schema changes affect production data. The consequences of a mistake are irreversible in ways that code bugs are not.
- Cross-service interface changes. The model lacks context about how other services consume the interface.
The Direction Is Clear
By the time I wrote this, the lesson was bigger than the tool or incident. The job had become setting defaults a team could trust, then proving those defaults in systems like jarvis, alfred, and the portfolio RAG stack. That is leadership work, not just technical taste.
AI coding tools are not replacing engineers. They are shifting the engineering role from production to supervision. The engineers who adapt to this shift will be dramatically more productive. The ones who resist it will wonder why their peers ship twice as much.
I now allocate roughly 20% of our sprint capacity to AI-assisted refactoring. An engineer identifies a module that needs cleanup, writes a refactoring brief, runs Opus 4.5, and reviews the output. What used to take a week takes a day. The codebase is cleaner than it has ever been, and the team spends more time on novel problems instead of cleanup. This is the future of engineering productivity, and it arrived faster than I expected.
Trusting an AI model to refactor production code required building verification infrastructure that did not exist when we started. We needed deterministic test suites, snapshot-based regression testing, and a staged rollout process that could catch subtle behavioral changes. The refactoring itself was impressive — Opus 4.5 identified patterns and simplifications that no engineer had proposed in two years of maintaining the codebase. But the real value was the verification pipeline we built around it, which now catches regressions regardless of whether the change came from a human or an AI.