Piensa en dónde iba el esfuerzo. Durante casi toda la historia del software, la parte cara era hacer que la cosa existiera: escribir el código, conseguir que compilara, pelearlo hasta que funcionara siquiera. Todo en cómo organizábamos equipos asumía que la producción era el recurso escaso. Las estimaciones eran sobre cuánto se tardaría en construir. La contratación, sobre cuánto se podía construir. El cuello de botella era el teclado.
Los agentes movieron el cuello de botella, y muchos procesos siguen optimizando la estación que ya no es la restricción.
Qué se abarató y qué no
Sé preciso con lo que cambió. Producir código se abarató de forma drástica. Un agente convierte una descripción en una implementación funcionando en minutos, y lo hace otra vez, y otra, a través de sesiones en paralelo, más rápido de lo que podría cualquier equipo de humanos. La estación de producción, aquella en la que todo solía atascarse, ahora corre casi gratis.
Lo que no se abarató es saber que el código producido es correcto, que es seguro y que es coherente con todo lo que lo rodea. Ese trabajo, llámalo aseguramiento, cuesta exactamente lo que costó siempre, y podría decirse que más, porque ahora tiene que seguir el ritmo de una tasa de producción que ya no lo espera. El modelo escribe la feature en cinco minutos. Decidir si fiarse de la feature le sigue costando a un humano la misma hora cuidadosa de siempre.
Cuando una estación de una línea se acelera enormemente y la siguiente no, la restricción se mueve a la estación lenta. No es una metáfora, es como se comporta cualquier pipeline. El cuello de botella de construir software se ha movido de producir a asegurar. El recurso escaso y caro ya no es generar código. Es establecer que el código generado se puede creer.
El síntoma: crecimiento rápido, podredumbre más rápida
Puedes detectar un equipo que no ha notado el cambio por sus síntomas. La base de código crece rápido, lo que se siente como progreso. Luego empieza a pudrirse más rápido de lo que crece, lo que se siente como mala suerte y en realidad es estructura. Features que individualmente pasaron la revisión se combinan en un comportamiento que nadie diseñó. Cada cambio era localmente correcto y el conjunto deriva hacia la incoherencia, porque la estación de producción corría a tope mientras el aseguramiento seguía siendo un sello de goma al final.
La pista es dónde aparece el dolor. Si tus días difíciles son sobre generar código, vives en el mundo antiguo. Si tus días difíciles son sobre fiarte del código, revisarlo, reconstruir por qué existe, decidir si el último verde fue real, entonces el cuello de botella ya se movió y tu proceso puede no haberse movido con él.
La trampa es que los instintos del mundo antiguo aún se sienten productivos. Generar más parece impulso, y el impulso es satisfactorio, así que la respuesta natural a ir por detrás es apuntar los agentes a más trabajo. Pero si la restricción es el aseguramiento, esa respuesta empeora el problema en vez de arreglarlo: ensancha el hueco entre lo que se ha producido y lo que se ha verificado, y ese hueco creciente es justo la podredumbre. Sentirse ocupado y estar bloqueado se ven idénticos desde dentro cuando optimizas la estación equivocada.
Asegurar no es hacer más tests
Sería fácil oír «aseguramiento» y echar mano de «escribe más tests». Los tests son parte, pero el aseguramiento es la pregunta mayor a la que sirven: ¿se puede creer este output, y cómo lo sé? Eso incluye si los tests llegaron a ejecutarse, que no es algo que la palabra del agente pueda zanjar. Es todo el problema detrás de un éxito falso, donde «los tests pasan» es una frase generada en vez de un evento observado.
El aseguramiento es la disciplina de convertir afirmaciones en evidencia al ritmo al que llegan las afirmaciones. Cubre qué prueba de verdad un build en verde y qué no, si la compleción costó una demostración real, y si la evidencia sobrevive más allá de la terminal en la que se imprimió. Testear es una herramienta dentro del aseguramiento. El aseguramiento es la estación.
Qué cambia cuando la restricción es el aseguramiento
Nombrar el cuello de botella solo sirve si cambia lo que haces. Unas cuantas cosas se mueven en cuanto aceptas que el aseguramiento, y no la producción, es el recurso escaso.
Las estimaciones dejan de ser sobre tiempo de construcción. La vieja pregunta, «cuánto se tarda en escribir esto», es casi gratis de responder ahora y casi inútil, porque escribirlo es la parte barata. La pregunta que predice tu caudal real es «cuánto se tarda en fiarse de esto», y ese es el número por el que merece la pena planificar. Un cambio que un agente escribe en cinco minutos pero que toca una ruta de pagos no es un cambio de cinco minutos. Es lo que tarde el aseguramiento, y fingir lo contrario es como los equipos se comprometen a una velocidad que en realidad no pueden sostener.
La planificación de capacidad también se invierte. Añadir más generación, más agentes, más sesiones en paralelo, no sube el output más allá del punto en que el aseguramiento se satura. Solo ahonda la cola de trabajo sin verificar esperando al único humano que puede decidir si fiarse de él. Pasado ese punto, más producción no es más entrega, es más inventario. La palanca que mueve software terminado y fiable es la capacidad de aseguramiento, y ahí es donde va la inversión una vez que la restricción se ha movido.
Y la definición de progreso cambia. En una línea limitada por la producción, un diff grande se siente como un buen día. En una línea limitada por el aseguramiento, un diff grande que llega sin evidencia es un pasivo que ahora tienes que saldar, y un cambio pequeño que cierra con su prueba adjunta es lo que de verdad hizo avanzar el sistema. El equipo que interioriza esto deja de celebrar el volumen y empieza a celebrar el cambio verificado y coherente, que es el único que compone en vez de pudrirse.
Optimizar la estación correcta
En cuanto aceptas que la restricción se movió, el trabajo se vuelve obvio aunque no sea fácil. Dejas de verter esfuerzo en producir más, más rápido, porque la producción no es el cuello de botella y acelerar un no-cuello-de-botella solo amontona inventario delante del de verdad. Más código generado delante de un paso de aseguramiento que no puede seguir el ritmo no es progreso, es una cola creciente de cambios sin verificar.
En su lugar inviertes en el caudal del aseguramiento. Haz que la evidencia sea un subproducto del trabajo para que no cueste una pasada manual aparte. Revisa en los momentos que llevan más información en vez de intentar leerlo todo, que es la salida de la fatiga de review. Cierra cada tarea con la prueba adjunta para que la confianza no haya que reconstruirla a mano después, el argumento del desarrollo basado en evidencia. Cada uno de esos movimientos apunta al mismo blanco: subir cuánto output puedes asegurar por hora, porque ese número, no cuánto puedes producir, es ahora lo que topa el sistema entero. Es la forma concreta de la afirmación de que el cuello de botella es la confianza, no el output.
Dónde encaja PaellaDoc
PaellaDoc es, en estos términos, una apuesta por que el aseguramiento es la restricción. Se niega al éxito auto-declarado, ejecuta el contrato de aceptación contra el resultado real y captura la evidencia junto al cambio, para que la estación de aseguramiento pueda seguir el ritmo de una estación de producción que se volvió muy rápida. La idea no es frenar la generación. Es hacer que fiarse de la generación sea lo bastante barato como para que las dos estaciones corran a la misma velocidad en vez de que una inunde a la otra.
Producir software dejó de ser la parte difícil. Asegurarlo se convirtió en todo el juego. Construye para la estación que es de verdad el cuello de botella.
Preguntas frecuentes
¿Qué es el aseguramiento de software en la era de la IA?
El aseguramiento es el trabajo de saber que el código producido es correcto, seguro y coherente con todo lo que lo rodea, y poder mostrar cómo lo sabes. Es la pregunta mayor a la que sirven los tests: ¿se puede creer este output, incluido si los tests llegaron a ejecutarse? Los agentes abarataron producir código. El aseguramiento cuesta lo que costó siempre, así que se convirtió en la restricción de cuánto software terminado se entrega.
¿Por qué se movió el cuello de botella de escribir código a verificarlo?
Cuando una estación de la línea se acelera enormemente y la siguiente no, la restricción se mueve a la estación lenta. Los agentes convierten una descripción en una implementación funcionando en minutos, a través de sesiones en paralelo. Decidir si fiarse de esa implementación le sigue costando a un humano la misma hora cuidadosa. Producir se abarató, asegurar no, así que el recurso escaso ya no es generar código sino establecer que el código generado se puede creer.
¿Asegurar es simplemente hacer más tests?
No. Los tests son una herramienta dentro del aseguramiento, no su totalidad. El aseguramiento es la disciplina de convertir afirmaciones en evidencia al ritmo al que llegan: si un build en verde prueba que la feature es correcta, si la compleción costó una demostración real, si los tests llegaron a ejecutarse, y si la prueba sobrevive más allá de la terminal en la que se imprimió. Testear es un instrumento; el aseguramiento es la estación.
¿Cómo deberían cambiar las estimaciones cuando el aseguramiento es el cuello de botella?
Deja de estimar tiempo de construcción y empieza a estimar tiempo de confianza. «Cuánto se tarda en escribir esto» es casi gratis de responder ahora y casi inútil. Un cambio que un agente escribe en cinco minutos pero que toca una ruta de pagos no es un cambio de cinco minutos, es lo que tarde el aseguramiento. Planificar por tiempo de construcción te compromete a una velocidad insostenible, porque el trabajo sin verificar se amontona ante el único humano que puede fiarse de él.