Desarrollo de software con Devin: Enviar una rodaja vertical (2ª parte)

¡Bienvenido de nuevo! En el primer tutorial de esta serie, Devin desempolvó mi antiguo repositorio fp-ts-exercises y abrió un PR de actualización de dependencias. En esta segunda parte, aumentaremos la dificultad y construiremos funciones de pila completa.

Puedes acceder a todos los tutoriales de la serie Devin aquí:

1. Configuración y primera Pull Request (Parte 1)
2. Enviar una rodaja vertical con Devin (2ª parte) 
3. Integraciones, pruebas y CI/CD (3ª parte) 
4. Seguridad, implantación y mantenimiento (4ª parte)

Cuando llegues al final de esta segunda parte, ya lo habrás hecho:

• A Zona de juegos Next.js 14 donde los alumnos editan código en el navegador;
• Pruebas Vitest en vivo que se vuelven verdes (o rojas) en tiempo real; y
• A NestJS con base de datos SQL que guarda el progreso con nada más que un UUID anónimo en localStorage.

Por el camino, dejaremos que Devin genere su propia lista de tareas, veremos cómo hace malabarismos con los tickets front-end y back-end, y cómo interviene cuando tropieza con problemas de configuración. Te mostraré dónde gasté (y ahorré) ACUs, qué arreglé a mano y cómo mantener sesiones eficientes.

Recapitulación y requisitos previos

A lo largo de esta serie de tutoriales, trabajaremos en mi (anteriormente) abandonado repositorio de ejercicios fp-ts.

El proyecto es una colección de pequeños retos destinados a enseñar conceptos de programación funcional (como Opción, Cualquiera, etc.) en TypeScript. Ahora mismo, es un repositorio de clonar y ejecutar: los alumnos lo descargan, editan los archivos localmente y ejecutan las pruebas en su propio terminal.

El objetivo es convertir esos ejercicios en un patio de recreo interactivo basado en un navegador, en el que la gente pueda leer una explicación, retocar el código en un editor dentro de la página y ver que las pruebas pasan (o fallan) al instante. Los alumnos también tendrán la oportunidad de iniciar sesión para guardar sus progresos.

Lo que conseguimos en la primera parte

Recuerda que en el primer tutorial:

• Modernizado el antiguo repositorio fp-ts: últimas dependencias, linting, comprobaciones de tipo.
• Conecta Devin a GitHub y prueba que puede abrir un pull request limpio.

Herramientas locales que necesitas para la segunda parte

Para este segundo tutorial, necesitaremos

• Node 20+ y npm 10 (viene con soporte para espacios de trabajo de fábrica).
• Docker ejecutando un contenedor PostgreSQL (o una instancia PostgreSQL local).

Ajustes recomendados de Devin

Recomiendo los siguientes ajustes para Devin:

• Establece un tope suave de 5 ACUs por sesión en Configuración > Uso y límitesy crearemos una nueva sesión para cada fase.
• Mantén visible la pestaña timelapse para pausar o dar un codazo a Devin si se estanca.

Deja que Devin escriba el plan de juego

Pensé que sería interesante empezar poniendo a prueba la capacidad de planificación de Devin. Creé un aviso y le pedí a Devin, utilizando la función "Preguntar" (actualmente gratuita en Beta), que me ayudara a planificar el trabajo que haríamos hoy.

Prompt:

Quiero convertir mi actual repositorio fp-ts-exercises Node + TypeScript (actualmente ejercicios CLI de clonar y ejecutar) en una plataforma de aprendizaje basada en navegador que realice un seguimiento del progreso. 

Experiencia objetivo: 

- Los alumnos abren una aplicación web Next.js, eligen un ejercicio, editan el código en el navegador y ven cómo las pruebas de Vitest pasan o fallan al instante. 

- El progreso (slugs completados) se almacena en el servidor y se recarga en visitas posteriores, pero aún no añadimos cuentas de usuario (utilizamos un UUID anónimo almacenado en el navegador). 

Opciones técnicas por las que me inclino: 

- Frontend: Next.js 14 (React 18, App Router) 

- Editor y ejecutor de código: Sandpack + @vitest/browser 

- API: NestJS 13 con @nestjs/graphql (controlador Apollo) 

- Base de datos: Prisma 5 con PostgreSQL 

- Espacio de trabajo: espacios de trabajo npm simples (apps/web, apps/api, packages/exercises) 

Propón un plan de aplicación paso a paso (lista de tareas) que dé vida a este corte vertical. Estima el coste ACU relativo de cada tarea y señala los pasos de larga duración (por ejemplo, migraciones grandes o instalaciones de dependencias pesadas).

Devin nos devolvió una lista de tareas de seis fases con estimaciones de ACU para cada una, y marcó los pasos de "instalación de dependencia pesada".

Respuesta de Devin:

Fase 1: Configuración del espacio de trabajo (2-3 ACU)

• Inicializar la estructura del espacio de trabajo npm (1 ACU)
• Crea apps/web, apps/apiy paquetes/ejercicios directorios
• Configurar raíz paquete.json con las definiciones del espacio de trabajo
• Mover los archivos de ejercicios existentes a paquetes/ejercicios/src/
• Configurar el frontend Next.js 14 (1-2 ACU - Long-running: instalación de dependencias)Inicializa Next.js con App Router en apps/webConfigura TypeScript y Tailwind CSSConfigurar la estructura básica de enrutamiento

Fase 2: Migración del Paquete de Ejercicios (3-4 ACU)

• Extraer el contenido del ejercicio al paquete compartido (2 ACU)
• Crea paquetes/ejercicios con extracción de metadatos de ejercicios
• Analiza los archivos de ejercicios existentes para extraerlos:
• Instrucciones
• Código de inicio
• Soluciones
• Definir interfaces TypeScript para la estructura del ejercicio
• Poner en marcha el sistema de detección de ejercicios (1-2 ACU)
• Construye un escáner del sistema de archivos (como fs.readdirSync en ejercicio.js:17-28)
• Exportar metadatos del ejercicio: título, descripción, dificultad, pruebas

Fase 3: API Backend (4-5 ACU)

• Configurar la API NestJS con GraphQL (2 ACU - De larga duración: instalación de dependencias)
• Inicializa el proyecto NestJS en apps/api
• Configurar el servidor Apollo GraphQL
• Configurar puntos finales básicos de comprobación de salud
• Implementar Prisma + PostgreSQL (2 ACU - De larga duración: configuración de la base de datos)
• Esquema de diseño para:
• Sesiones de usuario
• Ejercicios completados
• Configurar el cliente Prisma y las migraciones
• Crear resolvedores de seguimiento del progreso
• Gestión de sesión de usuario anónimo (1 ACU)
• Generar UUID y almacenarlo en el navegador localStorage
• Activar la persistencia del progreso basada en la sesión sin autenticación

Fase 4: Funciones básicas del frontend (5-6 ACU)

• Interfaz del navegador de ejercicios (2 ACU)
• Listar ejercicios por categoría (opción, o bien, tareaetc.)
• Mostrar indicadores de progreso y estado de finalización
• Habilitar la selección de ejercicios y la navegación
• Integración del editor de código Sandpack (2-3 ACU - De larga duración: Configuración Sandpack)
• Configurar Sandpack con soporte TypeScript
• Carga el código de arranque y fp-ts dependencias
• Configurar el sistema de archivos para los archivos de ejercicio + prueba
• Integración del navegador Vitest (1 ACU)
• Sustituye execSync las llamadas a Vitest (ejercicio.js:45-47) por @vitest/navegador
• Permite la ejecución de pruebas y la visualización de resultados en tiempo real

Fase 5: Seguimiento del progreso (2-3 ACU)

• Gestión del progreso del cliente (1 ACU)
• Configurar el Cliente Apollo para GraphQL
• Sincroniza el progreso con el backend
• Detección de finalización del ejercicio (1-2 ACU)
• Adaptar la lógica de detección de éxito existente (ejercicio.js:48-49)
• Activar actualizaciones de progreso del backend al pasar la prueba

Fase 6: Pulido y Despliegue (2-3 ACU)

• Mejoras UI/UX (1-2 ACU)
• Garantizar un diseño adaptable
• Añadir estados de carga y gestión de errores
• Mejorar la visualización de las instrucciones del ejercicio
• Configuración del despliegue de producción (1 ACU)
• Configura Docker para ambas aplicaciones
• Gestionar variables de entorno
• Configurar el despliegue de la base de datos

Coste total estimado: 18-24 ACU

El plan era bastante bueno en general. He cambiado algunas cosas, sobre todo en la fase seis, ya que abordaremos el despliegue en el cuarto tutorial.

Fase 1: Espacio de trabajo y andamio frontal

Objetivo: Crea espacios de trabajo npm, mueve los archivos heredados y arranca un terminal Next.js 14 en blanco.ACU burn: 3,66 (previsto 1-2).Resultado: El repositorio tiene ahora /apps/web, compartido packages/exercises, y una aplicación Next.js preparada para Tailwind que se ejecuta en localhost:3000.

El aviso

Le pedí a Devin que construyera el plan que hizo para la primera fase. Agentic Devin no tiene contexto de lo que previamente podrías haber preguntado en la función "Preguntar a Devin", así que tienes que crear una pregunta aparte y proporcionar el contexto. 

No voy a pegar todas las indicaciones en este artículo, pero aquí está la primera:

Prompt:

Tarea: Inicializar la estructura del espacio de trabajo npm y el frontend Next.js para la plataforma de navegador fp-ts-exercisesContexto:

Estoy convirtiendo mi actual sistema de aprendizaje basado en CLI fp-ts-exercises en una plataforma basada en navegador. El sistema actual tiene los ejercicios organizados en 10-from-either.exercise.ts:1-3 con la configuración de TypeScript en tsconfig.json:88 y la configuración de Vitest en vitest.config.ts:7 .

Requisitos:

• Crea la estructura del espacio de trabajo npm:
• Paquete raíz.json con la configuración del espacio de trabajo para apps/web, apps/api, paquetes/ejercicios
• Mover los archivos de ejercicios existentes del src/ actual a packages/exercises/src/
• Conserva la convención actual de nombres de archivos de ejercicios (.ejercicio.ts y .solución.ts)
• Inicializa el frontend Next.js 14 en apps/web:
• Utiliza el Enrutador de Aplicaciones (no el Enrutador de Páginas)
• Configura TypeScript con ajustes estrictos similares a los actuales tsconfig.json:88
• Añadir CSS de Tailwind para estilizar
• Crear una estructura básica de rutas para la navegación de ejercicios
• Mantén la compatibilidad:
• Asegúrate de que la estructura de ejercicios y las importaciones existentes siguen funcionando
• Mantener las dependencias fp-ts accesibles en todo el espacio de trabajo
• Conservar los patrones actuales de configuración de Vitest

Resultados:

• Paquete.json configurado en el espacio de trabajo en la raíz
• Aplicación Next.js en apps/web/ con TypeScript y Tailwind
• Ejercicios migrados en paquetes/ejercicios/
• Estructura básica de enrutamiento (/ejercicios, /ejercicios/[categoría], /ejercicios/[categoría]/[slug])

Pila tecnológica:

• Next.js 14 con App Router
• TypeScript (modo estricto)
• Tailwind CSS
• espacios de trabajo npm (no yarn/pnpm)

Presentación:

• Asegúrate de que el script lint y typecheck pasan
• Crea un RP con tus cambios

Todos los avisos que escribí posteriormente seguían el mismo patrón: tarea destacada, contexto, requisitos, entregables, pila tecnológica y detalles de presentación.

Lo que Devin hizo en realidad

Tardó bastante en decidir su curso de acción (unos cuatro minutos), pero lo hizo:

1. Creado el esqueleto del espacio de trabajo
2. Migrado todas las carpetas de ejercicios a packages/exercises/src.
3. Arranca Next.js 14 con App Router, TypeScript y Tailwind.
4. Se han añadido scripts de comprobación de tipo y de pelusa a la aplicación del frontend (después de que le diera un codazo).

Por qué se disparó el coste de la ACU

El coste de la ACU aumentó porque:

• Devin se pasó un minuto entero haciendo un bucle en npm install reintentos después de que se agotara el tiempo de espera de una réplica.
• Intentó detener el servidor devs y los procesos con q en Vim, luego Ctrl-C, y ambos fallaron. Le di un poco de tiempo para que intentara arreglarlo por sí mismo, pero acabé interviniendo manualmente y saliendo de los procesos las dos veces. Cada minuto extra significaba ACUs extra, y no habría detectado este problema rápidamente si no hubiera seguido de cerca las acciones de Devin.

Intervenciones humanas y lecciones aprendidas

Aquí tienes un resumen de las correcciones que tuve que hacer:

Mover grandes árboles de archivos es más rápido a mano, y mucho menos caro, ya que Devin cobra por tiempo/tarea. Arrastré las carpetas, las confirmé y dejé que el agente recogiera la nueva estructura. Pudo extraer mis cambios sin problemas y hacer una fusión por sí mismo.

Dicho esto, tuve que pedirle que ejecutara los scripts lint y typecheck, aunque lo hubiera especificado en mi solicitud inicial. Al final corrió a los dos, pero fracasaron. Aun así, Devin lo consideró un éxito y siguió adelante con las relaciones públicas.

Arreglé ambos problemas localmente, ejecuté los scripts yo mismo y puse en marcha el nuevo servidor de desarrollo web para asegurarme de que se iniciaba como estaba previsto, y envié el commit.

Fase 2: Empaquetar los ejercicios

Objetivo:  Extrae todos los archivos de los retos en un paquete reutilizable packages/exercises y genera metadatos para cada ejercicio.Quema ACU:  0,6 (previsto 2+).Resultado: El paquete compartido exporta metadatos tipificados que la aplicación web y la futura API pueden importar con import { exercises } from '@exercises/registry'.

Lo que Devin hizo en realidad

Creó Devin:

• Interfaces TypeScript estructuradas para ejercicios, metadatos, categorías y el catálogo completo.
• Ejercicio analizador sintáctico que:
• Extrae metadatos de comentarios de código y firmas de funciones
• Analiza el código de inicio, el código de la solución y los casos de prueba Vitest
• Genera automáticamente etiquetas a partir del uso de fp-ts
• Convierte los nombres en camelCase en títulos legibles
• Sistema de descubrimiento de ejercicios que:
• Busca en el sistema de archivos los pares .exercise.ts y .solution.ts
• Construye un catálogo basado en slug (por ejemplo, option-01 )
• Organiza los ejercicios por categorías con almacenamiento en caché para mejorar el rendimiento
• Exportaciones cómodas para consultar ejercicios y categorías:
• getExercises(), getExerciseBySlug(), getExercisesByCategory(), getCategories(), getCategoryBySlug()

Por qué Devin acabó por debajo del presupuesto

Devin consiguió mantener bajo el coste de la ACU: así lo hizo:

• Sin instalaciones pesadas ni llamadas a la red
• Los movimientos de archivos fueron sencillos; Devin utilizó git mv (barato) en lugar de copiar-pegar más diff
• La generación de metadatos era puro TypeScript, rápido de planificar y ejecutar

Intervenciones humanas

Esta vez, ¡nada!

Aprendiendo de la última vez, comprobé la rama de Devin y ejecuté los scripts localmente. Todo se compiló y el registro exporta definiciones de tipos limpias, lo que lo convierte en el material de entrada perfecto para la interfaz de usuario y la API que construiremos a continuación.

Fase 3: NestJS + GraphQL API

Objetivo: Monta un servicio NestJS 13 que exponga el progreso del ejercicio mediante GraphQL y persista los datos en PostgreSQL con Prisma.ACU burn: 4.2 (previsto 4).Resultado: apps/api botas en localhost:4000/graphql. Puedes consultar y modificar los registros de progreso mediante un identificador de sesión anónimo.

Lo que Devin hizo en realidad

Para la tercera fase, Devin:

1. Creada una API NestJS completa en apps/api con TypeScript y Apollo GraphQL
2. Integra PostgreSQL con Prisma ORM y configura el esquema con los modelos Session y CompletedExercise
3. Gestión de sesiones anónimas mediante UUID (sin necesidad de autenticación)
4. Construimos resolvedores GraphQL para la creación/validación de sesiones, consultas de ejercicio y seguimiento del progreso
5. Conectado el backend al paquete de ejercicio compartido (packages/exercises ) para el descubrimiento de datos
6. Configurado CORS para soportar la comunicación con el frontend Next.js
7. Garantizar la compatibilidad tipográfica entre el esquema GraphQL y las interfaces TypeScript existentes
8. Establecer scripts de desarrollo, flujo de migración de bases de datos e integración con Prisma Studio

Dónde tropezó Devin

Estos son los problemas que encontré durante la tercera fase y las correcciones que tuve que hacer:

Lecciones aprendidas

Estas son mis conclusiones:

• Config vs. código: Devin destaca una vez que el framework está en su sitio, pero para diagnosticar problemas de dependencia sigue haciendo falta un ojo humano.
• Ejecútalo siempre localmente: Ya había creado una base de datos PostgreSQL local en mi máquina, y las instrucciones de PR para ejecutar la migración de Prisma e iniciar el entorno de desarrollo eran claras y fáciles de seguir (véase la imagen siguiente). El comentario de Devin decía que había conseguido ejecutar la API localmente, pero npm run dev se bloqueó hasta que se añadió reflect-metadata .

• A Devin se le dan bien los comentarios de relaciones públicas. Comenté el PR, explicando a Devin que había intentado ejecutar la API localmente y había encontrado un error. Inmediatamente me dio un emoji de un ojito, y la sesión se reanudó sola para solucionar el error, y se envió una solución unos minutos después.

• Comprueba siempre si hay archivos secretos: Devin había enviado un archivo .env con una variable DATABASE_URL, que contenía un nombre de usuario y una contraseña ficticios. Una vez extraído localmente, cambié el nombre de usuario y la contraseña por los identificadores de mi base de datos local y me aseguré de eliminar el archivo del sistema de seguimiento git y añadirlo a .gitignore. Veremos en futuros tutoriales cómo manejar los secretos con seguridad.

Fase 4: Zona de juegos Sandpack y pruebas en vivo

Objetivo: Proporciona a los alumnos un editor de navegador que ejecute soluciones fp-ts y comprobaciones Vitest en tiempo real.Quema ACU: 7.2 (previsto 3-4).Resultado: Al visitar /exercises/option-01 se abre una vista dividida: El editor Sandpack a la izquierda, el túnel de pruebas a la derecha, y aparece un mensaje de éxito en el momento en que se superan todas las especificaciones.

Lo que Devin hizo en realidad

Esto es lo que hizo Devin en la cuarta fase:

• Páginas de navegación y listados de ejercicios con soporte dinámico de categorías y slug
• Editor Sandpack integrado con TypeScript, fp-ts y compatibilidad con el sistema de archivos en tiempo real
• Se ha sustituido el ejecutor de pruebas CLI por Vitest en el navegador y comentarios en directo
• Conecta el frontend al backend a través de Apollo Client para el seguimiento del progreso basado en sesiones
• Implementación de una interfaz de usuario responsiva con estados de carga y gestión de errores

Donde Devin quemó ACUs extra

Devin quemó más ACUs de lo esperado para esta fase: he aquí por qué:

Lecciones aprendidas

Mis conclusiones esta vez son:

• Mirar en silencio = quemar dinero. Mantén abierta la pestaña Timelapse, y si Devin hace un bucle, dale un codazo o haz una pausa.
• Elimina pronto el código muerto. En realidad, Devin no borra el código obsoleto por sí mismo, a menos que tú se lo indiques. Antes cometí el error de pedirle que moviera archivos sin que le dijeraexplícitamente que los borrara, y así acabamos con múltiples puntos de entrada que confundieron mucho al pobre Devin en esta fase.

Devin se tomó un tiempo aquí. Bucle for y bucle for, intentando salvar los mismos problemas, no conectando correctamente el backend y el frontend, haciendo cambios, reiniciando los servidores, comprobando en el navegador si funcionaba, etc. Era como un trabajo de desarrollo normal, supongo...

Ahora tenemos una aplicación funcional. Pude iniciar tanto la API como los servidores web, navegar hasta localhost, editar la función stub, pulsar Guardar y ver cómo el panel de prueba pasaba de rojo a verde. Entonces me di cuenta de que sólo hacía el trabajo a medias, y codifiqué el test y la solución del primer ejercicio en cada página de ejercicios. Se lo señalé y, después de más bucles, pudo corregirlo y enviar sus correcciones.