Tres ideas de noticias sobre agentes, convertidas en comprobaciones: qué incorporamos a nuestro harness y qué dejamos fuera

En una semana, tres ideas sobre agentes de IA recorrieron todos los canales que leo. Karpathy propuso pedirle a un modelo que escriba como un manual de avión. Google Research publicó Harness², un marco que mejora todo lo que rodea al modelo en lugar del modelo en sí. Los ingenieros de OpenAI describieron cómo eliminaron 800.000 líneas de código muerto con un agente en dos semanas. Las tres son buenas. Las tres también llegan en forma de "añade una línea mágica a tu prompt", y un prompt es exactamente lo que se desvía en la siguiente llamada. Así que las incorporamos a nuestra config abierta, github.com/AnastasiyaW/codex-claude-code-config, como comprobaciones. Esto es lo que conservamos, lo que descartamos y por qué.

El manual de avión: dos reglas de noventa

El estándar es ASD-STE100, Simplified Technical English. La aviación lo usa para que un mecánico lea un único significado en cada instrucción. El 2 de octubre, Karpathy ordenó las formas de hacer que la salida de un modelo sea más fácil de leer. El texto de este estilo va primero, luego un diagrama, luego una página HTML interactiva y por último un vídeo explicativo personalizado. La escalera es útil por sí sola. La mayoría de las respuestas necesitan el primer peldaño, un cambio de arquitectura necesita el segundo, y una comparación con muchos números merece el tercero.

La línea "escribe en STE100 estricto" es más débil de lo que parece. El estándar completo tiene un diccionario controlado de unas 900 palabras y decenas de reglas. El diccionario tiene copyright, y los modelos no lo conocen con fiabilidad. Si pides conformidad estricta, obtienes una imitación: frases troceadas, no el estándar.

Dos reglas concentran la mayor parte del valor y no necesitan diccionario:

• Un concepto, un término. Si el proyecto dice "worker", cada frase dice "worker". A los modelos les gustan los sinónimos por variedad. Entonces el lector técnico tiene que deducir si "worker", "handler" y "executor" son tres cosas o una.
• Frases cortas. STE limita las instrucciones a 20 palabras y las descripciones a 25.

Las convertimos en mecánicas. scripts/term_drift_check.py toma el glosario del proyecto y comprueba lo que escribió el agente frente a él. Una entrada del glosario como обработчик* detecta todas las formas de la palabra, así que la comprobación funciona también en ruso. Los linters STE existentes no hacen eso, porque el propio estándar es para inglés. Los bloques de código, los enlaces y los comentarios se omiten. El código de salida es 0 si está limpio, 1 si hay hallazgos y 2 cuando la comprobación no pudo ejecutarse. Necesitamos ese tercer estado porque una comprobación que en silencio no comprobó nada es peor que no tener comprobación.

La primera versión tenía exactamente ese problema. Un revisor independiente, otro agente con un contexto nuevo, encontró tres formas de obtener un resultado en verde sin comprobar nada. Un texto en una codificación distinta de UTF-8, un bloque de código sin cerrar y un glosario sin sinónimos salían limpios. Un segundo revisor encontró cinco más. Todas están corregidas, y la autoprueba ahora incluye casos que deben fallar, así que un detector roto no puede pasar en silencio.

Harness²: el método sí, el autoparcheador no

La idea detrás de Harness² es sólida. Los pesos del modelo quedan fijos. El agente propone cambios en su entorno: prompt de sistema, memoria, guía de herramientas, skills, scripts, plugins. Los ejecuta sobre la tarea, conserva lo que ayudó y recuerda la lección para la siguiente vez. En tres benchmarks de trabajo profesional, una ronda de esto mejoró GLM-5 y Gemini 3.5 Flash hasta 11,5 puntos.

No lo instalamos tal cual. En el README, su ejecutor corre con red abierta y con el sandbox de Codex desactivado, y no hay ningún protocolo para tareas retenidas. Para un agente que edita sus propias reglas, este es el riesgo principal: mejora en las tareas que ha visto y rompe en silencio las que no ha visto.

Así que tomamos el método como un piloto pequeño con límites estrictos:

• un conjunto congelado de tres a cinco tareas, más al menos una tarea retenida en la que el cambio no se ajustó;
• un cambio por candidato, para que la causa sea obvia;
• recibos mecánicos por tarea, no una opinión sobre el resultado;
• el candidato gana solo con una mejora estricta y sin regresión en seguridad ni en la tarea retenida;
• los hooks en vivo, los permisos y las salvaguardas nunca son objetivo del piloto.

El comparador lee dos recibos y escribe un veredicto. No ejecuta agentes y no toca la config en vivo. Un resultado aceptado es evidencia para una revisión, no un despliegue.

Código muerto: la evidencia viene de producción

Las cifras de OpenAI son impresionantes. Más de 1.400 PR fusionados y más de 800.000 líneas eliminadas en unas dos semanas. Una imagen de contenedor se redujo un 48 %, y el tiempo mediano de CI pasó de unos diez minutos a cuatro minutos y medio. Los prompts no fueron lo que lo hizo funcionar. Lo hizo el proceso.

Borrar código es un tipo especial de cambio. No falla nada cuando desaparece código inalcanzable. Tampoco falla nada cuando te equivocas al creer que es inalcanzable, hasta que lo hace producción. Así que la prueba tiene que venir de producción: telemetría, el estado vivo de los flags, cada punto de llamada incluidos los indirectos, el responsable. La auditoría es de solo lectura. Cada eliminación es un PR pequeño en borrador con la evidencia y el razonamiento en la descripción. Los kill switches y las salvaguardas nunca se eliminan por palabra del agente.

Lo añadimos como referencia a la skill refactoring-safely. Ahora la skill también se activa cuando alguien pide eliminar código muerto o flags de funcionalidad obsoletos.

Comentarios en el código: la investigación dice algo ligeramente distinto

Al mismo tiempo quería comprobar una idea que ya seguimos: si los agentes escriben y leen el código, la mayoría de los comentarios solo desperdician contexto. Tenemos esta regla desde el 15 de octubre, y busqué investigación que la respaldara. La respuesta resultó más interesante que "los comentarios son ruido".

• Los comentarios obsoletos arrastran el código generado hacia la implementación antigua.
• Los modelos pueden fiarse más de un comentario que del código que contradice.
• Un comentario que falta importó poco en los estudios que encontré.
• Un comentario correcto sobre código no evidente sí ayudó: en un estudio sobre código legado de mainframe, la precisión pasó de unos 84 % a 90-96 %.

Las muestras son pequeñas, y leí dos de los artículos solo en forma de resumen, así que tomaría las cifras exactas con cuidado. La dirección, sin embargo, es clara: un comentario que miente es más peligroso que un comentario que no existe. Así que añadimos un requisito a la regla. Si cambias el código, cambias o eliminas el comentario que está junto a él en el mismo commit. Repetir lo que hace el código sobra. La razón, el origen de un número y la trampa que el siguiente agente "arreglaría" si no, se quedan.

Lo que hay ahora en el repositorio

• docs/output-legibility.md: la escalera de legibilidad y las dos reglas, con una línea de prompt que funciona mejor que "escribe en STE100";
• scripts/term_drift_check.py: la comprobación de glosario, con pruebas y autoprueba;
• docs/harness-improvement-pilot.md y su comparador: el piloto acotado;
• references/dead-code-sweep.md en la skill refactoring-safely;
• la regla de comentarios actualizada en rules/quality-code.md.

Todo está en la versión v2026.10.24, y la lista completa de cambios está en UPDATES.md. Un agente puede tomar lo que necesite directamente del repositorio: empieza por CLAUDE.md y README.md, y luego las skills listadas en skills-lock.json.

Si algo de esto te ahorra un día, una estrella en GitHub ayuda a que otras personas encuentren el repositorio. Si algo se rompe, abre un issue: de ahí salieron la mayoría de nuestras reglas desde el principio.