La señal
de la feria.

La gran idea: un agente de IA es un modelo de razonamiento congelado más un harness: la memoria, las herramientas, el conocimiento semántico y la percepción que envuelves a su alrededor. Alquilas el modelo y no puedes controlar sus salidas no deterministas; el harness es la parte que diseñas para convertir la aleatoriedad de mismo-input-distinto-output en resultados fiables y repetibles.

Por qué importa: para el 99,9% de los equipos, cambiar los pesos del modelo está descartado, y meter ventanas de contexto cada vez más grandes sale mal: la atención escala de forma cuadrática, así que los contextos saturados se degradan en context rot. La verdadera palanca está en la ingeniería de memoria: esquemas, políticas de ciclo de vida, recuperación y gobernanza tratados como una disciplina formal en lugar de algo secundario.

Cómo funciona: la memoria se divide en corto plazo (el contexto de trabajo), largo plazo (memoria episódica, procedimental, semántica y de toolbox) y memoria compartida entre agentes que colaboran. Sobre el almacenamiento, Martinez rechaza la pelea archivos-contra-bases-de-datos: los archivos son cómodos por POSIX pero carecen de consistencia transaccional, así que propone un híbrido: memoria de corto plazo en archivos, promovida a una base de datos ACID mediante Oracle DBFS. El paquete OAMP de Oracle comprime luego la gestión en una sola llamada: context_card devuelve un bloque acotado y listo para el prompt con temas, un resumen en curso, hechos y preferencias relevantes, y mensajes recientes.

Qué robar: el patrón skillbox. Destila los flujos de trabajo que demostraron ser fiables en artefactos SKILL.md versionados y almacenados con embeddings, retira la receta cruda y usa recuperación en dos niveles: un manifiesto liviano en cada turno, el cuerpo completo de la skill solo cuando el agente lo invoca. El patrón hermano toolbox hace búsqueda vectorial de esquemas de herramientas por turno para que solo las herramientas relevantes lleguen a la ventana de contexto. Ambos ofrecen aprendizaje continuo en el espacio de tokens, sin reentrenamiento.

El matiz: este es un taller de patrocinador, y las respuestas convergen en Oracle: la base de datos convergente, DBFS, embeddings dentro de la base de datos y OCI Generative AI como un open router empresarial hacia modelos de Google, Meta, OpenAI y xAI. Los patrones generalizan; el tooling llave en mano asume que te sumas al stack de Oracle.

La gran idea: AWS hizo un speedrun práctico para construir agentes de producción sobre bases open-source. Strands Agents, un harness construido por AWS y con soporte de la comunidad y compatibilidad con MCP, maneja el bucle del agente, y Amazon Bedrock AgentCore lleva el resultado del prototipo en notebook a producción serverless.

Por qué importa: el argumento central del taller es el determinismo. Los prompts son sugerencias probabilísticas, mientras que los hooks, las skills y los handlers de steering son código, y el código es aplicable. Esa es la diferencia entre un chatbot de demo y un agente de atención al cliente en el que puedes confiar para hacer reembolsos.

Cómo funciona: siete módulos construyen un solo bot de atención al cliente. El Módulo 1 conecta el bucle del agente: input, razonamiento del LLM, selección de herramientas mediante funciones decoradas con @tool como lookup_customer y get_order_history, y luego una respuesta fundamentada. Los hooks interceptan antes o después de la invocación, las llamadas al LLM y las llamadas a herramientas para validar entradas, bloquear datos sensibles o aplicar límites de tasa. Las skills cargan archivos de conocimiento en markdown solo cuando una consulta los necesita. Los handlers de steering añaden un agente compañero en cada checkpoint para hacer cumplir el formato y el tono, y AgentCore Runtime despliega luego todo el conjunto en una sola acción.

Qué robar: el patrón RateLimiterHook, un callback de HookRegistry que reinicia un contador por petición y detiene en seco a un agente que se vuelve loco en bucle con las llamadas a herramientas antes de que queme tokens. También la jugada de Agent Control: mantén las reglas de steering en una base de datos que el motor lee en la invocación, de modo que una nueva regla de negocio (bloquear reservas de más de cinco personas) nunca toque el código del motor.

Los números: siete módulos en 2 a 3 horas, aprovisionados para unos 250 participantes con enlaces del taller válidos 2 a 3 días. Las sesiones de AgentCore corren de 15 minutos a dos horas en micro-VMs aisladas, la memoria de largo plazo persiste más allá de ocho horas, y el limitador de tasa de la demo tope las llamadas a herramientas en tres por petición.

El matiz: el Wi-Fi del recinto se cayó, forzando un recorrido en el escenario y enlaces de respaldo. Las cuentas temporales de Workshop Studio son efímeras (mantén los datos confidenciales fuera), y el hook de la demo bloquea las llamadas a herramientas sin terminar el turno del agente, así que debes diseñar tu propia parada en seco o el bucle seguirá reintentando.

La gran idea: la ingeniería de IA existe porque los agentes son no deterministas: el sistema puede verse perfectamente sano mientras cada respuesta es errónea o simplemente mediocre. La respuesta de Langfuse es un bucle: traza y monitorea online, construye datasets y ejecuta experimentos offline, y despliega solo cuando los resultados mejoran sin regresiones.

Por qué importa: una vez que una app escala, nadie puede leer cada conversación. Los dashboards agregados, el feedback de los usuarios y los evaluadores automáticos existen para sacar a la superficie los cinco o seis fallos genuinamente complicados escondidos entre 500 preguntas rutinarias, y para dirigir la atención humana ahí.

Cómo funciona: el vehículo práctico es "Specs", un agente de soporte técnico estilo papá: una app en TypeScript sobre el OpenAI Node SDK que llama a GPT-4o, con herramientas para el contexto del dispositivo y una búsqueda en la biblioteca de ayuda. Cada turno del usuario se convierte en una traza: una observación raíz del agente con llamadas anidadas a herramientas y al modelo que llevan coste, latencia, tokens y versión del prompt. Los asistentes conectan tres evaluadores en vivo: un LLM-as-judge que marca el desacuerdo del usuario ("ese botón no está ahí"), un detector de mayúsculas basado en reglas para la frustración en el último mensaje del usuario, y una comprobación de fuera-de-alcance que compara el system prompt con la petición. Los mapeos de rutas JSON dirigen cada evaluador exactamente a la porción de la traza que necesita.

Qué robar: no copies y pegues plantillas de evaluadores. Diseña los monitores en torno a cómo falla tu app específica. Versiona tus datasets y las configuraciones de evaluadores, calibra los evaluadores LLM-as-judge contra juicios humanos para que las puntuaciones sigan siendo señal en lugar de ruido, e instala la skill de la CLI de Langfuse para que un agente de codificación pueda consultar trazas, puntuaciones y datasets directamente.

Los números: apuntado a unas 120 trazas parecidas a producción provenientes de 70 casos de prueba, el informe en Markdown del agente de codificación sacó a la superficie una herramienta search_help_library que fallaba en silencio devolviendo candidatos ruidosos, fallos de recuperación correlacionados con el coste, brechas de cobertura de evaluadores a lo largo del tráfico, y desalineación de versiones de prompt, y luego propuso correcciones conscientes del repositorio.

El matiz: Langfuse queda fuera de la ruta crítica: analiza señales después de los hechos y se integra con frameworks de guardarrailes separados si necesitas bloquear peticiones de plano. Y los evaluadores automáticos, por escalables que sean, se pierden los modos de fallo novedosos que nunca anticipaste; el feedback humano y la anotación se quedan en el bucle exactamente por esa razón.

La gran idea: la superficie de agentes de Anthropic ha evolucionado en tres pasos. La Messages API era tokens de entrada, tokens de salida. El Claude Agent SDK empaquetó el harness de Claude Code pero dejó el alojamiento, el escalado y los secretos en tus manos. Claude Managed Agents lleva todo ese stack de producción a la nube de Anthropic, de modo que los equipos solo son dueños de su producto, su tarea y su contexto.

Por qué importa: los harnesses codifican suposiciones sobre lo que un modelo no puede hacer, y esas suposiciones se pudren rápido. El equipo construyó soluciones de reinicio de contexto para la "ansiedad de contexto" de Sonnet 4.5. Luego Opus 4.5 salió sin ese comportamiento, y las correcciones se volvieron puro lastre que degradaba al agente. Un harness rígido construido en torno al modelo del año pasado puede tardar semanas o meses en migrarse, convirtiendo al harness en el cuello de botella de la capacidad de frontera.

Cómo funciona: la arquitectura desacopla el cerebro (un bucle de agente persistente en la nube) de las manos (sandboxes levantados bajo demanda para el acceso a archivos y la ejecución de código). Tres primitivas componen todo: Agent (modelo, prompts, herramientas, skills), Environment (la definición del contenedor) y Session (un recurso duradero en la nube). Cada evento aterriza en un log de sesión, así que un sandbox muerto se reemplaza y se reintenta, un bucle caído vuelve a leer el log y reanuda, y el harness puede traer de vuelta porciones de contexto pasado a la ventana en lugar de perder los turnos descartados.

Los números: desacoplar el razonamiento del arranque del contenedor redujo el time-to-first-token un 60% en p50 y más del 90% en p95. En la demo en vivo, un agente SRE Investigator rastreó un pico de p99 en el checkout de 298 ms a 3.120 ms (errores del 0,3% al 14,2%) a través de 1.204 timeouts upstream y cuatro deploys recientes hasta el commit a3f9c21, que había eliminado un decorador de cache y disparado consultas N+1 a la base de datos, y luego recomendó el rollback.

Qué robar: mantén las credenciales en un vault y descífralas solo en el runtime de ejecución de herramientas, de modo que el modelo nunca vea un token. Nunca bloquees el razonamiento con el arranque del contenedor: ejecuta la configuración en paralelo o sáltatela. Expón los logs de sesión tanto como transparencia de cara al usuario como trazas de ingeniería. Luego cierra el bucle: Dreaming procesa por lotes transcripciones y memoria hacia sesiones futuras más inteligentes, y Outcomes ejecuta un agente evaluador contra tu rúbrica, reintentando hasta que el trabajo realmente pase.

El matiz: la propuesta asume que le entregas el harness a Anthropic: el cerebro vive en su nube. Para empresas conscientes de la seguridad, las vías de escape son los sandboxes autoalojados, que mantienen la ejecución de herramientas dentro de tu propia VPC bajo tus políticas, y los túneles MCP, que dejan que los servidores MCP permanezcan en una red privada y se conecten solo hacia afuera.

La gran idea: enviar IA a base de vibras (corre tres consultas, asiente, despliega) se cae porque la salida del LLM es no determinista y las pruebas unitarias no tienen una cadena esperada contra la cual afirmar. El modelo mental de reemplazo de Voss: las trazas son logs para la IA, las evals son pruebas para la IA, y juntas convierten la calidad del agente en un número que puedes rastrear, comparar y usar como puerta en CI.

Por qué importa: los agentes multiplican la superficie de falla. Cada llamada a herramienta y cada decisión es una nueva oportunidad de descarrilarse, y los errores se propagan en silencio: su agente de demo preguntó por Tesla el fabricante de autos, recuperó al inventor del siglo XVIII y escribió un informe hermoso y confiadamente equivocado donde ningún paso individual estaba mal. Sin evals juegas al golpea-al-topo: un arreglo de tono dispara alucinaciones en otra parte, y cambiar de modelo significa semanas de reprueba manual en lugar de horas.

Cómo funciona: Voss construyó el bucle en vivo: un agente de análisis financiero sobre el Claude Agent SDK, instrumentado en Arize AX con dos líneas de código de OpenTelemetry/OpenInference. Luego el paso que la mayoría de los tutoriales se salta: lee las trazas y categoriza las fallas a mano (codificación abierta, luego codificación axial) antes de escribir una sola eval. Solo entonces apila defensas al estilo queso suizo: evals de código deterministas para verificaciones baratas como si-apareció-el-ticker, jueces LLM integrados después, y una rúbrica de accionabilidad personalizada con un rol de juez definido, criterios observables, datos etiquetados en XML y opciones binarias definidas externamente.

Qué robar: prefiere la fidelidad sobre la corrección para agentes de datos en vivo. Su juez de corrección calificó cada informe con cero porque no podía conocer hechos de 2026, mientras que la fidelidad le dio al juez las mismas fuentes que usó el agente. Califica el resultado, no el camino: el agente de tau-bench de Anthropic mejoró legalmente un boleto de económica a primera clase para reprogramarlo y fue marcado como incorrecto. Construye un evaluador por dimensión, nunca una eval-Dios, y meta-evalúa a los jueces contra un dataset dorado etiquetado por humanos dividido en dev y test. Luego cierra el bucle: alimenta las explicaciones del juez a Claude Code, deja que reescriba los prompts y verifica con experimentos controlados.

Los números: dos líneas de código para instrumentar. La fidelidad marcó 7 de 13 informes de demo como no fundamentados; una reescritura de prompt guiada por explicaciones llevó el conjunto de fallas de cerca de la mitad equivocada al 100% aprobando. De 12 a 20 ejemplos dan una señal direccional, pero apunta a entre 200 y 400 antes de decisiones de envío. Los anotadores humanos pasan por alto hasta el 50% de los defectos por fatiga, y la fiabilidad entre evaluadores expertos puede quedar en 0,2 a 0,3, así que un juez que a veces discrepa contigo no está roto.

El detalle: los jueces LLM cargan sesgo de posición, longitud, confianza y autorreferencia (usa un modelo distinto para juzgar que para generar), y los prompts de eval son tan frágiles como el código de la aplicación, así que necesitan su propio ciclo de prueba e iteración. Automatizar antes de entender tus fallas solo construye métricas para lo que es fácil de medir en lugar de lo que realmente importa.

La gran idea: los agentes se están comiendo la implementación, así que la definición de ingeniería pasa de "¿podemos construirlo?" a "¿vale la pena construirlo?". Dodds, que se pasó una década vendiendo cursos de React y de testing, abre admitiendo que su propio producto es obsoleto: los ingenieros con experiencia ya no necesitan un curso de framework cuando un agente resuelve la sintaxis. Lo que sobrevive, argumenta, es el criterio. Su metáfora del tiro con arco: los agentes convirtieron a todos en tiradores certeros, así que el diferenciador ya no es dar en el blanco, es elegir qué blanco importa.

Por qué importa: un ingeniero que solo convierte tickets en implementaciones se parece a un equipo de agencia intercambiable, y Dodds dice sin rodeos que los ingenieros sin sentido de producto o de diseño serán fáciles de reemplazar a medida que los agentes mejoren. Mientras tanto los agentes amplifican el descuido: no van a frenar el scope creep, así que los productos se degradan en silencio a menos que los humanos sigan siendo intencionales sobre qué se añade.

Cómo funciona: el ingeniero de producto conecta el entendimiento del cliente con las decisiones técnicas, definiendo modelos de datos, la forma del flujo de trabajo, la observabilidad, los modos de fallo y pequeñas porciones con contexto río arriba. Eso significa vivir mitad en la tecnología y mitad en el mundo del cliente, cuestionar los prototipos hechos por vibe coding y reimplementarlos con verdadero pensamiento de sistemas. La responsabilidad es la función forzosa: un ingeniero que espera la llamada a las 2 a. m. diseña con mucho más cuidado, y elegir las primitivas equivocadas temprano hace que incluso las grandes soluciones sean caras de deshacer.

Qué robar: el ejercicio de entrevista de The Mom Test, ejecutado en vivo sobre una app votada por el público para saltarse las filas de los talleres de la conferencia. Nunca preguntes "¿usarías esto?": la gente escapa de la conversación halagándote. Pregunta en cambio por la última vez que ocurrió el problema, qué hicieron en su lugar y cuánto costó el apaño. Los usuarios que ya gastan tiempo o dinero en un apaño valen oro; los usuarios que no recuerdan el problema son un no cortés.

Los números: un equipo inmobiliario australiano gastó 1,2 millones de dólares australianos (casi 900.000 dólares estadounidenses, según la propia conversión de Dodds) y un año entero construyendo una plataforma escalada para que cada australiano iniciara sesión al mismo tiempo. Cero personas la usaron. Una prueba manual de dos semanas habría respondido la pregunta primero. Misma lección en la historia de Burbn: Instagram surgió al desechar todo excepto la única función que los usuarios realmente tocaban, compartir fotos.

El truco: la velocidad ahora corta en ambos sentidos. Puedes construir lo incorrecto increíblemente rápido y sentirte enormemente productivo al hacerlo, y las capas de superficie que parecen funcionales esconden casos límite faltantes y unas tripas que no escalan. Los agentes tampoco te avisarán; el trabajo humano es ir más despacio, poner barreras como tests y criterios de aceptación, y construir un patio de juegos donde los compañeros agentes puedan tener éxito de forma segura.

La gran idea: el prompt caching reescribe las reglas de la ingeniería de contexto. Los proveedores reutilizan el KV cache precalculado, así que reenviar una conversación entera cuesta una fracción de los tokens nuevos, mientras que cualquier summarization o compactación transforma el contexto, invalida el cache y fuerza un recálculo a precio completo. Para ganarle al descuento, la compresión tiene que superar aproximadamente 50x, algo difícil sin destruir el detalle.

Por qué importa: la mayoría de los stacks de agentes resumen por defecto, y también lo hacía el tutor de IA en producción de Towards AI: limpiar las salidas de las herramientas pasados los 5.000 tokens, resumir pasados los 30.000. Esos valores por defecto sin probar perdieron feo contra una línea base sencilla de historial completo: limpiar las salidas de las herramientas solo forzaba al agente a volver a recuperar información que ya tenía, sumando llamadas a herramientas, tokens y costo.

Cómo funciona: el tutor es un simple bucle ReAct construido con middleware de LangChain sobre un corpus de 8 mil millones de tokens de lecciones de cursos y documentación de librerías. La recuperación es híbrida (embeddings de Cohere más BM25, fusionados y reordenados a los cinco mejores fragmentos) junto a una herramienta bash en sandbox que navega un wiki de la base de conocimiento generado con Claude Code. El equipo construyó un arnés de evals con 60 pares reales de preguntas y respuestas de estudiantes y sesiones multiturno sembradas con hechos enterrados, calificados por comprobaciones de código y LLM-as-judge, y luego corrió 11 presets manteniendo fijos el modelo, el prompt y las herramientas.

Los números: en Gemini 3.5 Flash, el historial completo alcanzó 100% de recall en los hechos enterrados frente al 38% de los valores por defecto de producción, y fue más barato y más rápido. En DeepSeek, donde el descuento del cache llega a unos 50x, el preset que enviaba más tokens fue el más barato de correr: 97% de tokens en cache, 95% de recall frente a 32% tras la summarization. La búsqueda semántica densa se derrumbó a 0% de recall alrededor de los 400k tokens mientras que BM25 se mantuvo en 100%. La recuperación de hechos distintos se mantuvo sólida hasta unos 800k tokens, y solo la primera ronda de experimentos costó más de $500.

Qué robar: no compactes por defecto: nombra la restricción que realmente tienes y luego elige la técnica. Prueba siempre una línea base de no-hacer-nada con historial completo antes de nada ingenioso. Usa búsqueda híbrida, no puramente semántica. Construye skills pequeños y precisos que se referencien entre sí y se carguen de forma progresiva. Y registra todo (tasa de aciertos del cache, costo, latencia, tiempo hasta el primer token) con OpenTelemetry para que las decisiones salgan de datos, no de vibes.

El truco: el historial completo deja de ganar cuando el hardware limita la ventana. Los modelos locales tocaron techo en un contexto de 32k en su banco de pruebas MacBook, los beneficios del caching se rompieron y el recall en chats largos cayó a cerca del 33%, aunque el RAG local sobre documentos pegados obtuvo 100%. Y la herramienta de navegación de archivos que sonaba lista fue 50% más lenta sin ganancia de calidad en las preguntas reales de los estudiantes.

La gran idea: la generación de código de IA personal rompe la infraestructura de nube tradicional. Kenton Varda, que creó Cloudflare Workers en 2017 y todavía lo lidera, dice que el modelo de una-única-versión-bendecida-de-la-app-en-el-servidor-del-desarrollador que ha definido 25 años de arquitectura web no puede sostener un futuro donde el agente de IA de cada usuario adapta las apps solo para él.

Por qué importa: la tubería de la torre de marfil falla a todos. Los usuarios presentan solicitudes de funcionalidades que los product managers entierran en Jira, los desarrolladores se queman añadiendo if-statements de nicho, y luego desaparecen en una reescritura de sistema de plugins de años mientras los usuarios concluyen que el producto está abandonado. En móvil es peor: Varda bromea con que, tras 15 años de vigilancia de Apple y Google, es casi más fácil comprar un arma en EE. UU. que instalar software sin firmar en tu propio teléfono.

Cómo funciona: Fungy, su proyecto paralelo construido sobre Cloudflare Workers, se siente como Google Docs pero gestiona "gadgets" en lugar de documentos, cada uno una instancia de app de un solo propósito con su propio código, como un gadget por cada presentación de diapositivas. Los blueprints permiten a los usuarios compartir el código del gadget sin los datos. Como cada gadget mapea exactamente a una cosa compartible, la plataforma (no la app) hace cumplir el compartir y el control de acceso. Cada gadget se integra con agentes de IA: en su demo, Claude construyó sus diapositivas de la conferencia a partir de un Google Doc y, al decirle que podía extender la app por sí mismo, añadió tachado, centrado e inserción de SVG arbitrario, y luego generó un diagrama como SVG.

Qué robar: la arquitectura de seguridad. La UI hecha con vibe coding corre en un iframe sandbox de origen nulo bajo una CSP estricta que bloquea cookies y red saliente; su único canal es postMessage hacia una sesión de Web RPC de Cap'n Proto reenviada al código de servidor del gadget, un Durable Object que corre en un sandbox de worker dinámico igualmente aislado. El cliente y el servidor solo pueden hablar entre sí, así que un bug de XSS en código generado por IA no tiene nada que filtrar: ningún bug de seguridad en el código del gadget importa.

Los números: Workers sirve a millones de desarrolladores y billones de peticiones al día, y sin embargo toda la demo de 18 minutos corrió localmente en su portátil mediante workerd, el runtime open-source de Workers, sin contenedores, sin base de datos tradicional, solo workers dinámicos y Durable Objects, que es por lo que la internet caída del recinto no importó.

El matiz: la liberación open-source prometida no ocurrió. El entusiasmo interno puso serio el proyecto paralelo, y días antes de la charla un colega de Cloudflare argumentó en contra de lanzarlo directo a GitHub a favor de un lanzamiento disciplinado. El código de Fungy aterriza "pronto": por ahora puedes autoalojar workerd, pero no la plataforma.

La gran idea: las fábricas de software agénticas que eliminan la revisión de código humana fracasan, porque los modelos de codificación se entrenan para hacer pasar tests, no para mantener una base de código mantenible. Ninguna cantidad de ingeniería de harness o de maximización de tokens puede parchear lo que es fundamentalmente un problema de entrenamiento del modelo.

Por qué importa: las grietas ya son visibles. Desde que los equipos adoptaron ampliamente las herramientas de codificación de IA, un informe de la industria encontró que la calidad de la revisión de PRs caía, cientos de PRs se enviaban sin revisión alguna, y los incidentes y bugs por desarrollador subían. Horthy hizo él mismo el experimento sin supervisión en julio de 2025: los agentes toparon con problemas que no podían resolver, su equipo tuvo que volver a hurgar en código que nadie había leído en meses, y los usuarios se comieron la caída.

Cómo funciona: el RL de codificación se parece a SWE-bench: tareas de unos 15 minutos en repos open-source con recompensas binarias por arreglar el problema objetivo sin romper otros tests. Nada en ese bucle penaliza los bloques try/catch gratuitos, los hacks de casting de tipos o el diseño de cirugía de escopeta. Peor aún, el coste de la mala arquitectura aflora meses o años después, demasiado tarde para propagar una señal de recompensa de vuelta al episodio de codificación que lo causó. Los laboratorios que hacen RL de un modelo dentro del mismo harness que envían (el playbook de Claude Code) dominan a los constructores de solo-harness, que es precisamente por lo que el harness por sí solo no puede salvarte.

Qué robar: vuelve a encender las luces. Las tareas pequeñas siguen yendo directo a los agentes, pero el trabajo más grande recibe estructura por adelantado: una revisión de producto que clave el problema, el comportamiento y los mockups; una arquitectura de sistema con contratos de componentes, modelos de datos y restricciones; un diseño de programa que especifique las capas de abstracción y los grafos de llamadas; y luego cortes verticales que secuencien la implementación a través de los repos. Los humanos siguen leyendo cada línea. La IA solo comprime la planificación y la alineación.

Los números: unos 30 minutos de planificación previa pueden ahorrar horas de revisión. El primer agente de codificación de CLI entrenado por un laboratorio cabalgó esa ventaja de harness+pesos de cero a 4.000 millones de dólares (ahora unos 9.000 millones) de ingresos en menos de un año. E incluso un 20% de retrabajo de PRs, generoso para el código generado por IA, es un impuesto emocional e intelectual tanto para el revisor como para quien lo envía.

El matiz: vienen mejores verificadores: tareas de benchmark de 400 horas, evals sobre repos fuera del conjunto de entrenamiento, tareas de PR que penalizan que los tests pasen antes del parche, modelos juez que hacen cumplir reglas de calidad. Pero un modelo juez solo eleva el suelo: si un modelo de verdad supiera qué aspecto tiene el buen código, lo habría escrito de entrada. La propuesta de Horthy: HumanLayer, un IDE de IA y espacio de trabajo colaborativo para exactamente este flujo, gratis para equipos pequeños.

La gran idea: ahora todo agente es un usuario. La infraestructura dimensionada para cientos de millones de humanos colapsa bajo un tráfico de agentes impredecible y de alto volumen, y el panel sostiene que el arreglo no es un parche: los cimientos de la computación tienen que cambiar.

Por qué importa: la adopción empresarial se estanca por confianza y cultura, no por capacidad del modelo. Los equipos deben cambiar el instinto de culpar a la persona por bucles de aprender-del-agente, y los ingenieros tienen que aceptar el paso de construir a gestionar y dar soporte a los agentes que construyen.

Cómo funciona: el panel esboza un stack nativo de agentes. Los frameworks que compilan artefactos en tiempo de build ceden ante software generado y serializado en tiempo de ejecución; las GUI bonitas y caras en tokens ceden ante APIs eficientes centradas en texto; y las herramientas estandarizadas más la inversión en experiencia de desarrollo ponen a todo constructor de agentes en igualdad de condiciones.

Qué robar: trata a un agente en producción como cualquier app bien arquitecturada. Te obliga a las buenas prácticas que ya deberías tener. Convierte cada molestia en una verificación de CI para que el agente nunca repita un error. Y sigue dirigiendo el trabajo tú mismo: el criterio humano es lo que separa la magia del slop homogéneo.

Los números: un panelista proyecta 600 mil millones de agentes desplegados que odian las imágenes (suficiente para arrastrar la internet móvil, primero de imagen y video, de vuelta al texto), mientras otro limita su enjambre de agentes autoorquestados a 500, y cientos de miles de millones de dólares persiguen un razonamiento de modelo cada vez mejor.

El detalle: a los modelos todavía les falta lo que un panelista llama el cerebro de mono: coherencia de largo horizonte, guiada por creencias. Las sesiones no logran mantenerse en la tarea durante tres días, los humanos se adaptan más despacio de lo que cambia la tecnología, y la dependencia excesiva de la IA converge la salida de todos hacia el mismo medio mediocre.

La gran idea: el costo marginal de escribir código se ha desplomado a prácticamente cero, así que este panel sostiene que el trabajo del desarrollador se desplaza a lo que queda: alinearse sobre qué construir, validar que es correcto, y el criterio para saber qué vale la pena lanzarlo.

Por qué importa: los organigramas ya se están doblando. El CTO de LaunchDarkly trata a cada IC como un gerente de primera línea que dirige cuatro equipos de agentes a la vez, espera que los recién egresados hagan producto, diseño, especificación y trabajo de TPM, y bromea con que los equipos de dos pizzas ahora son equipos de dos rebanadas porque los agentes no comen. La curva de experiencia también se aplana: los juniors usan la IA como guardarrailes mientras los seniors apalancan su criterio sobre un ejército de agentes.

Cómo funciona: cada panelista aterriza en una versión de shift-left. Mueve la calidad aguas arriba con desarrollo guiado por evals y por especificación, requisitos demostrablemente correctos (TLA+ recibe una mención), y tipos. El auge de TypeScript se atribuye a que los agentes se mantienen en carril cuando los tipos los restringen. El PR se convierte en un punto de auditoría más que en la puerta de calidad, y los agentes se ganan autonomía a través de sandboxes en la nube configurados al riesgo del proyecto y personal.

Los números: el cofundador de Greptile dice que sus agentes de revisión de PR cubren unos 10 mil millones de líneas de código al mes, que el código escrito por persona subió aproximadamente 10x en la mediana en 12 meses y cerca de 100x en el P90, y que un estudio de 2017 encontró que escribir código es solo cerca del 5 por ciento del trabajo real de un desarrollador.

Qué robar: codifica el contrato con el usuario: haz de la documentación de producto de cara al público la fuente de verdad contra la que operan los agentes, porque el producto, no la base de código, es la salida de la empresa. Comparte tus tres supuestos más riesgosos en lugar de una especificación de cuatro páginas. Empaqueta las prácticas de un ingeniero con criterio como skills compartibles para que todo el equipo las herede.

El detalle: nadie ha construido aún herramientas para escalar equipos. Conductor y sus clones paralelizan a un individuo, y la colaboración multijugador en tiempo real para desarrollo con agentes sigue siendo una pregunta abierta. Y la IA es probabilística, no tiene criterio: los humanos conservan la selección de problemas, el oficio y la disciplina de recortar lo que no funciona.

La gran idea: la ingeniería forward-deployed es una función de transformación profundamente técnica y embebida en el cliente, no servicios profesionales, no staff augmentation, no un equipo de despliegue. Pauline Brunet, que dirige la práctica en Cursor tras una década de despliegues de IA empresarial, expuso un manual sin rodeos para montar una sin desperdiciar a tus mejores ingenieros.

Por qué importa: las empresas siguen comprando IA de vanguardia y viéndola pudrirse en el estante. La advertencia central de Brunet es que la tecnología sin acompañamiento fracasa: alguien tiene que sentarse dentro de la organización del cliente, encontrar el caso de uso correcto y llevar a las personas a través del cambio. Bromeó con que el rol está listo para un perfil de trabajo más codiciado de 2026 en Forbes.

Cómo funciona: ubica a cada cliente en una matriz de 2x2 de madurez digital frente a personalización del producto. Los clientes maduros con productos listos para usar necesitan documentación y autoservicio; el punto dulce de la transformación embebida son los clientes en etapas más tempranas de su recorrido que usan un producto altamente personalizable. Ancla cada engagement con el comprador económico o un champion senior, átalo a un objetivo estratégico y co-desarrolla dentro del codebase del cliente con validación human-in-the-loop.

Qué robar: define el alcance de forma direccional en fases acotadas en el tiempo (unas seis semanas) para que ambas partes puedan aprender y pivotar antes de haber visto sus datos y sistemas. Define el éxito y la línea base desde el inicio, y haz que el cliente sea dueño de los criterios de éxito, la medición y la operacionalización. Escribe una misión de equipo de una línea (la de Cursor: co-diseñar y co-construir tu fábrica de software de IA) para que todos puedan oler el staff augmentation y rechazarlo.

Los números: Cursor contrata ingenieros con cinco o más años de experiencia y con la EQ para tratar con clientes (todavía sin recién graduados), y luego planea dividir los roles y evolucionar de generalistas por geografía a pods por industria con SME de área de producto. Una definición de éxito de la charla: automatizar un proceso de extremo a extremo para que la resolución baje de tres horas a veinte minutos. Y una factura de agente de $2.000 al día dejó de parecer aterradora una vez replanteada como el costo de despachar a la persona correcta para reparar un equipo.

El truco: la línea entre FDE y el trabajo de body shop es delgada. Pon a ingenieros 10x a documentar bugs, a dar talleres de producto 101 o a engagements vagos de dos SDR durante seis meses, y se aburrirán y se irán. Decir que no a los casos de uso que no encajan, y ser honesto sobre dónde la plataforma no es la herramienta adecuada, es como la función mantiene su credibilidad y su talento.

La gran idea: los modelos de IA han resuelto de hecho la ejecución del trabajo de conocimiento. El siguiente cuello de botella es cuán profundo puedes llegar en el negocio de un cliente sin que la plantilla crezca exponencialmente. El CEO de Kepler, Vinoo Ganesh, presentó al ingeniero forward-deployed (FDE) como el rol que cierra la brecha: embeberse dentro del cliente, aprender cómo funciona realmente el trabajo y reimaginarlo en torno a la IA.

Por qué importa: pegar modelos de frontera sobre procesos rotos es la razón por la que la IA empresarial muestra tan poco retorno. Los operadores no técnicos en finanzas, ventas o compras no pueden manejar un modelo en crudo como lo hace un ingeniero, y cada negocio funciona distinto: un equipo de ventas de salud no opera en nada parecido a uno de SaaS. Las soluciones puntuales genéricas se pierden el contexto que hace que la automatización cuaje.

Cómo funciona: los FDE de Kepler se embeben con un departamento a la vez (digamos finanzas) y entrevistan a los dueños de los procesos de AP/AR, conciliación y FP&A. Documentan no el camino ideal sino lo que pasa cuando las cosas salen mal (Sarah maneja el flujo hasta que se rompe, y luego Chris se come cuatro días de tiempo de ciclo). Luego reingenierían el proceso: algunos pasos totalmente autónomos, algunos human-in-the-loop, algunos dejados en manos humanas donde el riesgo es demasiado alto, todo desplegado encima del sistema de registro existente del cliente, sin exigir nunca una migración.

Qué robar: para escalar los FDE sin contratación exponencial, Kepler está construyendo un Agente FDE interno en tres etapas. Un agente de engagement sintetiza notas de Granola, documentación, diapositivas y correo para que los FDE puedan consultar el contexto del cliente al instante. Un agente de flujo de trabajo vive dentro de la plataforma y señala los casos límite que se pasan por alto a medida que se construyen los flujos. Un futuro asistente autónomo enviará solicitudes menores de cambio del cliente de extremo a extremo. Por debajo: un grafo de dependencias de la empresa, modelos open source post-entrenados (los modelos de frontera resultaron demasiado verbosos para el análisis de nivel consultor) y un entorno de RL que entrena herramientas personalizadas de recorrido de grafos como resolución de entidades y detección de violaciones de DAG.

Los números: aproximadamente el 95 por ciento de los pilotos de IA generativa no llegan a producción, y el 87 por ciento no muestra ROI medible. Un cliente de Kepler gastó cinco millones de dólares y cinco años migrando a NetSuite, razón por la que los planteamientos de migrar-primero mueren al llegar. Las soluciones puntuales entregan un 5 a 10 por ciento de ROI; Kepler afirma que las transformaciones a nivel de departamento devuelven entre un 25 y un 75 por ciento entre aumento de ingresos, ahorro de costos y mitigación de riesgo.

El truco: todo el modelo depende de personas raras (ingenieros del percentil superior que además son consultores de alta EQ), y Ganesh admite que son brutalmente difíciles de encontrar. La tercera etapa autónoma del Agente FDE aún no está construida, así que los humanos todavía absorben el ajetreo del correo de clientes 24/7 que el agente debe borrar.

La gran idea: construir ahora es parte del trabajo de liderazgo. Los agentes de programación que corren de forma autónoma durante horas hacen que el calendario picado de un manager sea usable como tiempo de construcción. Agrawal envía de 2 a 10 PR por semana entre 15+ reuniones recurrentes, siete reportes directos y un niño pequeño en casa.

Por qué importa: los modelos de frontera redibujan sus contornos de capacidad cada pocos meses, y ningún volumen de opiniones sustituye al uso práctico. Un líder que construye puede fijar expectativas realistas para los ingenieros, percibir temprano los cambios de estrategia y ganar alineación con un prototipo funcional en vez de meses de persuasión. Y como los líderes tienen el mayor contexto de negocio, su dirección es, en palabras de Agrawal, más impactante por token que la de un IC.

Cómo funciona: un bucle diario. Una hora por la mañana revisando lo que hizo el agente durante la noche, bloques cortos de dirección entre reuniones, y luego un bloque a las 5 p. m. que lanza la corrida nocturna. Antes de ese bloque, su agente de trabajo conectado a Slack/Jira/Notion, Dia, pasa 20 minutos investigando la funcionalidad y arma un prompt de contexto gigante (objetivos de negocio, tradeoffs pasados, restricciones) para pegar en Claude Code o Cursor. El agente entonces trabaja de seis a ocho horas: tests escritos primero, comprobaciones de flujo de extremo a extremo, PR amigables para el revisor, CI en verde, una pasada de revisión de código con IA y un informe completo esperando por la mañana.

Qué robar: elige proyectos de cuatro categorías seguras (herramientas internas, mejoras de calidad de vida del producto, artefactos de celebración para los compañeros y prototipos de visión sobre nuevas familias de modelos) y nunca trabajo de ruta crítica que se atasca cuando te absorbe un incendio. Dos recetas nocturnas más: convierte volcados JSON de feedback de usuarios en un set de evals más un arnés de optimización que muele hasta que las puntuaciones suben (luego guarda el flujo como un skill reutilizable), y dale a un agente datos curados más acceso acotado a AWS para entrenar modelos personalizados candidatos. Agrawal despertó con dos clasificadores entrenados y un informe de despliegue.

El truco: nada de esto funciona sin el andamiaje organizacional (CI confiable, revisores de código con IA, logging, higiene de identidad de agentes, feature flags y una rama de pre-prod para que los prototipos no puedan tumbar producción). Y la carga de la higiene es tuya: prueba todo antes de que el stack avance por la mañana, mantén los PR pequeños y legibles porque el equipo copia lo que envías, y nunca asignes revisores a código que no has leído. Espera que te bajen los humos; hazlo de todos modos.

La gran idea: la ingeniería forward-deployed nunca fue un solo trabajo. Natalie Meurer, Head of Agent Engineering en Sierra y ex Palantir, rastrea el rol añada por añada (DevOps más integración de datos en 2008-2012, dashboards personalizados de Slate en 2016, habilitación de plataforma sobre Foundry en 2020), con cada era apilando nuevas responsabilidades encima en vez de reemplazar las viejas.

Por qué importa: el FDE está de pronto en todas partes en 2026. Google anunció un impulso de contratación de customer engineers para GCP, OpenAI montó una unidad fuertemente financiada para su empuje corporativo de IA, y la oferta de trabajo compuesta ahora exige ocho años como staff engineer, seis años de ventas directas y cuatro años como arquitecto de soluciones. El secreto sucio de Meurer: ese candidato no existe.

Cómo funciona: el único hilo que recorre cada añada es la responsabilidad ante el cliente, ya sea que el trabajo sea DevOps, integración de datos, solucionado personalizado o habilitación. Ahora que los agentes de programación hacen barato disparar un prompt y recibir algo estupendo de vuelta, los FDE pueden construir soluciones de extremo a extremo en lugar de solo prototipar, y los ingenieros de producto se vuelven más de cara al cliente a cambio. En Sierra, las líneas se están difuminando activamente.

Qué robar: entrevista a los candidatos de ingeniería deployed por añada (2008 siendo "estabilidad de plataforma con toques de pánico") y contrata generalistas que sean dueños de los resultados del cliente en vez de esperar un currículum unicornio. Además un spoiler para cualquiera que esté construyendo una plataforma de dashboards: un dashboard que no puede escribir de vuelta en su fuente de datos pierde valor con el tiempo.

El truco: el pricing basado en resultados es hacia dónde Meurer dice que se dirige la mayor parte de este mercado. El pricing por asiento encaja cuando el producto apenas es dueño del resultado, el basado en uso (lo que le pagas a los proveedores de modelos base) queda en medio, y los agentes empujan hacia pagar por consultas resueltas y ventas cerradas. Grafica los cuatro modelos, uso, resultado, meta e híbrido, en una cuadrícula de autonomía del agente frente a atribución, acreditando el análisis de 'outcomemaxxing' de Sierra. Pero alguien tiene que garantizar el resultado, y ese trabajo es la ingeniería forward-deployed. De ahí su cierre: el FDE ha muerto, larga vida al FDE.

La gran idea: En Decagon, la ingeniería forward-deployed y la ingeniería de producto son la misma disciplina: el mismo nivel de exigencia, la misma estructura de reporte, a menudo las mismas personas. Cada punto de dolor que un cliente Fortune 500 plantea en el campo se trata como una funcionalidad de producto que se construye una sola vez para todos.

Por qué importa: Los equipos de campo de todas partes sienten la tentación de improvisar (prompt-hack) un arreglo puntual para una cuenta exigente. Rekhi sostiene que la habilidad escasa en la era del AI-coding es la contención: resolver el problema del cliente A de una forma que llegue a B, C, D y E antes incluso de que lo expresen.

Cómo funciona: Decagon opera dos vías de forward-deployment. Los agent builders configuran el "cerebro del agente" de servicio al cliente de cada empresa (instrucciones, tono, acciones, reglas de traspaso a humanos), en gran parte dentro de la UI. Los mejores contribuidores están en primera línea de las peticiones de producto y elevan las solicitudes recurrentes a capacidades de plataforma para todos los clientes.

Los números: Decagon pasó de unos 50 empleados a 500 en un año, lo que obligó a dividir el antiguo rol de agent software engineer todoterreno en esas dos especialidades. Y tras construir a mano su integración de CRM número 26 a medida, el equipo productizó integraciones self-serve en bloque y dejó de escribir código a medida. En un caso de estudio de Chime sobre Decagon Voice, Rekhi reportó un 70% de resolución en chat y voz, un 60% menos de costes de soporte al cliente y una satisfacción de miembros 2x, con la COO de Chime, Janelle Sallenave, atribuyéndolo a la memoria multicanal.

Qué robar: Fija las métricas de éxito, los canales de soporte y los resultados durante el scoping del acuerdo, antes de construir. Dota a los acuerdos de expertos verticales que hablen el idioma del cliente. Demuestra valor rápido en una porción estrecha y de alto impacto, y luego expande hacia alianzas de varios años. E ingiere datos históricos de soporte para poder aconsejar a los clientes qué automatizaciones ofrecen el mayor ROI, incluso cuando eso no es lo que pidieron.

El truco: Los agentes que degeneran en una caja negra de prompts son demasiado frágiles para que los clientes se hagan cargo. Cada solución manual que realiza un ingeniero es un vacío de producto: si el arreglo no vuelve al producto self-serve, todo el movimiento de forward-deployment deja de escalar.

La gran idea: Las ganancias de productividad con IA no vienen de las herramientas: vienen de rediseñar intencionadamente cómo trabajan los equipos. Liguori repasa tres experimentos internos de Amazon, desde un equipo pathfinder de elite en Bedrock hasta un sprint de Prime Video y un piloto de 50 equipos en Stores, y destila lo que separó a los equipos que despuntaron en cinco hábitos diarios que llama ingeniería de frontera.

Por qué importa: En el piloto de Stores, la mitad de los 50 equipos vio ganancias por debajo de 3x en velocidad de despliegue, mientras que la otra mitad alcanzó una mediana de 4,5x (algunos superando 10x) con aproximadamente el 90% de ellos usando el mismo tooling interno, incluido Kiro. Los perdedores espolvorearon IA sobre su flujo de trabajo existente; los ganadores cambiaron el flujo de trabajo en sí.

Cómo funciona: Los cinco hábitos son: invertir en el contexto del agente (cada error del agente se convierte en una actualización de las skills y los steering files), ir más despacio para ir más rápido (arreglar los mensajes de error, construir servidores MCP, reestructurar bases de código, con algunos equipos incluso pasando de JavaScript a TypeScript o Rust para obtener feedback del compilador), alimentar a los agentes en lugar de vigilarlos (dar un objetivo más criterios de auto-validación, no una conversación continua), hacer la intención explícita (iterar sobre un documento de especificación antes del código, el flujo que Kiro construye), y desplazar las pruebas hacia la izquierda (linters, pruebas unitarias y de integración, y servicios mock deterministas ejecutados localmente que dan a los agentes bucles de feedback rápidos).

Los números: Seis ingenieros (incluidos dos Distinguished Engineers) construyeron Bedrock Mantle, un plano de datos de inferencia completamente nuevo, íntegramente con Kiro en 76 días, elevando los commits semanales 20x hasta 40 desde dos, frente a una estimación original de 30 personas durante 18 meses. Un equipo de Prime Video de seis personas recortó una estimación de proyecto de 90 semanas a 24 semanas en un sprint de 10 días. La meta de Amazon para 2026 es escalar la ingeniería de frontera de 50 equipos piloto a los siguientes 2.000.

El truco: Casi todos los equipos de alto rendimiento primero se volvieron más lentos mientras invertían en fundamentos, y los líderes que exigen velocidad de features inmediata matan la transición. El riesgo de burnout es real: los ingenieros afinan prompts hasta altas horas de la noche, los agentes en paralelo elevan la carga cognitiva, y los ingenieros junior encuentran más difícil revisar la salida de la IA que escribir código. Una vez que el código lleva semanas en lugar de meses, la toma de decisiones y las aprobaciones de lanzamiento se convierten en el nuevo cuello de botella.

Qué robar: Audita si estás vigilando a tu agente o alimentándolo con tareas con un listón de calidad contra el que pueda auto-validarse. Empieza con un solo equipo pathfinder en lugar de un despliegue amplio, presupuesta la caída de productividad, y poda las reglas obsoletas de los steering files a medida que mejoran los modelos: los do-nots escritos para las peculiaridades de Sonnet 3.7 eran en su mayoría innecesarios en Opus 4.5.

La gran idea: Leo Mehr, que hizo crecer la organización de ingeniería forward-deployed de Ramp de dos ingenieros a unos treinta en dos años y medio, reduce la disciplina a dos principios: siempre estar haciendo scoping, y escalar con tokens. En Ramp, el FDE se sitúa dentro de ingeniería y endurece el producto central para los mayores clientes empresariales; no es, según él, una especie de evolución "modo jefe" del go-to-market técnico.

Por qué importa: los dos principios solo funcionan juntos. Un equipo que hace scoping sin piedad pero nunca construye sistemas agent-native es superado por competidores que sí lo hacen; un equipo que vierte tokens en peticiones mal planteadas simplemente quema cómputo en el trabajo equivocado. La afirmación de Mehr es que el futuro del rol de FDE requiere ambos a la vez.

Cómo funciona: cuando un comercial escribe un viernes por la noche insistiendo en que un logo estratégico solo cerrará con una integración de SAP S/4HANA, el FDE entrenado hace una pausa en lugar de ir a por la documentación de la API. ¿Es el cliente quien impulsa la urgencia, o una cuota de fin de trimestre? ¿Quién lo usaría realmente? ¿Hay soluciones manuales? ¿Puede el cliente usar las APIs existentes? ¿Necesitan esto también otros prospectos del pipeline? Solo entonces decide qué construir.

Qué robar: el intake agent de Ramp. Los comerciales publican los bloqueos en un canal interno de Slack "FDE requests" respaldado por un flujo de trabajo de Notion, y la calidad de las peticiones varía enormemente: algunas detalladas, otras de una sola línea. Un agente de Notion V1 que simplemente leía cada petición y hacía un par de preguntas aclaratorias demostró su valía en cuestión de semanas; la versión actual ejecuta varias rondas de ida y vuelta con el remitente hasta que juzga que la petición está lista para convertirse en un ticket.

Los números: la latencia de respuesta a las nuevas peticiones cayó de horas o días a segundos, y Mehr estima que el agente ahorra alrededor del veinte por ciento del tiempo que el equipo dedicaba al scoping. Mientras tanto, los modelos de frontera ya pueden resolver de un tirón (one-shot) features de tamaño medio, así que el último paso del pipeline (de una especificación bien formada a un producto funcional) sigue volviéndose más fácil.

El truco: el medio del pipeline sigue siendo enrevesado y sin forma, y exige invertir en agent harnesses, rúbricas de calidad, feedback humano y meter el contexto adecuado (datos históricos, conocimiento del producto, skills, memorias, herramientas) en cada llamada al LLM. Los fallos de scoping también siguen siendo caros: Ramp una vez tuvo a dos FDEs aprendiendo iOS y Android para enviar una feature de reembolso móvil en ambas plataformas, solo para descubrir que el cliente exigía dispositivos solo iOS. Y sea lo que sea que produzcan los agentes, el FDE mantiene la responsabilidad final sobre el gusto y el criterio.

La gran idea: Fable, que se despliega el mismo día de la charla, es el momento en que el tutorial termina y empieza el mundo abierto: un modelo cuya amplitud pura exige una nueva forma de trabajar. Thariq Shihipar, de Anthropic, comprimió una serie de blog planificada en una guía de campo de cuatro partes: libera a Claude, encuentra tus incógnitas, lidia con el duelo y sé irrazonable.

Por qué importa: los modelos se vuelven más inteligentes de formas irregulares, y tu harness solo refleja tu entendimiento actual de ellos. GPT-4 no pudo nombrar los dos Pokemon cuyos nombres terminan en '-aw' aunque conoce a todos los Pokemon; Claude, con una herramienta de ejecución de código, simplemente obtuvo la lista completa y la filtró con un script. Ese exceso de capacidad significa que lo posible puede cambiar de la noche a la mañana, si sabes dónde mirar.

Cómo funciona: las mejores prácticas de prompting no dejan de invertirse. La era de Sonnet 3.5 premiaba prompts de sistema pequeños con muchos ejemplos; los modelos más inteligentes premiaban prompts grandes, cargados de instrucciones, con muchas herramientas; los modelos de clase Fable quieren menos de nuevo: menos ejemplos (restringen a un modelo más imaginativo que tus ejemplos), menos reglas de 'no hagas', y contexto sin sobrerrestricción. El mismo arco produjo al propio Claude Code: herramientas como bash superan a pegar toda una base de código, porque el modelo construye y busca su propio contexto. Claude Chat ahora extiende eso a trabajo proactivo y multijugador donde Claude se despierta a sí mismo.

Qué robar: tu prompt es un mapa, pero el territorio es la base de código real, y Fable recorre lo suficiente como para toparse con cada vacío que nunca especificaste. Las contramedidas de Shihipar: haz que Fable haga una pasada de orientación sobre una base de código desconocida y apúntalo a fuentes de contexto como Git y Slack; haz lluvia de ideas de prototipos HTML muy distintos para fijar el gusto de lo-sé-cuando-lo-veo; pide al modelo que te entreviste para extraer restricciones implícitas; dale código de referencia (incluso en otro lenguaje) como un mapa ya hecho; haz que registre incógnitas a mitad de ejecución para que veas dónde mutaron las decisiones; y deja que te examine después para que aún puedas representar el trabajo.

Los números: se eliminó cerca del 80 por ciento del prompt de sistema de Claude Code. Dos de unos mil Pokemon terminan en '-aw', la prueba que GPT-4 reprobó y que Claude, equipado con herramientas, aprobó. El propio deck de la charla se construyó con Fable en unas cuatro horas la noche anterior.

El detalle: construir es más fácil, pero generar valor sigue siendo difícil: requiere muchos intentos, y los ingenieros de IA sobrevaloran el proceso y las configuraciones. También hay un duelo real: el trabajo que tomaba semanas ahora toma horas, lo que significa perder la depuración de madrugada, el modelo mental de una base de código rotado a mano, las victorias y los fracasos. Su veredicto: no hay vuelta atrás, y la única salida es a través.

La gran idea: Los LLM basados en texto asombraron incluso a un veterano del NLP con 30 años de experiencia, pero aún solo describen el mundo. Christopher Manning sostiene que el camino hacia la AGI encarnada pasa por los world models, y Moonlake AI los construye poniendo código debajo de escenas 3D reconstruidas en lugar de generar píxeles más bonitos.

Por qué importa: Aprender políticas de robots directamente en el mundo real es brutalmente lento: los esfuerzos al estilo QT-Opt de Google X se apoyaron en aproximadamente 10.000 horas de teleoperación humana. Un simulador con estructura causal real permite a los robots planificar, entrenar y transferir a la realidad de forma barata, reviviendo ideas de world models que van desde Kenneth Craik en los años 40 hasta el robot Shakey de SRI.

Cómo funciona: Moonlake toma una imagen o un video corto, separa el fondo de los objetos manipulables y genera código que renderiza cada objeto y sus propiedades. Un bucle agéntico (escribir código de renderizado, comparar el render con la realidad física, revisar) afina la fidelidad, mientras que las búsquedas web al estilo RAG recuperan hechos ocultos, como las bolsitas de té dentro de una caja de té cerrada. El resultado es neurosimbólico: verificable, editable y controlable de formas que los modelos de video de profundidad de píxel como Genie 3 no son.

Los números: Google ya tenía un modelo de lenguaje de 2 billones de tokens en 2007, el mismo orden de magnitud que los runs actuales de 15 billones de tokens. La escala llegó mucho antes que la arquitectura. En el lado de la robótica, Manning contrasta 10.000 horas de teleoperación pagada con 10.000 horas de experiencia simulada generada esencialmente gratis.

Qué robar: Juzga un simulador por el problema que resuelve, no por los píxeles que dibuja. Una escena 3D recorrible a partir de una sola imagen está bien para hacer turismo, pero un robot que debe abrir la caja de té necesita semántica y código debajo de cada objeto relevante. Y salta la fidelidad total: como los world models humanos, simula solo las partes del mundo que la tarea realmente necesita.

El truco: El video generativo se ve lo bastante bien como para confundirse con comprensión, y Manning advierte que esos píxeles no dan base para planificar. La transferencia sim-to-real solo funciona cuando la simulación captura el detalle causalmente relevante, que es precisamente la parte difícil. El software de Andreessen nunca se comió el mundo físico; la simulación verificable y potenciada por código es la apuesta de Moonlake sobre cómo finalmente lo hace.

La gran idea: Las apps hechas por bots comparten las mismas señales delatoras: degradados morados, encabezados en cursiva, "scroll to explore", botones de píldora en mayúsculas, logos con degradado, spam de emojis. El arreglo de El Mghari es nombrar esas señales explícitamente (dice que puedes listar entre 20 y 30 de ellas) y prohibirlas en las instrucciones que tus agentes llevan a cada proyecto.

Por qué importa: Envía alrededor de diez apps de IA al año, varias con enorme alcance, y atribuye el diseño y la UX, no la amplitud de features, como el impulsor número uno de la adopción. Dedicar un 10-20% extra de esfuerzo a la UI, sostiene, es ahora una ventaja competitiva seria porque los usuarios detectan una página generada por IA en cuestión de segundos.

Cómo funciona: Su skill de diseño, Hallmark, hace dos cosas: "slop gates" que le dicen a los modelos qué no hacer nunca, y packs de temas curados inyectados como contexto para que el modelo diseñe a partir de buenas referencias en vez de sus opciones por defecto. Las landing pages de un tiro (one-shot) con Hallmark salen visiblemente más limpias que las generaciones sin asistencia, dándote una base creíble desde la que iterar.

Qué robar: Mantén un baúl de inspiración con capturas de pantalla y pega varias en cada prompt de diseño. Escribe briefs de dos a tres párrafos (él graba notas de voz de 1 a 3 minutos) que cubran el usuario, el layout, los componentes y las referencias. Persiste tu gusto en un archivo agents.md o de skill. Levanta la base con un modelo pesado, luego itera una o dos features a la vez con un modelo abierto rápido.

Los números: 85.000 usuarios probaron su creador de logos y 8.000 su generador de subtítulos; Hallmark atrajo a más de 10.000 usuarios en unas seis semanas. En un A/B en vivo, solo cuatro manos eligieron correctamente la landing page de GLM 5.2 sobre la de Claude Opus 4.8, y la versión de Opus costó cinco veces más y corrió más lento.

El truco: La iteración barata solo funciona si el modelo pequeño es genuinamente bueno en diseño. GLM 5.2 superó ese listón para él solo hace poco. Y ningún archivo de skill reemplaza el bucle humano: lo que sea que produzca el agente es andamiaje, y el pulido en el espaciado, los logos, los estados de carga y el movimiento corre por tu cuenta.

La gran idea: Casi todas las métricas populares de ingeniería de IA son un espejismo. Los panelistas reportaron que el gasto en tokens, el volumen de uso de agentes y la densidad de power-users correlacionaban con más líneas de código, pero ninguna de ellas correlacionaba con una entrega de proyectos más rápida. Lo único que sí lo hizo: si ya existían prácticas de ingeniería sólidas y bucles de validación deterministas en la base de código.

Por qué importa: Los equipos que apuestan todo por el código generado por IA se enfrentan a un problema de slop. La empresa de uno de los panelistas ha enviado software 100% generado por IA durante nueve meses, y admitió que los primeros dos o tres meses fueron slop hasta que hicieron del mantenimiento de la calidad un esfuerzo metódico y activo. Si se deja sola, la calidad de la base de código se degrada.

Cómo funciona: El equipo de uno de los panelistas instrumentó más de 150 bucles de validación deterministas dentro de las bases de código y los agregó en una puntuación de preparación para agentes (agent readiness score); las bases de código que puntúan en el nivel cuatro o cinco se comportan como lenguaje-natural-a-software con tasas de error muy bajas. En Vercel, los ingenieros senior incrustan su gusto tácito en skills y herramientas internas, lo comparten en las office hours de ingeniería e impulsan una cultura donde borrar y simplificar código gana a añadirlo.

Qué robar: Trata la calidad del agente como un problema de datos, no de tono. Construye una capa de contexto que seleccione las fuentes adecuadas, las resuma y pase el resultado por comprobaciones antes de que llegue siquiera al agente. Luego instrumenta todo (latencia, recuperación de contexto, cuándo el agente elige hacer preguntas y dónde los usuarios chocan con la fricción) y optimiza sin piedad, porque te conviertes en lo que mides.

Los números: más de 150 bucles de validación deterministas instrumentados por base de código; ratios de prompt-caching objetivo de 96-98%; nueve meses de software totalmente generado por IA, con los primeros dos o tres meses produciendo slop.

El truco: Nada de esto se autosostiene. Los agentes son sistemas extremadamente sensibles, e incluso las personas inteligentes y con gusto derivan sin una instrumentación rigurosa, y si alguien quiere enviar basura, las pruebas estáticas y los escáneres de IA por sí solos no lo detendrán. Los humanos con gusto permanecen en el bucle.

La gran idea: los agentes de navegador son agentes de código disfrazados. La plataforma de Browserbase trata el navegador como un sistema completo (almacenamiento, cómputo, un motor de nodos) para que los agentes escriban y ejecuten código contra él en lugar de solo hacer clics.

Por qué importa: la mayor parte del trabajo de conocimiento ocurre en la web, y los agentes de hoy son mucho mejores en los benchmarks de código que en tareas del mundo real. Darle un navegador a los agentes de código es la apuesta de Browserbase para cerrar esa brecha: pasar de la recuperación de datos a completar transacciones de verdad.

Cómo funciona: un agente de demo llamado "Feed Myself" inició sesión en Uber Eats con las credenciales y el método de pago guardados del presentador, volvió a pedir su última comida de The Bird y realizó el pedido de principio a fin. Cada paso produjo una traza completa: el razonamiento del agente, sus llamadas a herramientas y los scripts de Playwright que ejecutó contra el navegador, junto con una minivista en vivo de exactamente lo que el agente veía.

Qué robar: plantea las tareas de navegador como flujos de trabajo impulsados por código, no como secuencias de clics. Una segunda demo le dio al agente un login guardado y le hizo resolver el problema Two Sum de LeetCode enteramente en el navegador (escribiendo el código, ejecutándolo y enviándolo), prueba de que un solo harness cubre tanto los recados como la ingeniería.

El detalle: la única diapositiva de la charla contrastaba SWE-bench con el remote labor index, un benchmark más duro de entregables reales como archivos, presentaciones y exposiciones de trabajo, donde las tasas de resolución siguen siendo mucho más bajas. Las demos muestran una dirección para automatizar el trabajo de conocimiento, no una capacidad terminada.

La gran idea: los agentes no se detendrán en escribir código de aplicación: provisionarán y gestionarán la infraestructura que hay debajo. Un ponente de Neon dijo que entre el 80 y el 90 por ciento de las bases de datos de la empresa ya son creadas o gestionadas de alguna forma por agentes a través de Claude Code y plataformas como Replit, lo que significa que la infraestructura tiene que volverse legible para las máquinas: un archivo declarativo de infraestructura como código que le diga al agente exactamente qué existe antes de gastar un montón de llamadas a herramientas en descubrirlo.

Por qué importa: el debate CLI contra MCP pasa por alto que la mayor parte de la fricción de los agentes es la recopilación básica de contexto: averiguar qué hay en tu cuenta de Vercel o en tu proyecto de Neon. Una configuración concisa y codificada colapsa ese paso. Y el stack clásico de IaC (Terraform, Pulumi, SST) es demasiado pesado para equipos que envían SaaS en TypeScript al estilo Vercel; el ponente sostuvo que este espacio necesita algo más ligero y nativo de TypeScript.

Cómo funciona: el flujo de trabajo es CLI primero. "neon link" vincula un espacio de trabajo local a un proyecto remoto de Neon y trae sus variables de entorno directamente a .env. Luego declaras tu stack en un pequeño archivo neon.ts: bases de datos Postgres, Neon Auth (construido sobre Better Auth), buckets de almacenamiento de objetos compatibles con S3. Ejecutar "neon deploy" (alias "neon config apply") compara la declaración con el proyecto remoto, provisiona lo que falte y refresca .env con exactamente las nuevas variables que necesitan los recursos.

Qué robar: el truco del env tipado. Importa la configuración neon.ts a la función parseEnv de neon-env y obtienes variables de entorno tipadas para coincidir con precisión con lo que provisionaste: las variables del bucket solo existen si se declara un bucket. La gestión del env sigue siendo una de las superficies más incómodas para los agentes, y tiparlo contra la declaración de la infraestructura cierra el ciclo entre lo que está desplegado y lo que el código espera.

Las cifras: entre el 80 y el 90 por ciento de las bases de datos de Neon están provisionadas o gestionadas por agentes, y toda la demo en vivo (vincular un proyecto, declarar auth y un bucket de avatars, desplegar, obtener variables de env tipadas y frescas) cupo en un espacio relámpago de cinco minutos.

El detalle: neon.ts solo cubre la propia superficie de Neon (Postgres, auth, almacenamiento de objetos y una AI gateway que hace de proxy de funciones de Databricks AI Gateway). El ponente ve un hueco en el mercado para una capa de infraestructura genérica en TypeScript y señaló infra.ts.dev, un experimento temprano en esa dirección, con la advertencia explícita de que no está listo para producción.

La gran idea: deja de alquilar modelos de frontera y empieza a ser dueño de los tuyos. Jetashree Ravi, de Fireworks AI, sostiene que las empresas están pasando de Claude y ChatGPT hacia la "inteligencia propia": tratar un modelo de código abierto ajustado como propiedad intelectual propia que mejora continuamente mediante un bucle de entrenar, desplegar, monitorear y reentrenar.

Por qué importa: las facturas de las API de código cerrado se sienten insostenibles para una porción creciente de equipos. Ravi abrió preguntando a la sala quién las encontraba demasiado caras, y se alzaron manos. Mientras tanto los modelos abiertos han cerrado la brecha; sondeó al público sobre GLM 5.2 y lo presentó como rindiendo casi tan bien como Opus.

Cómo funciona: la parte difícil es servir modelos abiertos a escala de producción. La respuesta de Fireworks es FireAttention, un motor de inferencia interno con kernels CUDA personalizados (la capa de traducción entre el modelo y la GPU) afinados por carga de trabajo para alcanzar objetivos específicos de latencia y coste para clientes como Cursor, Uber y Notion.

Qué robar: el volante de inercia, sin importar el proveedor. Ajusta con SFT, reinforcement fine-tuning o DPO; despliega el checkpoint; observa la latencia, el coste y las tasas de acierto de cache en dashboards; recolecta datos de producción; luego reentrena partiendo del checkpoint anterior en lugar de desde cero. La herencia de checkpoints es lo que hace que el bucle se componga.

Las cifras: Fireworks afirma más de 30 billones de tokens procesados al día (antes de GLM 5.2), más de 10.000 clientes y unas 280K solicitudes. Composer 2 de Cursor fue entrenado con la API de entrenamiento de Fireworks y se sirve en la plataforma; un modelo v0 de Vercel alojado allí se cita con 40x mejor latencia; GenSpark ejecuta RLHF en Fireworks para elevar la calidad de la aplicación final.

El detalle: esta es una charla relámpago de siete minutos de un proveedor: cada benchmark y cifra de escala es una afirmación de la propia Fireworks. Y la propuesta misma admite que los modelos abiertos a menudo no funcionan de fábrica; la inteligencia propia solo compensa si inviertes en el bucle de entrenamiento y en el servido a nivel de kernel que las API de modelos cerrados abstraen.

La gran idea: la búsqueda vectorial recupera parecidos; no recuerda. Spectron, una capa de memoria construida sobre SurrealDB, intenta replicar cómo funciona de verdad la memoria humana (formar creencias, consolidarlas y rastrear cómo cambian los hechos con el tiempo) para que los agentes conserven conocimiento duradero entre sesiones.

Por qué importa: casi todos los stacks de agentes olvidan en el momento en que empieza una nueva conversación. Meter el historial en la ventana de contexto quema tokens, y la búsqueda por similitud no tiene opinión sobre qué es verdad. Cuando el ponente preguntó a la sala quién estaba contento con la calidad del agente más allá de la ventana de contexto, se alzó una mano.

Cómo funciona: Spectron ingiere dos tipos de entrada, fuentes autoritativas (PDFs, video, audio, código, JSON) y datos experienciales (cada turno de conversación), y extrae de ambos entidades, verbos, acciones y palabras clave. Procesos en segundo plano modelados sobre el soñar hacen el resto: la elaboración enlaza memorias distintas en nuevas, la reflexión las reevalúa contra entradas externas, la consolidación fusiona creencias duplicadas y la reconciliación retira hechos obsoletos.

Qué robar: trata el tiempo como un hecho de primera clase. Spectron registra el tiempo del sistema para la auditabilidad más un ciclo de vida del hecho (cuándo entró algo, cambió, pasó de incierto a cierto y cuánto tiempo sigue siendo válido), de modo que un CTO que se muda a una nueva empresa se actualiza limpiamente en lugar de corromper la base de conocimiento. Y nunca borres memorias viejas; sustitúyelas para que sobreviva el linaje del cambio.

Las cifras: los clientes manejan cientos de terabytes hasta escala de petabytes de datos transaccionales, y el diseño de memoria compartida apunta a cientos de miles hasta millones de agentes en toda una organización. La integración se presenta como dos líneas de configuración, con hooks para MCP, Claude Code y Codex.

El detalle: esta fue una charla relámpago de cinco minutos, no una sesión de benchmarks; la calidad de recuperación, la latencia y el coste a esa escala quedaron sin demostrar en el escenario. La demo vive en throughthelobby.com/spectron.

La gran idea: cuando cualquiera puede levantar un agente desde Slack, la flota se infla rápido, y la mayoría de esos agentes acaban siendo subóptimos o con errores. La solución de RunLayer es un metaagente llamado Agent Optimizer que audita, depura y afina de forma autónoma a todos los demás agentes de la plataforma.

Por qué importa: RunLayer opera 482 agentes con solo 40 personas, y los equipos internos compiten en un ranking de token-maxing. A esa proporción, nadie puede revisar manualmente cada agente, así que los tokens desperdiciados y las configuraciones rotas se acumulan calladamente en dinero real.

Cómo funciona: con una cadencia semanal, Agent Optimizer recorre los últimos siete días de ejecuciones de cada agente (éxitos y fallos), luego audita su modelo, herramientas provisionadas, conectores MCP, programaciones, adjuntos de memoria y archivos de skills. A partir de ahí sube o baja el tamaño de los modelos, reescribe prompts, desprovisiona herramientas sin usar durante semanas, repara conectores MCP rotos y clasifica las ejecuciones programadas fallidas.

Qué robar: clasifica la automatización por niveles de riesgo. Las correcciones de baja prioridad y bajo radio de impacto se aplican automáticamente; los cambios de riesgo medio y alto surgen como recomendaciones que una persona debe aprobar. Y cada recomendación se vincula a un valor en dólares, lo que hace obvia la priorización y el argumento de negocio.

Las cifras: 482 agentes, 40 personas. Una ventana de revisión de siete días de historial de ejecuciones, una cadencia de optimización semanal, ejecuciones de producción de 15 a 20 minutos por pasada y unos 65.000 dólares de ahorro anual, incluyendo ganancias de productividad.

El detalle: la demo en vivo se simplificó a propósito: un agente de cumpleaños del salón de la vergüenza quemando un modelo de clase frontera solo para enviar felicitaciones. En despliegues reales las decisiones más difíciles siguen enrutándose a las personas, y la cifra de ahorro estrella mezcla estimaciones blandas de productividad junto al gasto duro en tokens.

La gran idea: Exa está construyendo un motor de búsqueda diseñado para la IA y no para las personas: un laboratorio de búsqueda de frontera, según su propia descripción, que es dueño de todo su stack, desde los modelos de embeddings y la base de datos vectorial hasta el rastreo, la extracción y las GPUs por debajo, todo afinado para un contexto de baja latencia y alta relevancia.

Por qué importa: los modelos no pueden absorber toda internet durante el preentrenamiento y quedan estáticos en el momento en que este termina, así que necesitan datos web en vivo para actuar sobre insights reales. El ponente enmarcó el contexto como la mayor palanca sobre el rendimiento del modelo, y las ventanas de contexto sobredimensionadas dañan activamente la calidad mientras elevan la latencia y el coste.

Cómo funciona: la funcionalidad Highlights de Exa invierte el movimiento habitual de recuperación. En lugar de volcar una página entera en el prompt, selecciona computacionalmente los mejores caracteres de esa página para la consulta y devuelve solo esos. Pide el cumpleaños de Einstein y obtienes la única cadena que lo contiene, no todo el artículo de Wikipedia. Los laboratorios ya están alimentando esa salida sin relleno en pipelines de RL y post-entrenamiento.

Las cifras: se retó a Exa Agent (un harness de modelo ajustado montado sobre estos primitivos de búsqueda) a conectar a Marc Andreessen con Kevin Bacon con una fuente de dominio distinta por paso, con IMDb y el Oracle of Bacon prohibidos. Devolvió un camino de tres grados (Andreessen a Rogan a Hartman a Bacon) en 42 segundos, citando evidencia tan específica como el episodio de Saturday Night Live (temporada 16, episodio 12) donde Hartman y Bacon aparecieron juntos. El ponente estimó que la misma tarea le habría costado un día entero.

Qué robar: optimiza para la eficiencia en tokens, no para el token maxing. Y al evaluar agentes de búsqueda, usa tareas desde cero que prohíban redes precalculadas y exijan una fuente citada distinta para cada salto: fuerza un razonamiento verificable de varios pasos en lugar de consultas a una base de datos.

El detalle: las victorias probadas de hoy se agrupan en nichos: inteligencia GTM, finanzas, código y datos de RL. El agente de búsqueda generalista que maneja cualquier consulta compleja sigue siendo una apuesta a que los modelos sigan mejorando, no una realidad ya entregada.

La idea central: MiniMax construyó su modelo más reciente, M3, para ser multimodal desde el primer paso literal del entrenamiento y para cargar una ventana de contexto de un millón de tokens, impulsada por una arquitectura propia que el laboratorio llama MiniMax Sparse Attention.

Por qué importa: Un millón de tokens de contexto eficiente desbloquea el razonamiento sobre bases de código completas y la comprensión de videos más largos, y MiniMax presenta las capacidades de programación y agénticas de M3 como un reemplazo local de los modelos de código cerrado. El laboratorio también opera modelos de lenguaje, de generación de video y de voz bajo un mismo techo, y quiere fusionar esas modalidades en aplicaciones agénticas más capaces.

Cómo funciona: La atención dispersa corre en dos ramas. Una rama de índice ligera hace una pasada barata de atención completa para señalar qué tokens del contexto realmente importan; una rama dispersa luego realiza el cómputo pesado de KV solo sobre esos tokens seleccionados, evitando el costo n al cuadrado de la atención estándar. El diseño se codesarrolló deliberadamente entre los equipos de algoritmo e infraestructura, con la eficiencia de decodificación como objetivo de primera clase.

Qué robar: Dos ajustes hicieron que la atención dispersa funcionara con Grouped Query Attention. Primero, múltiples cabezales KV terminaban seleccionando exactamente los mismos tokens, así que el equipo eliminó la agregación de las salidas de la rama de índice para preservar la diversidad por cabezal. Segundo, cambiaron de recuperación a nivel de token a nivel de bloque porque las GPU prefieren el acceso a memoria contiguo, recortando la sobrecarga y mejorando la relación entre cómputo y acceso a memoria.

La trampa: El trabajo previo no se transfirió limpiamente. La atención dispersa de DeepSeek existe, pero no se mapea sobre arquitecturas basadas en GQA, que es justo el desajuste que MiniMax tuvo que resolver por ingeniería. Del lado multimodal, las opciones fáciles también fallaron: inyectar visión después del preentrenamiento, después del decaimiento o justo antes del post-entrenamiento rindió por debajo. Solo entrenar con imágenes y video desde el paso cero produjo mapas de atención donde los tokens de texto genuinamente atienden a los tokens de imagen.