The first version of my Kubernetes Operator worked.
It was built for one database platform, for one customer problem, and it did exactly what it needed to do. But it was concrete all the way down: tightly coupled, not extensible, and impossible to test without live infrastructure.
If I wanted to support other database platforms, I'd have to refactor the entire core. Replace concretes with interfaces. Restructure the codebase so logic could be reused across implementations.
This is the part of AI-assisted development that nobody talks about. Not the greenfield build, but what happens next. Taking production code and making it better without breaking it.
Here's the workflow I used.
Phase 1 - Specification with Opus
Before touching a single line of code, I asked Claude Opus to generate a detailed refactoring plan as a Markdown document.
Not a vague outline. A precise spec: which files would be created, which code segments would move where, what the new interfaces would look like, how the abstractions would enable reuse across future database implementations.
I used Opus specifically for this phase: the more capable model, slower and more expensive, but worth it for the reasoning depth required to plan a structural refactor without introducing regressions. The goal was to get the plan right before any implementation began.
I reviewed it, pushed back on specific decisions, asked for alternatives in places where the approach felt wrong. The MD file went through several iterations before I was satisfied.
That document became the single source of truth for everything that followed.
Phase 2 - Implementation with Sonnet in Plan Mode
Once the spec was locked, I switched to Claude Sonnet and engaged Plan Mode, Claude Code's built-in capability to propose a complete implementation plan before executing any changes.
This is a critical step that most people skip.
Plan Mode reads the specification, maps it against the existing codebase, and produces a detailed proposal of exactly what it intends to do (file by file, change by change) before writing a single line. You review it. You approve it. Then it executes.
The spec I'd built with Opus was the input. Plan Mode's proposal was the verification that the model understood the spec correctly. Implementation only started when both aligned.
The refactor ran in one shot. Clean interfaces. Reusable core. Testable without live infrastructure.
Phase 3 - The slash command
Once the architecture was right, I built a custom Claude Code slash command to scaffold new database integrations.
Now, when I need to add support for a new platform, I run the command. It generates the API layer, the controller structure, the interface implementations: all consistent with the refactored architecture, all following the same patterns.
What used to require understanding the entire codebase and carefully threading new logic through it now takes minutes.
The full workflow, in plain terms:
Opus → think deeply, plan precisely, produce a spec
Sonnet + Plan Mode → verify understanding, execute against the spec
Custom slash command → compound the investment, make the pattern reusable forever
Each phase uses the right tool for the right job. Opus for reasoning. Sonnet for execution. The slash command for scale.
This is what AI-native development looks like when it matures past the prototype stage.
The 2-week MVP was speed. This is something different: it's using AI to improve the architecture of something already in production, responsibly, with a verification step between planning and execution.
The spec isn't just a prompt. It's a contract between you and the model. Plan Mode is how you confirm the model understood the contract before it acts on it.
That discipline (spec first, verify before executing, build reusable patterns from every solved problem) is what separates teams that ship consistently with AI from teams that generate impressive demos and then spend weeks cleaning up.
What's your workflow for using AI on existing production code, not just greenfield builds?
Top comments (0)