Si nos fijamos en los historiales de compromisos de las plataformas de datos modernas, algo profundo ha cambiado en los últimos dos años. La fricción de la sintaxis de la escritura se ha derrumbado. Ahora que Cursor, Claude Code y flujos de trabajo agentes se encuentran dentro de nuestros contenedores Docker e IDE, generar la primera implementación de una canalización de transmisión distribuida o una integración API compleja ya no es el cuello de botella central.
Los agentes pueden navegar por los repositorios, escribir cobertura de prueba, inspeccionar seguimientos de pila y proponer refactorizaciones. Describa un mapeo de sumidero de Kafka a Iceberg en un lenguaje sencillo y un agente podrá producir un punto de partida creíble antes de que el ingeniero haya abierto todos los archivos relevantes.
Eso cambia la pregunta para los ingenieros de software.
Si el agente se está convirtiendo en el autor principal de la lógica del sistema local, ¿qué le queda exactamente por hacer al ingeniero? ¿Nos dirigimos hacia una industria en la que los revisores aprueben un flujo interminable de solicitudes de extracción plausibles? ¿O el trabajo se ha alejado de la construcción de la lógica hacia algo más abstracto?
Para responder a eso, es útil tomar prestada una lente de la termodinámica, que nos brinda un lenguaje para el trabajo dirigido, la retroalimentación, la pérdida y los límites que mantienen coherente un sistema complejo.
El agente como motor térmico.
Cuando eliminamos la ilusión antropomórfica de la IA, lo que queda es un motor computacional. Toma dirección y la convierte en acción.
Un LLM ubicado en un centro de datos tiene una capacidad inmensa, pero no realiza ningún trabajo útil hasta que se le da la intención. Un aviso, un requisito comercial, una instrucción del sistema o una prueba fallida le dan al agente una dirección. Convierte esa dirección en código, llamadas a herramientas, consultas, pruebas y cambios en un sistema en ejecución.
Todo motor tiene pérdidas. Cada bucle de agente también lo hace.
Cualquiera que haya dejado a un agente corriendo contra un repositorio difícil ha visto esto. Comienza con una tarea clara. Luego sigue una suposición obsoleta, fija un síntoma en lugar de una causa, trata una antigua migración como un comportamiento actual y comienza a acumular su propia historia. Unas cuantas llamadas a herramientas más tarde, el contexto contiene suficientes detalles plausibles pero contradictorios que hacen que el siguiente paso sea menos seguro que el primero.
Llamémoslo entropía operativa: la acumulación de suposiciones obsoletas, contextos ramificados y dependencias no resueltas dentro de un bucle que todavía intenta avanzar.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
Una interrupción humana ayuda porque introduce nueva información. Lo mismo ocurre con una prueba fallida, un contrato de datos preciso, una herramienta determinista o una evaluación que le dice al agente exactamente en qué se equivocó. Sin esa señal, un agente puede seguir generando resultados mientras se aleja más de un resultado correcto.
Los agentes claramente generan movimiento. La verdadera pregunta es si el sistema que los rodea convierte ese movimiento en un trabajo útil.
El mono infinito y la aceleración del espacio de búsqueda
El teorema del mono infinito nos da una imagen útil de lo que sigue: intentos repetidos, restricciones finitas y retroalimentación.
El teorema dice que un mono que pulsa teclas al azar durante un tiempo infinito casi seguramente escribirá las obras completas de Shakespeare. Los agentes modernos son monos mucho más inteligentes. Tienen compiladores, herramientas, repositorios, conjuntos de pruebas y bucles de retroalimentación. Su trabajo no es aleatorio (la retroalimentación dirige el siguiente intento), pero la dinámica es familiar: propone, ejecuta, observa, corrige y vuelve a intentarlo.
En una tarea limitada, ese bucle es notablemente eficaz.
Proporcione a un agente un esquema de entrada conocido, un esquema de destino conocido, una pequeña base de código y pruebas que detecten las fallas relevantes. Puede inspeccionar el código, realizar cambios, ejecutar las pruebas, absorber el resultado y volver a intentarlo. La definición de hecho es visible. El espacio de búsqueda es estrecho. El bucle tiene la posibilidad de converger.
Pero los sistemas empresariales rara vez ofrecen ese tipo de quietud. Un motor de fijación de precios en tiempo real puede depender de un estado operativo variable, API de terceros, eventos tardíos, políticas regionales y reglas comerciales que existen en parte en el código y en parte en la cabeza de alguien. Un lago de datos puede ser físicamente consistente y semánticamente incorrecto. Un oleoducto puede pasar sus pruebas y aun así producir cifras que las finanzas no reconocen.
El entorno cambia mientras el mono escribe.
El problema de los tres cuerpos de la lógica empresarial
Esta es la razón por la que problema de tres cuerpos Es una imagen muy útil para el software empresarial.
Con dos cuerpos (un planeta y una estrella) se puede predecir el movimiento con una descripción matemática clara. Agregue un tercer cuerpo y el problema se vuelve mucho más difícil de resolver. No existe una solución general de forma cerrada y algunas configuraciones exhiben un comportamiento caótico. Pequeños cambios en un lugar pueden producir trayectorias muy diferentes en otros lugares.
Las plataformas de datos modernas tienen la misma forma. Los datos del flujo de clics cambian con el comportamiento del producto. Las bases de datos operativas mutan según la actividad del cliente. Las API imponen límites de velocidad y cambian de versión. Los esquemas evolucionan. Las políticas de seguridad cambian. Los sistemas heredados conllevan reglas que nadie ha escrito porque han estado enterradas en el manejo de excepciones durante años.
Cada sistema ejerce presión sobre los demás. Un cambio en un lugar altera el significado o comportamiento de otro. Lo que comienza como una solicitud de función local comienza a afectar a todo el sistema.
Considere una situación hipotética: se le pide a un agente que agregue un campo customer_tier a un modelo de ingresos. Encuentra un campo llamado estado en la base de datos operativa, lo asigna a la transformación y pasa las pruebas de tipo y de nulidad existentes. El código está limpio. El oleoducto es verde. La respuesta sigue siendo incorrecta.
Un contrato de datos semánticos dice que customer_tier se deriva del gasto de los últimos doce meses, tiene un propietario comercial asignado y no se puede completar a partir del estado de la cuenta. El contrato rechaza el cambio antes de que llegue al tablero. La contribución del ingeniero no fue la transformación: fue el límite que hizo que el error del agente fuera visible, específico y recuperable.
El nuevo mandato: diseñar el equilibrio
El trabajo del ingeniero de software ya no es escribir cada pieza de micrológica. Los agentes harán cada vez más ese trabajo, a menudo más rápido. El nuevo mandato –diseñar el equilibrio– es crear las condiciones en las que se pueda confiar en la lógica generada.
Cuando un requisito empresarial cambia más rápido de lo que un agente puede absorber la retroalimentación, el ingeniero tiene que crear campos de contención. Las capas semánticas estrictas, los registros de eventos inmutables, los contratos de datos, las API idempotentes y las máquinas de estado deterministas no son solo una buena higiene de la plataforma. Reducen el número de suposiciones que un agente tiene que hacer a la vez.
Convierten un problema acoplado en un dominio delimitado con entradas claras, reglas explícitas y retroalimentación confiable.
Una vez que ese dominio existe, el agente se vuelve genuinamente poderoso. Puede escribir la transformación, ejecutar las pruebas, reparar las fallas y enviar el cambio sin necesidad de inferir el historial no escrito detrás de cada tabla y servicio.
El valor de la ingeniería de software no desaparece a medida que la generación de código se abarata: se vuelve más visible, que es el cambio que realmente importa.
Los sistemas autónomos generarán cada vez más software. Pero los contratos, los circuitos de retroalimentación y los límites que determinan si ese software tiene éxito o se precipita hacia el caos seguirán siendo diseñados por ingenieros de software.
Ananth Packkildurai es líder en ingeniería de datos, escritor y autor de Data Engineering Weekly, y comparte conocimientos sobre plataformas de datos modernas, canalizaciones a gran escala y arquitecturas impulsadas por IA.
