Del estudio de drenaje me llegó una planilla: progresiva, cota de terreno y tipo, para unas 28 cruces a lo largo de una circunvalación que estábamos diseñando para una localidad. De esa lista había que colocar 26 alcantarillas de alivio dentro del software de diseño vial, cada una cruzando la calzada, cada extremo apoyado en el pie de talud real del terraplén. (Una obra mayor de cajón en el brazo de un río sumaba 27 obras en total; esa ya estaba cargada a mano.)
Es la parte poco glamorosa de todo proyecto: repetitiva, cargada de geometría, fácil de equivocar sin darte cuenta. Le pedí a un agente de IA que escribiera un script para hacerlo, y una vez que funcionó, lo generalicé en una skill reutilizable. Lo interesante está en otra parte: en el único detalle que decidía si el resultado servía o quedaba mal en silencio, escondido en un archivo distinto del que miré primero.
El agente tiene nombre. Lo llamo MARCO, y vale la pena ser preciso sobre qué es, porque “agente” carga más misticismo del que la cosa merece. Pensalo menos como una IA autónoma independiente y más como un modelo de propósito general apuntado a una configuración específica: el conocimiento del software vial cargado, las reglas de cómo trabajamos en los proyectos, y un puñado de skills chicas que puede ejecutar. La inteligencia es general; lo que lo hace MARCO es el contexto y las herramientas que armé a su alrededor. Así que “se lo pasé a un agente” en realidad significa que le di al modelo el conocimiento correcto y lo dejé escribir y correr el script.
Qué hay que resolver
Para colocar una alcantarilla hacen falta tres cosas: su progresiva sobre el eje, su cota de fondo, y los dos puntos donde sus extremos llegan al pie del talud a cada lado. Ese último es todo el juego. Si errás el pie, la boca termina enterrada dentro del terraplén o flotando más allá de donde está el terreno. Del tipo de error que en una miniatura se ve bien y te muerde en obra.
El atajo fácil, y por qué falla
La tentación es tratar el pie como una distancia fija desde el eje. Un offset, aplicado a todas. Falla casi en todas partes. El pie se mueve con cada sección: más altura de relleno lo empuja hacia afuera, un talud más parado lo trae hacia adentro, el peralte en curva hace que los dos lados sean distintos. En estas 26 obras el ancho pie a pie fue de unos 19,5 a 27 metros, y en curva los lados izquierdo y derecho no coincidían. Un offset constante erraría por metros justo donde importa.
El pie de talud real estaba en otro archivo
Acá está la parte que erré al principio. Busqué el pie en el archivo obvio, el que tiene el trazado, la rasante, los peraltes. No estaba ahí. Ese archivo describe la ruta; no fija el pie en cada progresiva.
El pie real vive en el archivo de secciones transversales, marcado con un código de punto, y solo después de que el software cubicó cada sección. No hubo método ingenioso. Solo tenía que saber qué archivo guardaba el dato verdadero. El script lee ese archivo, encuentra el código del pie a cada lado, y como las obras caen entre secciones calculadas, interpola entre los dos perfiles vecinos. La boca va al lado más alto; su cota sale del pie en ese archivo, no de la cota de terreno de la planilla original.
Lo validé antes de confiar
Ya había una obra cargada a mano, de unos 28,6 metros de ancho. Antes de generar las otras 26, la usé de prueba: calcular sus extremos desde el archivo de secciones y compararlos contra los reales. Un seguro barato contra una tanda confiada y equivocada.
La trampa que rompe todo en silencio
La salida es el formato nativo del software, y tiene un borde feo. La cabecera lleva una cantidad fija de espacios para obras y un contador que tiene que ser igual a la cantidad real de registros. Si el contador queda mal, el software carga las obras vacías. Sin error. Simplemente nada donde deberían estar las 27 obras. Es el tipo de detalle frágil y no documentado que te come una tarde la primera vez y no debería costarte una segunda.
La lección que se traslada
Cuando un agente se equivoca en algo así, la causa casi siempre es la misma que me pasó acá: está leyendo un sustituto cómodo en lugar del dato real. Un offset fijo, el archivo obvio, un supuesto que nadie escribió. El modelo nunca fue lo difícil. Lo difícil era asegurarme de que leyera el pie de talud real y no un número fácil de tipear.
Así que esto es lo que reviso ahora antes de apuntar un agente a cualquier cosa: ¿cuál es la fuente de verdad real acá, y el agente la está leyendo, o está leyendo algo cercano? Casi siempre el dato verdadero ya existe en algún lado del sistema. El trabajo es conectar el agente a ese dato en lugar de al atajo.
Y después, congelarlo
No arranqué con una herramienta pulida. Arranqué con un script atado a este proyecto, lo dejé bien, lo verifiqué contra la obra cargada a mano, y esa misma tarde lo generalicé en una skill: parametrizada, reutilizable, cargando los detalles que costaron encontrar. Usar el archivo de secciones, no el de trazado. Usar el código del pie. Corregir el contador de la cabecera.
El caso puntual resolvió un proyecto. La skill resuelve todos los que siguen. Ese segundo paso es el que solía saltearme, y es donde está la acumulación.
Lo que me quedó
El agente no necesitaba ser inteligente en ingeniería vial. Necesitaba dos cosas poco glamorosas: que lo apunten a la fuente de verdad real, y una respuesta convertida en algo reutilizable. Las obras se cargaron rápido. La receta es la parte que me quedó, y ya está esperando para el próximo proyecto.