Crear aplicaciones web en Laravel con ayuda de la inteligencia artificial

Hola, ¿cómo están? Llegamos a la última lección del curso.

En la anterior vimos cómo meter inteligencia artificial dentro de tu aplicación. Hoy vemos el otro lado: usarla para construir la aplicación.

Y quiero ser directo con algo desde el principio, porque hay mucho ruido en este tema: la IA es una herramienta excelente para quien ya entiende lo que está haciendo, y una trampa para quien no. Todo lo que vimos en las 39 lecciones anteriores es lo que te permite usarla bien.

¡Empecemos!

Dónde ayuda de verdad

Después de bastante tiempo usándola a diario en proyectos reales, esto es lo que noto que funciona:

El código repetitivo. Un CRUD completo, un Form Request con veinte reglas, un factory, una migración con quince columnas. Es trabajo mecánico donde tú ya sabes exactamente qué quieres y escribirlo solo cuesta tiempo.

Traducir entre formatos. Pasar de un CREATE TABLE a una migración de Laravel, de un JSON a un API Resource, de una consulta SQL a un constructor de consultas. Es de lo que mejor hace.

Explicar código ajeno. Cuando heredas un proyecto y hay un método de doscientas líneas sin un solo comentario, pedirle un resumen ahorra media mañana.

Entender errores. Pegar una traza de error y preguntar qué la causa suele ser más rápido que buscar el mensaje en internet.

Pruebas. Escribir pruebas es tedioso y por eso mucha gente no las escribe. Generarlas y revisarlas cambia bastante esa ecuación.

La primera versión de algo que no dominas. Una integración con una API que no conoces, una consulta compleja, una configuración de despliegue.

Dónde no

Y aquí está la parte que importa más:

Las decisiones de diseño. Cómo modelar las tablas, dónde poner un límite, qué es un servicio y qué un modelo. Eso depende del negocio, y la IA no conoce tu negocio.

La seguridad. El código generado suele funcionar, pero no siempre es seguro. Falta el authorize(), la lista blanca en el orderBy, el filtro por usuario autenticado. Todo lo que vimos en las lecciones de autorización y validación hay que verificarlo a mano.

El rendimiento. El problema N+1 es el ejemplo perfecto: el código generado funciona, pasa las pruebas y es lentísimo. Nada en la respuesta te avisa.

Lo que no sabes evaluar. Si pides algo que no entiendes, no vas a poder distinguir una buena respuesta de una mala. Y es ahí donde la gente se mete en problemas serios.

El contexto lo es todo

La diferencia entre una respuesta útil y una inservible casi siempre está en cuánto contexto diste.

Mal:

Hazme un CRUD de productos en Laravel.

Te va a dar un CRUD genérico, con nombres en inglés, sin validación real, sin autorización y sin encajar con nada de tu proyecto.

Bien:

Necesito un CRUD de productos para un sistema de inventario en Laravel 13.

La tabla productos tiene: codigo (único, hasta 20 caracteres), nombre, categoria_id, precio (decimal 10,2), stock (entero), activo (booleano).

Sigo estas convenciones del proyecto:

• Controladores de recursos con authorizeResource()
• Form Requests separados para guardar y actualizar
• Componente <x-campo> para los formularios
• Mensajes de éxito con ->with('exito', ...)
• Todo en español: variables, rutas y mensajes

El listado necesita paginación de 15, buscador por código o nombre, y filtro por categoría. Solo el rol admin puede eliminar.

Dame el controlador, los dos Form Requests y la vista del listado.

La segunda pide diez veces más y devuelve algo que puedes usar casi tal cual. El tiempo que inviertes escribiendo el contexto lo recuperas con creces en el que no gastas corrigiendo.

Laravel Boost: darle contexto automáticamente

Escribir todo ese contexto en cada pregunta es cansado. Laravel tiene una solución oficial:

composer require laravel/boost --dev
php artisan boost:install

Boost es un servidor MCP que conecta tu asistente con tu aplicación real. El instalador detecta tu editor y tus herramientas, y configura lo necesario.

Lo que gana el asistente:

• Tu esquema de base de datos real, sin que se lo describas
• Tus rutas registradas, con middleware y controladores
• Tus versiones exactas de Laravel y de cada paquete
• Tus logs, para diagnosticar errores
• Tinker, para ejecutar código y comprobar cosas
• Documentación oficial filtrada por tus versiones instaladas

Ese último punto resuelve el problema más molesto de usar IA con Laravel: que te sugiera sintaxis de una versión anterior. Un Kernel.php que ya no existe, un $dates que fue reemplazado por casts(), un routes/api.php que en Laravel 13 hay que crear con install:api.

Boost también instala guías de estilo específicas del ecosistema, adaptadas a los paquetes que tu proyecto realmente usa.

Si vas a trabajar con IA en Laravel de forma habitual, instálalo. Es la diferencia entre un asistente genérico y uno que conoce tu proyecto.

Un detalle práctico: los archivos que genera —.mcp.json, CLAUDE.md, boost.json— pueden ir al .gitignore si prefieres que cada quien configure su entorno.

Cómo reviso el código generado

Esta es mi lista, en el orden en que la aplico:

1. ¿Hace lo que pedí? Suena obvio. A veces la respuesta es elegante y resuelve otro problema.

2. ¿Es de la versión correcta? Señales de código antiguo: Kernel.php, Handler.php, $dates, protected $casts como propiedad en lugar del método casts(), Route::resource con métodos que ya no existen.

3. ¿Falta autorización? Es lo que más se omite. Un controlador generado casi nunca trae authorize().

4. ¿Hay N+1? Busco bucles en las vistas que accedan a relaciones, y verifico que el controlador tenga su with().

5. ¿Valida de verdad? Un 'nombre' => 'required' no es validación. Faltan max, unique, exists.

6. ¿Necesita transacción? Si hay más de una escritura relacionada, sí.

7. ¿Los paquetes existen? A veces sugiere paquetes que no existen o que están abandonados hace años. Compruébalo antes de instalarlo.

8. ¿Lo entiendo entero? Si hay una línea que no sé explicar, no entra al proyecto. Sin excepciones.

Ese último punto es el más importante de la lección. Código que no entiendes es código que no puedes mantener, y en tres meses ese proyecto es tuyo igual.

Trabajar por partes

Pedir «hazme el sistema completo» da un montón de código que nadie revisa y que casi nunca encaja.

Lo que funciona es ir por piezas, verificando cada una:

1. La migración → la ejecuto, reviso la tabla
2. El modelo con sus relaciones → lo pruebo en Tinker
3. El Form Request → mando datos inválidos a ver si los rechaza
4. El controlador → lo recorro entero
5. Las vistas → las abro en el navegador

Cada paso verificado antes del siguiente. Es más lento en apariencia y mucho más rápido en total, porque un error en la migración detectado al final obliga a rehacer todo lo demás.

Casos donde más lo uso

Migraciones desde una base existente. Le paso el SHOW CREATE TABLE y me devuelve la migración. Con una tabla de veinticinco columnas, ahorra veinte minutos de teclear.

Consultas complicadas. Describo lo que necesito y me da el constructor de consultas. Después la reviso con toSql() y explain, que es lo que vimos en el curso de MySQL.

Factories con datos realistas. Nombres bolivianos, cédulas con el formato correcto, teléfonos que parecen teléfonos.

Pruebas. Le doy el controlador y le pido las pruebas de los casos importantes, incluidos los de permisos.

Refactorizar. «Este controlador tiene 300 líneas, ayúdame a separar la lógica en un servicio.» Y después reviso que la separación tenga sentido.

Depurar. Le paso el error y el código relacionado. Acierta con bastante frecuencia.

Lo que aprendí a no hacer

No acepto la primera respuesta sin leerla. Especialmente cuando es larga y se ve bien. El código que se ve bien y está mal es el peligroso.

No le doy datos reales de clientes. Ni credenciales, ni .env, ni volcados de base de datos con información de personas. Si necesito ayuda con datos, los invento.

No la uso para decidir la arquitectura. Le pregunto por opciones, pero la decisión es mía, porque yo soy quien conoce el proyecto y quien va a mantenerlo.

No dejo que escriba las migraciones de producción sin revisarlas línea por línea. Una migración mal hecha en un servidor con datos reales es de los pocos errores realmente difíciles de deshacer.

No pido «arregla esto» sin entender qué está mal. Si no sé cuál es el problema, no puedo evaluar si la solución lo resuelve o lo esconde.

Y sobre aprender

Voy a decir esto con claridad porque me parece lo más importante de toda la lección.

Si estás aprendiendo, escribe el código tú.

La IA te da la respuesta, y eso se siente productivo. Pero entender por qué esa es la respuesta —que es lo que te convierte en desarrollador— requiere haberte peleado un rato con el problema.

He visto gente que lleva meses «programando con IA» y no sabe explicar qué hace un middleware. Esa persona no puede depurar cuando algo falla, no puede decidir entre dos opciones, y no puede saber si lo que le entregaron es correcto.

La IA multiplica lo que ya sabes. Multiplicar por cero da cero.

Mi recomendación concreta: mientras aprendes, úsala para explicar, no para escribir. «¿Por qué esto no funciona?» en lugar de «hazme esto». La diferencia en lo que aprendes es enorme.

Cuando ya domines el tema, entonces sí: deja que escriba lo repetitivo mientras tú te ocupas de lo que importa.

Errores comunes

• Pedir sin dar contexto, y recibir código genérico.
• Aceptar código que no se entiende.
• No verificar la versión y meter sintaxis obsoleta.
• Confiar en la seguridad del código generado.
• Compartir datos reales o credenciales.
• Pedir el sistema entero en lugar de ir por partes.
• Instalar paquetes sugeridos sin comprobar que existen y están mantenidos.
• Saltarse el aprendizaje de los fundamentos.

Para cerrar el curso

Llegamos al final de las 40 lecciones.

Empezamos instalando Laravel y terminamos con agentes de inteligencia artificial, pasando por migraciones, Eloquent, Blade, un CRUD completo, autenticación, colas, APIs, reportes y despliegue. Es, más o menos, todo lo que se necesita para construir un sistema de gestión real y ponerlo en producción.

Si me quedo con una idea de todo el curso, es esta: Laravel resuelve lo mecánico para que tú puedas ocuparte del problema del cliente. Las migraciones, la validación, las colas, la autenticación — nada de eso es tu problema a resolver. Tu trabajo es entender qué necesita el negocio y traducirlo en un sistema que funcione.

La inteligencia artificial acelera ese trabajo, pero no lo reemplaza. Sigue haciendo falta alguien que entienda el problema, tome las decisiones y responda por el resultado.

Si llegaste hasta aquí, ya tienes con qué. Lo que sigue es construir algo.

Y si necesitas ayuda con un proyecto real —o quieres que revisemos el sistema que ya tienes— en Norvic Software es a lo que nos dedicamos.

Gracias por acompañarme en estas 40 lecciones.

Saludos y éxitos.