Una crónica en lenguaje llano de veinticuatro horas en las que un equipo de software trató el vocabulario como material de ingeniería, construyó una máquina para empaquetar trabajo destinado a la IA, y vio cómo la honestidad de la IA encontraba errores en la máquina. Escrita el 2026-08-15; cada número de aquí sale de una medición registrada, no de la memoria.
---
El problema que nadie anota
Todo equipo de software tiene un idioma privado. El nuestro tenía una palabra — llamémosle «la palabra A» — que usábamos todo el tiempo, y resultó que significaba dos cosas completamente distintas: a veces un tipo de objeto de negocio (un cliente, un contrato) y a veces una secuencia de pasos de procesamiento (traer, extraer, indexar). Nadie lo notó, porque las personas resuelven esa clase de ambigüedad sin pensar.
Nuestros integrantes más nuevos no pueden. Son modelos de IA, y para un lector que es un modelo, una palabra borrosa no es un problema de estilo: es un defecto que se propaga. El modelo adivina, la adivinanza aterriza en un documento, el siguiente modelo lee el documento, y la adivinanza se endurece en «hecho». Ya lo habíamos visto pasar: un sufijo inventado para un archivo especial se copió a treinta y tres archivos en nueve días, sin significar nada en treinta y dos de ellos.
Así que dejamos de discutir sobre palabras y empezamos a medirlas.
El experimento: llevar el diccionario a juicio
El montaje es fácil de describir. Toma treinta componentes reales de nuestro código. Escríbele a cada uno una ficha con hechos llanos. Entrégale las fichas a un panel de jueces de IA — cada uno nuevo, aislado, sin ver nada más que las fichas — y pídele a cada juez que clasifique todos los componentes usando el vocabulario A (nuestros términos caseros) o el vocabulario B (los términos establecidos de la industria). Luego mide con qué frecuencia jueces independientes coinciden.
Ese puntaje de acuerdo es todo el truco. Una buena palabra es la que lectores distintos resuelven igual; una mala los dispersa. No se debate: se cuenta.
Veintiún jueces y 540 votos después:
- Nuestro vocabulario casero y el de la industria empataron — hasta que notamos
que el conjunto de la industria no tenía palabra para «herramienta de desarrollador», y el nuestro sí. Añadimos una palabra, volvimos a correr el panel, y el vocabulario de la industria enmendado ganó de calle, con el mejor puntaje de acuerdo de todo el estudio.
- La palabra A ambigua se partió exactamente como se predijo: los jueces mandaron
por unanimidad uno de sus significados a un término de la industria y el otro significado a otro. Una palabra había sido dos desde el principio.
- Un comportamiento nos preocupó: a los jueces se les permitía decir «no sé» y
nunca lo dijeron — ni una vez en 540 votos. Acuérdate de eso; regresa más adelante.
Para la tarde el vocabulario ganador estaba ratificado y conectado a las propias comprobaciones de commit del repositorio, así que las palabras retiradas ya no pueden físicamente volver a entrar en nuestros documentos sin una excepción registrada. Esa es la filosofía de la casa en una línea: una regla es un deseo; un mecanismo es un hecho. Ya lo habíamos comprobado por las malas: en una sesión anterior, el único documento que argumentaba a favor de prohibir una palabra contenía él mismo la palabra prohibida, y solo la comprobación automática lo atrapó.
El desorden que luego tuvimos que limpiar
Toda esta maquinaria vigila la puerta de nuestro repositorio de código, y la puerta estaba reportando 88 problemas: estadísticas viejas pegadas a mano en documentos, un enlace muerto, cinco pares de documentos de planeación compartiendo por accidente el mismo número, y unos cuarenta componentes de código sin ningún README.
La forma vieja de arreglar esto es apuntarle una IA al repositorio y decir «límpialo» — y cruzar los dedos. Hicimos lo contrario, y esta es la mitad de la historia que trata del método.
El método: fichas, no la biblioteca
Escribimos un programa pequeño al que llamamos compilador de paquetes de trabajo. Su único trabajo: leer la lista de 88 problemas de la puerta y meter cada problema en uno de tres cajones.
1. Esto lo puede arreglar un programa. Números viejos, renombrados, enlaces muertos — una máquina sabe la respuesta correcta exactamente. Sin IA de por medio. (Resultó ser la mayor parte.) 2. Hace falta una decisión mínima. Un enlace muerto con varios destinos plausibles — una IA puede elegir uno, de una lista, y nada más. 3. Hace falta escribir de verdad. Los README que faltaban. Solo aquí escribe prosa una IA — y solo a partir de un fragmento.
Un fragmento es la ficha del experimento, hecha rigurosa. Para cada componente de código, un programa recolector extrae mecánicamente: su nombre, la descripción de su manifiesto, sus propias líneas de documentación, las firmas de sus funciones públicas (nunca sus entrañas), sus características opcionales, los nombres de sus módulos, qué otros componentes lo usan, en qué capa vive, su versión, y si tiene pruebas. Trescientas noventa y tres fichas, construidas por un programa en segundos.
Igual de importante es lo que un fragmento nunca contiene: el cuerpo del código fuente del componente, nada sobre otros componentes, y nada sobre nuestras conversaciones. La IA que escribe recibe la ficha y un contrato: cuatro secciones, veinticinco líneas, y si la ficha no contiene un hecho que necesitas, escribe «NECESITO: ese hecho» — nunca lo inventes. La ficha es todo el mundo de quien escribe. No puede filtrar lo que nunca se le dio, y no puede alucinar una afirmación que no podamos rastrear, porque toda afirmación tiene que apuntar de vuelta a una línea de la ficha.
El giro inesperado
Aquí viene lo que no esperábamos. Cuando corrimos la limpieza de verdad, nunca se llamó a las IA que escriben. Una herramienta más tonta — una que arma los README directamente a partir de la descripción que cada componente ya tenía — cubrió los cuarenta componentes. El cajón del «criterio», el único cajón que habíamos reservado para la inteligencia, se vació solo. Las máquinas arreglaron los números, las máquinas renombraron los archivos y reescribieron cada referencia, las máquinas armaron la documentación. Los 88 problemas se volvieron cero, y la subida final a GitHub pasó todas las puertas automáticas corriendo en vivo, sin ninguna excepción.
De camino, las puertas atraparon cuatro errores — dos en las herramientas que acabábamos de construir — que es justamente el punto. Nadie tuvo cuidado. La maquinaria sí.
Aun así pusimos a prueba la ruta de la IA
Una ruta sin probar es una promesa, no un resultado. Sacamos seis fichas representativas y se las dimos a seis IA aisladas que escriben, y luego calificamos sus README contra los armados por la máquina.
Ronda uno: cero hechos inventados en las seis — cada frase rastreable hasta la ficha — y seis notas honestas de «NECESITO» donde a la ficha de verdad le faltaba un hecho (el formato de ficha no tenía campo de versión ni de estado de pruebas). Una de las IA se pasó, marcando «NECESITO» en un campo que estaba presente pero vacío. Los dos problemas eran problemas de la ficha, no de quien escribía. Así que arreglamos la ficha: añadimos los dos campos faltantes y añadimos una frase al contrato — un campo vacío es un hecho; repórtalo como «ninguno».
Ronda dos, fichas nuevas: otra vez cero hechos inventados, cero NECESITO, seis README completos. Y entonces el mejor momento de todo el día: dos de las IA reportaron con verdad «versión: vacía», que era un error nuestro — el fabricante de fichas no entendía los componentes que heredan su versión del taller. La honestidad de la IA encontró un defecto en el instrumento que la estaba midiendo. Arreglamos el fabricante de fichas esa misma hora.
¿Te acuerdas de los jueces del panel que nunca decían «no sé»? Por eso importa esto. No puedes pedirle a un modelo que tenga incertidumbre y esperar que le dure — nuestro propio estudio de desgaste muestra que las reglas escritas se doblan donde sea que cuesten algo. Pero sí puedes construir la incertidumbre dentro del paquete: un contrato cerrado, una ficha que es el mundo entero, y una válvula de escape NECESITO que sale más barata que inventar. La honestidad aguantó doce generaciones seguidas no porque los modelos fueran virtuosos, sino porque nada tiraba en contra.
Los números, todos en un lugar
- Palabras: 540 votos de clasificación, 21 jueces; mejor puntaje de acuerdo 0.914
tras la enmienda de una palabra; la confianza de clasificación subió a lo largo de tres generaciones de vocabulario: 0.912 → 0.945 → 0.967.
- Limpieza: 88 hallazgos de la puerta → 0; cinco documentos en colisión renombrados
bajo la regla del operador de «añade otro decimal», con cada referencia cruzada reescrita; el empuje final pasó todas las puertas en vivo.
- Fragmentos: 393 fichas recolectadas mecánicamente; 12 README escritos por IA en
dos pruebas; 0 hechos inventados en los 12; notas NECESITO de 6 → 0 tras arreglar la ficha.
- Errores encontrados por la maquinaria durante el día: 6, incluidos 3 en las
herramientas nuevas de ese mismo día. Disco recuperado de escombros viejos de pruebas: 142 GB.
A qué suma todo esto
La tesis callada del día: con una IA en el equipo, el lenguaje y el proceso son el mismo problema de ingeniería. Las palabras se miden y se ratifican como interfaces. El trabajo se compila en paquetes igual que el código fuente se compila en binarios — con la parte inteligente confinada a huecos pequeños, sellados y comprobables. El precedente industrial (la plataforma de Palantir corre sobre un credo parecido: la IA propone, la maquinaria ejecuta) dice que esto escala; nuestra aportación es hacerlo a la vista, dentro de un repositorio git corriente, con los comprobantes guardados junto al código.
La próxima vez que alguien del equipo eche mano de una palabra, hay una lista de cinco líneas esperándolo. La próxima vez que un trabajo necesite una IA, hay una ficha. Y la próxima vez que alguien afirme que el sistema funciona — hay una puerta que va a querer pruebas.