Ingeniería probabilística y el empleado 24/7

• El desarrollo de software está pasando silenciosamente de sistemas deterministas a sistemas probabilísticos, y en una era en la que agentes de IA generan, revisan y fusionan código durante toda la noche, el rol del desarrollador y la estructura de las organizaciones están cambiando de forma fundamental
• Dentro de los equipos nativos de IA, los roles se desplazan hacia arriba al mismo tiempo que se fragmentan hacia abajo, y existe el riesgo de que las tareas simples de gestionar la salida de los agentes se fijen como una nueva categoría laboral de bajos salarios
• A medida que el costo de generar código converge a cero, la producción de código se dispara como en la paradoja de Jevons, pero el desafío clave es la asimetría de que generar se ha abaratado, mientras que verificar no
• Los ingenieros junior ya están viviendo una crisis de entrenamiento en depuración, criterio y oficio, al depender de la IA para producir código pulido desde el inicio
• Como el modelo actual es el más débil de todos los modelos que se usarán en el futuro, las organizaciones deben construir sistemas preparados no para las capacidades de hoy, sino para modelos futuros que aún no se han lanzado

---

El giro hacia la ingeniería probabilística

• La industria del software ha estado construida durante décadas sobre un contrato determinista: si escribías el código, lo probabas y lo desplegabas, había una garantía de que funcionaría
• Ese contrato se está rompiendo, y entre los operadores de élite de las compañías nativas de IA, el codebase está pasando a algo que se cree que funciona, en un estado en el que ya no es posible expresar probabilidades exactas
• El detonante fue la experiencia de construir un proyecto paralelo llamado Compound Loop: un sistema que hacía que varios modelos frontier compitieran entre sí para escribir, revisar y fusionar código de forma autónoma
  • Si ejecutabas el sistema sobre un problema real antes de irte a dormir, por la mañana estabas haciendo triage de una pila de PRs que no existía la noche anterior
  • Algunas eran excelentes, algunas tenían errores y algunas sacaban a la superficie preguntas que nadie había hecho
• Por primera vez en la historia del trabajo del conocimiento, quien termina su jornada no se lleva consigo la única copia del cerebro
• La idea del 9-9-6 está, en la práctica, muerta, y un empleado 24/7 no es alguien que trabaja 24 horas, sino alguien cuyos agentes trabajan en paralelo a gran escala
• En 2026, la mayoría de los equipos sigue teniendo cuellos de botella no en teclear, sino en la coordinación, y la reorganización de las empresas todavía está en una etapa temprana

La fragmentación de roles: ascenso y descenso al mismo tiempo

• Dentro de los equipos nativos de IA existe un patrón mucho más complejo que la narrativa ordenada de que “todos suben de nivel”
• Movimiento hacia arriba: los mejores ingenieros se vuelven PMs más efectivos, los mejores PMs pasan a arquitectos de sistemas, y los mejores arquitectos se mueven hacia pensar en distribución, crecimiento y estructura de mercado
  • Para este grupo, es el entorno laboral de mayor apalancamiento en la historia
• Fragmentación hacia abajo: al mismo tiempo, muchos ingenieros no se convierten en arquitectos, sino en redactores de especificaciones, revisores y cuidadores de agentes
  • Su trabajo es traducir la intención a prompts que la máquina pueda leer y calificar el trabajo de la máquina según criterios que ellos mismos no dominan por completo
  • Parte de esto es trabajo importante, pero otra parte es simplemente captura de datos versión 2026 envuelta en nueva terminología
• Se espera que estos roles fragmentados impliquen salarios más bajos, menor valoración y, en muchos casos, callejones sin salida profesionales
• La brecha salarial entre el tercio superior capaz de operar eficazmente una flota de agentes y la capa intermedia que solo gestiona resultados será mayor que la vieja brecha entre ingeniería y ventas
• En la infraestructura de IA, el rendimiento del kernel, el diseño de compiladores y la abstracción de hardware siguen siendo fosos defensibles: en el nivel más bajo de la ingeniería de sistemas, todavía se necesita una precisión determinista muy alta

La paradoja de Jevons, versión código

• En 1865, el economista William Stanley Jevons observó que las máquinas de vapor más eficientes no redujeron el consumo de carbón, sino que lo aumentaron: la eficiencia amplió el rango de cosas para las que valía la pena construir motores
• El software está viviendo el mismo fenómeno a medida que el costo unitario de escribir código converge a cero: no se escribe menos, sino muchísimo más y se lanza muchísimo más
• Las empresas que creen que las leyes de escalado son infinitas están construyendo en consecuencia, y serán las ganadoras de una distribución de ley de potencia
• Lo que ya está pasando en campo real:
  • Los agentes abren PRs, revisan el trabajo de otros agentes y los cierran sin que un humano toque el teclado
  • Suites de pruebas autorreparables se reescriben solas cuando cambia el código base
  • Bucles autónomos de experimentación ejecutan, miden y descartan 100 hipótesis mientras un equipo antes apenas habría ejecutado 3
  • La documentación se actualiza automáticamente al fusionar cambios y aprovecha habilidades de IA que se mejoran a sí mismas
• Los equipos reestructurados alrededor de agentes ya están logrando 3x, 5x y 10x más output que hace un año, y la curva no se está aplanando: sigue subiendo
• La segunda lección de Jevons: cuando la oferta explota, la selección se vuelve el núcleo
  • Quien dirige la flota de agentes hacia los problemas correctos, filtra de la salida lo valioso e integra los resultados en algo coherente está haciendo el trabajo de mayor apalancamiento en el software actual
  • El valor del trabajo ya no lo determina el esfuerzo de producción, sino la dirección, la selección y la coherencia

De la ingeniería determinista a la ingeniería probabilística

• La ingeniería determinista fue el contrato dominante durante casi toda la historia del software: si escribías, probabas y revisabas código, podías entender su comportamiento dentro de un rango bien conocido, y los bugs eran reproducibles
• La ingeniería probabilística ya llegó a los equipos frontier: la mayor parte del codebase es generado por sistemas probabilísticos, revisado bajo presión de tiempo e integrado en un todo que ningún ser humano diseñó por completo
• La asimetría central: generar se abarató, pero verificar no
  • Un agente puede generar un PR de 500 líneas en un minuto, pero detectar bugs sutiles —problemas de concurrencia, mala interpretación de especificaciones o implementaciones que no reflejan la intención— todavía puede tomarle más de una hora a un ingeniero senior
  • La revisión escala más lento que la generación y escala peor que linealmente respecto al volumen de salida: cuanto más codebase escriben los agentes, más contexto hace falta para evaluar cada pieza individual
• Pasado cierto tamaño, el sistema produce más de lo que los humanos pueden evaluar de forma confiable, y la exactitud se vuelve probabilística
• Casos concretos: condiciones de carrera que pasan la suite de pruebas 9 de cada 10 veces, funciones perfectas en staging pero que fallan ante distribuciones de prompts no previstas, y migraciones que corrompen silenciosamente 1 fila entre 10 mil y solo se descubren tres semanas después
• Proximal y Modular publicaron una investigación conjunta sobre pruebas de tareas básicas para sistemas de agentes frontier, y los patrones de falla documentados coinciden directamente con este fenómeno
• El modo de falla no es un colapso dramático, sino una degradación lenta y silenciosa: aumenta la generación, baja la calidad de revisión, se acumulan defectos poco visibles y la confianza se erosiona en silencio hasta que clientes, auditorías o incidentes en producción revelan el problema
• Todavía no existen herramientas que resuelvan bien este problema: respuestas culturales como fusiones pequeñas, gates estrictos, escepticismo despiadado ante salidas demasiado pulidas, observabilidad y disciplina de rollback ayudan, pero la cultura no escala más allá de cierto tamaño de equipo
• Quien resuelva esto definirá el sistema operativo del desarrollo de software serio durante la próxima década

Diferencias en la velocidad de adopción según la industria

• La transición de la ingeniería determinista a la probabilística no es uniforme; está estratificada por industria y perfil de riesgo

• Capa determinista

  • Aviónica, dispositivos médicos, infraestructura de trading financiero, sistemas de control nuclear, núcleos de redes de pago y otros dominios altamente regulados y de alto riesgo
  • Adoptarán asistencia de agentes con cautela, detrás de verificación formal, simulación extensa y cadenas de aprobación humana
  • Esto no es falta de imaginación, sino un juicio correcto sobre el nivel de riesgo

• Capa probabilística

  • Software de consumo, herramientas internas, sistemas de marketing, la mayoría del SaaS, infraestructura de contenido y productos experimentales o en etapa temprana
  • Ahí el costo de un bug se limita a rollback, disculpas y hotfixes, y a cambio se obtiene una velocidad de iteración que el mundo determinista no puede igualar estructuralmente
  • Los equipos probabilísticos pueden aprender 10 veces más por trimestre que sus competidores deterministas

• Zona de convergencia

  • A medida que los modelos se vuelven más inteligentes y mejoran los harnesses, la frontera de lo “suficientemente seguro para hacerse de forma probabilística” sigue moviéndose
  • Los métodos probabilísticos están penetrando de abajo hacia arriba, un 10% a la vez, en dominios que hoy parecen deterministas, como seguros, salud y partes de la infraestructura empresarial
  • Los líderes de la ingeniería probabilística están reconstruyendo guardrails deterministas: chequeos formales, rutas críticas verificadas y sistemas híbridos donde la generación probabilística queda delimitada por validación determinista
• Los ganadores de la próxima década serán los equipos que sepan en qué capa están, resistan la tentación de fingir que están en otra y definan con precisión los límites dentro de su propio stack

La flota de agentes

• El “turno de fábrica” no es una metáfora adecuada: el trabajador de fábrica pertenecía a un sistema que se automatizaba, pero eso no describe bien lo que está ocurriendo ahora
• La metáfora correcta es una flota de agentes, aunque el “orden, jerarquía y confiabilidad” que sugiere la palabra flota todavía supera a la realidad
  • En la práctica, lo que la mayoría de los operadores ejecuta se parece más a una banda de contratistas frágiles que a una marina bien entrenada
  • Los agentes tienen capacidades desiguales, comportamientos probabilísticos, a veces se equivocan con total confianza, y operarlos a escala es costoso
  • La capa de orquestación se rompe, las ventanas de contexto explotan y el costo de inferencia aparece en facturas que nadie quiere enseñar en la junta directiva
• Aun así, la idea de flota sigue siendo válida: composición (distintos agentes para distintas tareas), coordinación (handoffs, dependencias, escalamiento), estructura de mando (decidir la misión, reglas de ejecución, revisión de resultados) y trabajo por turnos (mientras el comandante duerme, el sistema sigue trabajando dentro de sus instrucciones y reporta por la mañana)
• Una buena flota no se define por la cantidad que produce, sino por la consistencia de lo que produce
• Una nueva forma de trabajo:
  • Por la mañana, triage y merge
  • En medio del día, trabajo humano de alto apalancamiento: hablar con clientes, estrategia, decisiones de producto y redactar especificaciones que impulsarán la ejecución nocturna
  • Por la tarde, revisión y reajuste de rumbo cuando regresan los primeros agentes
  • Y al final del día, algo que la generación anterior no hacía: el handoff —poner trabajo en cola y entregar a la flota de agentes especificaciones para que intente avanzar durante la noche; algunas cosas saldrán mal, otras brillarán, y distinguir entre ambas sigue siendo una tarea que solo los humanos pueden hacer

Construir para los modelos que todavía no se lanzan

• Un punto que se ha repetido con consistencia en los últimos años: el modelo que usas hoy es el más tonto de todos los modelos que usarás en el futuro
• Eso sí, no hay garantía de que el crecimiento de capacidades sea uniforme: costo, latencia, confiabilidad y límites de escalado pueden complicar la curva
• Pero la apuesta direccional está bien respaldada por lo que se observa en la capa de infraestructura: las capacidades frontier van a superar de manera significativa las actuales en los próximos 6 a 12 meses, y es probable que la brecha entre el mejor modelo de hoy y el de dentro de un año sea mayor que la brecha entre el año pasado y este
• La implicación estratégica: las organizaciones deben construir no para el modelo actual, sino para la capacidad de aprovechar modelos que aún no tienen
  • Cómo escribir especificaciones, cultura de revisión, cableado de observabilidad, operación de flotas de agentes y rituales de entrenamiento para preservar las habilidades de los junior: todo eso no es preparación para 2026, sino andamiaje para 2027~2028
• Las empresas que construyan este andamiaje ahora absorberán el siguiente salto de capacidad como palanca; las que esperen a que las herramientas maduren pasarán su primer año aprendiendo lo que los early movers ya sabrán
• Se necesita la voluntad de sobreinvertir en especificaciones, revisión y disciplina operativa más allá de lo que exigen los modelos actuales
• En esta era, la irrelevancia no se anuncia sola: llega como una incapacidad gradual para seguir a equipos que hace un año ni siquiera parecían claramente mejores

Los músculos que se van a perder

• Frente a la idea de que la IA estratificará decisivamente a la sociedad o, por el contrario, la democratizará en general, los humanos son excelentes para optimizar la ruta de menor resistencia
• La tesis central: si no construyes algo tú mismo, también pierdes la capacidad de evaluar lo que se construyó
• Ya se ve en la práctica: ingenieros junior que dependen de la IA desde la primera semana lanzan rápido y producen código pulido, pero cuando el modelo falla de una forma que no anticipaba, no pueden encontrar el bug porque nunca desarrollaron ese modelo mental interno del sistema que solo se forma peleando por centésima vez con un stack trace a las 2 a.m.
• El gusto no se aprende aprobando borradores pulidos; el criterio no se desarrolla aceptando en cinco segundos una respuesta plausible de la máquina en vez de pasar una tarde entera con un problema difícil; y el oficio no se adquiere revisando el trabajo de otro agente
• Esta es la crisis de entrenamiento que la mayoría de las organizaciones todavía no reconoce
  • El modelo de aprendiz en ingeniería de software (un junior lanza algo pequeño → un senior revisa → el junior absorbe criterio a través de la tinta roja) se está derrumbando: el junior lanza a través de agentes y el senior revisa salida de agentes en lugar de salida humana
  • ¿De dónde va a salir el oficio de la siguiente generación? ¿Cómo se entrena el gusto sin repetición? ¿Cómo se sustituye la mentoría cuando el aprendiz no escribió la primera versión desde cero?
• En la mayoría de las organizaciones tradicionales, la generación actual de ingenieros senior es la última cohorte completamente entrenada con la metodología antigua
• Una respuesta equilibrada: de forma intencional y regular, hacer algo importante uno mismo, por el camino difícil y sin flota. La mayoría de tus colegas no va a conservar ese músculo, y dentro de 10 años eso puede marcar la diferencia

La parte inquietante

• Este ensayo no desemboca deliberadamente en un optimismo tranquilizador: fingir que el cambio no viene no impide su llegada
• El trabajo ya cambió para siempre, y lo hizo de forma evolutiva y gradual, al ritmo de la IA
• Los humanos recuperarán el día para el trabajo en el que de verdad se los necesita, y las máquinas recuperarán la noche para el trabajo que siempre fue simple mano de obra
• Escenarios plausibles en los próximos años:
  • Una capa de trabajadores agotados por la carga de revisión
  • Una capa de roles fragmentados que el sistema necesita, pero no recompensa
  • Una generación junior incapaz de desarrollar el oficio con el que los seniors actuales ejercen criterio
  • Equipos que confunden volumen de output con calidad de trabajo y no ven la brecha hasta que ocurre un incidente
  • Una brecha que sigue ampliándose entre organizaciones que construyeron los músculos operativos para el siguiente modelo y las que no
• El mensaje central: construye una organización para los modelos que todavía no tienes, de vez en cuando haz tú mismo algo difícil para recordar cómo se hace, manda la flota nocturna y duerme tranquilo sabiendo que el trabajo avanza, pero mantente alerta ante la posibilidad de que parte de lo que regrese esté mal de maneras que ya no te entrenaste para ver
• El empleado 24/7 no es una promesa, sino una reubicación y una apuesta por un futuro de ingeniería probabilística: una apuesta a que el humano dentro del loop siga siendo lo bastante agudo, honesto y bien entrenado como para merecer seguir ahí, y a que la organización que lo rodea esté construida no para los modelos de hoy, sino para los modelos que aún no se han lanzado