(Este es el material presentado el 17 de diciembre en el meetup de Claude Code en Seúl. Para la presentación completa, consulta este enlace.)
Objetivo de la "consultoría interna" del equipo AX de Korca
- Asentar buenas prácticas de ingeniería agéntica en Korca y crear una base para seguir mejorándolas juntos de forma constante.
- En Korca, las "prácticas de ingeniería agéntica" se definen como "métodos prácticos para aprovechar agentes de IA de una manera que eleve tanto la calidad como la productividad del software"
- Hacer que la capacidad de ingeniería se convierta en otra ventaja competitiva clave de Korca.
- Para eso, empezaron ayudando al equipo Moonlight.
Situación de Moonlight
- Moonlight, el producto principal de Korca, se presenta como un "compañero de IA para leer papers juntos".
- "Conversar con PDFs" es una idea que existe desde los primerísimos días de ChatGPT. Entre muchísimos productos competidores de ese tipo, logró sobrevivir y ahora está en la etapa inicial de una curva J (recientemente, con un rápido aumento de usuarios en China).
- Hubo muchísimos ensayos y errores hasta llegar aquí, pero la ventaja competitiva clave fue mantener "como fuera" la velocidad y el ritmo del desarrollo de funcionalidades.
- Algunas decisiones iniciales tomadas para priorizar la velocidad
- typescript strict: false
- Minimizar las pruebas automatizadas
- Permitir duplicación y hardcoding
- Sin distinción estricta de roles. Casi todos los integrantes del equipo (6 de 7) implementan con agentes de código y suben PRs
- Una vez que el producto entró en órbita, la deuda técnica empezó a pesar poco a poco
- El producto se fue volviendo más complejo, se sumaron nuevos integrantes al equipo y al mismo tiempo aumentó la cantidad de experimentos corriendo en paralelo
- La velocidad de mejora del producto empezó a bajar gradualmente y la sensación de incertidumbre empezó a crecer
- La carga de code review se concentró en unas pocas personas y comenzaron a aparecer errores grandes y pequeños
Retos inmediatos para el equipo AX
- [Producto] ¡Hagamos que la calidad de Moonlight mejore, mientras la velocidad para agregar y mejorar funciones se acelera!
- [Equipo] ¡Hagamos que cualquier persona pueda modificar el código de Moonlight con más facilidad y que haya menos estrés después del despliegue!
- [Cultura] Para lograr 1 y 2, que el equipo Moonlight y el equipo AX colaboren para descubrir, aplicar, perfeccionar y difundir gradualmente dentro de la empresa buenas prácticas de ingeniería agéntica.
→ Consideraron que la mayoría de estos problemas se resolverían si los agentes de código pudieran dar mejores respuestas.
¿Qué hace falta para que un agente dé mejores respuestas?
[1] Hacer que tome una buena ruta desde el principio
- Si la calidad de la base de código es alta, hay ventajas en tres aspectos
- Se necesita meter menos contexto innecesario (Less is More)
- El agente tiende a seguir los buenos patrones existentes
- Se puede sesgar la probabilidad de que la respuesta se muestree desde una zona del preentrenamiento donde se concentran códigos de alta calidad
- Hay muchos estudios que muestran que, si se le da contexto de alta calidad, salen mejores respuestas.
- (Hipótesis personal) Si le mandas una solicitud al agente en una base de código donde el orden de los imports está alineado, ¿no será más probable que el código del preentrenamiento con imports ordenados sea, en general, de mayor calidad?
- En el blog de Anthropic: "Con solo hacer que use fuentes interesantes, también mejoran otros elementos del diseño"
[2] Evitar que tome rutas equivocadas
- Verificación de errores de tipos, errores del linter, pruebas automatizadas, detección de código muerto, revisión de longitud de archivos, medición de complejidad, enforcement de dependencias, enforcement de la proporción entre código de pruebas y código de producción, etc. Con diversas herramientas de análisis estático se pueden bloquear rutas equivocadas (hacer que vuelva a trabajar hasta pasar los criterios)
[3] Pedirle sobre todo lo que hace bien
- Las personas, los LLM y los algoritmos son buenos en cosas distintas. Si se elige con inteligencia qué usar y cuándo, se puede ahorrar tiempo y costo
- ej.) Decirle que no olvide una i18n key vs pedirle que ejecute un script para encontrar las i18n keys faltantes
- Quién hace bien qué y en qué momento cambia con el tiempo y depende del dominio del problema. Conviene formar el hábito de actualizar ese "olfato" dentro del propio dominio
- ej.) Cuando sale un nuevo modelo, probarlo con tus propios benchmarks, o reproducir ejemplos famosos de redes sociales
[4] Ayudarle en lo que no hace bien
- Eso sí, siempre hay que comprobar si realmente no lo hace bien. Salvo que delegarlo sea riesgoso o demasiado ineficiente, suele ser mejor que lo hagan más la IA o los algoritmos que las personas. (Al fin y al cabo, el costo de tokens probablemente terminará siendo tan barato como la electricidad).
- ¿Y si de verdad no puede? Hacer que otro LLM lo revise
- ej.) En la forma más simple: "Esto lo hizo un desarrollador principiante..."
- Si quieres que la IA trabaje mejor, hay que darle un entorno en el que pueda trabajar mejor. Dicho de otro modo, lo que el agente (actual) probablemente no hace bien (aquí) debe ser reforzado por personas, algoritmos y otros agentes
Cosas a las que prestaron atención
- Moonlight es un cohete que recién empieza a despegar, y el equipo AX es un invitado que llegó desde afuera
- Había que evitar a toda costa el patrón de que alguien externo venga, "resuelva" algo y se vaya
- Procurar que los esfuerzos por mejorar la calidad no frenen el desarrollo de funcionalidades
- Decidieron mezclar en una proporción adecuada trabajos que no cambian demasiado la manera habitual de trabajar con otros más desafiantes pero efectivos
→ Imaginaron un escenario donde el equipo AX y el equipo Moonlight descubren y aplican "juntos" prácticas adecuadas para el equipo y el producto, y en ese proceso mejoran al mismo tiempo la calidad del código, la calidad del producto y la capacidad del equipo
Principales logros obtenidos en las últimas 4 semanas
[1] Se están consolidando buenos hábitos y se están encontrando buenos patrones
- Subir todos los días pequeños commits de refactorización minúscula (
tidying) sin necesidad de PR review - Prompts para seguir commits ejemplares del pasado (como soporte para nuevos modelos) y prompts para descubrir y recopilar esos patrones
- Una SKILL de code review actuando como si fuera un senior
[2] Comenzaron a medir y visualizar métricas de calidad de código. La cantidad de errores/advertencias en proporción a las líneas de código está bajando rápidamente
- Las métricas de calidad de código están disminuyendo, a veces de forma gradual y a veces de forma dramática
- Fue muy importante que el
tidyingmejorara un poco la base de código todos los días, porque eso terminó dando la confianza de que en algún momento sí se podrían intentar grandes refactorizaciones y trabajos grandes - Al aplicar knip paquete por paquete, también eliminaron código viejo y sin uso
- Las métricas siempre deben ser complementarias. Es mucho mejor tener 5000 errores en una base de código de 100 mil líneas que 1000 errores en una base de código de 1000 líneas. Por eso, en vez de mirar solo la cantidad absoluta, definieron una métrica de gestión más sana observando la tasa de errores respecto a la cantidad de líneas
- La cantidad de líneas significativas, excluyendo comentarios y espacios en blanco, se mide con tokei
[3] Arreglaron un problema de memory leak que llevaba más de un año
- Movilizando al máximo varias herramientas y técnicas de prompting, incluido repomix, lograron atrapar un problema de memory leak que había durado más de un año, después de varios intentos
- Están contentos porque parece que incluso podrán bajar el tier de las instancias del servidor
[4] Ahora cuentan con una estructura de abstracción, prompts y scripts que permiten agregar/quitar con más facilidad y seguridad los experimentos que corren en paralelo cada semana
Como resultado, la calidad del código sigue subiendo, el desarrollo de funcionalidades se vuelve más rápido y seguro, y la capacidad de ingeniería (agéntica) del equipo sigue mejorando de forma sostenida: esas tres cosas están encajando muy bien al mismo tiempo
Ensayo y error
- Por supuesto, no salió bien desde el principio. Originalmente querían hacer dos cosas al mismo tiempo
- Introducir de golpe cambios de mucho valor aunque generaran cierta inquietud: activar la opción
strict, meter reglas estrictas de eslint, borrar de una sola vez todo el código muerto, etc. - Avanzar de forma segura, aunque el valor fuera menor, paso a paso: dejar commits diarios de
tidying, etc.
- Introducir de golpe cambios de mucho valor aunque generaran cierta inquietud: activar la opción
- Pero lo primero no se hizo porque daba miedo, y lo segundo no se hacía porque resultaba aburrido
- Entonces lo cambiaron así
- Hacer lo desafiante más seguro (activar
tsc strictarchivo por archivo para arreglar y luego apagarlo, aplicar eslint con el mínimo de reglas, usar knip uno por paquete, etc.) - Hacer lo seguro más valioso (por ejemplo, crear prompts que sugieran
tidyingsobre cambios recientes)
- Hacer lo desafiante más seguro (activar
- Aún quedan muchas tareas pendientes
- Activar
typescript: strict - Introducir zod para alinear el contrato entre servidor y cliente
- Introducir reglas de eslint más estrictas
- Aumentar la cobertura de pruebas automatizadas
- Bloquear más rutas equivocadas con una variedad mayor de herramientas de análisis estático
- Activar
- Pero siguen avanzando juntos, de forma constante y nunca lentamente
One More Thing: mis hábitos de aprendizaje + depuración
En una situación así, se aprende mucho si validas cruzadamente preguntándole a la IA y también a gente experta. Ese proceso también lo están dejando registrado en GitHub PRs, issues y Slack para compartirlo con la organización
- Otras personas saben cosas que yo no sé
- ¿Cómo llegó esta persona a tener ese conocimiento/experiencia? ¿Con qué señales detectó este problema?
- Descubro mis errores, bugs y anti-patrones de la base de código
- ¿Qué causas hicieron inevitable que apareciera este problema? ¿Cómo se puede mejorar la estructura para cometer menos errores la próxima vez y detectar los errores más temprano?
Cierre
- Si logramos que la IA dé mejores respuestas, se resuelve una parte importante de los problemas de los equipos de producto
- Subiendo la calidad de la base de código (tomar una buena ruta desde el principio) e introduciendo diversas herramientas (bloquear rutas equivocadas)
- Ayudemos a que las capacidades de ingeniería agéntica de los miembros del equipo aumenten (pedir lo que hacen bien, ayudar en lo que no hacen bien)
- Si el equipo eleva su capacidad y se construye un buen entorno colaborando con la IA de manera inteligente, mejorar la calidad y aumentar la velocidad para agregar/mejorar funcionalidades son cosas totalmente compatibles
- En lugar de traer algo bueno "desde afuera" para ayudar, hay que descubrirlo e intentarlo "desde adentro" y en conjunto. Midamos, visualicemos, celebremos y aprendamos unos de otros
3 comentarios
También salió una nota del meetup.
[Reportaje] "Nace en Corea el usuario n.º 1 de Claude"… así fue el evento meetup de Anthropic
https://n.news.naver.com/mnews/article/092/0002402940
Unos 1,8 millones de wones al mes, dios mío.
Parece que también sería significativo como una forma de ayudar a la participación activa y al crecimiento de los desarrolladores junior.
Oh, sí, correcto jaja. También estamos trabajando duro por ese lado.