¿Dónde está el último seguro? Desarrollo con agentes de código

Un escalador avanza por la pared. Lleva arnés, está encordado y alguien le asegura desde abajo. A medida que sube, pasa la cuerda por los seguros de la vía.

Cada elemento cumple una función. El croquis ayuda a elegir el recorrido. Los seguros limitan la distancia de una caída. La cuerda absorbe parte de su energía. El asegurador presta atención y actúa cuando hace falta.

Llevar arnés es solo una pieza del sistema.

Esta es la imagen que me sirve para pensar en desarrollo con agentes de código. El agente escala. Nosotros elegimos la vía y aseguramos. Las instrucciones, los tests, los checks y el pipeline forman parte del equipo con el que le dejamos avanzar.

Y la palabra encaja: harness significa arnés.

Chris Richardson utiliza la conducción para desarrollar esta idea en Speed limits, GenAI coding agents and Autobahns, part 2: raising the safe speed, publicado en agosto de 2026: podemos aumentar la velocidad segura mejorando el código, la entrega y el entorno del agente.

Quiero llevar esa misma tesis a la escalada y hacerme una pregunta antes de darle más cuerda: si falla el siguiente movimiento, ¿qué va a pasar?

La distancia al último seguro

Cuando escalas de primero, alejarte del último seguro puede aumentar la distancia de una caída. También influyen la holgura, la elasticidad de la cuerda, cómo te aseguran y el terreno que hay debajo.

En desarrollo también necesitamos mirar el conjunto: cuánto trabajo hemos acumulado, qué puede detectar un error y qué consecuencias tendrá si se escapa.

Podemos empezar por una expresión sencilla:

Distancia al último seguro ≈ ritmo de cambio × tiempo hasta recibir feedback relevante.

La propongo como una forma de razonar sobre nuestro trabajo. Si el ritmo es aproximadamente constante, expresa cuánto cambio dejamos acumular sin esa comprobación. Para convertirla en una medida necesitaríamos definir qué contamos como cambio.

La consecuencia es clara: si el agente avanza más rápido y el feedback tarda lo mismo, aumenta la distancia entre seguros.

Podemos acortarla comprobando antes y trabajando en tramos más pequeños.

La palabra relevante importa. Que el linter pase no significa que el importe de una factura sea correcto. Cada seguro protege frente a ciertos fallos; necesitamos saber cuáles.

Imaginemos que el agente modifica una regla de descuentos. Después adapta la API y construye la pantalla. Pero ha interpretado mal qué ocurre cuando coinciden dos promociones.

Si comprobamos ese caso al cambiar el cálculo, podemos corregir la interpretación antes de construir encima. Si lo descubrimos al probar la compra completa, ya habremos apoyado más trabajo sobre el mismo error.

Esa es nuestra distancia al seguro. Me interesa observar qué decisiones estamos dando por buenas y cuánto trabajo depende de ellas.

Lo que hay debajo

Pero la distancia no describe por sí sola el riesgo. En este ejemplo, descubrir el fallo mientras desarrollamos obligaría a rehacer trabajo. Descubrirlo después de cobrar a los clientes tendría otras consecuencias.

Para pensar en el daño en producción, podemos usar una segunda expresión:

Daño esperado por cambio = probabilidad de que el cambio llegue defectuoso a producción × daño medio cuando eso ocurre.

La primera parte pregunta si nuestras protecciones evitarán que el error llegue hasta los usuarios. La segunda pregunta qué consecuencias tendrá si lo hace, contando con nuestra capacidad de contenerlo y recuperarnos.

Es una media esperada: muchos cambios pueden no causar ningún daño y unos pocos concentrar las pérdidas. Para estimarla necesitaríamos datos de cambios comparables y una medida concreta del daño. Aquí la usaremos para decidir dónde intervenir, sin asignarle porcentajes por intuición.

Las dos expresiones miran cosas distintas. La primera describe cuánto avanzamos sin comprobar. La segunda incorpora la posibilidad de que un defecto llegue a producción y sus consecuencias.

El croquis

Volvamos a la pared.

Primero prepararía el croquis de la vía: el comportamiento esperado, los límites del cambio, las convenciones y las restricciones de arquitectura.

Ahí encajan un AGENTS.md, un CLAUDE.md, documentación y skills para tareas concretas. Birgitta Böckeler los sitúa entre las guías en Harness engineering for coding agent users: elementos que orientan al agente antes de actuar.

Para los descuentos, el croquis debería incluir ejemplos inequívocos: qué promociones se combinan, cuáles se excluyen y cuánto debe pagar el cliente en cada caso.

Los seguros

Después colocaría los seguros: las comprobaciones que nos permiten detectar un mal movimiento. Cuando devuelven información al agente para que pueda corregirse, funcionan como los sensores que describe Böckeler.

Lo que queremos comprobar	Protección que pondría
Tipos y convenciones	Type checking y lint durante el trabajo.
Reglas de descuentos	Tests con ejemplos de negocio revisados.
Compatibilidad entre componentes	Tests de integración y de contrato.
Compra completa	Un E2E del recorrido crítico.

Buscaría el primer momento razonable para ejecutar cada comprobación y actuar sobre su resultado. La distancia al seguro depende de cuándo recibimos feedback útil, no de que la prueba se llame unitaria, de integración o E2E.

Pasar la cuerda

Tampoco basta con que los seguros estén disponibles. Hay que pasar la cuerda por ellos.

Por eso conectaría los checks a la ejecución mediante hooks y los exigiría en CI. Richardson distingue dos funciones del mismo check: sensor cuando ayuda al agente a corregirse y guardarraíl cuando bloquea el cambio en el pipeline. Una comprobación que depende de que alguien recuerde ejecutarla deja un hueco en la protección.

También revisaría dónde están anclados esos seguros. Böckeler advierte de los límites de confiar en tests generados por IA para validar el comportamiento. En nuestro ejemplo, implementación y tests podrían compartir la misma interpretación equivocada de los descuentos.

Por eso no evaluaría la protección contando checks. Preguntaría qué errores detectan y qué puntos ciegos comparten. Nuestro trabajo como aseguradores incluye revisar qué estamos dando por correcto.

Preparar la caída

Y prepararía el sistema para los errores que consigan atravesar las comprobaciones.

En la segunda fórmula, esa preparación actúa sobre el daño. Richardson propone, entre otras medidas, canary deployments y rollback rápido. Para nuestro cambio, pediría concretar a quién se expone inicialmente, qué señal detiene el despliegue y cómo se recupera la versión anterior. También qué consecuencias quedarían por resolver: en el ejemplo, habría que revisar los cobros afectados.

La autonomía debe quedar definida. Un agente que propone un diff, otro que puede integrar y otro que puede desplegar tienen permisos distintos. Al evaluar el riesgo, dejaría explícito hasta dónde puede actuar cada uno y qué controles encontrará por el camino.

Antes de darle más cuerda

Para empezar a medir, registraría errores, dónde se detectaron y qué consecuencias tuvieron, separando tipos de cambios comparables. Mientras no tengamos esos datos, las fórmulas nos sirven para hacer mejores preguntas.

¿Estamos ayudando al agente a acertar? ¿Qué detectará sus errores? ¿Cuánto habrá avanzado cuando reciba ese feedback? ¿Qué ocurrirá con lo que se escape?

Quiero que el agente suba deprisa. Para dejarle hacerlo, necesito poder responder esas preguntas.

Antes de darle más cuerda, miraré dónde está el último seguro y qué hay debajo.