Taylor Otwell is immortal and costs $200/month

What if you could have Taylor Otwell review every piece of Laravel code you write?

Not his tweets. Not his conference talks. The actual Taylor, sitting next to you, telling you when your service class is pointless and your repository pattern is cargo cult programming.

You can. He's available 24/7. He costs about $200/month in Claude credits. And after months of using him on Stagent, I'm convinced this approach produces better Laravel code than I could write alone.

Enter Claude Code sub-agents

Claude Code sub-agents let you create specialized AI assistants with custom system prompts. Think of them as personalities you can invoke for specific tasks. A code reviewer. An architect. A testing specialist.

The key insight: some developers have such well-documented opinions that you can import their philosophy wholesale. They've written books. Given talks. Recorded podcasts. Merged thousands of pull requests with detailed feedback. Their thinking is captured across the internet in enough detail that you can reconstruct how they'd approach any problem.

Taylor Otwell is perfect for this. Fourteen years of Laravel development. Thousands of hours on Laracasts. Laracon keynotes going back a decade. The Maintainable podcast where he talks philosophy. Twitter threads. And most importantly, the Laravel source code itself, which is a masterclass in elegant API design.

His philosophy is clear: elegance over cleverness, convention over configuration, code that's "simple and disposable and easy to change".

The problem with AI code

AI loves to over-engineer.

Give Claude a simple feature request and watch what happens. Repository patterns wrapping Eloquent. Service classes that proxy model methods. Interfaces for classes that will never have a second implementation. Dependency injection ceremonies for operations that should be three lines of code.

It builds enterprise Java inside a framework that exists specifically because PHP doesn't have to feel like enterprise Java.

Taylor warned about this in a recent interview: developers are drawn to building "cathedrals of complexity that aren't so easy to change". He said the best Laravel apps "don't get too clever". That if a developer finds a "clever solution" beyond the standard documented way, "that would be like a smell".

The problem is that AI doesn't know when to stop. It optimizes for looking thorough, not for being simple. It doesn't understand that Laravel's whole point is that you don't need most of this architecture.

The Taylor code reviewer

So I built an agent that catches it.

The core of the system prompt channels Taylor's documented philosophy:

You are an elite code reviewer channeling the philosophy of Taylor Otwell, creator of Laravel.

You believe in code that is:
**Elegant**: Laravel exists because PHP can be beautiful. Every line should prove it.
**Simple**: The best abstraction is often no abstraction. Solve today's problem.
**Expressive**: Code should read like prose. If you need a comment, the code isn't clear enough.
**Conventional**: Laravel has opinions. Follow them. Fighting the framework is a code smell.

You ask yourself:
Would this code fit in a Laravel documentation example?
Does it use Laravel's features idiomatically?
Is this the simplest solution that works?

The agent reviews specs and code against these standards. When it finds over-engineering, it doesn't just flag it. It shows the simpler Laravel way.

Tools like Laravel Boost already give Claude context about your app and Laravel coding guidelines. That helps. But guidelines tell Claude how to write Laravel code, they don't tell it when not to write code at all. The Taylor agent is the second opinion that asks: does this abstraction need to exist? Is this the simplest solution? Boost and the Taylor agent work together: one provides context and conventions, the other enforces ruthless simplicity.

Real examples from Stagent

Let me show you what this looks like in practice. These are real files from Stagent, my booking and artist management platform. The Taylor agent reviewed them. The feedback was brutal.

To test consistency, I ran the agent 40 times across 10 different features. Every review reached the same verdict with 100% agreement. More importantly, it doesn't just criticize everything. It praised good code (our BookingObserver, the MCP tools), caught actual bugs (a Carbon mutation issue, an unused parameter), and only flagged the over-engineered patterns. That's what makes it useful: judgment, not just criticism.

Here are two examples it flagged for deletion.

The service that wraps in_array()

I found this in our codebase:

namespace App\Services\Notifications;

class NotificationTypeDetector
{
    public function hasStatusChange(array $changedFields): bool
    {
        return in_array('status', $changedFields);
    }

    public function isPureStatusChange(array $changedFields): bool
    {
        return count($changedFields) === 1 && in_array('status', $changedFields);
    }

    public function hasAdvancingStatusChange(array $changedFields): bool
    {
        return in_array('advancing_status', $changedFields);
    }

    public function isFieldUpdate(array $changedFields): bool
    {
        return count($changedFields) > 1 ||
               (! in_array('status', $changedFields) && ! in_array('advancing_status', $changedFields));
    }
}

Taylor's review:

This is not Laravel. This is cargo cult programming.

This service class is the textbook example of what Taylor warns against: abstraction for abstraction's sake. We have a 39-line file that wraps four in_array() and count() calls in a class with a grandiose name. Worse, it is not used anywhere in the codebase.

Over-Engineering Alert: Someone imagined a future where "detecting notification types" would become complex. That future never arrived.

The Laravel Way: Delete the file. If you need these checks later, write them inline:

if (in_array('status', $changedFields)) {
    // Handle status change
}

Verdict: Delete it. Do not build architecture for problems you do not have.

The file is gone now.

The action that does nothing

Here's another one. An action class with its interface:

namespace App\Actions\Events\Contracts;

class GenerateEventContractPdf implements GeneratesEventContractPdf
{
    public function __invoke(
        EventContract $contract,
        EventContractParty $party = EventContractParty::Recipient,
    ): ?string {
        return $contract->getPdfContents($party);
    }
}

Plus an interface in a nested Contracts/Contracts folder. Thirty-one lines of code to wrap a single method call.

Taylor's review:

This is architecture astronautics that Laravel explicitly exists to prevent.

This action does nothing. It receives a contract, calls a method on that contract, and returns the result. No additional logic. No coordination. No transaction wrapping. It is a proxy method masquerading as architecture.

The Laravel Way: Delete both files. In your Livewire component, change from:

public function downloadContract(
    GeneratesEventContractPdf $generateEventContractPdf,
    EventContract $contract,
): StreamedResponse {
    return response()->streamDownload(function () use ($contract, $generateEventContractPdf) {
        echo $generateEventContractPdf(contract: $contract);
    }, "{$contract->name}.pdf");
}

To simply:

public function downloadContract(EventContract $contract): StreamedResponse
{
    return response()->streamDownload(
        fn () => print $contract->getPdfContents(EventContractParty::Author),
        "{$contract->name}.pdf"
    );
}

Bottom Line: Laravel is not Java. Stop writing Java in PHP.

That line, "Laravel is not Java", has become a mantra in our codebase.

What I learned

When it comes down to coding, I'm not a framework expert. I'm a professional Googler who learned Laravel by reading docs, copying patterns from tutorials, and asking AI for help. Running the Taylor agent across Stagent showed me that many patterns I'd absorbed - from Stack Overflow, from AI suggestions, from codebases built by developers with different backgrounds - don't actually fit Laravel's philosophy.

The agent doesn't just catch over-engineering. It teaches you why the simpler solution is better. Every review is a mini-lesson in Laravel philosophy, backed by Taylor's actual documented opinions.

This connects to something I've written about before: my struggle with perfectionism. Over-engineering is perfectionism in disguise. It's building for hypothetical futures instead of shipping what works today. The Taylor agent is a check against that instinct.

Here's the thing I didn't expect: this is the first AI coding approach that produces better code than I'd write myself. Not faster code. Not more code. Better code. Simpler. More Laravel.

Is this for everyone?

Yes.

If you're a junior Laravel developer, the Taylor agent accelerates your learning. Instead of absorbing patterns from random Stack Overflow answers, you're learning from the framework's creator.

If you're a senior developer, it catches the Java habits you picked up along the way. The patterns that seemed reasonable at the time but don't fit Laravel's philosophy.

If you're vibe coding with AI, it produces more maintainable output. The code that ships today doesn't become the code you curse tomorrow.

The agent is available as a Claude Code plugin called Taylor Says via the Ryde Ventures plugin marketplace.

# add the marketplace with:
/plugin marketplace add rydeventures/claude-plugins

# then install with
/plugin install taylor-says@rydeventures-claude-plugins

# invoke Taylor with
@taylor

Taylor Otwell has been building Laravel for fourteen years. He's reviewed thousands of pull requests. He's thought deeply about what makes PHP code elegant. Now you can have that perspective on every file you write.

He's immortal. And he costs $200/month.

This article was inspired by Daniel Tenner's excellent DHH is immortal, and costs $200/m, which applies the same concept to Ruby on Rails development.