Ask Claude to Extract Logic from a Fat Controller

Controllers should orchestrate, not implement. When a controller method grows past 50 lines it's usually doing too much — and Claude can refactor it cleanly.

This controller method is doing too much. Extract the business logic into a dedicated
OrderService class. The controller should only handle HTTP concerns: parsing the
request, calling the service, and returning the response. Move validation, database
writes, email dispatch, and event firing into the service.

Claude identifies the HTTP concerns (request parsing, response formatting) and separates them from the business logic (calculations, persistence, side effects), producing a clean service class with a single public method.

Ask it to go further:

Now make OrderService testable in isolation. Replace direct model calls with a
repository interface, and inject the mailer as a dependency so we can mock it
in tests.

Claude will introduce the interface, update the service constructor, and update the service container binding — making the whole thing unit testable without hitting the database.

If you have multiple fat controllers, point Claude at the whole directory:

Look at all controllers in app/Http/Controllers and identify the top 3 that have
the most business logic mixed in. List the methods and what they're doing.

That gives you a prioritised refactoring backlog without reading a single file yourself.

A fat controller is a symptom, not a sin — Claude turns the diagnosis into a diff.