El código aparece casi al instante ahora. Describes una feature, un agente la escribe, y treinta segundos después hay un diff en tu pantalla con aspecto plausible. Luego pasas los siguientes cuarenta minutos decidiendo si te lo crees. Leyéndolo, hurgándolo, confiando a medias, publicándolo con un nudo en el estómago. Escribirlo salió gratis. Confiar en él te costó la tarde.
Esa brecha, entre que el código exista y que estés dispuesto a poner tu nombre en él, es el verdadero cuello de botella ahora. Siempre estuvo ahí. Antes se escondía dentro del tiempo que costaba escribir el código, porque si lo escribías despacio a mano, confiabas en él como subproducto de construirlo. Quita la escritura lenta y la confianza deja de venir gratis. Se queda ahí de pie, sola, sin pagar, y resulta ser la parte cara.
El output nunca fue de verdad la restricción
Pasamos décadas optimizando la producción. Lenguajes más rápidos, mejores editores, autocompletado, frameworks, snippets, todo dirigido a sacar el código de tu cabeza y meterlo en el fichero más rápido. Funcionó, y todo ese tiempo resolvía el problema equivocado, o mejor dicho un problema a punto de desaparecer.
Porque la producción ya está resuelta. No perfectamente, pero muy por encima del punto en que restringe algo. Los modelos escriben código. El cuello de botella no se desvaneció cuando producir se abarató, se movió, como se mueve siempre un cuello de botella, a la siguiente cosa más escasa. Y la siguiente cosa más escasa es la confianza. Puedes generar diez implementaciones de una feature antes de comer. No puedes confiar en diez implementaciones antes de comer. La lectura, la comprobación, el «¿rompe esto lo de al lado?», eso no se aceleró nada. Si acaso se volvió más lento, porque ahora respondes por código que no escribiste y no entiendes del todo.
Por eso «la IA me hizo más rápido» tantas veces sabe a mentira para la hora de cenar. La generación se aceleró. La tarde no se acortó. El tiempo solo se mudó, de escribir a verificar, y nadie te avisó de que lo segundo es más duro que lo primero.
La confianza no es una sensación, y esa es la buena noticia
Aquí está la trampa. Como la confianza se siente como un estado subjetivo, intentamos ganárnosla subjetivamente. Leemos el diff con más ahínco. Miramos el código hasta que se disipa la incomodidad y a eso lo llamamos seguridad. Pero una sensación de seguridad no es lo mismo que un código correcto, y la sensación es justo lo que un agente fluido y de tono seguro fabrica mejor. Un agente que escribe código de aspecto limpio e informa «hecho, los tests pasan» produce la sensación de fiabilidad merézcala el código o no.
Así que la confianza subjetiva no escala y ni siquiera sigue bien a la realidad. La salida es dejar de confiar en el código y empezar a confiar en el proceso que produjo la evidencia. Es un objeto distinto por completo. No tienes que creerte la frase del agente. Tienes que poder comprobar la afirmación que hay detrás, mecánicamente, igual cada vez.
La confianza mecánica tiene este aspecto. Hay una especificación de qué significa correcto, escrita antes del código, para que «correcto» no lo decida mirar lo que sea que el agente produjo. Hay una comprobación que el agente no escribió y no puede editar, y pasa o falla por su cuenta. Hay un registro de la comprobación corriendo, salida real, no un resumen. Cuando esas tres cosas existen, tu confianza no está en la palabra del modelo. Está en una cadena de evidencia que puedes inspeccionar. Ese tipo de confianza escala, porque verificar una afirmación contra evidencia fija es rápido, y aguanta, porque la evidencia no cambia su versión para agradarte.
Cómo cierra la brecha de verdad
Cierras la brecha de confianza encogiendo la parte que depende de que tú leas todo personalmente, y agrandando la parte por la que una máquina puede responder.
Mueve la definición de correcto antes de generar. Si decides qué significa «funciona» solo después de ver el código, el código ya enmarcó tu juicio, y tu confianza es en realidad familiaridad. Los criterios de aceptación puestos de antemano te dan algo contra lo que comprobar que la implementación no llegó a moldear.
Haz que la evidencia sea un artefacto real, no una afirmación. «Los tests pasan» es una frase. Un proceso de test que salió con código cero, con su salida capturada, es evidencia. La diferencia es el juego entero. Una la tienes que creer, la otra la puedes mirar. Cerrar el trabajo con la prueba adjunta es lo que convierte una promesa en un hecho sobre el que actuar sin releer el mundo.
Verifica las fronteras a las que el agente es ciego. Un modelo escribe cada pieza para que sea localmente correcta, y la corrección local es justo lo que se le da bien. La brecha de confianza vive en las costuras, donde el código nuevo se encuentra con el viejo, donde una asunción aquí contradice un invariante allá. Es el problema de lo localmente correcto y globalmente incoherente, y es precisamente la región donde leer el diff te dice menos, porque el diff te muestra el cambio y esconde todo lo que el cambio debía respetar. Aquí la confianza viene de comprobaciones que cruzan las costuras, tests de integración y contratos, no de mirar un fichero con más intensidad.
Reserva tu atención para lo que solo tú puedes juzgar. La confianza mecánica no quita al humano, lo recoloca. La máquina responde por «los tests pasan y no hubo regresión». Tú respondes por «este es el comportamiento correcto que construir». Son trabajos distintos, y colapsarlos es lo que te quema la tarde. Cuando la capa mecánica es sólida, tu tiempo de lectura va a las decisiones que de verdad piden una persona, no a hacer de niñera de un tic verde.
La brecha es donde vive ahora la disciplina
Hay un desplazamiento entero escondido en esto, de producir software a asegurarlo, y reordena el trabajo. Cuando el output era escaso, el buen ingeniero era el que sabía producir. Cuando la confianza es escasa, el buen ingeniero es el que sabe establecerla, rápido y de forma repetible, sobre un volumen de código que ningún humano leería línea a línea. No es un descenso del oficio. Es el oficio moviéndose adonde se movió la restricción.
Nada de esto significa leer con menos cuidado cuando la lectura importa. Significa no gastar tu único recurso escaso, la atención cuidadosa, en cosas por las que una máquina debería haber respondido antes de que el código llegara a ti. La brecha de confianza es el verdadero tema de verificar código generado por IA: no cómo hacer que el agente produzca más, sino cómo hacer creíble su output a la velocidad a la que llega.
Dónde encaja PaellaDoc
La brecha de confianza es justo la costura que PaellaDoc está hecho para sostener. Los criterios que pones antes de generar viven junto al código, para que «correcto» no sea algo que reconstruyes desde el diff. Las comprobaciones corren y dejan un registro, para que la evidencia sea un artefacto que inspeccionas en vez de una frase que crees. Y el trabajo no llega a «hecho» hasta que esa evidencia existe. Dejas de ser el mecanismo de confianza entero, leyendo cada línea para sentirte bien al publicar, y vuelves a gastar tu juicio donde cuenta: decidir qué debería ser verdad, y dejar que el sistema demuestre que lo es.
Preguntas frecuentes
¿Qué es la brecha de confianza en el código generado por IA?
Es la distancia entre que el código exista y que estés dispuesto a poner tu nombre en él. Cuando escribías el código despacio a mano, confiabas en él como subproducto de construirlo. Los agentes quitaron la escritura lenta, y la confianza deja de venir gratis. Se queda ahí sin pagar, y resulta ser la parte cara: el código llega en segundos, creértelo te lleva el resto de la tarde.
¿Por qué la IA no me hace más rápido en realidad?
Porque la generación se aceleró mientras la verificación no. Puedes producir diez implementaciones de una feature antes de comer, pero no puedes confiar en diez antes de comer. El cuello de botella no se desvaneció cuando producir se abarató, se movió a la siguiente cosa más escasa, que es la confianza. El tiempo se mudó de escribir a verificar, y verificar es más duro, porque ahora respondes por código que no escribiste y no entiendes del todo.
¿Cómo confío en código que no escribí y no entiendo del todo?
Deja de intentar ganarte la confianza subjetivamente leyendo el diff con más ahínco, porque eso solo fabrica una sensación que un agente fluido produce bien. Confía en el proceso: una especificación de correcto escrita antes del código, una comprobación que el agente no puede editar y pasa o falla por su cuenta, y una ejecución registrada con salida real. Esa cadena de evidencia es inspeccionable y escala, porque verificar una afirmación contra evidencia fija es rápido.
¿Dónde falla más a menudo el código generado por IA?
En las costuras, donde el código nuevo se encuentra con el viejo, donde una asunción aquí contradice un invariante allá. Un modelo escribe cada pieza para que sea localmente correcta, que es justo lo que se le da bien, así que el diff parece limpio mientras la incoherencia se esconde en lo que el cambio debía respetar. Leer el fichero cambiado es lo que menos te dice aquí. La confianza en las fronteras viene de tests de integración y contratos que cruzan las costuras, no de mirar un fichero con más intensidad.