Inteligencia Artificial en el día a día de Netflix, Meta e IBM: agentes, contexto y el famoso impuesto de preparación
La IA generativa ya parece mágica en muchas demos, pero en la práctica todavía está muy lejos de algo como mandar un comando tipo Alexa, créame un e-commerce completo y salir a tomar un café. Y no sirve de nada rematar con una petición dramática del tipo NO ALUCINES, eso no resuelve el problema de fondo. Lo que está quedando cada vez más claro, sobre todo para quien trabaja en empresas como Netflix, Meta e IBM, es que cuanto más quieres que los agentes de IA hagan por ti, más trabajo de bastidor tiene que hacerse antes, durante y después de cada interacción.
En el escenario de eventos recientes sobre IA, ejecutivos e ingenieros de estas empresas vienen repitiendo un punto en común: la tecnología multiplica nuestra capacidad, pero solo entrega resultados confiables cuando hay un buen nivel de preparación, revisión y orquestación. Eso se conecta directamente con algo bien conocido en economía, la llamada Paradoja de Jevons: cuando una tecnología aumenta mucho la eficiencia del uso de un recurso, la tendencia es que usemos ese recurso todavía más. Con la IA pasa algo parecido. En lugar de simplemente sustituir tareas humanas, abre nuevas frentes de trabajo, crea funciones que no existían y empuja a los equipos hacia una rutina en la que siempre hay una automatización más posible, un ajuste más de contexto, un experimento más para ejecutar.
Hoy, quien usa modelos como asistentes de programación, soporte para texto, investigación o análisis de datos hasta logra convertirse en un desarrollador 10x en volumen de salida. El problema es que esa cuenta viene con truco: ganas 10x velocidad, pero también terminas teniendo que revisar 10x más resultados, pulir 10x más bordes y decidir 10x más veces qué se queda y qué va a la basura. Si algún día llegamos a un escenario de ciencia ficción en el que una superinteligencia domina todo, el camino hasta ahí va a pasar por un largo período en el que los humanos todavía necesitan empujar muchos datos, limpiar contexto y revisar la salida de agentes todo el día.
Netflix y la revisión adversarial: muchos agentes, mucho contexto, mucha conversación
Un ejemplo bien concreto de cómo esta dinámica está apareciendo en el mundo real viene desde dentro de Netflix. Ben Ilegbodu, arquitecto de UI en la empresa, contó en una conferencia cómo cambió su trabajo con la llegada de los agentes de IA. En lugar de solo escribir código y revisar PRs de otros devs, hoy monta verdaderos pipelines de agentes especializados para tareas específicas, principalmente en revisión de código y automatización de partes del desarrollo.
Cuando crea un agente para automatizar una tarea, como implementar una feature en una base de código grande, no se detiene ahí. A continuación configura un segundo agente con la misión específica de evaluar el trabajo hecho por el primero, mirando con ojo crítico bugs, estilo, seguridad y adherencia a patrones internos. A este enfoque por capas lo llama revisión de código adversarial, porque un agente actúa como contrapunto del otro, intentando encontrar fallos, inconsistencias y puntos de atención.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
En la práctica, eso significa que el flujo deja de ser humano → código → revisión y pasa a ser algo como humano → agente que implementa → agente que revisa → humano que cierra la cuenta. Solo que el juego se vuelve aún más interesante: muchas veces Ilegbodu divide la propia revisión en múltiples agentes, cada uno enfocado en una parte diferente del problema. Uno puede ocuparse de performance, otro de accesibilidad, otro de estandarización de componentes. Y sí, entra en escena todavía un tercer agente para orquestar la conversación entre todos los demás, consolidar resultados y armar un resumen accionable para que el humano cierre la decisión.
Mientras uno de esos agentes está tocando una parte de la base de código, ya dispara otro para preparar el terreno para una próxima tarea en paralelo. En palabras suyas, es como si estuviera paralelizándose a sí mismo, dejando el trabajo siempre avanzando en diferentes frentes. Este estilo de trabajo deja muy claro la Paradoja de Jevons en la práctica: cuanto más fácil se vuelve crear agentes para tareas específicas, más agentes aparecen, se hacen más revisiones y entra más coordinación en el día a día.
Un detalle curioso es cómo eso afecta la propia experiencia de trabajo. Con tantos agentes corriendo, Ilegbodu pasó a programar con comodidad en lenguajes que antes no dominaba, como Python, Bash y Groovy, porque consigue pedir a la IA fragmentos de código, ejemplos y revisiones sobre contextos bien definidos. Al mismo tiempo, admite que el impacto mental de todo esto es pesado: al final del día, la sensación es de cansancio no por haber escrito cada línea, sino por haber pasado horas conversando, instruyendo, corrigiendo y refinando con agentes de IA. En vez de menos conversación, el trabajo se volvió un diálogo constante con sistemas que necesitan contexto, límites y direccionamiento todo el tiempo.
Meta y el becario que nunca se cansa: demasiado contexto, poco foco
En Meta, la metáfora favorita para describir el uso de IA en el desarrollo es la del becario súper entusiasmado. La comparación es buena: el modelo es rápido, incansable, aguanta un volumen absurdo de información y acepta prácticamente cualquier tarea. La diferencia frente a un becario humano es que la IA no se sobrecarga, al menos no en términos de cansancio, pero el sistema empieza a sufrir de otro problema: lo que Justin Jeffress, Developer Advocate de la empresa, llama pudrición de contexto.
Funciona así: comienzas un proyecto con un agente de IA, compartes documentación, explicaciones, ejemplos, patrones de código, bugs conocidos y por ahí va. Con el tiempo, la conversación crece, el historial aumenta y cada nueva respuesta tiene que calcularse sobre un rastro cada vez mayor de mensajes, instrucciones y detalles. Cuantas más cosas compiten por la atención del modelo, mayor es la probabilidad de que se apoye en una parte irrelevante de la conversación o en un ejemplo antiguo que ya no tiene sentido, entregando un resultado distante de lo que esperabas.
Esa degradación gradual del foco es el contexto que se va echando a perder con el paso del tiempo. Para combatir eso, Jeffress defiende la práctica de la ingeniería de contexto como algo central en el trabajo con agentes: en lugar de simplemente ir tirando cosas al historial, defines cuidadosamente qué entra, qué sale y qué se recupera en cada etapa. En términos simples, es como construir un conjunto de reglas, herramientas y habilidades que el agente puede consultar bajo demanda, en lugar de depender solo del texto arrojado en la conversación.
Una técnica que recomienda bastante es el encadenamiento de prompts, o prompt chaining. En lugar de mandar un pedido gigante, vago y lleno de deseos, rompes la tarea en pasos específicos, orientando al agente a seguir una secuencia: primero entender el problema, luego levantar requisitos, a continuación proponer soluciones y solo entonces generar código, y así sucesivamente. ¿Da trabajo preparar esto? Seguro. Pero en la práctica, ese esfuerzo anticipado reduce bastante la posibilidad de desvíos más adelante y baja la necesidad de rehacer todo porque la IA decidió seguir un atajo raro.
Jeffress sugiere además algo muy práctico para el día a día: usar un archivo markdown u otro tipo de documento como fuente de verdad sobre lo que está en marcha, lo que ya se decidió y cuáles son las reglas del juego. El agente puede consultar ese archivo en lugar de depender solo de mensajes sueltos, lo que ayuda a evitar que olvide objetivos por el camino. Trabajando así, la IA normalmente llega a algo como el 80 por ciento de una tarea, dejando el 20 por ciento final para el humano. Pero ahí viene un giro interesante: cuando intentó automatizar también parte de ese 20 por ciento, descubrió que otra franja del 80 por ciento de esa etapa podía hacerse con bots. Y el ciclo se repite, casi como una versión fractal de la regla 80/20, solo que aplicada a un proceso de limpieza y refinamiento aparentemente interminable.
IBM, descomposición y mellea.ai: menos hechizo, más ingeniería
Mientras Netflix y Meta traen relatos muy prácticos de uso de agentes, IBM empuja la conversación hacia un lado más estructural. Luis Lastras, director de tecnologías de lenguaje y multimodalidad en la empresa, cuestiona una ilusión común: creer que el problema es siempre la IA que no obedece. Según él, en la mayoría de los casos el problema está en la forma en que describimos el trabajo, o mejor dicho, en cómo fallamos a la hora de descomponer el problema en partes lo suficientemente pequeñas para que la máquina pueda manejarlas con seguridad.
Él llama prompting ilusorio a ese intento de resolver todo a base de drama, con mensajes exagerados del tipo mi carrera depende de esto, no alucines, hazlo perfecto. Al final del día, eso es casi como intentar lanzar un hechizo y esperar que un modelo gigante haga magia con instrucciones vagas. En lugar de eso, Lastras refuerza algo que parece básico, pero que es fácil olvidar en el hype de la IA: descomposición es Ingeniería 101. Es el arte de tomar un sistema complejo, identificar piezas críticas, modularizar, diseñar cada parte y, si hace falta, asignar especialistas distintos para cada módulo.
En el mundo de los agentes, eso significa abandonar la idea de lanzar un tocho de texto a un LLM genérico y cruzar los dedos. El enfoque que defiende es montar funciones bien definidas que ayuden al agente a ejecutar tareas específicas: validar formatos, aplicar políticas, comprobar consistencia, detectar salidas potencialmente dañinas, controlar estilos de respuesta, estructurar resultados en esquemas previsibles y así sucesivamente. Para apoyar este tipo de flujo, IBM lanzó la biblioteca open source mellea.ai, que trae patrones listos en Python para estructurar llamadas a modelos de lenguaje con más disciplina.
Con estos patrones, es posible adjuntar requisitos a las llamadas al LLM, interceptar e inspeccionar respuestas antes de entregarlas al usuario, imponer formatos rígidos de salida o incluir etapas de verificación automática sobre ciertos tipos de contenido. En paralelo, IBM investiga un concepto que Lastras describe como cambio de cerebro: agentes que consiguen alternar entre modelos distintos, eligiendo el más adecuado para cada subtarea. En lugar de depender siempre de un modelo enorme, genérico y caro, se pueden usar modelos más pequeños y especializados, siempre que se les dé tiempo de inferencia suficiente y se mantenga una buena alineación de contexto. En varios escenarios probados, esta combinación de buenos patrones de ingeniería con modelos más pequeños y enfocados superó, en calidad, opciones más pesadas y generalistas.
Herramientas que usamos a diario
El impuesto de la preparación: por qué asumir que la máquina sabe es deuda técnica
Cerrando este mosaico, entra una visión práctica traída por Justin Chau, ingeniero senior en Intuit. Resume un punto delicado con una frase directa: las suposiciones implícitas son deuda técnica. Aquello que para ti es obvio, para la IA no existe hasta que esté especificado. Si no dejas claro qué es aceptable, qué está prohibido y cuáles son los límites de la tarea, en la práctica estás plantando bombas de comportamiento inesperado listas para explotar más tarde.
Un consejo que destaca es invertir un poco la forma en que solemos escribir instrucciones. En vez de enfocarte solo en lo que la IA debe hacer, vale la pena enfatizar los límites de lo que puede hacer. Restricciones bien definidas funcionan como noes firmes, más difíciles de ignorar por el modelo. Si dices que, bajo ninguna circunstancia, el agente debe usar HTML en una determinada salida, por ejemplo, la tendencia es que esa regla se respete con mucha más fuerza que un simple hazlo en texto plano.
Aún más fuerte que las restricciones explícitas es la ausencia de permiso. Si el agente no puede acceder a un repositorio, una API o una base de código, simplemente no puede tocar ahí, por muy bueno que sea el modelo de lenguaje por detrás. Para Chau, esta es una forma práctica de reducir riesgos: en lugar de confiar únicamente en instrucciones textuales, diseñas el entorno de forma que ciertas acciones sean imposibles, protegiendo sistemas críticos sin tener que revisar cada respuesta manualmente.
Ese trabajo de preparar contexto, diseñar limitaciones, elegir fuentes y dividir problemas en partes más pequeñas es lo que mucha gente ya está llamando impuesto de preparación. No hay cómo escapar de él. Igual que en la clásica Guía del autoestopista galáctico, en la que una supercomputadora pasa eras calculando la respuesta a la gran pregunta de la vida, el universo y todo lo demás y suelta un seco 42, estamos descubriendo que tener tecnología poderosa sin formular bien las preguntas, sin descomponer bien los problemas y sin cuidar el contexto solo conduce a respuestas vacías. En lugar de un futuro en el que la IA lo hace todo por su cuenta, lo que aparece hoy es un escenario en el que nos empuja a un ciclo constante de preparación, orquestación y revisión.
Al final de cuentas, el mensaje que llega desde Netflix, Meta, IBM, Intuit y compañía no es de apocalipsis ni de utopía. Es un aviso bien pragmático: la IA sí puede potenciar tu día de trabajo, abrir espacio para experimentar más, probar más hipótesis y acelerar proyectos. Pero el precio de esa aceleración es aprender a pensar como ingeniero de contexto, aceptar el impuesto de preparación y ver a los agentes no como magos infalibles, sino como herramientas poderosas que necesitan límites claros, buenas fuentes y una persona atenta dirigiendo la orquesta.
