Curso
Developing LLM Applications with LangChain
3 h
24.4K
¡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í:
- Configuración y primera Pull Request (Parte 1)
- Enviar una rodaja vertical con Devin (2ª parte)
- Integraciones, pruebas y CI/CD (3ª parte)
- 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:
- Creado el esqueleto del espacio de trabajo
- Migrado todas las carpetas de ejercicios a
packages/exercises/src. - Arranca Next.js 14 con App Router, TypeScript y Tailwind.
- 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 installreintentos después de que se agotara el tiempo de espera de una réplica. - Intentó detener el servidor devs y los procesos con
qen Vim, luegoCtrl-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:
|
Fix |
Tiempo |
Cómo lo hice |
|
Eliminada la tarea de vigilancia del nodo colgado |
15 s |
Proceso eliminado en el terminal VM. |
|
Reinstalar Tailwind |
90 s |
npm install tailwindcss postcss autoprefixer --workspace=apps/web y reran tailwind init. |
|
Añadido .next/ a .gitignore |
10 s |
Comprometido manualmente para evitar PRs hinchados. |
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.tsy.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:
- Creada una API NestJS completa en
apps/apicon TypeScript y Apollo GraphQL - Integra PostgreSQL con Prisma ORM y configura el esquema con los modelos
SessionyCompletedExercise - Gestión de sesiones anónimas mediante UUID (sin necesidad de autenticación)
- Construimos resolvedores GraphQL para la creación/validación de sesiones, consultas de ejercicio y seguimiento del progreso
- Conectado el backend al paquete de ejercicio compartido (
packages/exercises) para el descubrimiento de datos - Configurado CORS para soportar la comunicación con el frontend Next.js
- Garantizar la compatibilidad tipográfica entre el esquema GraphQL y las interfaces TypeScript existentes
- 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 devse 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
.envcon una variableDATABASE_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.
Fase 5: Sincronización del progreso con UUID
Objetivo: Persiste el estado de finalización de cada alumno y vuelve a pintar la barra lateral al recargar, todo ello sin cuentas de usuario.ACU burn: 2,7 (previsto 2-3).Resultado: Un diminuto gancho de React almacena ahora un UUID generado por el navegador, llama a la API GraphQL en cada pasada de prueba y precarga el progreso cada vez que se monta la zona de juegos.
Lo que Devin hizo en realidad
Para la quinta fase, Devin:
- Cliente Apollo integrado para la comunicación GraphQL entre el frontend y el backend
- Implementada la gestión de sesiones anónimas con UUIDs almacenados en localStorage
- Datos de progreso sincronizados en tiempo real e indicadores visuales tanto a nivel de categoría como de ejercicio
- Detecta la finalización del ejercicio conectándote al ejecutor de pruebas Vitest en el navegador
- Se ha añadido compatibilidad sin conexión, actualizaciones optimistas y una sólida gestión de errores con lógica de reintento (que nunca pedí).
Una de las ventajas es que Devin ha añadido la actualización optimista-UI para que las insignias pasen a ✅ al instante. Esto es importante porque mantiene la interfaz ágil incluso en conexiones de alta latencia.
Lecciones aprendidas
Mis conclusiones son:
- Un alcance pequeño significa errores mínimos: Se trataba de una tarea bastante pequeña y con un alcance muy ajustado, por lo que Devin la ejecutó bien y dentro de un buen plazo.
- Di lo que quieras, pero también lo que no quieras: Me di cuenta de que Devin tiene tendencia a intentar ampliar el alcance, y una vez más me dio más de lo que le pedí. En este caso, no me importó, pero si hay algo que realmente no quieres que haga, dilo explícitamente. Por ejemplo, en cada uno de los avisos, especifiqué "sin funcionalidad de inicio de sesión" porque supuse que iba a intentar ir allí.
Ahora tenemos la prueba de que nuestra canalización de sesiones anónimas funciona de extremo a extremo. Es hora de darle un buen aspecto en la fase de pulido final.
Fase 6: Pulido de la interfaz de usuario y panel de progreso
Objetivo: Transforma la interfaz utilitaria en una experiencia "aireada" en tonos pastel y añade un panel que visualice la racha de cada alumno, su escala de dificultad y su actividad semanal.ACU burn: 11 (previsto ≈ 3).Resultado: Temas pastel claro / oscuro, tarjetas de ejercicio rediseñadas y un panel de control en vivo que muestra anillos, barras y contadores de rachas. Devin consiguió las líneas generales, pero yo intervine para rescatar los desajustes de nombres y los intercambios de dependencias deshonestos.
En esta fase, amplié deliberadamente el alcance para ver cómo manejaría Devin un conjunto mayor de peticiones. En realidad, pensé que sería mucho más fácil para Devin que la fase 3, con toda la implementación del backend. Alerta de spoiler: Me equivoqué.
Lo que Devin abordó a partir del aviso
Este es el desglose de mis requisitos y el resultado de Devin:
Dónde se equivocó Devin
Las cosas no salieron a la perfección-Devin:
- Cambiados los nombres de los archivos de paquetes de ejercicios sin actualizar el wrapper o el resolver → tiempo de ejecución 500s; parcheando +1 ACU.
- Sustituyó silenciosamente Postgres por SQLite "para facilitar el desarrollo local" sin pedirme permiso. No lo habría sabido si no hubiera estado observando.
- Dejé docenas de declaraciones
console.logen componentes React, y las comprobaciones de pelusa seguían reintentando.
Lecciones aprendidas
Mis conclusiones:
- La lógica del salpicadero aún necesita trabajo: Devin conectó contadores de rachas y de tiempo, pero los dejó sin funcionar. Las métricas del back-end deben tener al menos una prueba de integración para que la interfaz de usuario del "camino feliz" no se fusione prematuramente.
- El uso de ACU se acelera en sesiones largas: Después de ~8 ACUs, la sesión se ralentizó notablemente. Las sesiones cortas y limitadas (< 5 ACUs) mantienen el contexto ajustado y al agente receptivo.
- Devin "ayudará" a intercambiar dependencias: Sustituyó Postgres por SQLite sin preguntar. Fija los servicios críticos en tu aviso: "No cambies el motor de la base de datos; sigue con Postgres".
- Las tareas de diseño activan la recarga en caliente: Cada actualización de Tailwind/Vite cuenta como tiempo de agente. Quizá una forma mejor de hacerlo sea pausar la sesión antes de editar estilos en masa, y luego despertar a Devin cuando el proyecto se compile limpiamente.
Esa tarea fue larga y costosa, en comparación con el resto del trabajo que hicimos. Al menos Devin es consciente de dónde fueron mal las cosas:
Tenemos algo bonito, pero nos ha llevado un poco de tiempo y no es totalmente funcional. Algunas de las métricas del panel de control están codificadas: ¿dos ejercicios en nuestra categoría de opciones? Tenemos 10. Las métricas de rachas y tiempo empleado tampoco están conectadas a nada, y la interfaz de usuario de las páginas de ejercicios individuales es bastante mala.
