El precedente no es la verdad — Cómo la IA copia parches y fabrica autoridad

El precedente no es la verdad

Si la IA te ofrece un parche aparentemente razonable basado en código existente pero algo no cuadra, si la frase “el codebase siempre lo hace así” empieza a resultarte sospechosa, si cambias a un modelo más grande y los mismos errores se repiten — el problema no es la inteligencia del modelo. Es la estructura que confunde el precedente con la verdad.

Lo viví en primera persona. Más exactamente, fue lo que hizo la IA que trabaja conmigo frente a mi propio código. Intervine con una sola frase, y lo que esa frase rompió es de lo que trata este artículo.

El punto de bloqueo

Estaba construyendo un generador de código: una herramienta que extrae backend y frontend a partir de una especificación declarativa (esquema). La promesa central de esa herramienta es una sola — “si pasa la validación, la compilación debe tener éxito.” Si el validador muestra verde y el compilador muestra rojo, la herramienta ha mentido.

Un día, un tipo concreto (un identificador único, UUID) fue rechazado por el validador. Se detuvo diciendo “esperaba una cadena pero recibí otro tipo”. Le pedí a la IA que resolviera el bloqueo. La IA trazó el código y pronto encontró algo familiar.

“Un tipo similar (valores de tiempo) ya se gestiona correctamente en la misma situación. Hay una bifurcación con un marcador especial para que el validador lo deje pasar. Para UUID esa bifurcación no existe. Es una omisión pura. Solo hay que restaurar la simetría. Copiaré el mismo mecanismo que se aplica al valor de tiempo al UUID. Es la solución de raíz.”

Era un diagnóstico impecable. “Asimetría”, “restaurar la simetría”, “solución de raíz”. Las palabras sonaban sólidas. El plan de acción estaba redactado. Si lo hubiéramos seguido, el parche habría sido fusionado.

Una frase

Mientras leía el plan, me detuve y pregunté:

"¿Precedente? ¿Ese tratamiento de valores de tiempo es realmente el enfoque correcto? Compruébalo."

Eso fue todo. No sabía la respuesta. Tampoco sabía cómo debería tratarse el UUID. Lo único que tenía no era la respuesta sino la duda — “ese punto de referencia que vas a copiar, ¿ha sido validado?”

Esa sola frase forzó a la IA a cambiar de modo referencia-de-código a modo verificación-de-comportamiento.

La premisa que se derrumbó

Cuando la IA verificó el output real — no la estructura del código sino el resultado que la herramienta producía de verdad — la premisa se derrumbó por completo.

El valor esperado que el validador asumía como “cadena” era una falsedad que no coincidía con lo generado. El generador real produce el UUID como tipo específico y los valores de tiempo como tipo temporal. Ninguno de los dos es una cadena.
El tratamiento de valores de tiempo que “funcionaba correctamente” tenía exactamente el mismo agujero. No era un diseño correcto sino un parche defectuoso que pasaba la validación pero podía romper la compilación.
¿Y si hubiéramos copiado ese parche al UUID? Habríamos creado un estado nuevo en el que el validador muestra verde y el compilador muestra rojo — una violación directa de la promesa central de la herramienta.

La solución que la IA llamó “solución de raíz” era incorrecta. Y no solo incorrecta — iba en una dirección peor: replicaba el defecto existente y además hacía que el validador ignorara el nuevo defecto.

Cómo llamar a esto — error amplification

Pongámosle nombre a lo que ocurrió aquí. Es error amplification de IA.

La IA lee el código existente y capta con precisión su estructura. Pero si eso es un diseño correcto o un parche rápido — es decir, si es una decisión o una deuda — no puede distinguirlo solo mirando el código. Y así ocurre esto:

Trata la implementación existente como la respuesta implícita,
la replica en el nuevo contexto bajo el pretexto de “consistencia” y “simetría”,
y cuanto más se replica, ese patrón gana autoridad falsa — “el codebase ya lo hace así en varios sitios”.

El defecto no desaparece. El número de casos aumenta y la legitimidad se acumula. Eso es la amplificación. Un parche se convierte en dos, y ante la tercera réplica nadie lo cuestiona — “el codebase lo hace así, siempre.”

Esta historia no termina en mi anécdota. En 2025 un grupo de investigadores midió exactamente este fenómeno y le pusieron el título “LLMs are Bug Replicators” (Pan et al., 2025, arXiv:2503.11082). Cuando el código circundante tenía defectos, una fracción significativa de los bugs que producía el modelo era literalmente idéntica a los bugs existentes — GPT-4o alcanzó un 82,6%, y la media de modelos mostró un 44,4% de coincidencia exacta con la versión sin corregir. Lo más inquietante: en contextos con defectos, la probabilidad de generar código correcto y código incorrecto era casi 1:1. El modelo no falla aleatoriamente. Selecciona y reproduce el patrón de defecto que subyace en el contexto.

El derecho tiene la misma trampa. Una sentencia errónea gana autoridad cuantas más veces se cita. El número de citas no es evidencia de legitimidad, pero los confundimos constantemente. Y esto era una enfermedad que la ingeniería de software conocía antes de la IA — los clones de código creados por copiar y pegar transportan en silencio los bugs del original. Un estudio empírico reportó que aproximadamente el 18% de los clones que habían pasado por una corrección de bug albergaban bugs propagados de este modo, y los clones dentro del mismo archivo tenían mayor probabilidad de propagación. (Mondal et al., ICSME 2017) En el código y en el derecho es igual. La frecuencia de un precedente no es su legitimidad.

Por qué ocurrió esto

No es porque la IA sea torpe. Al contrario — fue por ser prudente por lo que intentó mantener la consistencia, y al intentar mantener la consistencia se alineó con un punto de referencia incorrecto. El mecanismo tiene cuatro componentes.

Colocó la fuente de autoridad en el código. “El código está así, luego es correcto.” Pero el código puede ser una proyección desechable de una decisión, no la decisión en sí. O simplemente deuda. La IA no hizo esa distinción. La ciencia cognitiva lo llama sesgo de anclaje. Investigaciones que experimentaron con este sesgo en LLMs mostraron que los modelos no solo se ven fuertemente atraídos por el valor dado primero, sino que esa atracción es mayor cuando el valor aparece marcado como de un “experto”, y que prompts que piden “ignorar esa pista” o razonar paso a paso apenas lo corrigen. (Nguyen et al., 2024, arXiv:2412.06593) La implementación existente es el ancla más autoritativa que ofrece el codebase.
Confundió consistencia con corrección. “Hagamos simetría con lo existente” era una lógica interna, pero no verificó si ese punto de referencia coincidía con la realidad externa (el output generado). La autoconsistencia es una propiedad distinta de la exactitud — un modelo puede acumular convicción sin fundamento con autoexplicaciones plausibles pero incorrectas. (Chen et al., 2023, arXiv:2305.14279)
Malinterpretó los comentarios como evidencia. Tomó el comentario “este tipo se reduce intencionalmente a cadena” como “evidencia de diseño correcto”. Un comentario es solo la intención de quien lo escribió, no evidencia de su legitimidad.
Empaquetó la deuda con vocabulario de certeza. Palabras como “solución de raíz” o “según el manual” añadieron credibilidad a una propuesta no verificada. Elevaron el coste de que yo la filtrara. Los modelos entrenados con preferencias humanas están sesgados hacia priorizar la aceptación y la cortesía por encima de la exactitud — la tendencia conocida como sycophancy hace que el modelo presente sus propuestas de forma suave y categórica. (Sharma et al., ICLR 2024, arXiv:2310.13548)

Qué rompió el bucle

Aquí está el núcleo de este artículo. Lo que rompió el error no fue un modelo más grande ni más tiempo de razonamiento. Fue una pregunta de un humano.

Y esa pregunta no fue una intervención que “sabía la respuesta”. Yo no la sabía. Fue una indicación de dirección: cuestiona la premisa. Con solo esa frase, la IA cambió de modo — de la mano que referenciaba el código a la mano que verificaba el comportamiento.

Sorprendentemente, un estudio encontró exactamente esta asimetría. Investigadores de DeepMind mostraron que la mala capacidad de autocorrección de los LLMs viene no de la incapacidad de corregir errores sino de la incapacidad de encontrarlos — si se les señalaba externamente la ubicación del error, los modelos lo corregían bien. (Tyen et al., Google DeepMind, 2023, arXiv:2311.08516) Eso fue exactamente lo que hice yo. No sabía cómo corregir el UUID, pero señalé la ubicación: “aquí, duda de este precedente.” Con eso fue suficiente.

Esto dice algo sobre la estructura en que humanos e IA trabajan juntos. El valor humano no reside en saber más y más rápido. En eso la IA ya gana. El valor humano reside en poder ocupar la posición de cuestionar las premisas sobre las que se apoya la IA. La pregunta “¿de verdad es correcto?” pertenece no a quien tiene la respuesta, sino a quien sabe dudar de la respuesta.

Aunque esa posición no se otorga gratis. Un estudio de usuarios de Stanford reportó el incómodo hecho de que los participantes asistidos por IA escribían código menos seguro y al mismo tiempo creían que su código era más seguro. Pero en el mismo estudio, los participantes que confiaban menos en la IA y cuestionaban más produjeron código más seguro. (Perry et al., Stanford, 2022, arXiv:2211.03622) La posición de dudar no es el valor por defecto. Cuanto mayor es la confianza, más vacía queda esa posición.

Entonces, cómo prevenirlo

Las lecciones deben quedar como diseño, no como consuelo.

Precedente ≠ verdad. Antes de extender un patrón existente, verificar primero no si el patrón es internamente consistente sino si produce el resultado correcto.
Anclar en la realidad (ground truth). Situar el criterio de juicio no en la “estructura del código existente” sino en el output real, el comportamiento en runtime, los tests. En este caso, la clave fue siempre “¿qué se produce realmente?”, no “¿cómo está escrito el código?”.
Intentar distinguir decisión de parche, y admitir que no siempre se puede. Cuando el código y los comentarios no permiten distinguirlos, declarar la incertidumbre explícitamente: “esto sigue el precedente, y la legitimidad del precedente está sin verificar”.
Moderar el vocabulario de certeza. No añadir palabras como “raíz”, “correcto” o “según el manual” a propuestas no verificadas.
Insertar puntos de control en la automatización. Cuando un agente toma la decisión de extender una implementación existente, se necesita una puerta que fuerce la pregunta "¿se ha verificado la legitimidad de este precedente?".

Al final, la misma historia

Llevo tiempo sosteniendo una cosa: el raw code no es un medio que preserve las decisiones. El código no puede contener el “por qué se hizo así”. Por eso git blame muestra quién y cuándo pero no qué se decidió.

Este incidente es la demostración más afilada de esa tesis. No es que la persona pierda las decisiones. Es que incluso un agente cuidadosamente diseñado confunde el parche con el diseño y lo propaga al nuevo código. Si las decisiones no se registran explícitamente, la inteligencia no es la solución. Al contrario — cuanto más inteligente, más consistente y más plausiblemente se difunde la deuda.

Por eso construyo especificaciones. Inscribo las decisiones en una única capa declarativa y autoritativa fuera del código. En lugar de esperar a que un humano lance cada vez la pregunta que cuestiona el precedente, intento hacer que el sistema la lance por sí solo.

La ley no es un cuchillo sino una señal. Una buena señal le dice al que se ha perdido “aquí, duda” antes de que ocurra el error. Este artículo es el registro de cómo se erigió una de esas señales — empezando por una sola pregunta.

Lecturas recomendadas (externas)

Generative AI and the End of Chesterton’s Fence — Reece. El principio “no derribes una valla sin saber por qué está ahí” se quiebra ante código generado probabilísticamente sin intención. Encaja exactamente con la tesis de este artículo: el código no preserva las decisiones que hay detrás.
Programming as Theory Building — Christian Ekrem. Toma el clásico de Peter Naur para argumentar que “el programa no es el código fuente sino la teoría en la mente de las personas”. La raíz teórica de por qué la IA, mirando solo el código, no puede distinguir diseño de deuda.
Vibe coding is not the same as AI-Assisted engineering — Addy Osmani. Por qué el vibe coding que confía ciegamente en el output de la IA explota en producción, y la prescripción de un flujo de trabajo basado en especificaciones con verificación humana.
Cognitive Debt — Simon Willison (citando a Storey). Cuanto más rápido genera código la IA, la deuda real no es “defectos en el código” sino “que las personas dejan de entender ese código” — el concepto de deuda cognitiva.
Overreliance on AI: Addressing Automation Bias — Lumenova AI. El mecanismo por el que el sesgo de automatización, el anclaje y el sesgo de confirmación embotan el juicio humano, y la solución del “dispositivo de coerción cognitiva” — respaldo psicológico para el valor humano de saber dónde dudar.

Bibliografía

Pan et al. “LLMs are Bug Replicators: An Empirical Study on LLMs’ Capability in Completing Bug-prone Code” (2025, arXiv:2503.11082)
Mondal, Roy, Schneider. “Bug Propagation through Code Cloning: An Empirical Study” (ICSME 2017, link)
Nguyen et al. “Anchoring Bias in Large Language Models: An Experimental Study” (2024, arXiv:2412.06593)
Chen et al. “Two Failures of Self-Consistency in the Multi-Step Reasoning of LLMs” (2023, arXiv:2305.14279)
Sharma et al. “Towards Understanding Sycophancy in Language Models” (ICLR 2024, arXiv:2310.13548)
Tyen et al. (Google DeepMind). “LLMs cannot find reasoning errors, but can correct them given the error location” (2023, arXiv:2311.08516)
Perry, Srivastava, Kumar, Boneh. “Do Users Write More Insecure Code with AI Assistants?” (Stanford, 2022, arXiv:2211.03622)
Imagen principal: generada por IA (Google Gemini)