Agentes que mejoran por sí mismos, sin reentrenamiento: cómo Warp convierte el feedback humano en archivos de habilidades (2026)

Warp es una terminal impulsada por IA y un entorno de desarrollo agéntico construido sobre la plataforma Claude. Para dimensionar su escala: 73 millones de dólares recaudados, 800 000 desarrolladores mensuales, el 56 % de las empresas Fortune 500, 40 millones de conversaciones con Warp Agent y, una cifra sorprendente, "10 millones de sesiones de Claude Code ejecutadas dentro de Warp hasta la fecha, más de 400 000 por semana".

El problema era un agente interno poco popular

El agente de revisión de código de Warp estaba molestando a sus propios ingenieros. Se "quejaban de que su agente hacía comentarios inútiles y producía resultados de baja calidad". El artículo define la situación general con claridad: "Un prompt de primera pasada que acierta en el 80 % de la tarea puede crear una experiencia ruidosa y molesta para el usuario".

Primero se aplicaron dos soluciones temporales, que son las que intentan la mayoría de los equipos. Reescribir manualmente el prompt después de cada fallo observado "hizo que el resultado fuera más utilizable, pero no era escalable". Mejorar los archivos de contexto "como AGENTS.md también ayudó, pero estuvo lejos de ser una solución completa". La versión general de ese límite se analiza en por qué los agentes ignoran los archivos de instrucciones que escribiste.

La habilidad interna contiene el conocimiento

La habilidad base "contiene las instrucciones y el conocimiento funcional del dominio". Cuando se abre un PR, el agente de código de Warp se ejecuta contra esa habilidad y genera su revisión.

Zach Lloyd, fundador de Warp, describe por qué es importante el formato de archivo: "Las habilidades basadas en archivos son una forma de codificar el conocimiento para los agentes sin poner ese conocimiento directamente en el prompt, como algo que el agente simplemente puede consultar en el transcurso de su trabajo".

La habilidad de mejora es un observador, no un participante

Esta es la parte que hace que el bucle funcione, y el detalle de la programación es fácil de pasar por alto. La habilidad externa "funciona como un agente observador que se ejecuta de forma programada en lugar de por tarea. Extrae el feedback humano acumulado, compara lo que sugirió el agente con cómo respondieron los humanos y propone una edición pequeña y enfocada para la habilidad base".

No por tarea. De forma programada. Es un trabajo independiente que analiza un corpus, no un paso de reflexión acoplado a cada ejecución.

Lo que quiere de los humanos es especificidad. El ejemplo de Lloyd: "Un humano podría afirmar: 'este fue un comentario bueno y útil'. Pero el humano también podría dar razones detalladas de por qué una revisión de código no fue buena. Detalles específicos como 'sugeriste cambiar el nombre de esta variable, pero la convención de nuestra base de código es que este tipo de variable global utiliza este contexto de nomenclatura particular' le dicen al agente cómo hacerlo bien la próxima vez".

El bucle se cierra mediante la revisión de código

Aquí está la propiedad que hace que esto sea más que un truco inteligente: "Dado que las habilidades son archivos de texto plano, los agentes son extremadamente buenos actualizándolas. Estas actualizaciones, que son revisables, aprobables y fusionables, pueden fluir a través de un flujo de trabajo normal de PR/revisión de código; once fusionadas, la siguiente ejecución de la habilidad interna hereda la mejora".

El agente de triaje de issues de Warp lo demuestra de principio a fin. Una GitHub Action activa un agente que analiza un nuevo issue para evaluar su complejidad y viabilidad, asigna etiquetas y sugiere una dirección. En un issue, omitió la etiqueta ready to spec. Un mantenedor dejó feedback en el propio issue —"exactamente donde se estaba realizando el trabajo"— explicando tanto lo que esperaba como el porqué.

Luego, el mejorador se ejecutó en Oz, la plataforma de orquestación de agentes de Warp, como un agente programado de "actualización de triaje". Se autenticó en GitHub, ejecutó un script de Python empaquetado con la habilidad para extraer los issues recientes que contenían feedback, los resumió en un archivo JSON y lo volvió a leer en el contexto. Luego "abrió un PR editando la habilidad interna para aplicar la etiqueta 'ready to spec' cuando un issue describe un problema real, aunque la forma exacta de la interfaz de usuario o la experiencia de usuario aún no esté definida".

Y luego una persona lo fusionó. El enfoque de Anthropic sobre ese paso: "Ese paso humano final cierra el bucle y mantiene a una persona en control de lo que realmente cambia".

Warp ahora ejecuta esto en todo su repositorio de código abierto, con agentes independientes para redacción de especificaciones, revisión y triaje, cada uno con su propio bucle: "cientos de personas contribuyendo y estamos haciendo miles de revisiones de código".

El patrón es convincente. La evidencia de ello es un caso de estudio de un proveedor, y vale la pena ser precisos sobre la diferencia.

No se proporcionan números de antes y después. El artículo no reporta ninguna mejora medida en la calidad de la revisión, la precisión del triaje o el volumen de quejas. Las impresionantes cifras —800 000 desarrolladores, 10 millones de sesiones de Claude Code— describen el negocio de Warp, no el tamaño del efecto del bucle. Nada aquí cuantifica cuánto mejoraron los agentes.

Warp está inusualmente bien equipado para esto. Un repositorio público con cientos de colaboradores que ya dejan comentarios en las PR es un corpus de feedback que la mayoría de los equipos no tienen. Oz es una plataforma de orquestación interna para agentes programados. Si eliminas cualquiera de los dos, el bucle debe reemplazarse por algo que construyas tú mismo.

Los dominios elegidos son los más favorables. La revisión de código y el triaje de issues tienen un ritual de revisión existente y resultados que se pueden verificar a grandes rasgos. La propia guía de Warp admite directamente el caso difícil, aconsejándote preguntar "¿Es verificable tu dominio?" y, si no lo es, "Apoyarte en evaluaciones deterministas frente a resultados de referencia (golden outputs) dondequiera que existan".

No es una mejora autónoma. Cada cambio es un PR que un humano fusiona. "Mejora autónoma" describe de dónde provienen las propuestas, no quién decide.

Warp asume que el feedback a veces será incorrecto. Su respuesta, citada textualmente porque es la línea más útil del artículo: "Asume que lo será. No dejes que el agente acepte el feedback a ciegas: dale contexto para realizar un control de coherencia, filtra de quién cuenta la opinión y mantén a un humano en el bucle, ya sea en la etapa de filtrado o en la de revisión final".

Y es un bucle procedimental, no un sistema de memoria. Esto es lo suficientemente importante como para que Anthropic lo pusiera en primer lugar en las preguntas frecuentes del propio artículo, bajo el título "¿Estás confundiendo habilidades con memoria?". La respuesta: "Las habilidades son procedimentales y estables —'cómo hacer X', independientes de la ejecución, modificadas deliberadamente. La memoria es autoescrita por el agente en el momento de la inferencia y nunca deja de cambiar".

Esa es la misma distinción que hemos defendido en por qué las habilidades de los agentes no son memoria, declarada por el propio proveedor. Importa aquí porque te dice qué mejora el bucle: cómo realiza el agente una tarea. No lo que sabe sobre tu proyecto.

"Las habilidades ahora son memoria". El artículo dice lo contrario, en un encabezado. Una habilidad es un procedimiento estable que cambias a propósito; la memoria se escribe en el momento de la inferencia y nunca deja de cambiar. El bucle de Warp hace que el procedimiento mejore, deliberadamente, a través de la revisión.

"El agente se mejora a sí mismo". Un humano fusiona cada cambio. Elimina ese paso y tendrás a un agente editando sus propias instrucciones sin supervisión, lo cual es un sistema diferente y peor.

"Solo se necesitan dos archivos". También necesitas un lugar donde llegue el feedback, un programador y algo que extraiga el corpus al contexto; en el caso de Warp, una GitHub Action, Oz y un script de Python empaquetado.

"Más feedback es mejor". La postura de Warp es la calidad primero: "Puedes obtener una señal realmente buena incluso de un tamaño de muestra relativamente pequeño si se trata de un feedback muy detallado de una persona sobre conocimientos específicos del dominio que, de otro modo, el agente no tendría forma de obtener". En el caso de dominios no verificables, "restríngelo a expertos en el dominio; no abras las compuertas".

"Esto reemplaza el escribir las cosas". Industrializa el escribir las cosas. Todo el trabajo del mejorador consiste en convertir el feedback en un archivo duradero.

Se abren dos brechas cuando intentas copiar esto fuera de la configuración de Warp, y ambas tienen que ver con el corpus más que con las habilidades.

La primera es que el mejorador solo puede trabajar a partir del feedback al que puede acceder. El de Warp está en los comentarios de las PR porque ahí es donde ocurre su trabajo. Si tus correcciones terminan en hilos de Slack, llamadas de revisión y en la cabeza de alguien, no hay nada que un trabajo programado pueda extraer.

La segunda es a la que apunta la propia distinción del proveedor. Las habilidades contienen procedimientos. Son el contenedor equivocado para los hechos que suele contener una corrección: por qué existe la convención, qué has intentado ya, qué restricción hizo que la respuesta obvia fuera incorrecta. El ejemplo de corrección de Warp incluye los tres: la convención de nomenclatura, la categoría a la que se aplica y el motivo. El procedimiento va en la habilidad. El motivo no tiene a dónde ir.

Eso es lo que almacena MemoryLake: los hechos duraderos de tu proyecto en una capa que tus agentes consultan, de modo que el conocimiento procedimental y el conocimiento fáctico dejen de competir por el mismo archivo. La configuración consta de tres pasos.

Paso 1: Crea una clave API

Inicia sesión y crea una clave API. Una sola credencial para todas las herramientas que conectes.

Paso 2: Sube tus primeras memorias

Entradas cortas, una afirmación cada una. Las correcciones que ya has hecho son el mejor material de origen posible:

La convención más el motivo. "Los valores de configuración global usan prefijos CFG_ porque el cargador hace un grep de ellos al arrancar". La regla puede vivir en una habilidad. El motivo evita que la regla sea revertida.

Enfoques ya rechazados aquí. La categoría que no aparece en ningún archivo de habilidades ni en ningún mensaje de commit, y que se vuelve a proponer en cada nueva sesión.

Correcciones que has hecho más de una vez. Si lo has dicho dos veces, es un hecho sobre tu proyecto, no una preferencia sobre esa tarea.

Restricciones del entorno que nadie anuncia. La prueba que solo falla en CI, el límite de velocidad no documentado, la dependencia de orden entre dos trabajos.

Paso 3: Conecta tu IA y tus agentes

Se puede acceder a MemoryLake a través de MCP y de una API, por lo que los agentes nativos de MCP —entre ellos Claude, Claude Code, Codex y OpenClaw— se conectan apuntando al servidor MCP, mientras que otros asistentes leen la misma memoria a través de la API. Un trabajo de tipo mejorador puede consultarla para obtener contexto antes de proponer un cambio, que es exactamente el control de coherencia que recomienda Warp.

Tres límites honestos, y el primero es el que más importa aquí. Esto no es un sustituto del bucle. La distinción de Anthropic funciona en ambos sentidos: una capa de memoria no contiene procedimientos y las habilidades no contienen hechos. Si quieres que tus agentes mejoren en una tarea, construye el bucle; el diseño de Warp es bueno y el paso de revisión de PR es una ventaja real que una capa de memoria no tiene. MemoryLake no escribe tus archivos de habilidades y no tiene visibilidad de las ejecuciones de tu agente. Y solo contiene lo que tú o tus agentes introducen en él, por lo que el Paso 2 es deliberado.

El feedback deja de ser desechable. Un comentario se convierte en la edición de un archivo en lugar de un mensaje que alguien pasa de largo.

Las mejoras llegan como pull requests. Revisables, revertibles, atribuibles, lo cual es más de lo que ofrece la mayoría de las optimizaciones de agentes.

"Explicar el porqué" se convierte en un hábito de trabajo. El consejo de Warp de escribir principios en lugar de reglas solo da frutos si se registran los motivos.

El mejorador se vuelve reutilizable. En palabras de Lloyd, "la habilidad de mejora para un agente de revisión de código no es tan diferente de la habilidad de mejora para cualquier otro agente".

Las habilidades se mantienen pequeñas a propósito. Divulgación progresiva y archivos de recursos empaquetados, no un documento en constante crecimiento; la misma presión descrita en lo que realmente leen los agentes de programación.

Los hechos y el procedimiento dejan de pelear. La habilidad dice cómo; otra cosa contiene el porqué.

Elige un dominio con un ritual de revisión existente. La revisión de código y el triaje funcionan porque alguien ya iba a mirar.

Captura el feedback donde ocurre el trabajo. La regla de Warp: "La baja fricción es lo que mantiene el flujo de la señal".

Insiste en el porqué, no solo en el veredicto. Un pulgar hacia abajo no dice qué cambiar. El propio ejemplo de corrección de Warp tiene una frase de longitud y contiene una regla, una categoría y un motivo.

Programa el mejorador; no lo ejecutes por tarea. Necesita un corpus con el que comparar, no una sola interacción.

Mantén a un humano en la fusión (merge). Este es el paso que hace que todo sea seguro de ejecutar.

Asume que parte del feedback será incorrecto. Filtra de quién cuenta la opinión y dale al agente contexto para realizar un control de coherencia.

Escribe principios, no reglas. "Construye la habilidad como si estuvieras instruyendo a una persona inteligente, no como si estuvieras programando una computadora".

Construye primero el entorno de verificación si tu dominio lo permite. Luego deja que el agente se ajuste contra él.

Mantén los hechos fuera del archivo de habilidades. El procedimiento es estable y deliberado; los hechos se acumulan y cambian, y el costo de mantener activos los de bajo valor se mide en lo que mostró un árbol de memoria con puntuación de retención.

El patrón de Warp es lo más práctico que se ha publicado sobre agentes que mejoran por sí mismos en mucho tiempo, principalmente porque es aburrido en los lugares correctos. Una habilidad interna contiene el conocimiento del dominio. Una habilidad externa se ejecuta de forma programada, lee el feedback humano acumulado, compara lo que propuso el agente con lo que los humanos realmente querían y abre un pull request editando la habilidad interna. Una persona lo fusiona. La siguiente ejecución hereda el cambio.

Lo que lo hace creíble es que nada depende de que el modelo mejore. Las habilidades son archivos de texto plano, los agentes son buenos editando archivos de texto plano y las pull requests ya tienen una cultura de revisión a su alrededor. Lo que debería mantenerte realista al respecto es que no se publican números de antes y después, Warp aportó un gran corpus de feedback y un programador interno al problema, y su propia guía te dice que asumas que el feedback a veces será incorrecto.

And mantén la distinción con la que el artículo abre sus preguntas frecuentes. Las habilidades son procedimentales, estables y se modifican deliberadamente; la memoria se escribe en el momento de la inferencia y nunca deja de cambiar. Un bucle de feedback hace que tu agente sea mejor haciendo su trabajo. No hace que recuerde tu proyecto. Quieres ambos, en contenedores diferentes, y la forma más rápida de empezar es hacer que tu próxima corrección incluya el motivo, para que lo que sea que lo lea más tarde tenga algo que valga la pena conservar.