Dejen de discutir sobre código de memoria

8 min de lectura

El código cambió. El argumento no lo hizo.

El software es especialmente bueno para producir estos falsos argumentos porque el objeto en discusión es invisible. No puedes mirar al otro lado de la habitación y ver si la lógica de integración es mejor ahora que el mes pasado. Tienes que abrir el código. Ejecutar las pruebas. Rastrear el comportamiento. La mayoría de las personas prefieren proteger su memoria que actualizar su modelo.

Ese es todo el problema.

Lo he visto con código de integración (glue code) construido por un creador semitécnico usando Claude Code y una herramienta de redacción de especificaciones. La primera versión más o menos funcionaba, de la misma manera que una silla con tres patas más o menos funciona hasta que te sientas demasiado rápido. Luego alguien vino, desenredó el desastre, agregó cientos de pruebas, eliminó los archivos markdown que seguían dirigiendo la IA hacia suposiciones obsoletas y logró que el sistema fuera sustancialmente más confiable.

Y aún así, la conversación siguió orbitando sobre la antigua base de código.

No el código en el repositorio. El código en la cabeza de alguien.

La memoria es barata. Mirar es trabajo.

Normalmente, las personas no discuten de memoria porque sean malintencionadas. Lo hacen porque la memoria es rápida, socialmente conveniente y halagadora.

Mirar el objeto de trabajo es más lento. Puede exponer que tu opinión está desactualizada. Puede demostrar que la persona a la que descartaste realmente mejoró el sistema. Puede forzarte a decir una frase que muchos profesionales odian: “Estaba hablando de una versión anterior”.

La memoria te permite evitar todo eso.

En el desarrollo de software, esto empeora porque el objeto en sí es blando. Un gerente de ventas que discute sobre un envío roto al menos puede señalar la caja que falta. Un desarrollador, gerente de producto, fundador o experto adyacente que discute sobre un flujo de integración generalmente está apuntando a una simulación interna. Un stack trace recordado. Un fallo recordado. Una queja arquitectónica recordada. Una impresión de hace tres semanas que se calcificó en certeza.

Cuanto menos visible es el trabajo, más fácil es mitificarlo.

Esa es una de las razones por las que la naturaleza invisible del software causa tanto teatro gerencial. La gente llena el vacío de visibilidad con narrativa. Una vez que la narrativa se endurece, la evidencia se siente como un ataque personal.

La IA hizo barato el primer borrador, no la verdad automática

Las herramientas de programación de IA hicieron que este patrón fuera más común, no menos.

Ahora un semi-desarrollador puede crear código de integración en un fin de semana. Bien. Eso puede ser útil. El primer borrador de software siempre ha sido el momento más fácil para impresionar a las personas que no tienen que mantenerlo.

Luego llega la realidad.

El flujo de trabajo que realmente mejora el sistema es aburrido exactamente de la manera correcta: caracterizar el comportamiento, agregar pruebas, eliminar andamiajes engañosos, estrechar el ciclo de retroalimentación y forzar cada cambio futuro a través de comprobaciones ejecutables. Ahí es donde comienza el trabajo real. No en el momento en que la IA emite archivos. En el momento en que alguien convierte un montón de resultados plausibles en un sistema en el que otro humano puede confiar.

Por eso las pruebas vencen a las instrucciones para los agentes de programación de IA. Un montón de archivos markdown que le dicen al modelo cómo debería funcionar el mundo es frágil. Cientos de pruebas que muestran lo que el sistema realmente debe hacer son más difíciles de discutir.

O al menos deberían serlo.

En la práctica, las personas a menudo siguen defendiendo la ficción del markdown porque esa ficción es lo que recuerdan. Los archivos .md eliminados siguen siendo más reales para ellos que la suite de pruebas que pasa. Eso suena absurdo hasta que recuerdas que las organizaciones están llenas de personas que confunden la documentación con la verdad y los planes con la evidencia.

Los argumentos defensivos suelen ser sobre el estatus

Una vez que alguien ha explicado públicamente cómo se comporta el código, una corrección posterior puede sentirse humillante. Si el sistema cambió bajo sus pies, ahora tienen dos opciones.

Pueden inspeccionar el estado actual y actualizar su modelo.

O pueden seguir hablando como si el modelo antiguo aún se mantuviera y convertir cada corrección en un debate.

Muchos eligen la segunda opción porque protege el estatus a corto plazo.

Aquí es donde la conversación se vuelve estúpida rápido. Una persona está hablando sobre el repositorio tal como existe ahora. La otra está hablando sobre un repositorio recordado, una antigua cadena de prompts, un modo de fallo anterior o un diseño con el que se comprometieron emocionalmente. Ambos piensan que están discutiendo sobre el mismo objeto. No lo están.

Luego comienzan las tonterías habituales.

• “Ese módulo sigue siendo inestable”. No, solía ser inestable.
• “La IA necesita esos archivos de especificaciones”. No, esos archivos estaban envenenando el resultado.
• “El comportamiento probablemente sigue roto”. “Probablemente” es lo que dice la gente antes de negarse a ejecutar las pruebas.

Nada de esto tiene que ver realmente con el código. Se trata de autoprotección.

Eso no lo hace inofensivo. Ralentiza las decisiones, envenena la colaboración y convierte una verificación sencilla en una crisis política en miniatura.

La mejor pregunta siempre es: ¿qué hace ahora?

Hay una salida limpia de esta trampa, y es mucho menos glamurosa que la discusión.

Haz mejores preguntas.

No “¿Acaso no era esta integración poco fiable?”

Pregunta: ¿qué hace ahora?

No “¿No necesitaba la IA ese archivo de requisitos?”

Pregunta: ¿qué cambió después de eliminarlo?

No “Recuerdo que este flujo se rompía cuando el sistema upstream daba un tiempo de espera.”

Pregunta: ¿hay alguna prueba para ese caso, y pasa?

Ese cambio importa porque fuerza la conversación de vuelta hacia la realidad observable. También revela quién está colaborando y quién está defendiendo un artefacto de la memoria.

Por esta misma razón el documento de concepto era una solución provisional. Las descripciones envejecen mal. La evidencia ejecutable envejece mucho mejor. Lo mismo se aplica a los argumentos en una revisión de código, una discusión de arquitectura o un debate entre fundador y desarrollador. Si puedes inspeccionar la cosa, entonces inspecciona la cosa. Deja de litigar una descripción de la cosa.

La base de código merece testigos, no historiadores

Los equipos de software tienen la mala costumbre de premiar el recuerdo seguro. Alguien recuerda una interrupción de hace seis meses y de repente se convierte en la autoridad de un subsistema que no ha tocado desde entonces. Alguien recuerda un archivo de prompt de borrador y lo trata como arquitectura permanente. Alguien recuerda un prototipo y sigue hablando de él mucho después de que otra persona hizo el duro trabajo de convertirlo en un sistema real.

Así es como los equipos quedan atrapados en narrativas obsoletas.

Lo que necesita una base de código no son más historiadores. Necesita testigos.

Un testigo revisa la rama actual. Lee la prueba que falla. Reproduce el comportamiento. Mira los registros. Actualiza su punto de vista cuando los hechos cambian.

Un historiador te dice lo que el sistema alguna vez fue y mete esa historia de contrabando en el tiempo presente.

Ambos tipos de conocimiento importan. Sólo uno debería ganar un argumento sobre el comportamiento actual.

Si eso suena duro, qué bien. Demasiados debates técnicos son en realidad sólo concursos de memoria disfrazados de experiencia.

El movimiento profesional

El movimiento profesional no es discutir más fuerte. Es reducir el área de superficie donde la memoria puede fingir ser la verdad.

• Pon el comportamiento bajo pruebas.
• Elimina los documentos engañosos cuando dejen de coincidir con la realidad.
• Trata la guía obsoleta de la IA como un defecto, no como conocimiento sagrado.
• Pide a la gente que señale evidencia actual, no un comportamiento recordado.
• Recompensa la corrección rápida más que la confianza terca.

Ese último punto importa más de lo que la mayoría de los líderes se dan cuenta. Si actualizar tu punto de vista te hace ver débil, la gente se aferrará a viejas historias. Si actualizar tu punto de vista te hace ver competente, el equipo se vuelve más inteligente más rápido.

Vibe coding no es desarrollo de software. El mismo principio se aplica socialmente. Las opiniones basadas en “vibras” no son juicio técnico. Si el artefacto está disponible, mira el artefacto.

El código cambió. Las pruebas cambiaron. El comportamiento cambió.

La respuesta adulta es cambiar de opinión también.