Duolingo enseña a sus ingenieros a usar IA para revisar código de forma autónoma
El equipo DevEx AI de Duolingo lleva dos años formando a sus desarrolladores con talleres, cuadros de mando y consultas de quince minutos. De ahí salió el rediseño de su revisión de código.
Duolingo mantiene desde hace dos años un equipo dedicado a que sus ingenieros metan IA en su trabajo diario, y no a mantener la integración continua. Se llama DevEx AI y su método se apoya en tres piezas: talleres prácticos con material validado dentro de la casa, cuadros de mando que miden el consumo de IA en la empresa y consultas rápidas de quince minutos. Sarah Deitke, ingeniera de ese equipo, ha contado en una charla cómo ese trabajo acabó desembocando en el rediseño de la revisión de código, un proceso que la compañía trata con pinzas.
El diagnóstico de Deitke es que la herramienta ya no es el cuello de botella. La mayoría de las organizaciones tiene acceso a asistentes tipo Cursor o Claude Code; lo que falta es alguien que enseñe a sacarles partido. A partir de ahí aparecen los frenos: ingenieros escépticos ante un cambio que contradice lo que estudiaron, procesos centrales como la revisión de código que nadie quiere tocar, y una pregunta incómoda cuando la IA escribe: si antes respondían el autor y el revisor, quién responde ahora. Encima está la confianza, que se construye despacio y se pierde en un día.
Talleres con material de casa
Los talleres del equipo son de laboratorio, guiados y a ritmo propio. Cubren servidores MCP, reglas de Cursor, peticiones por lotes a los LLM y evaluaciones. Deitke sostiene que los ingenieros se fían bastante más del contenido que prepara su propia organización que del que trae un proveedor con una solución genérica. En una encuesta que pasaron durante un all-hands, el 95% de la organización de ingeniería dijo haber aprendido algo nuevo y recomendaría el formato. La cifra es interna y autodeclarada, no de un tercero, pero sirve de referencia para quien quiera montar algo parecido.
Medir el consumo antes de decidir qué enseñar
Para elegir los temas, el equipo levantó cuadros de mando de observabilidad de IA. Empezaron con un gráfico de usuarios activos diarios para uno o dos proveedores y herramientas internas, y fueron añadiendo desgloses por función (ingeniería, diseño, finanzas), por comunidad de desarrollo (iOS, Android, backend), por IDE, por lenguaje, y métricas de tokens, coste y familia de modelo. El propio cuadro está hecho con vibe coding, así que añadir una vista nueva es pedirla. Eso les ha dado argumentos ante la dirección.
A los talleres se suman las consultas en directo: franjas de quince minutos que cualquiera puede reservar. Deitke apunta un detalle que no esperaba. No las usan tanto los ingenieros como la gente que roza la ingeniería de refilón, como diseñadores de aprendizaje que ahora necesitan manejar GitHub porque hacen vibe coding, o el equipo de soporte de QA, que intenta escalar lo que ya ha montado en su máquina.
Para quien tenga que justificar un equipo así, el argumento no es el precio de las licencias, sino el tiempo que tarda la organización en adoptarlas. Lo que hay publicado es el arranque de una charla, no un manual, y no incluye métricas de impacto sobre la calidad del código revisado ni sobre el tiempo ahorrado. Queda por ver si otras empresas copian el modelo o si se queda en el caso de una compañía con recursos para dedicarle un equipo entero.
