Poniendo a prueba TRAE 2.0 con Laravel: Formulario de Contacto Avanzado

Primera experiencia con TRAE 2.0

En este vídeo decidí probar TRAE 2.0, un editor de código con inteligencia artificial que permite desarrollar aplicaciones mediante prompts. Era mi primera vez usando esta herramienta, así que quería ver cómo se comportaba con un caso real de Laravel. TRAE ofrece acceso a varios modelos de IA, incluyendo Grok y Claude Sonnet 4, con un plan mensual que actualmente cuesta $3 el primer mes y $10 los siguientes.

El objetivo era simple pero específico: crear un formulario de contacto que siguiera buenas prácticas de arquitectura. No quería un formulario básico, sino uno que implementara el patrón Action de Laravel con Pipeline, procesando los datos a través de una cadena de responsabilidades bien definida.

Configuración del entorno de desarrollo

El desarrollo se realizó en WSL2 con Ubuntu 24.04, usando Laravel 12 con Sail. Este detalle es importante porque con Sail no necesito tener PHP instalado en mi equipo - todo funciona mediante contenedores Docker. Por eso fue crucial especificar en el prompt que todos los comandos debían ejecutarse con vendor/bin, para que TRAE entendiera el contexto y no intentara usar comandos PHP directos.

El prompt inicial: Definiendo requisitos claros

El prompt que proporcioné a TRAE especificaba exactamente lo que necesitaba:

• Un modelo Contact con su migración (campos: email, subject, message)

• Un FormRequest para validación del lado del servidor

• Un controlador invocable que llamara a una acción principal

• Una acción que utilizara Pipeline con un passable

• Dos procesos en cascada: crear el registro en base de datos y enviar la notificación

• Sin validaciones en el cliente ni uso de fetch

TRAE en acción: Generación del código

TRAE comenzó ejecutando los comandos en el orden correcto. Primero creó el modelo y la migración con make:model Contact -m. Me pedía autorización para cada comando, mostrando el terminal donde se ejecutaba todo. Agregó los campos necesarios a la migración y configuró el modelo con los atributos fillable correspondientes.

Luego creó el FormRequest con las reglas de validación apropiadas, la notificación para el email, y las acciones necesarias. En este punto creó SaveContactAction y SendNotificationAction como acciones independientes, cada una con su método handle que recibe los datos y la closure para continuar el pipeline.

El problema detectado: Arquitectura incorrecta

TRAE inicialmente implementó el pipeline directamente en el controlador, pero yo quería que el pipeline estuviera en una acción principal y que las otras fueran procesos de ese pipeline. Detuve el proceso y le especifiqué: "El controlador debe llamar a la acción principal, la cual utiliza el pipeline y ejecuta los otros dos procesos que hemos creado".

Con esta corrección, TRAE creó CreateContactAction como la acción principal que contiene el pipeline, manteniendo las otras dos como procesos. El controlador ahora simplemente llamaba a esta acción principal con los datos validados.

Probando el resultado

Tras aceptar todos los cambios y ejecutar las migraciones, el formulario funcionó correctamente. Sin embargo, noté que TRAE había añadido el atributo required en los campos HTML, proporcionando validación del cliente que yo explícitamente no quería. Eliminé manualmente estos atributos para verificar que la validación del servidor funcionara correctamente.

Al probar el formulario vacío, las validaciones del servidor se mostraron correctamente. Al enviarlo con datos válidos, el registro se creó en la base de datos y la notificación llegó a Mailpit. Todo funcionó en aproximadamente 15 minutos desde el inicio.

Refactorizaciones aplicadas

Aunque el código funcionaba, apliqué algunas mejoras siguiendo mis estándares habituales:

• En el controlador, inyecté la acción directamente en lugar de usar app()

• En CreateContactAction, utilicé el método thenReturn() del pipeline

• En SaveContactAction, usé data_set() para establecer el contacto en el passable

• Eliminé la desestructuración del array ya que los datos venían validados

• Limpié comentarios innecesarios que TRAE había generado

Reflexiones sobre la herramienta

TRAE 2.0 demostró ser capaz de entender requisitos complejos y generar código funcional rápidamente. Para una primera prueba, el resultado fue satisfactorio. La herramienta entendió el contexto de WSL2 con Sail, implementó correctamente los patrones solicitados y generó un flujo completo de trabajo.

Lo importante no es que el código sea perfecto desde el principio, sino tener una base sólida que funcione y que podamos refactorizar según nuestros estándares. TRAE acelera significativamente el desarrollo inicial, pero sigue siendo esencial tener el conocimiento para guiar la herramienta, detectar problemas y aplicar mejoras.

En poco más de 15 minutos obtuvimos un sistema funcional con arquitectura profesional. No es magia, pero sí una herramienta que, bien dirigida, puede acelerar considerablemente nuestro flujo de trabajo manteniendo la calidad del código.