El problema del setenta por ciento es la observación de que la generación tiende a llevar una compilación de software la mayor parte del camino hasta que funciona, para luego quedarse atascada ante un remanente que resiste la automatización. Esa última fracción no es más del mismo código a menor escala. Es trabajo cualitativamente diferente: integración, casos límite, endurecimiento de producción y la parte que nadie se molestó en especificar. El primer tramo premia la fluidez; el último tramo premia el juicio, y el juicio no se comprime como lo hace el código boilerplate.
- El primer 70% es una superficie bien especificada; el resto es el interior no especificado.
- Una demo prueba el camino esperado y oculta las condiciones que lo rompen.
- Los casos límite se multiplican más rápido de lo que cualquier instrucción puede enumerarlos.
- La fricción de la integración existe entre sistemas, donde ningún generador individual puede verlo.
- El endurecimiento de la producción consiste principalmente en defenderse contra entradas que nadie describió.
- La figura cambia con el tiempo, pero la forma de la dificultad no.
¿Por qué el último tramo es cualitativamente diferente del primero?
El primer tramo de una compilación está cargado de estructuras que se han descrito miles de veces. Formas, listas, enrutamiento, estado, una forma de datos con campos predecibles. La generación es fuerte aquí porque los patrones son comunes y la intención es legible. Hay poca ambigüedad sobre lo que debe hacer una tabla ordenable o un formulario validado.
El remanente es diferente en su naturaleza. Es propiedad de un sistema en el que la especificación se agota y la realidad continúa. ¿Qué sucede cuando dos escrituras entran en competencia? ¿Cuándo una superficie aguas abajo devuelve una forma que prometió nunca devolver? ¿Cuando un usuario hace lo razonable pero no anticipado? Estas preguntas no son versiones más difíciles de las primeras. Son una categoría separada, definida menos por escribir código que por decidir qué debe significar el código bajo condiciones que la solicitud original nunca nombró.
También hay un efecto de retroalimentación. El código inicial se genera rápido, por lo que se acumula rápido, y el volumen en sí se convierte en terreno por atravesar. Una construcción que se materializa en minutos aún tiene que entenderse en horas. El lector llega a una estructura que no escribió, con convenciones que no eligió, y el costo de comprensión cae exactamente en el momento en que comienzan las decisiones difíciles.
Por eso el porcentaje es resbaladizo. A medida que los modelos mejoran, el límite tiende a moverse, pero se mueve a lo largo de la misma línea de falla: dondequiera que termine una especificación explícita, la automatización se ralentiza. La pendiente se acelera precisamente donde la descripción se adelgaza. Una figura que parece progreso es realmente una marca en una frontera que sigue desplazándose hacia las partes que siempre fueron las menos legibles.
¿Qué oculta una demo que revela la producción?
Una demo es una actuación controlada. Corre un único camino, con entradas elegidas, en una red tolerante, ante un público que quiere que tenga éxito. La producción es su contrapartida adversaria: todos los caminos a la vez, entradas hostiles, fallos parciales, y nadie al mando. La distancia entre esos dos estados es la brecha entre demostración y producción, y ahí es donde va la mayor parte del esfuerzo de la última milla.
La brecha es amplia porque una demo funcional y un sistema funcional comparten una apariencia, pero no una estructura. La demo optimiza lo visible. El sistema debe tener en cuenta lo invisible: los reintentos, la idempotencia, el time-out que se dispara una vez a la semana, la migración que debe ejecutarse mientras el tráfico continúa. Nada de eso aparece en una grabación de pantalla.
Una compensación que emerge es la velocidad frente a la durabilidad. La generación compra un artefacto rápido y plausible. Convertir ese artefacto en algo que resista la carga real es más lento, y rara vez parece generar más código. Se parece a leer, rastrear y restringir lo que ya existe.
La brecha también tiene un costo perceptual. Una demo convincente genera una expectativa de que el trabajo está casi terminado, lo que hace que el esfuerzo restante parezca una regresión en lugar de la mayor parte del trabajo. Los interesados lo vieron funcionar. La distancia entre ese momento y un sistema confiable es real, pero es difícil de defender porque es invisible para cualquiera que solo haya visto la ejecución.
¿Por qué el remanente no especificado es el más difícil?
El remanente no especificado se refiere al comportamiento que un sistema debe exhibir que ninguna solicitud, instrucción o ticket describió jamás.
La especificación es costosa precisamente donde más importa. Nadie especifica qué hace el proceso de pago cuando la confirmación de la superficie de pago tiene éxito pero la escritura del pedido falla, porque nadie quiere pensar en ello hasta que ocurre. Por lo tanto, la brecha entre la intención declarada y el comportamiento requerido se convierte en el trabajo. Alguien tiene que notar la ausencia, nombrarla y decidir.
Notar es la habilidad infravalorada aquí. Un generador llena lo que se le da y guarda silencio sobre lo que no es, y ese silencio se interpreta como completitud por cualquiera que solo verifica el camino feliz. El remanente es invisible por construcción. Hacerlo visible implica imaginar el sistema bajo estrés antes de que llegue el estrés, lo cual es un hábito de atención más que una característica que cualquier herramienta entregue.
- Camino feliz
- La secuencia única de eventos que una demo está diseñada para mostrar, donde cada dependencia funciona como corresponde.
- Remanente no especificado
- Comportamiento que el sistema debe exhibir que ninguna solicitud, instrucción o ticket describió jamás.
- Costura de integración
- El límite entre dos sistemas, donde las suposiciones de cada uno sobre el otro quedan sin declarar.
- Endurecimiento de producción
- El trabajo de hacer que la estructura generada sobreviva a entradas, fallos y carga que no se mostró.
¿A dónde se desplaza el esfuerzo humano cuando la generación absorbe el primer 70%?
El esfuerzo no desaparece; migra. Cuando la masa inicial bien especificada de una construcción se genera en minutos, las horas humanas que antes se dedicaban a escribirla se mueven hacia las actividades en las que la generación es más débil. Leer código desconocido se convierte en una habilidad principal. Decidir qué debe hacer un sistema en sus límites se convierte en la contribución escasa.
Este traslado cambia la forma de un día. Menos tiempo produciendo bocetos iniciales, más tiempo interrogándolos. El cuello de botella cambia de la creación a la verificación — confirmar que lo plausible también es lo correcto bajo condiciones que el generador nunca probó. El juicio, el gusto por los modos de fallo y la paciencia para perseguir un error que aparece una vez a la semana se convierten en el trabajo que tiene peso.
También cambia el valor de la experiencia. El valor de haber visto fallar a muchos sistemas no se transfiere a un generador; reside en la persona que reconoce un olor familiar en código desconocido. Ese reconocimiento es lo que permite a alguien echar un vistazo a un flujo generado y sentir, antes de que se ejecuten pruebas, dónde se doblará. El código temprano se estandariza; el instinto para sus bordes no lo hace.
| Propiedad | Primer 70% (generado) | Último 30% (humano) |
|---|---|---|
| Especificación | Explícita, común, legible | Implícita, rara, disputada |
| Actividad dominante | Producir estructura | Restringir el comportamiento |
| Visibilidad de fallos | Obvia en una demo | Oculta hasta la producción |
| Motor de costo | Volumen de código | Profundidad del juicio |
| Compresibilidad | Alta | Baja |
¿Cómo cruzan los equipos la última milla deliberadamente?
Cruzar la última milla tiende a seguir un orden, no porque exista una receta, sino porque las fallas llegan en una secuencia predecible. La disciplina es tratar el artefacto generado como una hipótesis y el trabajo restante como falsación.
- Mapa las costuras: enumera cada límite donde la construcción toca un sistema que no controla.
- Enumera las entradas que la demo nunca usó, especialmente las malformadas, vacías y duplicadas.
- Rastrea cada ruta de fallo hasta una decisión: reintentar, rechazar, degradar o exponer.
- Haz explícito lo implícito escribiendo el comportamiento que nadie especificó, y luego eligiéndolo.
- Presiona el resultado con concurrencia real y volumen real antes de declararlo terminado.
Cada paso convierte lo desconocido en una intención declarada. El 70% generado te brinda un cuerpo para interrogar; este procedimiento es la interrogación. Es más lento que la generación por diseño, porque su producto es certeza en lugar de superficie.
El orden importa más que cualquier paso individual. Mapear las costuras primero previene el error común de endurecer el interior mientras las fronteras quedan desprotegidas. Enumerar las entradas antes de rastrear fallos mantiene el trabajo anclado en lo que realmente llega, en lugar de en lo que se imaginaba. La secuencia es una forma de gastar la atención donde lo más probable de que surja la próxima falla, en lugar de donde el código es más cómodo de leer.
¿Qué se convierte la frontera de la última milla a medida que mejora la generación?
La frontera no se está disolviendo; se está trasladando hacia arriba. A medida que la generación maneja más de la parte central bien especificada, la frontera humana se desplaza hacia las partes que siempre fueron las menos describibles — las decisiones de juicio, la semántica de fallo, y las decisiones sobre lo que un sistema debe a sus usuarios cuando algo falla. El porcentaje puede aumentar. El carácter del remanente se vuelve más difícil, no más fácil, porque lo que queda es el residuo de todo lo que resistió la especificación.
Lo que se vuelve más escaso, entonces, no es la capacidad de codificar, sino la capacidad de sostener los bordes de un sistema en la mente y decidir bien sobre ellos. El campo tiende a premiar a quienes pueden leer rápido, dudar de forma productiva y terminar. La última etapa de una construcción generada permanecerá humana mientras alguna parte de cada sistema permanezca no especificada — es decir, durante mucho tiempo.
Hay una implicación más tranquila sobre cómo se organizan los equipos. Si la parte central generada sigue creciendo, el trabajo que distingue un sistema terminado de uno plausible se concentra en unas pocas horas más densas. Esto tiende a premiar la profundidad sobre el rendimiento, y hace que la capacidad de decir qué debe hacer un sistema ante fallos sea más valiosa que la capacidad de producir más de ello. La frontera se mueve; no se cierra.
F.A.Q.