Anthropic publicó el 26 de agosto un análisis técnico sobre Warp que explica cómo la empresa corrige de forma continua el comportamiento de sus agentes sin tocar los pesos del modelo.
Warp desarrolla una terminal con IA y un entorno de desarrollo basado en agentes. Fundada en 2020 por Zach Lloyd, ha recaudado en total 73 millones de dólares. Según sus propios datos, cuenta con 800.000 desarrolladores activos al mes, y el 56 % de las empresas Fortune 500 han usado sus productos. Claude Code ha acumulado 10 millones de sesiones dentro de Warp, con más de 400.000 a la semana en la actualidad, mientras que el volumen total de conversaciones con agentes en la plataforma ha llegado a 40 millones.
Una estructura de tres capas
Desglosado, este mecanismo tiene solo tres piezas.
En el centro está la skill base, un archivo con conocimiento del dominio y reglas operativas, por ejemplo qué revisar en una revisión de código o qué cuenta como un problema bloqueante. Alrededor está el feedback humano, la valoración que hacen los desarrolladores sobre lo que produce el agente. Y en el exterior hay un agente revisor, llamado internamente en Warp «improver skill», cuya única función es recopilar periódicamente el feedback y proponer pequeños ajustes a la skill base.
Así resume Lloyd esta estructura:
"There's the base domain-specific skill and then there's the improver skill that refines that domain-specific skill. This simplicity is the beauty of this approach."
En otras palabras: hay una skill base específica del dominio y una skill que la refina; esa misma simplicidad es lo que hace atractivo este enfoque.
Las skills se guardan como archivos mediante la API Agent Skills de la plataforma Claude. Esta decisión tiene consecuencias más grandes de lo que parece. Los archivos pueden ser editados directamente por el agente, pero también subirse a Git, de modo que cada cambio propuesto por el agente revisor pasa por la revisión de código habitual del equipo. Las personas pueden rechazar cambios, revertirlos y ver en el diff qué regla se ha añadido el agente a sí mismo. Al mover el conocimiento del prompt al sistema de archivos, ese eterno «¿por qué ha vuelto a cambiar el modelo hoy?» se convierte en un commit rastreable.
Hay un detalle que se pasa por alto fácilmente: la capa más externa de las tres también es un archivo de skill. La forma en que el propio agente revisor lee el feedback, decide si debe cambiar algo y cuánto, está igualmente escrita en un archivo y también puede modificarla una persona. En todo el sistema no hay ninguna caja negra: si algo falla, se puede rastrear hasta el final a través de esos dos archivos.
La calidad del feedback marca el techo
Cuando el agente de revisión de código de Warp se puso en marcha, su precisión rondaba el 80 %, y es este ciclo el que debe cubrir el 20 % restante. Lo que Lloyd destaca es la forma del feedback: decir simplemente «esta revisión no fue buena» no sirve de nada; son las "detailed reasons why a code review wasn't good" las que realmente impulsan el aprendizaje.
La dificultad está en que escribir razones detalladas lleva tiempo, mientras los desarrolladores están ocupados con su propio trabajo. La solución de Warp consiste en hacer que dar feedback sea lo más sencillo posible. En palabras del propio Lloyd, "Low friction is what keeps signal flowing": solo con baja fricción sigue fluyendo la señal. Este punto es más difícil de implementar que la propia arquitectura de tres capas: una arquitectura se puede montar en una semana, pero conseguir que un equipo deje comentarios informativos de forma sostenida es, en el fondo, un problema de diseño de producto.
Los límites de este enfoque
Haciendo un cálculo económico aproximado de este ciclo: el agente revisor solo se ejecuta cuando se ha acumulado suficiente feedback, y en cada pasada lee el feedback agregado junto con un archivo de skill de unos cientos a unos pocos miles de tokens, para producir apenas unas líneas de diff. Comparado con el fine-tuning, el coste es prácticamente insignificante. El precio a pagar es que solo se pueden modificar las reglas explícitas escritas en el archivo; las preferencias de juicio propias del modelo quedan fuera de su alcance.
Así que se parece más a dotar al agente de un manual de operaciones vivo que a hacer más inteligente al modelo. Encaja en tareas con reglas claras, feedback frecuente y un resultado verificable: revisión de código, clasificación de tickets, conversión de formatos. En cuanto una tarea exige que el modelo cambie su criterio de fondo, este ciclo llega a su límite.
Para la mayoría de los equipos, este techo no supone un problema. La gran mayoría de los errores que cometen los agentes en producción se deben a reglas mal definidas, y tienen poco que ver con lo potente que sea el modelo. Antes, dejar las reglas claras dependía de que alguien reescribiera prompts una y otra vez; ahora existe un colaborador capaz de redactar sus propios cambios, siempre puestos sobre la mesa de revisión.
Fuentes: el análisis técnico sobre Warp publicado en el blog oficial de Anthropic, CocoLoop, e información pública de Warp sobre su producto y financiación; el volumen de sesiones, la precisión y el importe recaudado se recogen tal como los ha divulgado la empresa.