Forem: Sander Muller

[Boost]

Sander Muller — Tue, 14 Apr 2026 08:55:38 +0000

Sander Muller

Apr 14

Building and battle-testing a Laravel package with AI peers

#ai #laravel #opensource #php

Comments

7 min read

Building and battle-testing a Laravel package with AI peers

Sander Muller — Tue, 14 Apr 2026 08:55:09 +0000

I built laravel-fluent-validation, a fluent rule builder for Laravel. Magic strings like 'required|string|max:255' have always bothered me. I tried PRing expansions to Laravel's fluent API, but even small additions got closed with the usual answer: release it as a package instead. So I did.

Along the way I also fixed a performance problem with wildcard validation and built a Rector companion for automated migration.

The interesting part wasn't the package itself. It was the workflow that built and hardened it.

I used four Claude Code sessions. One owned the package, three owned real Laravel codebases that were adopting it. They reviewed each other's work through claude-peers, a peer messaging MCP server. The codebase peers would test, hit edge cases, report back. The package peer would fix, tag a release, and the codebase peers would re-verify. This compressed release-and-feedback loops from days to minutes.

The Rector companion went through eight functional releases in about 24 hours this way. 108 files converted on one codebase, net -1,426 lines of code, 566 tests green after migration with no behavioral regressions observed. But the Rector cycle is just the most compressed example. The same method shaped the performance benchmarks, the Livewire integration, the error messages, the documentation.

The examples below are Laravel-specific, but the method isn't. Isolated AI agents become far more useful when they review changes against multiple real environments with automated verification.

The workflow

claude-peers is an MCP server for Claude Code. Each instance running on your machine can discover other instances, see what they're working on, and send messages. They don't share context. Each has its own conversation with full codebase access.

In practice it works like this: the package peer tags a new release. It sends a message to the three codebase peers saying "0.4.5 tagged, fixes the parallel-worker race, please re-verify." Each codebase peer receives the message, pulls the new version, runs the migration, runs their tests, and sends back results. If something breaks, the response includes the exact error, the file, and usually a theory about why. The package peer reads that, asks follow-up questions if needed, fixes the issue, and the loop continues.

One thing I didn't expect was how quickly the peers developed their own review dynamic. They would challenge each other's assumptions, ask for evidence, and sometimes reach consensus before coming back with a recommendation.

I had four terminals open:

The package repo, building features, writing tests, shipping releases
Three production codebases, each a real Laravel app with its own validation patterns, framework integrations, and test suites

Everything runs locally. Claude Code works on local clones of each codebase, with the same filesystem access you'd have in your terminal. No production servers, no remote environments, no secrets exposed to AI.

Why real codebases beat synthetic fixtures

Running against multiple codebases isn't about redundancy. Each one stresses a different part of the code.

The first app has 108 FormRequests and uses rules() as a naming convention on Actions and Collections, not just validation. The Rector's skip log grew to 2,988 entries and 777KB. The package author expected a near-empty log. At 108 files, it was unusable. On a smaller codebase, you'd never notice. The same app also runs Filament alongside Livewire, and five of its components use Filament's InteractsWithForms trait, which defines its own validate() method. Inserting the package's trait would have created a fatal method collision on first form render. The right fix was to bail and flag those classes for manual review, since the Rector can't know whether the developer intends fluent validation or Filament's form validation.

The second app runs 15 parallel Rector workers. The skip log's "truncate on first write" flag was per-process, so every worker thought it was first and wiped the others' entries. Synthetic test fixtures run single-process. This bug doesn't exist there.

The third app was already on fluent validation with only 7 files left to convert. They tracked Pint code-style fixer counts across releases as an acceptance metric, and found that 5 of their 7 Livewire files had #[Validate] attributes coexisting with explicit validate([...]) calls. Dead-code attributes the package author hadn't anticipated. That drove a whole new hybrid-detection path.

None of these were likely to surface in a fixture-based test suite.

What automated tests still missed

The first app tracked firing counts across every release, how many times each Rector rule fired on their 108-file corpus. On one release, trait-insertion rectors fired zero times. Rector still reported "108 files changed" because the converter rules worked fine. A tester checking that output would have shipped it. The peer tracking counts caught that "108 to 0 on trait rectors" was a regression. The fix landed the same day, and expected counts became a permanent test.

One peer asked a question during a retrospective: "You've tested that the Rector output parses. Have you tested that the runtime semantics match?" Nobody had asked this in nine releases. It led to 16 parameterized test cases asserting that FluentRule and string-form rules produce identical error messages. All 16 passed. But those tests only exist because a peer who didn't write the code asked "prove it."

What peers changed at the design level

Before one release, the package peer was weighing whether to expand detection to handle new Password() constructor calls inside rule arrays. It sounded reasonable, more complete conversion, 30-60 minutes of work. A codebase peer killed it with one observation: the converter is context-free. It runs inside rules() methods and inside attribute arguments. Any expansion would fire in both contexts, silently rewriting code where the developer chose the constructor form intentionally. No test was failing. The feature would have worked in the narrow case it was designed for. The peer prevented it by naming a failure mode the author hadn't considered.

All three codebases reported near-zero ternary rules ($condition ? 'required' : 'nullable'), which was enough to shelve the feature on demand alone. But one peer added a reframe: developers who reach for ternaries in rule arrays are optimizing for terseness, and the closure-form fluent version loses on that axis by construction. Even with demand, the feature might make its target audience's code worse. That moved it from "deferred" to "won't fix."

In both cases, the peer contributed framing, not just evidence.

What made this work

Each Claude instance has full codebase access and its own conversation history. The package peer knows the internals. The codebase peers know their app's patterns, test suites, and integrations. Nobody has to context-switch.

The codebases were real, not demo fixtures. Every bug described above required production-level complexity that doesn't exist in test scenarios.

Automated verification made the loop objective. The package runs PHPStan on level max, Rector, and Pint on every change, with 616 tests and 1,235 assertions. Each codebase peer runs the same stack. When a peer reports "PHPStan clean, 566 tests green, Pint fixer count down from 3 to 2," you can trust the result.

The back-and-forth was fast because it stayed in the same session. Tag a release, three codebases verify, issues come back with exact errors and hypotheses, fix ships, re-verify. The whole cycle in 15-30 minutes. GitHub issues lose context between messages. These peers kept corpus knowledge across every release.

And the peers could challenge scope, not just report failures. The new Password() conversation and the ternary-rule reframe both came from peers who could say "I don't think you should build this" with technical reasoning.

What this workflow costs

Running four Claude Code sessions in parallel means watching your weekly usage limits and session caps burn in front of your eyes. It's worth it for a focused release cycle, but you feel the cost. For a solo contributor, the same process works across sequential sessions. You'd lose the synchronous loop but keep the corpus context.

The workflow also has a blind spot: if all test codebases share the same architectural assumptions, peers can miss the same category of bug together. The three-codebase model worked here because each app had genuinely different patterns: scale, parallel execution, hybrid Livewire attributes. If all three had been small Livewire apps, the skip-log volume and parallel-worker bugs would have shipped uncaught.

When I would and wouldn't use this

I'd use this workflow for packages or tools that modify other people's code: Rector rules, code generators, migration tools, linters. The cost of a silent-rewrite bug is high, and running against codebases you didn't write is the most reliable way to catch them before release.

I'd also use it for packages with integration surface across frameworks. Livewire, Filament, and Inertia all have their own quirks. A peer running on a codebase that actually uses Filament + Livewire together will find trait conflicts and method collisions that your test suite won't.

For a simpler utility package with a narrow API surface, I'd scale it down. One project peer instead of three. You still get the "does this actually work in someone else's codebase" signal without the overhead of a full multi-peer setup.

The surprising part was that multiple isolated peers, each grounded in a different real codebase, acted more like an internal design-and-QA loop than an autocomplete tool. That changed what got built, what got cut, and what got tested.

The package: laravel-fluent-validation -- fluent validation rule builders with up to 160x wildcard performance gains, full Laravel parity, Livewire and Filament support.

The Rector companion: laravel-fluent-validation-rector -- automated migration from string rules. 108 files converted on one production codebase, -1,426 LOC, 566 tests green.

The peer messaging: claude-peers

AI skills for Laravel packages: package-boost -- ships migration guides, optimization hints, and framework-specific gotchas alongside your package so each peer has context without manual setup.

[Boost]

Sander Muller — Tue, 07 Apr 2026 15:57:17 +0000

Sander Muller

Apr 7

Laravel's wildcard validation is O(n ) — here's how to fix it

Comments

7 min read

Laravel's wildcard validation is O(n ) — here's how to fix it

Sander Muller — Tue, 07 Apr 2026 15:55:22 +0000

I maintain several large Laravel applications. Last year I was profiling an import endpoint that accepts JSON payloads with up to a hundred items. Each item has around 47 fields, many with conditional rules like exclude_unless and required_if. The endpoint was taking 3.4 seconds. I assumed it was database queries.

It wasn't. Validation alone was taking 3.2 of those 3.4 seconds. The database work was 200ms.

I spent a good part of a day on finding out why. Once I figured out what was causing it, I submitted 10 performance PRs to Laravel. Most were closed. As Taylor always says: "Consider releasing it as a package". So I did, and it brings that 3.2s down to 83ms of time spent on validation.

What actually happens when you validate arrays

When you write this:

'items.*.name' => 'required|string|max:255',
'items.*.qty'  => 'required|numeric|min:1',

Laravel's explodeWildcardRules() expands the wildcards into concrete rules for every item in the data:

items.0.name => required|string|max:255
items.0.qty  => required|numeric|min:1
items.1.name => required|string|max:255
items.1.qty  => required|numeric|min:1
items.2.name => required|string|max:255
...
items.499.name => required|string|max:255
items.499.qty  => required|numeric|min:1

For a simpler example: 500 items with 7 fields gives you 3,500 concrete rules. The expansion works by matching each wildcard pattern against every key in the flattened data array. That's where the O(n²) comes from — for every wildcard rule, it scans every data key.

That's not the only cost. During validation, each attribute runs through validateAttribute() which evaluates every rule — including exclude_unless and exclude_if. These exclusion rules call dependent-rule parameter resolution and accumulate excluded attributes. After the main loop, shouldBeExcluded() checks each attribute against that list and removes excluded ones. For conditional-heavy payloads, the cost of evaluating all those exclusion rules dominates. With 100 items and 47 conditional patterns, you end up with 4,700 concrete rules, each evaluating its exclusion conditions.

Here's a simplified view of what the validator is doing:

for each of 4,700 expanded attributes:
    for each rule on this attribute:
        parse the rule string                       ← repeated for identical rules
        resolve the value from nested data          ← Arr::dot() on every access
        evaluate exclude_unless/exclude_if          ← dependent-rule parameter resolution
        run the validation logic
    check if attribute was excluded                  ← scans excludeAttributes list

Multiply that inner loop by 4,700 and you have your 3.2 seconds.

How I found it

I started with Laravel Telescope, which showed the validation taking most of the request time but didn't show why. So I switched to Xdebug's profiler and opened the trace in KCachegrind.

explodeWildcardRules() was eating 35% of validation time — converting Arr::dot() output to regex patterns, then matching every wildcard against every key. Exclusion rule evaluation (validateExcludeUnless, validateExcludeIf, and the dependent-rule parameter resolution they trigger) took another 28%. ValidationRuleParser::parse() accounted for 15%, parsing the same rule strings hundreds of times because there's no caching between items.

The remaining 22% was scattered: BigNumber for simple integer comparisons that could've been native PHP, repeated hasRule() calls, message placeholder replacement on strings that had no placeholders.

What I tried upstream

On March 15, 2026, I submitted 10 performance PRs to laravel/framework:

Traverse data directly for wildcard expansion instead of Arr::dot() + regex
Cache parsed string rules to avoid re-parsing identical rules across items
Pre-compute bail/nullable/sometimes flags instead of calling hasRule() repeatedly
Use native PHP comparison for size validation instead of BigNumber
Short-circuit shouldStopValidating() when no errors exist yet
Cache Arr::undot() results in Rule::compile()
Skip placeholder replacements when the message template has none
Use array_push with spread in MessageBag::all()
Cache route instances in CompiledRouteCollection::getByName()
Avoid redundant Util::getParameterClassName() in the container

The last four were merged. The six validation-specific ones were all closed. I resubmitted the wildcard traversal PR (#59287) against the 13.x branch with benchmarks from a real application. Closed again.

What I tried that didn't work

Before building a package, I tried a few things.

Splitting the payload into chunks and validating each chunk separately. Helps with memory, but the O(n²) expansion still runs per chunk, and error messages lose their original indices.

Rule::forEach() instead of wildcard rules. It uses NestedRules::compile() to generate per-item rules, avoiding explodeWildcardRules(). But the compilation overhead per item — instantiating rule objects, re-parsing strings, resolving callbacks — meant it was actually slower for simple cases.

Pre-expanding rules manually before passing them to the validator. This skips the expansion cost but you still pay for exclusion rule evaluation during validation. Half the problem, not the whole thing.

I also tried caching the validator instance across requests, but rules change with every payload — different item counts mean different expanded rules.

The fundamental issue is that Laravel's validator works well up to maybe 50-100 rules. Beyond that, the linear scans become quadratic.

The fix

Since the fixes couldn't go upstream, I built them into laravel-fluent-validation. The HasFluentRules trait plugs into your existing FormRequest and applies three optimizations.

The first optimization replaces the O(n²) wildcard expansion with O(n) tree traversal. Instead of flattening the data with Arr::dot() and matching regex patterns against every key, WildcardExpander walks the data tree once and emits concrete paths as it descends. For 500 items with 7 fields, all those regex matches become a single tree walk. It also skips the intermediate Arr::dot() array, which saves memory on large payloads. About 20% faster by itself.

The second optimization makes the biggest difference on simple rules. The package compiles PHP closures for 25 common rules — string, numeric, integer, boolean, email, url, ip, uuid, in, regex, and others. Each closure is a few is_string() / strlen() / in_array() calls. During validation, each item hits the closure first. Pass? Laravel's validator never sees it. Fail? That item goes through Laravel for the correct error message.

is_string($v) && strlen($v) <= 255 takes nanoseconds. Laravel's validator doing the same check goes through rule parsing, method dispatch, BigNumber size comparison, and message formatting — even when the value is valid. Custom Rule classes, closures, and anything the package doesn't recognize pass through to Laravel untouched.

The third optimization targets conditional rules. For exclude_unless and exclude_if, the package evaluates the conditions before the validator starts and removes excluded attributes from the rule set entirely. Instead of 4,700 rules where each attribute evaluates its exclusion conditions at validation time, the validator only sees the ~200 rules that actually apply.

You don't need to change your rules. Just add the trait:

use SanderMuller\FluentValidation\HasFluentRules;

class ImportRequest extends FormRequest
{
    use HasFluentRules;

    // your existing rules() method, unchanged
}

The numbers

These benchmarks run in CI on every PR. The data is randomly generated each run; the numbers are median of 3 runs.

Scenario	Native Laravel	With HasFluentRules	Speedup
500 items × 7 simple fields (string, numeric, in)	~200ms	~2ms	97x
500 items × 7 mixed fields (string + date comparison)	~200ms	~20ms	10x
100 items × 47 conditional fields (exclude_unless)	~3,200ms	~83ms	39x

97x on simple rules because every field is fast-checkable and the validator only runs for items that fail. 10x on mixed rules because string and numeric fields use closures while date comparisons still go through Laravel. 39x on conditional rules comes almost entirely from pre-evaluation removing excluded attributes before the validator starts.

If your form has 5 fields, validation takes ~1ms either way. Nobody cares. But if you're validating a CSV import with 500 rows or an API endpoint accepting a batch of orders, 200ms vs 2ms is the difference between a page that feels instant and one that feels broken.

Is this safe?

The closures implement the same logic as Laravel's validator — is_string(), is_numeric(), filter_var(), the same checks. If a fast-check passes, the value would have passed Laravel's validator too. If it fails, that value goes through Laravel's full validation pipeline for the correct error message and rule identifier.

The package has 516 tests and 1,020 assertions, and benchmarks run in CI on every PR. It's Octane-safe (factory resolver restored via try/finally, no static state between requests).

When you don't need this

If your form requests have fewer than ~50 expanded rules, the standard validator is fine. The overhead is negligible at that scale. This package solves a specific problem: array validation with hundreds or thousands of items where wildcard expansion and per-attribute scanning become the bottleneck.

If you're not sure whether validation is your bottleneck, profile first. Laravel Telescope shows total request time breakdowns. If validation isn't in the top 3, you have bigger fish.

Try it

composer require sandermuller/laravel-fluent-validation

Add use HasFluentRules to a FormRequest with wildcard rules and run your benchmarks. The performance optimization works with your existing string rules — just add the trait. There's also a fluent rule builder API with IDE autocompletion (FluentRule::string()->required()->max(255)) but the performance fix is the real reason you want this.

I've deployed this across all the large applications I maintain — around 80 files converted, thousands of tests passing, zero behavioral regressions. Each codebase surfaced different edge cases (Livewire's rule key pre-reading breaking each(), Filament's trait collision with the validation override) and the package got better each time.

If you've ever wondered why your import endpoint is slow, check validation before reaching for query optimization. It might be where 90% of the time goes.

https://github.com/SanderMuller/laravel-fluent-validation

These optimizations belong in the framework. I'll keep advocating for that upstream while maintaining the package. The performance issue is tracked in laravel/framework#49375.