4. El bucle de feedback y el costo del fallo tardío

Descripción

Al terminar esta lección vas a entender la razón económica de todo el CI, y es una sola: mientras más tarde se detecta un fallo, más caro cuesta arreglarlo. No un poco más caro: mucho más, y de forma que se acelera con cada escalón. El mismo bug —el descuento pro que se olvida, un assert 7500 == 6000— cuesta casi nada si lo cazas en el segundo en que lo escribiste, y puede costar una fortuna si viaja sin ser visto hasta que un cliente recibe un cobro de más. Entre esos dos extremos hay una escalera de escalones —tu editor, el test local, el CI, la revisión de código, staging, producción, el cliente— y en cada escalón que el bug sube, el costo de bajarlo se multiplica.

La palabra que ordena todo esto es bucle de feedback: cuánto tarda tu código en decirte que algo se rompió, medido desde el momento en que lo rompiste. Un bucle corto —el test te avisa a los segundos— es barato y casi indoloro. Un bucle largo —te enteras semanas después, en producción— es caro y doloroso, no solo por el arreglo en sí, sino porque para entonces perdiste el contexto: ya no recuerdas qué cambiaste ni por qué. Vas a ver por qué el CI es, ante todo, una máquina de acortar el bucle: no elimina los bugs (eso lo hacen tus tests), pero se asegura de que el aviso llegue temprano, automáticamente, cuando el arreglo todavía es barato.

Conexión con el módulo: esta lección da el "cuánto vale" que las anteriores dejaron implícito. La 2 mostró el problema (el fallo de entorno), la 3 definió la solución (el CI); esta explica por qué corre la pena montarla, en términos de costo y tiempo. Lo que sigue se apoya en esto: la lección 5 muestra las etapas del pipeline que producen ese feedback rápido; la 6, cómo ese feedback protege la rama principal. Si la lección 3 te dijo qué es el CI, esta te dice por qué te conviene.

El error de dedo en el volante del periódico

Piénsalo así. Escribes un artículo para un periódico y, sin querer, tecleas "el evento será el jueves" cuando era el viernes. ¿Cuánto cuesta arreglar ese error de dedo? Depende enteramente de cuándo lo descubras.

Si lo ves mientras escribes, en el mismo renglón: borras "jueves", escribes "viernes", cero costo, ni te acuerdas mañana. Si lo ve el corrector una hora después: te manda una nota, tú corriges, cinco minutos. Si lo ve el editor al día siguiente, cuando la página ya está maquetada: hay que rehacer la maqueta, cuesta más. Si se cuela a la imprenta y salen diez mil ejemplares con el jueves: hay que decidir si se reimprime (una fortuna) o se vive con el error. Y si llega al lector, que se presenta el jueves a un evento que era el viernes: el costo ya no es tuyo, es de otra persona que perdió su tarde, y encima es un golpe a la credibilidad del periódico que no se arregla con una corrección.

El error es el mismo en los cinco casos —una letra—. Lo que cambia brutalmente es el costo, y cambia por una sola variable: cuándo se detectó. Cada escalón que el error sube antes de que alguien lo vea multiplica lo que cuesta bajarlo, porque en cada escalón hay más cosas construidas encima —la maqueta, la tinta, el viaje del lector— que hay que deshacer.

Un bug en software es exactamente ese error de dedo, y sube exactamente esa escalera. La diferencia entre un equipo que sufre y uno que no, no es que el segundo no cometa errores de dedo —todos los cometen—, sino dónde los caza: el equipo sano los caza en el renglón, con un test que corre al instante; el equipo que sufre se entera en la imprenta, con un cliente enojado. Y el CI es, ni más ni menos, el corrector que lee cada artículo automáticamente antes de que pase a maqueta —para que ningún error de dedo llegue a la imprenta solo porque alguien tenía prisa un viernes—.

El costo de un bug no lo fija el bug: lo fija el momento en que se detecta. Cada escalón que sube antes de ser visto multiplica lo que cuesta arreglarlo. El CI existe para bajar ese momento lo más cerca posible del instante en que el bug nació.

La escalera del costo, escalón por escalón

Pongámosle escalones concretos a la escalera, con el bug que ya conoces: alguien "mejora" el descuento pro de Reservo y, sin querer, rompe el número-ancla —el pro de 3 horas debería pagar 6000 y ahora paga 7500—. Sigamos ese mismo bug subiendo, y veamos qué cuesta cazarlo en cada escalón.

Escalón	Quién/qué lo caza	Cuánto tarda el aviso	Costo de arreglarlo
1. El editor	Tú, mientras escribes	Segundos	Casi cero: borras y reescribes, contexto fresco
2. El test local	pytest en tu máquina	Segundos a minutos	Muy bajo: sabes exactamente qué tocaste
3. El CI	El pipeline, en el push/PR	Minutos	Bajo: el cambio es reciente, el contexto sigue tibio
4. La revisión de código	Un compañero, leyendo el PR	Horas a días	Medio: hay que reconstruir por qué se hizo el cambio
5. Staging / QA	Pruebas manuales antes de producción	Días	Alto: el bug ya cruzó varias manos, el contexto se enfrió
6. Producción	El sistema en vivo	Días a semanas	Muy alto: hay que diagnosticar en caliente, con prisa
7. El cliente	Alguien que pagó de más	Cuando se queja (o se va)	El más alto: dinero real, confianza rota, quizá legal

Mira la forma de la última columna: no crece de a poco, se dispara. Entre el escalón 1 y el 2 casi no hay diferencia. Pero entre el 3 (CI) y el 6 (producción) hay un abismo, y entre el 6 y el 7 (cliente) el costo deja de ser técnico y se vuelve dinero, reputación y a veces asuntos legales. Es la misma letra mal tecleada; lo que explotó fue cuándo se vio.

Fíjate dónde está el CI en la escalera: en el escalón 3, tempranísimo, justo después de tu test local y antes de que un humano gaste su tiempo revisando (escalón 4). Esa posición es todo el punto. El CI no baja el bug del escalón 7 al 1 —para eso necesitarías tener el test escrito, que es fundamentos—; el CI se asegura de que, si el test existe, el aviso llegue en el escalón 3 automáticamente, sin depender de que tú te acuerdes de correr la suite. Convierte "quizá alguien lo cace tarde" en "la máquina lo caza temprano, siempre".

Por qué el bucle largo cuesta más de lo que parece: el contexto se enfría

Hay un costo del fallo tardío que la tabla no captura del todo, y es el más importante: el contexto se enfría. Cuando rompes algo y el aviso llega en segundos, tienes toda la escena en la cabeza —qué línea tocaste, qué querías lograr, qué probaste—. Arreglarlo es trivial porque no tienes que reconstruir nada; sigues ahí.

Cuando el aviso llega tres semanas después, en producción, esa escena se evaporó. Ya no recuerdas ese cambio; tuviste veinte cambios más desde entonces. Ahora arreglar el bug empieza por una arqueología: ¿cuál de mis cambios fue?, ¿por qué lo hice?, ¿qué más depende de esto ahora? El arreglo en sí sigue siendo una línea, pero rodearlo de contexto perdido puede costar horas o días. Por eso el bucle largo es tan caro: no pagas solo por el arreglo, pagas por redescubrir lo que ya sabías el día que lo escribiste.

Este es el argumento más fuerte a favor del CI, más incluso que "atrapa bugs". El CI atrapa el bug mientras el contexto sigue tibio. Te avisa en el escalón 3, minutos después del push, cuando todavía recuerdas perfectamente qué hiciste. El bug que el CI caza en un PR se arregla en minutos porque el autor todavía tiene la escena fresca; el mismo bug cazado en producción tres semanas después se arregla en un día porque hay que reconstruir la escena entera. El CI no hace el arreglo más fácil; hace que el arreglo llegue cuando todavía era fácil.

Un matiz honesto: el CI no es el bucle más corto

Vale la pena decirlo con claridad para no vender humo. El bucle más corto de todos no es el CI: es tu test local, corrido en tu máquina, que te avisa en segundos (escalón 2). El CI vive en el escalón 3, y es un poco más lento —minutos, no segundos, porque tiene que arrancar una máquina limpia, instalar y correr—. Entonces, ¿para qué el CI, si tu test local es más rápido?

Por dos cosas que tu test local no te da, y que ya conoces de las lecciones anteriores. Primero: tu test local depende de que tú te acuerdes de correrlo (la grieta del olvido); el CI corre siempre, sin fallar, en cada push. Segundo: tu test local corre en tu entorno con sus supuestos (la grieta del entorno); el CI corre en el limpio, y caza las fugas de la lección 2 que tu test local nunca vería. O sea: el CI cambia unos segundos de latencia por dos garantías enormes —que el aviso siempre llega y que llega desde un entorno neutral—. Es un escalón apenas más arriba que tu test local, pero es el más alto en el que el aviso todavía es automático y confiable. Los escalones de más arriba (revisión, staging, producción) son mucho más lentos y ya dependen de humanos o de que el bug se manifieste solo.

Ejemplo trabajado: el bucle corto, en segundos

Veamos el escalón barato en acción, con salida real, para sentir lo que significa "el contexto todavía tibio". Imagina que estás "mejorando" la promoción pro de Reservo y, sin querer, cambias el descuento de 20% a 25% —un error plausible, alguien tecleó 25 pensando en otra cosa—:

# reservo/pricing.py
PRO_DISCOUNT_PERCENT = 25   # bug introducido a proposito (era 20)

Acabas de romper dos números-ancla: el pro de 3 horas ya no da 6000, y el pro de 1 hora ya no da 2000. Pero no lo sabes… hasta que corres la suite, aquí mismo, en el mismo minuto en que lo tecleaste.

Qué esperar. Corriendo python3 -m pytest test_pricing.py -q con Python 3.14.0:

FAILED test_pricing.py::test_price_by_tier_and_hours[pro-3h] - AssertionError: assert 5625 == 6000
FAILED test_pricing.py::test_price_by_tier_and_hours[pro-1h] - AssertionError: assert 1875 == 2000
2 failed, 2 passed in 0.03s

Léelo por el lado del tiempo, que es el tema de la lección. Entre que tecleaste 25 y que la suite te gritó assert 5625 == 6000 pasaron tres centésimas de segundo. Todavía tienes la mano en la tecla. El contexto está tan tibio que no hay nada que reconstruir: sabes exactamente qué cambiaste —el descuento— y el diagnóstico te confirma la aritmética (7500 - 25% = 5625, cuando debía ser 7500 - 20% = 6000). Arreglarlo es volver el 25 a 20 y correr de nuevo. Costo: casi cero. Esto es el escalón 2 de la escalera —tu test local— en su forma más pura.

Ahora imagina ese mismo assert 5625 == 6000 llegándote no en tres centésimas de segundo sino en un reporte de producción, tres semanas después, cuando un cliente pro reclama que le cobraron de más. El diagnóstico sería idéntico —la misma línea, el mismo número—, pero para entonces ya no recordarías haber tocado el descuento, tendrías veinte cambios encima que revisar, y estarías depurando bajo presión con dinero real de por medio. El mensaje de error es el mismo; lo que cambia es cuánto cuesta recibirlo tarde. Y el CI existe justo para que ese mensaje —el que aquí llegó en segundos porque tú corriste la suite— llegue siempre y automáticamente en el escalón 3, aunque hoy hayas olvidado correrla, aunque tu entorno la hubiera tapado.

Errores comunes

Creer que "ya lo probé en local, el CI es redundante". Qué pasa: alguien corre la suite en su máquina, la ve verde, y siente que el CI no aporta nada porque "ya sé que pasa". Salta el paso mental de que el CI protege de lo que su test local no ve. Por qué pasa: si el bucle local ya te dio verde, el CI parece una repetición más lenta. Cómo detectarlo: si piensas "el CI solo repite lo que ya corrí", olvidaste sus dos garantías. Cómo corregirlo: recuerda que el CI no está para ser más rápido que tu test local, sino para dar lo que tu test local no puede: que el aviso llegue siempre (aunque olvides correr la suite) y desde un entorno limpio (que caza las fugas de entorno). El pequeño costo en latencia compra esas dos garantías.

Optimizar por "que no falle el CI" en vez de "que el fallo llegue temprano". Qué pasa: un equipo, harto de los rojos del CI, empieza a saltárselo —mergea sin esperar el check, o desactiva tests que "molestan"— para que el pipeline no los frene. Sienten que están yendo más rápido. Por qué pasa: un CI rojo se vive como un obstáculo, no como un aviso barato. Cómo detectarlo: si el equipo trata el CI como un peaje a evadir en vez de un corrector que trabaja gratis, invirtió el valor. Cómo corregirlo: cada rojo del CI es un bug cazado en el escalón 3, o sea, dinero ahorrado —ese mismo bug en producción habría costado cien veces más—. Saltarse el CI no acelera al equipo; solo mueve el bug a un escalón más caro. Ir "más rápido" saltándose el corrector es ir más rápido hacia la imprenta con el error puesto.

Medir el costo de un bug por el tamaño del arreglo. Qué pasa: alguien dice "pero si es una línea, ¿cómo va a costar tanto?", y subestima el impacto de un bug tardío porque el arreglo es trivial. Por qué pasa: se confunde el tamaño del cambio con el costo total. Cómo detectarlo: si tu estimación de "cuánto cuesta este bug" solo cuenta las líneas a cambiar, te falta la mitad. Cómo corregirlo: el costo de un bug tardío no es el arreglo, es todo lo que hay que deshacer y reconstruir alrededor: el contexto perdido que hay que redescubrir, el diagnóstico en producción bajo presión, el cliente afectado, la confianza dañada. Una línea de arreglo puede arrastrar un día de arqueología. Por eso importa cuándo se caza, no cuánto mide.

Ejercicios

Ejercicio 1 — Ordena la escalera. Aquí tienes cinco momentos en los que se podría cazar el bug del descuento pro, en desorden. Ordénalos del más barato al más caro de arreglar, y para cada uno di en una frase por qué cuesta lo que cuesta. (a) Un cliente pro llama enojado porque le cobraron 7500 en vez de 6000. (b) El CI marca el PR en rojo con assert 7500 == 6000. (c) Tú, tecleando el cambio, notas que borraste el if member.tier == "pro". (d) Un compañero, revisando tu PR, ve el número raro. (e) Un tester en staging nota que el total no cuadra.

Ver solución

De más barato a más caro:

1. (c) Tú, al teclear. Escalón 1, el editor. Costo casi cero: el contexto es el instante mismo, borras y reescribes.
2. (b) El CI en el PR. Escalón 3. Costo bajo: el cambio es de hace minutos, el contexto sigue tibio, y el aviso fue automático, no dependió de que alguien mirara.
3. (d) El compañero revisando. Escalón 4. Costo medio: horas o un día después, el revisor tuvo que gastar su tiempo y tú tienes que reconstruir un poco el porqué del cambio.
4. (e) El tester en staging. Escalón 5. Costo alto: días después, el bug ya cruzó varias manos, el contexto se enfrió, y hay que rehacer el camino hasta producción.
5. (a) El cliente enojado. Escalón 7. El más caro: dinero real cobrado de más, confianza rota, y un arreglo bajo presión con un cliente esperando.

La lección: es el mismo bug de una línea en los cinco casos. Lo único que ordena la escalera es cuándo se detecta. Y fíjate dónde cae el CI: segundo, casi tan barato como cazarlo tú mismo, y —a diferencia de (c)— sin depender de que estuvieras atento.

Ejercicio 2 — El costo escondido del contexto frío. Dos equipos cazan el mismo bug del descuento pro. El equipo A lo caza en el CI, 10 minutos después del push. El equipo B lo caza en producción, 3 semanas después. En ambos, el arreglo es la misma línea de código. Explica por qué, aun siendo el mismo arreglo, al equipo B le cuesta mucho más, nombrando al menos tres costos que el equipo A no paga.

Ver solución

Aunque la línea a cambiar sea idéntica, el equipo B paga varios costos que el A no:

1. Arqueología del contexto. El autor del equipo B ya no recuerda ese cambio (hizo veinte más en tres semanas). Antes de arreglar, tiene que averiguar cuál cambio fue y por qué lo hizo. El equipo A todavía tiene la escena fresca: arregla directo.
2. Diagnóstico en producción bajo presión. El equipo B descubre el bug porque algo falla en vivo, con clientes afectados y prisa. Diagnosticar en caliente, sin poder reproducir con calma, es lento y estresante. El equipo A lo tiene servido: el CI le dio el assert 7500 == 6000 exacto.
3. El daño ya causado. Durante tres semanas, el equipo B le cobró de más a clientes reales. Aunque arregle el código, tiene que lidiar con reembolsos, disculpas y confianza dañada —un costo que el equipo A, que cazó el bug antes de que llegara a nadie, simplemente no tiene—.

(Se aceptan otros: el equipo B quizá tenga que hacer un despliegue de emergencia, coordinar a más gente, escribir un post-mortem, etc.)

La lección: el costo de un bug tardío casi nunca está en el arreglo; está en todo lo que hay que reconstruir y reparar alrededor. El CI ahorra justo eso, cazando el bug mientras el contexto sigue tibio y antes de que cause daño.

Ejercicio 3 — ¿Por qué no basta con el test local? Un compañero argumenta: "el bucle más corto es mi test local, que me avisa en segundos; el CI es más lento, así que es innecesario". Tiene razón en la primera mitad y se equivoca en la conclusión. Explica por qué, nombrando las dos garantías que el CI da y el test local no, y di qué "paga" el CI a cambio de esas garantías.

Ver solución

Tiene razón en que el test local es el bucle más corto: te avisa en segundos, más rápido que el CI (que tarda minutos en arrancar una máquina limpia, instalar y correr). Pero se equivoca al concluir que el CI es innecesario, porque el CI da dos garantías que el test local no puede:

1. El aviso siempre llega. El test local depende de que tú te acuerdes de correrlo (la grieta del olvido). El día que subes un cambio con prisa sin correr la suite, tu test local no te avisa de nada. El CI corre siempre, automáticamente, en cada push.
2. El aviso viene de un entorno limpio. Tu test local corre en tu máquina, con sus supuestos (la grieta del entorno). Caza bugs de lógica, pero es ciego a las fugas de entorno de la lección 2. El CI corre en el entorno neutral y las caza.

Lo que el CI "paga" a cambio: unos segundos (o minutos) más de latencia que el test local. Es un intercambio muy favorable —cambias un poco de velocidad por que el aviso sea automático y confiable—. Por eso el CI no reemplaza al test local; lo respalda. Corre tu test local para el feedback instantáneo mientras trabajas, y deja que el CI sea la red que no olvida y que ve lo que tu máquina esconde.

Resumen y siguiente paso

En esta lección viste la razón económica del CI: el costo de un bug no lo fija el bug, lo fija el momento en que se detecta. El mismo assert 7500 == 6000 cuesta casi cero si lo cazas al teclear, y una fortuna si llega a un cliente. La escalera —editor, test local, CI, revisión, staging, producción, cliente— multiplica el costo en cada escalón, no de a poco sino disparándose, porque cada escalón tiene más cosas construidas encima que deshacer, y sobre todo porque el contexto se enfría: pagas por redescubrir lo que ya sabías el día que lo escribiste.

El CI vive en el escalón 3 —tempranísimo, justo tras tu test local y antes de gastar el tiempo de un humano— y su valor no es ser el bucle más corto (ese es tu test local), sino ser el escalón más alto donde el aviso todavía es automático y confiable: llega siempre, aunque olvides correr la suite, y desde un entorno limpio que caza las fugas que tu máquina esconde. El CI no hace el arreglo más fácil; hace que el arreglo llegue cuando todavía era fácil.

Antes de avanzar deberías poder: explicar por qué el costo de un bug depende de cuándo se detecta; nombrar tres escalones de la escalera y ordenarlos por costo; explicar el argumento del "contexto tibio"; y decir qué dos garantías da el CI que tu test local no.

Lo que sigue es abrir el CI por dentro. En la lección 5 vas a ver las etapas de un pipeline —checkout, instalar, testear, reportar— que son, en concreto, la maquinaria que produce ese feedback rápido y automático del escalón 3, y la señal exacta —el código de salida— con la que el pipeline decide verde o rojo.

Recursos

• Continuous Integration — Martin Fowler — el ensayo de referencia; su sección sobre "encontrar los bugs rápido" desarrolla exactamente el argumento del bucle de feedback y el costo del fallo tardío que vimos aquí.
• Sobre la integración continua — documentación de GitHub — la visión de GitHub sobre por qué correr los tests temprano y a menudo ahorra tiempo y dinero. Encaja con la escalera del costo de esta lección.
• Buenas prácticas de pytest — documentación de pytest — cómo tener una suite rápida y confiable que haga barato el bucle de feedback local (el escalón 2). Un bucle local rápido es lo que hace que el CI sea un respaldo y no tu única red.
• "The Economics of Software Quality" — panorama sobre el costo de los defectos — una lectura de fondo sobre por qué los defectos detectados tarde dominan el costo del software. Complementa la intuición de la escalera con el porqué de fondo.