Todo mundo optimiza lo que no importa
Pásate una hora leyendo sobre programación con IA y vas a salir creyendo que todo el juego está en el prompt. La redacción perfecta. La frase mágica. El modelo más nuevo y más grande. Si le atinas a eso —dice el cuento—, el código se escribe solito.
Yo corro un agente de IA todos los días sobre un sistema del que dependen personas de carne y hueso, y he acabado por creer casi lo contrario. El prompt es lo que menos importa. El modelo importa menos de lo que crees. Lo que de verdad distingue a un agente que entrega software confiable de uno que suelta tonterías con toda seguridad es lo que no tiene nada de glamur y está alrededor del agente: la memoria, las salvaguardas, los procedimientos codificados. La infraestructura.
Esta es la afirmación menos emocionante que voy a hacer y, me atrevo a decir, la más útil: un agente de IA vale exactamente lo que valgan el contexto y las restricciones que le des. La astucia del prompt es un error de redondeo al lado de eso. Déjame mostrarte qué es, en realidad, la infraestructura.
Un agente sin memoria vuelve a aprenderlo todo, y mal
Empecemos por el problema que la infraestructura existe para resolver. Una sesión de IA recién arrancada no sabe nada de tu proyecto, ni de tus estándares, ni de tus decisiones pasadas, ni de los tres errores que cometió la semana pasada. Si la dejas adivinar, adivina: con verosimilitud y, muchas veces, mal, justo como lo conté en Del vibe coding a la ingeniería de IA. Cada sesión se vuelve el día uno.
Por eso la primera pieza de infraestructura es un archivo de reglas del proyecto que el agente lee al inicio de cada sesión: las instrucciones fijas que lo vuelven reproducible en lugar de improvisado. No son trucos de prompt. Son reglas duraderas: cómo nombramos las cosas, las fronteras que el agente nunca cruza, la lista de verificación que corre antes de proponer un cambio, dónde viven las utilidades canónicas. Agregar una regla aquí es como fijar un buen patrón para siempre. Borrar una es como dejar ir. El agente deja de redescubrir tus convenciones y empieza a respetarlas.
La segunda pieza es la memoria que persiste entre sesiones: notas cortas, ordenadas por tema, que el agente lee al arrancar: quién soy y cómo me gusta trabajar, correcciones que ya se le hicieron antes (para que deje de repetir un error), el estado no evidente del proyecto. Esa es la diferencia entre un asistente que te conoce y uno que se vuelve a presentar cada mañana. Y algo clave: la memoria es para lo que no se puede deducir del código —el criterio y el contexto—, no para lo que el código ya dice.
¿Reglas de quién? No toda la infraestructura es de todos
Hay una distinción que acabo de pasar por alto y que importa más que cualquier regla suelta: esta infraestructura no es un solo montón indistinto. Tiene alcance y el alcance es justo el punto.
Una parte es del proyecto: las convenciones, las fronteras, las funciones auxiliares canónicas; la verdad compartida sobre este código que hereda todo el que lo toca. Lo escribes una vez y cada ingeniero y cada sesión arrancan con ventaja.
Pero otra parte es de la persona. Cada quien trae a la mesa una mezcla única de conocimiento, gusto y criterio ganados a pulso, y eso se nota en cómo le damos instrucciones a un agente, en qué le pedimos que vigile y en las correcciones que cada uno ha ido acumulando a lo largo de los años. Esa capa es personal y así debe quedarse: viaja con el ingeniero de un proyecto a otro. Todo este andamiaje nunca tuvo como fin aplanar a un equipo hasta convertirlo en un montón de operadores intercambiables que ejecutan reglas idénticas; eso borraría justamente la experiencia que hace que el equipo valga algo desde el principio. La buena infraestructura amplifica la mezcla de cada persona. No la promedia hasta desaparecerla.
Entre las dos está la capa que vale la pena encapsular en una habilidad o un proceso compartido —una ronda de revisión, una forma de acotar un ticket— para que un compañero nuevo herede la práctica que al equipo le costó años desde el día uno, en vez de absorberla por ósmosis durante un mes. Ese es el verdadero acelerador de la integración: pásale rápido el acervo común al recién llegado, sin dejar de darle espacio para que crezca su propia capa personal, porque su criterio es justo para lo que lo contrataste.
Así que son tres capas, no una: la verdad compartida del proyecto, la experiencia individual de la persona y el acervo común y portátil que lleva la práctica de una a otra. Manténlas separadas y cada una hace su trabajo. Revuélvelas —al querer estandarizar la capa personal, o al encerrar la común en la cabeza de una sola persona— y o aplanas a tu gente o no logras integrarla.
El catálogo aburrido que evita la mitad de los errores
Esta es mi pieza de infraestructura favorita porque es de lo más mundano y evita toda una clase de fallas.
Cuando un agente necesita una función —para dar formato a una fecha, para revisar un permiso, para dibujar una gráfica— la escribe nuevecita sin pensarlo dos veces. Haz eso cien veces y acabas con cien funciones auxiliares casi idénticas que, poco a poco, se van separando, y en esa separación es donde se crían los errores cosméticos. Dos formateadores de fecha que hoy coinciden y mañana, tras un cambio de horario, ya no. Dos verificaciones de permisos que antes se igualaban.
La solución es un catálogo de las funciones auxiliares canónicas: un índice que se le pide al agente (y a cada humano) revisar antes de escribir lógica nueva. Reutiliza la que ya existe; no acuñes una rival. Suena a burocracia. En realidad, es el documento que más nos rinde de todos los que mantenemos, porque convierte “el agente reinventó la rueda y las ruedas no embonan” de una sorpresa recurrente en un no evento.
Automatiza las reglas que un humano se saltaría
El siguiente principio es discreto: toda regla que puedas hacer cumplir de forma mecánica es una regla que nadie —ni humano ni agente— puede saltarse por accidente.
Si una verificación puede correr sin que nadie tenga que pensarla —una suite de pruebas, un lint, un escaneo en busca de un patrón malo conocido, un filtro de formato—, entonces que corra, y así tu escasa atención humana (y tus escasos tokens de IA) se gastan en el criterio y no en acordarte de una lista de pendientes. La automatización se gana su lugar de una forma muy concreta: se paga sola la primera vez que atrapa eso que a todos se les olvidó revisar. La meta no es automatizar el pensamiento. Es automatizar todo lo que no es pensar, para que el pensamiento se lleve la atención.
Codifica los procedimientos, no los vuelvas a explicar
La última capa es el procedimiento. Los flujos de trabajo valiosos y repetibles —cómo corremos una revisión completa, cómo preparamos un cambio para entregarlo— no deberían vivir en la cabeza de alguien para explicarlos una y otra vez. Se codifican como comandos con nombre que el agente puede invocar: corre la ronda de revisión, corre la lista para entregar. La revisión de varias rondas que describí en La revisión es el producto es uno de estos: un procedimiento que se invoca por su nombre, no que se reconstruye de memoria cada vez. Codificarlo significa que corre igual un viernes cansado que un lunes fresco, que es justo el punto de un procedimiento.
Y deberías observar tu propia práctica con el mismo ojo de “primero la evidencia” que le pones al código. Instrumenta cómo se está usando el agente en realidad —adónde se va el tiempo, qué patrones se repiten— para mejorar el flujo de trabajo con datos y no con corazonadas. (El /insights de Claude Code es una puerta de entrada: un repaso de cómo has estado trabajando, que de verdad te dice qué va bien, qué arreglar y qué vale la pena convertir en una habilidad reutilizable; lo que importa es el principio: cierra el ciclo sobre tu propio proceso.)
Por qué esta es la parte humana, no la parte de la máquina
Sería fácil leer todo esto como “hacer que la IA sea más autónoma”. Es al revés. Cada pieza de infraestructura que describí es una manera de codificar el criterio humano en el entorno para que el humano siga al mando aunque el agente vaya rápido.
El archivo de reglas es nuestro criterio sobre lo que aquí significa “bueno”. La memoria es nuestra corrección acumulada. El catálogo es nuestra decisión sobre la forma correcta de hacer algo común. Las verificaciones automáticas son nuestros estándares, imposibles de saltar. Nada de esto hace que el agente piense por nosotros. Todo esto hace que el agente actúe dentro de las fronteras que pensamos con cuidado, una sola vez. Eso es lo que te deja pasarle más tecleo a una máquina sin entregarle el volante.
Los equipos que entregan con IA de forma confiable no están ganando por los prompts ni por los modelos. Están ganando por la ingeniería de contexto: el trabajo paciente de dotar al agente de memoria, reglamento, catálogo y un conjunto de salvaguardas. No tiene glamur y no luce bien en un demo; es, sencillamente, lo que hace segura la velocidad. Un agente bien equipado, sobre un modelo promedio, le gana a un agente a secas sobre el mejor modelo, siempre —porque el bien equipado opera dentro de una estructura que un humano construyó a propósito, y el otro anda adivinando.
Deja de ajustar el prompt. Construye la memoria, las reglas, el catálogo y las salvaguardas. La infraestructura es el trabajo de verdad; el agente es nada más que la parte que se mueve.