Warp ha publicado cómo consigue que sus agentes mejoren sin que nadie se siente a reescribirlos, y lo interesante es que no hay nada exótico en la receta: ni fine-tuning, ni un pipeline de reentrenamiento, ni infraestructura propia de evaluación. Hay dos archivos de Skills y un agente que corre de forma programada para editar uno de ellos. El patrón es replicable esta misma semana por cualquiera que ya use Claude Code con skills, y esa es la razón por la que merece atención más allá del caso de estudio corporativo.
Warp es una terminal con IA convertida en entorno de desarrollo agéntico: 800.000 desarrolladores al mes, el 56% de las Fortune 500 entre sus usuarios, 10 millones de sesiones de Claude Code ejecutadas dentro del producto, más de 400.000 semanales y 40 millones de conversaciones acumuladas con su agente. Volumen suficiente para que el problema que resuelven sea el problema real: no cómo escribir una buena instrucción, sino cómo evitar que esa instrucción envejezca.
Una skill hace el trabajo y otra la corrige por encima
La arquitectura tiene dos capas. La skill base —la interior— contiene el conocimiento de dominio y las instrucciones concretas: en su agente de revisión de código, es la que se dispara cuando se abre un pull request y ejecuta el análisis con su contexto específico. Es el archivo que cualquiera de nosotros ya tiene escrito de una forma u otra.
La segunda capa es la que cambia el juego. La skill improver —la exterior— no se ejecuta por tarea, sino de forma programada, y funciona como observador: acumula el feedback humano recibido, compara lo que sugirió el agente con lo que respondieron las personas y propone ediciones pequeñas y muy acotadas sobre la skill base. No reescribe el archivo entero ni genera una versión nueva desde cero: recorta la distancia entre lo que la skill dice y lo que la práctica ha demostrado que debería decir.
El agente no aprende: aprende el archivo. Y como el archivo es texto, su mejora pasa por code review como cualquier otro cambio.
Aquí está la decisión más limpia de todo el diseño: como las skills son archivos, las propuestas del improver circulan por el flujo normal de pull request y revisión de código. Un humano las mira, las aprueba o las rechaza, y una vez mergeadas la siguiente ejecución hereda la mejora automáticamente. No hay caja negra, no hay estado oculto, no hay un modelo que se ha vuelto distinto sin que nadie sepa por qué. Hay un diff. Warp mantiene bucles separados para sus agentes de especificación, de revisión y de triaje, todos en su repositorio abierto.
El feedback se recoge donde la gente ya está trabajando
Todo el sistema depende de una materia prima: opiniones humanas sobre si el agente lo hizo bien. Y ahí Warp toma dos decisiones que explican por qué les funciona. La primera es capturar la señal sin pasos añadidos: el feedback se recoge en los comentarios que la gente ya escribe en los PR y en las incidencias, no en un formulario aparte que habría que recordar rellenar. Cualquiera que haya intentado montar un sistema de evaluación con un paso manual extra sabe cómo acaba: con tres respuestas la primera semana y ninguna la segunda.
La segunda es priorizar calidad por encima de volumen. Zach Lloyd, CEO de Warp, lo plantea así: una persona puede limitarse a confirmar que un comentario fue útil, pero también puede explicar con detalle por qué una revisión de código no fue buena. Lo segundo vale mucho más. Un pulgar hacia abajo le dice al improver que algo falló; un párrafo explicando qué se pasó por alto le dice exactamente qué línea añadir a la skill.
Cuando el dominio lo permite, además, cierran el circuito con bucles de verificación: si el resultado es comprobable de forma objetiva, no hace falta esperar a que alguien opine.
Principios en vez de reglas, y skills que no lo cuentan todo de golpe
La recomendación más contraintuitiva del artículo va contra el instinto de todo el que ha peleado con un agente desobediente. Lloyd lo resume en una frase: escribe principios, no reglas; construye la skill como si estuvieras instruyendo a una persona inteligente, no como si estuvieras programando un ordenador. Y añade un matiz que importa: explica el razonamiento detrás de cada regla, no solo la regla.
Tiene lógica dentro de este sistema concreto. Un listado de reglas rígidas es imposible de mejorar de forma incremental: cada caso nuevo obliga a añadir otra excepción, y el archivo crece hasta volverse contradictorio consigo mismo. Un principio bien explicado, en cambio, se puede afinar. El improver puede matizar el porqué, y ese matiz cubre casos que nadie enumeró.
El otro principio de diseño es mantener las skills pequeñas, con revelación progresiva: en lugar de volcar todo el contexto disponible en un único archivo enorme, se apoyan en archivos de recurso que se consultan cuando hacen falta. Menos contexto por defecto, más contexto bajo demanda.
💡 Para replicarlo en pequeño: coge la skill que más uses —revisión de código, generación de contenido, control de calidad antes de publicar— y crea junto a ella un archivo de notas donde apuntes, en una línea, cada vez que corriges su resultado a mano. Una vez por semana, lanza una sesión que lea la skill y esas notas y proponga tres ediciones concretas. Tú apruebas o descartas. Eso ya es el bucle completo, sin infraestructura ninguna.
Qué cambia si trabajas solo y no tienes 800.000 usuarios
La tentación al leer un caso así es descartarlo por escala: el volumen de Warp genera feedback constante y un freelance no. Pero el cuello de botella que resuelve el patrón es exactamente el que sufre quien trabaja solo. Las instrucciones que escribimos para nuestros agentes —el archivo de contexto del proyecto, las skills, las reglas de estilo del cliente— se escriben una vez, con la información de ese día, y después se quedan quietas mientras el proyecto cambia. La corrección ocurre en la cabeza de uno: ves que el agente falló, lo arreglas a mano y sigues. Ese aprendizaje no vuelve nunca al archivo.
Lo que hace Warp es institucionalizar ese momento. Y la pieza clave no es la automatización, sino que la mejora sea un cambio de texto revisable. Es la diferencia entre un agente que se vuelve mejor y un agente que se vuelve distinto: el primero deja rastro en un commit, el segundo te sorprende un martes.
Si ya usas skills en Claude Code, el coste de entrada es una carpeta y una sesión programada. Si todavía tienes todo el conocimiento del proyecto metido en el prompt, este es el argumento para sacarlo de ahí: lo que vive en un archivo se puede versionar, revisar y mejorar; lo que vive en un prompt solo se puede volver a escribir.
