The Situation

I was handed a legacy payment system built in PHP that I have to migrate over to latest Laravel.

The code was massive, messy, and tightly coupled. We’re talking 800-line methods where payment logic mixed with email sending mixed with logging mixed with everything else.

Two problems:

1. I don’t regularly use PHP
2. This is payments — bugs mean lost money

The kind of project that makes you question your life choices.

The First Instinct: Ask AI

I did what anyone would do in 2024. I threw the code at Claude and asked: “Explain how this payment system works.”

And it gave me this beautiful, clean breakdown. Subscriptions flow here, payments process there, webhooks handle this, refunds work like that. Suddenly I had a map.

But something felt off.

The explanation was suspiciously clean for such messy code.

So I went into the database. Pulled actual payment records. Traced through the logs. And I found quirks AI completely missed — special webhook handling for edge cases, weird refund timing logic, currency precision issues that had been patched over years.

The AI gave me the idealized version, not the real version.

First lesson: AI gives you the most plausible explanation, not necessarily the correct one. Always verify against reality.

The Fork in the Road

At this point I had a choice:

Option A: Understand every weird edge case before doing anything. Could take months.

Option B: Design the right architecture first, then figure out where things fit.

I chose B.

The bet: if I design clean structure, the edge cases will have obvious homes. The mess becomes manageable when you have a framework to organize it.

Generating Options

I asked AI for architectural approaches. It gave me three:

1. Service Layer pattern
2. Event-Driven architecture
3. Strategy Pattern for payment processors

Each with different tradeoffs. None obviously “correct.”

Applying Judgment

Here’s the thing: I’m rusty on PHP. But I know good architecture when I see it. These principles are universal:

• Can I add new payment processors easily?
• Can I test without hitting real APIs?
• Can I trace a payment through the system?
• Can I debug this at 2am when something breaks?

I evaluated each option against these criteria and picked one.

Not because AI said so. Because my judgment said so.

Second lesson: Trust your accumulated knowledge, even in unfamiliar territory. AI suggests, you decide.

Building Clean

I built just the happy path first:

• One payment method
• One currency
• No edge cases yet

Just prove the architecture works.

The result: what was an 800-line method became PaymentService, RefundService, ProcessorInterface, WebhookHandler. Everything had a place.

Third lesson: Build clean structure first. It becomes the framework for understanding complexity.

Adding Complexity Back

Now I started finding all the weird legacy behavior:

• Weekend refund calculations (different business rules)
• Expired card handling
• Currency rounding edge cases
• Retry logic for failed webhooks

But instead of being overwhelmed, I could ask: where does this fit?

Weekend refunds? Goes in RefundService. Expired cards? Goes in the Stripe processor. The clean structure made complexity understandable.

I also used AI differently here. I’d say: “Here’s my RefundService interface, here’s the legacy refund code — what behavior am I missing?”

And it would find things like partial refunds, duplicate attempt handling, precision issues. Things I might have missed.

But here’s critical: not all legacy behavior is worth keeping. Some of that mess was solving problems that don’t exist anymore. You have to decide what matters.

Verification

This is payments. Bugs mean lost money.

I wrote tests that compared the old system to the new one:

• Same inputs → same outputs?
• Same refund amounts?
• Same state transitions?

Used real production data (anonymized).

And yeah, I found differences. Sometimes the new system was correct and the old one had bugs. Sometimes I’d missed something. Every single difference required a conscious decision.

Fourth lesson: Verify everything. AI can help generate tests, but only you can validate they test what actually matters.

What I Shipped

A payment system migration that was:

• Faster than manual would have been
• Cleaner architecture than legacy
• Thoroughly verified and tested
• Something I actually understood

No production incidents.

AI made it possible. Discipline made it responsible.

What Emerged

Looking back, there was a pattern to what worked. A framework I didn’t plan — it just emerged from doing it right.

I’m writing more about this framework in the next post. The phases, the practices, how they work together.

But the core insight is this: AI didn’t make me faster by replacing my thinking. It made me faster by amplifying my judgment.

That’s the difference.

---

Next in this series: The Responsible AI Development Framework — the systematic approach that emerged from this project.