There’s a lot of hype about AI coding tools. Most of it describes them as autocomplete on steroids — you write less, they fill in the blanks, you ship faster.
That’s a real benefit. But the more significant one, in our experience, is different: AI pair programming raises the quality floor. It’s not just about writing code faster. It’s about what happens between writing and shipping.
Here’s a concrete example: the SLA claim filing module we shipped recently. 920 tests passing, 0 failures. 9 commits. Multiple provider integrations. Here’s how we built it with Claude Code.
The Setup
Claude Code is Anthropic’s CLI-based coding agent. It has access to read and write files, run commands, and make multi-step decisions. We use it for complex implementation tasks where the work is well-specified but the execution is tedious or error-prone.
For the claim filing module, the process was:
Brainstorming session — Claude asked clarifying questions about requirements, we worked through the design decisions (auto-file vs manual, which providers, daily poll vs webhook).
Spec writing — Claude drafted the technical design document, we reviewed and approved it.
Plan writing — Claude wrote a detailed implementation plan with exact file paths, code snippets, and test cases for each task.
Subagent-driven execution — Claude dispatched fresh subagents for each task, with two-stage code review after each: spec compliance check first, then code quality.
The TDD Loop That Actually Worked
For every component, the pattern was:
1. Write the failing test
2. Run it — confirm it fails for the right reason
3. Write minimal implementation
4. Run the test — confirm it passes
5. Run full test suite — confirm no regressions
6. Commit
This isn’t new. TDD is decades old. What’s different with AI is that it follows the discipline even when it’s tedious.
Human developers (myself included) sometimes skip step 2 — “I know why it’ll fail, let’s just implement it.” Sometimes they skip step 5 — “This change is too small to break anything.” AI doesn’t take those shortcuts because it doesn’t feel the time pressure.
For the ConnectorFactory (which builds authenticated provider strategies for AWS, Azure, and GCP), Claude wrote 7 tests before writing a line of implementation. The tests failed correctly. The implementation made them pass. All 7 tests for the factory ran in under a second.
The Two-Stage Review
After each task was implemented, Claude ran two reviews:
Stage 1: Spec compliance. A fresh agent read the implementation and checked it line-by-line against the spec. “Did they implement everything requested? Anything missing? Anything extra?”
This caught real issues. On the get_claim_status() implementation for GCP, the spec reviewer noted that the credential fallback path (no _sa_credentials, falls back to parsing service_account_key) was implemented correctly but had no test. It was added before merge.
Stage 2: Code quality. A separate agent reviewed the code for maintainability, patterns, and correctness. This caught a more serious issue:
On the auto-file hook, ClaimFilingService.file_claim() can return {"status": "assisted"} for legitimate cases (AWS Basic plan, GCP without Support SDK). The initial implementation treated anything other than "submitted" as an error and hit the exception handler, which logged a misleading warning. The quality reviewer caught it. We added an explicit elif result.get("status") == "assisted" branch.
These weren’t bugs that would have caused crashes. They were wrong semantics — the kind of thing that shows up as confusing log output or incorrect metrics six months later.
What the Numbers Look Like
For the claim filing module specifically:
| Task | New tests | Existing tests | Issues caught in review |
|---|---|---|---|
| ConnectorFactory | 10 | 0 | authenticate() return not checked |
| TenantClaimSettings | 6 | 0 | None |
| AWS service code expansion | 0 | 16 (pass) | DRY violation noted |
GCP get_claim_status() | 7 | 10 (pass) | Missing credentials test path |
| Auto-file hook | 6 | 14 (pass) | "assisted" status handled wrong |
| Poll endpoint | 7 | 0 | Unused imports (ruff failure) |
| Duplicate removal | 1 | all (pass) | None |
Total: 37 new tests added for this feature. Full suite: 920 tests, 0 failures.
What Surprised Us
The reviews catch semantic bugs, not just syntax. We expected the AI to catch missing imports and wrong variable names. We didn’t expect it to catch “this status path leads to a misleading log entry that will confuse your on-call engineer at 3am.”
The spec compliance check is more valuable than the quality check. The quality check surfaces issues that will matter in 6 months. The spec compliance check surfaces issues that would have made the feature incomplete on day one.
Fresh context per task is important. Using a new agent for each task means no accumulated context drift — “I think we decided X three tasks ago” doesn’t happen. Each task starts with the exact context it needs.
What It Doesn’t Replace
Architecture decisions. The AI can propose approaches, but the decision about which approach to take is still yours. It doesn’t know your business constraints, your team’s skills, or what’s actually important to your customers.
Domain judgment. When the code quality reviewer flagged the DRY violation in the AWS service code map (identical 27-entry dicts in two files), it was technically correct. We looked at the context — both files existed before this feature, both served similar purposes — and decided the fix was acceptable tech debt for now. That judgment call required knowing the codebase history.
Customer empathy. What to build is a human decision. How to build it well is where AI adds the most value.
Fintropy is a multi-cloud FinOps platform in private beta. Learn more at nuvikatech.com