En el YC Startup School de 2026, la voz de Jeff Dean sonaba un poco ronca.
Al comienzo de la entrevista, explicó que tenía afonía y que hoy sonaría diferente a lo habitual. Pero eso no afectó la atención del público. Sentada frente a él, la socia de YC, Diana Hu, enumeró de un tirón una serie de nombres que podrían entrar en la historia de la informática: MapReduce, BigTable, TensorFlow, TPU, Gemini.
Cualquiera de esos proyectos sería suficiente como obra representativa de la carrera de un ingeniero. Sin embargo, todos aparecen concentrados en el currículum de Jeff Dean y de un grupo de ingenieros de Google a su alrededor.
Diana no convirtió la entrevista en un repaso de logros. Le interesaba más otra cuestión: cuando la IA generativa ya ha arrasado la industria del software, ¿en qué está fijándose hoy alguien como Jeff Dean, que es experto en reestructurar sistemas desde la base?
La respuesta no son modelos más grandes.
En esta conversación de casi una hora, Jeff Dean habló repetidamente de hardware de inferencia, energía, movimiento de datos, ingeniería de contexto, agentes de larga ejecución, sistemas de experimentación automatizada y de cómo las startups pueden evitar el choque frontal con los modelos generales. Lo que expuso parece disperso, pero en el fondo hay una línea muy clara: la siguiente fase de la IA no consiste solo en entrenar modelos más inteligentes, sino en integrarlos en un sistema que pueda trabajar a largo plazo, probar y errar continuamente, validar automáticamente y acumular capacidades de forma constante.
Esto también significa que la competencia en IA está pasando de «quién tiene el modelo más grande» a «quién puede organizar mejor la inteligencia».
一、La IA ya es como un ingeniero junior, pero ese no es el cambio más importante
En mayo de 2025, Jeff Dean hizo una afirmación que generó un amplio debate: la capacidad de la IA ya se acerca a la de un ingeniero junior.
Un año después, Diana le preguntó cómo había resultado esa predicción.
La respuesta de Jeff Dean fue directa. Cree que la afirmación fue «bastante acertada». Los avances de los modelos en cuanto a su capacidad para actuar como agentes, codificación de flujos largos y tareas complejas han sido incluso más rápidos de lo que él esperaba entonces.
«La capacidad de los modelos para completar tareas cada vez más complejas está creciendo más rápido de lo que yo anticipaba», dijo.
Lo más notable es que esta capacidad ya no se limita a escribir código. Cada vez más sistemas de agentes están entrando en campos científicos, de ingeniería y otras áreas profesionales. No solo responden preguntas, sino que descomponen tareas, usan herramientas, ejecutan experimentos, leen resultados y actúan en base a la retroalimentación.
Comparar la IA con un ingeniero junior puede hacer que la atención se centre en la sustitución de mano de obra. Pero a Jeff Dean le interesa más otro cambio: cuando un «ingeniero junior» se puede replicar en decenas o cientos de instancias, trabajando en paralelo durante días o incluso semanas, ¿cómo cambiará la forma de organizar la producción?
En un equipo tradicional, un ingeniero junior necesita familiarizarse con el negocio, entender las herramientas y recibir retroalimentación constante. Un agente también. Solo que su material de formación no son solo documentos, sino instrucciones (prompts), especificaciones de herramientas, archivos de habilidades, sistemas de pruebas, evaluadores y todo el entorno de contexto.
Esto crea una nueva división en la ingeniería de IA.
Antes, los ingenieros se centraban principalmente en escribir código. En el futuro, más ingenieros se encargarán de definir problemas, configurar entornos, escribir especificaciones, diseñar bucles de retroalimentación y coordinar un grupo de agentes para completar tareas.
La predicción de Jeff Dean para 2027 va en esa línea. Cree que los sistemas de aprendizaje automático participarán cada vez más en la mejora de los propios sistemas de aprendizaje automático. Descompondrán objetivos en subproblemas, ejecutarán automáticamente multitud de experimentos, compararán resultados y combinarán soluciones efectivas para formar nuevos sistemas más potentes.
«Siempre que exista un objetivo medible en un campo, hay una oportunidad de lograr un gran progreso.»
Esta frase es la primera clave de toda la entrevista.
Lo primero que atacará la automatización de la IA no serán necesariamente los campos con más conocimiento, sino aquellos donde la retroalimentación sea más clara. Si el código pasa las pruebas, si el layout de un chip reduce el área, si la arquitectura de un modelo mejora la precisión, si las propiedades de un material cumplen los requisitos... todas estas preguntas tienen criterios de evaluación relativamente claros. Mientras el evaluador sea suficientemente fiable, la máquina puede experimentar repetidamente a una frecuencia muy alta.
Por lo tanto, la unidad realmente importante en la era de la IA podría dejar de ser una respuesta única, sino un ciclo completo: proponer una solución, ejecutarla, medir los resultados y corregir el rumbo.
二、Lo que cambió la búsqueda de Google fue un problema de aritmética
Muchos de los trabajos representativos de Jeff Dean parten de un inicio muy sencillo: primero calcular los órdenes de magnitud.
En 2001, la búsqueda de Google aún dependía en gran medida de los discos duros. Estos tenían mucha capacidad, pero un acceso lento. Jeff Dean y Sanjay Ghemawat hicieron un cálculo y descubrieron que el índice de búsqueda completo de Google en ese momento ya podía caber en la memoria de todos sus servidores.
Hoy suena como una simple actualización del medio de almacenamiento. Pero en aquel entonces, significaba un diseño de sistema completamente diferente.
Si el índice residía principalmente en el disco duro, las consultas requerían esperar a la búsqueda mecánica. Al poner el índice en la memoria, la latencia de acceso caía en picado. Los dos escribieron rápidamente una nueva versión y la pusieron en producción en cuestión de días. La búsqueda de Google se volvió notablemente más rápida.
Esta historia se puede embellecer fácilmente como un destello de genialidad. Pero la explicación de Jeff Dean se parece más a la de un ingeniero que expone algo de sentido común: las condiciones del sistema han cambiado, una solución que antes no era viable de repente lo es, así que deberíamos recalcular.
Muchas innovaciones en la industria ocurren en esos momentos.
Un viejo problema persiste durante mucho tiempo y la gente se acostumbra a aplicar parches. Luego, el precio del hardware, la capacidad de memoria, el ancho de banda de la red o la capacidad de los modelos cruzan un punto de inflexión y las restricciones anteriores desaparecen. Pero la mayoría sigue usando la arquitectura antigua porque se ha convertido en sentido común.
Lo que Jeff Dean hace bien es volver a convertir el sentido común en una hipótesis.
Se pregunta: ¿por qué tiene que ser así? ¿Siguen siendo los órdenes de magnitud de hoy los mismos que los de ayer? Si reemplazamos el paso más costoso, ¿adquirirá el sistema entero una forma completamente diferente?
Este es también su consejo para los emprendedores. No mires solo dónde fallan las soluciones actuales, sino replantea el problema desde los primeros principios. ¿Se puede mejorar el rendimiento en un orden de magnitud? ¿Se puede reducir el coste en dos órdenes de magnitud? ¿Se puede dejar de seguir el camino de implementación por defecto de la industria?
«A veces, solo necesitas entrecerrar los ojos para ver un problema, no dejarte anclar por las soluciones de hoy, sino pensar desde los primeros principios cómo debería resolverse.»
Esta frase no suena misteriosa. Lo realmente difícil es que, una vez que la mayoría entra en una industria, aprende rápidamente todas las respuestas por defecto de esa industria. La experiencia ayuda a la eficiencia, pero también hace que se pierda la capacidad de volver a preguntar.
三、Tres minutos de voz, ¿por qué dieron lugar a un TPU?
En 2013, el reconocimiento de voz por aprendizaje profundo de Google empezó a superar claramente a los sistemas antiguos. La tasa de error se redujo a la mitad, equivalente a condensar en unos meses los avances de veinte años en reconocimiento de voz.
El equipo de producto, por supuesto, estaba entusiasmado. Pero Jeff Dean primero hizo unos cálculos.
Si el reconocimiento de voz realmente mejoraba, los usuarios lo usarían más. Suponiendo que cada usuario de Google usara solo tres minutos de reconocimiento de voz al día, ¿cuántos servidores necesitaría Google para soportarlo?
El resultado no era optimista. Según la eficiencia de las CPU de la época, Google podría necesitar duplicar su flota de servidores.
Este fue el origen del TPU.
No surgió porque al equipo de investigación se le ocurriera de repente fabricar un chip, ni para demostrar que Google podía hacer hardware, sino porque un modelo exitoso estaba a punto de generar un costo de servicio insostenible.
Esta historia revela una regla a menudo ignorada en los productos de IA: mejorar la efectividad del modelo no siempre reduce los costes. Al contrario, cuanto mejor funciona, mayor es su uso y mayor la presión sobre el sistema.
Cuando el reconocimiento de voz no funcionaba bien, los usuarios rara vez lo usaban. El costo del sistema no era un problema. Cuando la tasa de error cae drásticamente, la demanda se libera de repente y las limitaciones de capacidad de cómputo que antes estaban ocultas salen a la superficie.
El camino que eligió el TPU fue crear hardware especializado para el patrón computacional más central del aprendizaje automático. No necesitaba ejecutar navegadores ni procesar todos los programas generales. Se especializaba principalmente en álgebra lineal densa de baja precisión. Este tipo de cálculo está justo en el centro del aprendizaje automático moderno.
La primera generación de TPU finalmente aportó beneficios de un orden de magnitud. Según Jeff Dean, era entre 30 y 80 veces más eficiente energéticamente que las CPU y GPU de la época, y la latencia era entre 20 y 30 veces menor.
Aquí también hay una escala de diseño que a menudo se pasa por alto.
El TPU era muy especializado, pero no tanto como para ejecutar solo un modelo fijo. El equipo sabía que los algoritmos de aprendizaje automático seguirían cambiando rápidamente, por lo que diseñaron el chip como un sistema de álgebra lineal relativamente genérico. Sacrificó la capacidad de ejecutar Chrome o Word, pero conservó espacio para soportar la evolución futura de los algoritmos.
Este es un equilibrio difícil de alcanzar. Si no es lo suficientemente especializado, los beneficios no son claros. Si es demasiado especializado, cuando el algoritmo cambia, el hardware queda obsoleto.
El juicio de Jeff Dean sobre el hardware de inferencia actual hace eco claramente del TPU de entonces. Cree que la próxima ronda de oportunidades importantes seguirá estando en la especialización, pero el foco se desplazará aún más hacia la inferencia de baja latencia y bajo consumo energético.
«Imagina lo que podrías hacer si la latencia mejorara 50 veces.»
Cuando la respuesta de un modelo tarda una decena de segundos, la gente lo ve como una herramienta de consulta ocasional. Cuando la latencia se acerca a lo instantáneo, puede integrarse realmente en interfaces de usuario, robots, vídeo en tiempo real, sistemas operativos y flujos de decisión continua.
La espera no es un simple problema de experiencia. La espera cambia la forma del producto.
四、El centro de coste de la IA no es el cálculo, sino mover datos
Si hubiera que actualizar para los ingenieros de IA de 2026 la versión de «Números de latencia que todo ingeniero debería conocer», Jeff Dean cree que el foco debería pasar de la búsqueda en disco, los fallos de caché y la latencia de red intercontinental, al flujo de datos dentro del chip.
Los ingenieros necesitan saber: cuál es el ancho de banda de la memoria principal a la memoria en el chip, cuál es el ancho de banda de la memoria en el chip a las unidades de multiplicación, cuánta energía requiere una multiplicación, cómo se interconectan los chips, cómo cae la eficiencia de la red al escalar de 500 chips a 10,000 chips.
Estos números parecen lejanos al producto, pero en realidad determinan qué producto es viable.
Jeff Dean dio una proporción impactante. Realizar una multiplicación matemática requiere aproximadamente un picojulio de energía. Mover datos desde la memoria de alto ancho de banda a la unidad de cómputo puede costar unas 1000 veces más energía.
En otras palabras, la operación costosa en los sistemas de IA actuales muchas veces no es «calcular», sino «traer lo que hay que calcular».
Esto también explica por qué el procesamiento por lotes (batch processing) es tan importante.
Una vez que un conjunto de pesos del modelo se mueve desde la memoria a la unidad de cómputo, si solo procesa un token, todo el costo de mover datos recae en ese único token. Si se procesa simultáneamente un lote más grande, el mismo conjunto de pesos puede servir para más cálculos, y el costo de energía y ancho de banda se diluye.
Pero el procesamiento por lotes entra en conflicto natural con la baja latencia. Para acumular suficientes solicitudes en un lote, el sistema a menudo tiene que esperar. Aumenta el rendimiento agregado (throughput), pero la respuesta a un usuario individual puede ralentizarse.
Por lo tanto, muchos problemas que parecen ser de la capa del modelo son, en realidad, problemas de hardware y sistema. Por qué el entrenamiento usa lotes grandes, por qué la inferencia necesita caché KV, por qué los modelos buscan baja precisión, por qué los sistemas necesitan cuantización… detrás de todo esto están las restricciones de movimiento de datos y energía.
Que Jeff Dean centre últimamente su atención en la inferencia se debe precisamente a que la inferencia es extremadamente sensible a la latencia. Si una tarea de entrenamiento se ralentiza un poco, a menudo solo significa que el experimento tarda más en terminar. Cada segundo extra de espera en una tarea de inferencia afecta directamente a la experiencia del usuario y a la eficiencia de trabajo de un agente.
Si un agente necesita invocar al modelo 1000 veces de forma consecutiva, reducir la latencia individual a la mitad puede suponer una enorme diferencia en el tiempo total de finalización de la tarea. Y no hablemos de futuros agentes que funcionen durante días o semanas.
Por lo tanto, el «problema energético» de la IA no es una cuestión medioambiental lejana. Determina directamente si los modelos pueden servir a más personas de forma económica, si los agentes pueden funcionar de forma continua, y también si el margen bruto de una startup es saludable.
五、El modelo es solo un componente, el contexto es el lugar de trabajo del Agente
En los últimos años, la industria de la IA se ha acostumbrado a medir el progreso por el número de parámetros, los datos de entrenamiento y las puntuaciones en benchmarks. En 2026, Jeff Dean enfatiza más todo lo que rodea al modelo.
Un sistema de IA realmente útil, además del modelo, necesita recuperación de información (retrieval), herramientas, memoria, información histórica, entorno de ejecución y mecanismos de retroalimentación. El modelo debe saber qué herramientas tiene, cuándo invocarlas, cómo descomponer un problema complejo en una secuencia de acciones, y también poder comparar múltiples enfoques y juzgar cuál tiene más probabilidades de éxito.
Por eso la «ingeniería de contexto» está empezando a ocupar un lugar central.
Jeff Dean dice que la información que el modelo ve durante la fase de entrenamiento acaba «mezclada» en cientos de miles de millones o billones de parámetros. Es como un caldo concentrado: el conocimiento está ahí, pero no necesariamente de forma clara. La información que realmente se coloca en el contexto actual es más directa para el modelo y más fácil de usar con precisión.
Esto deja una oportunidad importante para los equipos pequeños.
Entrenar un modelo base requiere capital, datos y capacidad de cómputo masivos. Pero la ingeniería de contexto puede empezar desde una API. Los emprendedores pueden organizar, en torno a un negocio concreto, el conocimiento del dominio, los flujos de herramientas, los datos del cliente y los criterios de evaluación, para que un modelo general se comporte de forma más fiable en un escenario específico.
Jeff Dean puso un ejemplo propio.
Él y Sanjay Ghemawat optimizan a menudo bibliotecas internas de bajo nivel en Google. Estas estructuras de datos pueden ejecutarse en millones de procesos, por lo que pequeñas diferencias de rendimiento se amplifican con la escala. El enfoque tradicional es que un ingeniero primero escriba micro-benchmarks, mida el rendimiento actual, modifique el código, vuelva a ejecutar los benchmarks, observe el uso de caché y los cambios de rendimiento, y luego itere.
Los dos codificaron esta forma de trabajar como una habilidad (skill) para un agente. El modelo aprendió a ejecutar benchmarks, modificar código, comparar resultados y seguir optimizando en base a las mediciones.
«Simplemente tomamos el método que usaría una persona y se lo dimos al modelo en una forma que él puede usar.»
Esta frase puede considerarse casi la definición sencilla de la ingeniería de contexto.
No son trucos misteriosos de prompts, ni añadir más material de fondo. Consiste en responder a tres preguntas: ¿qué pasos seguiría un experto para hacer algo?, ¿qué herramientas fiables tiene el sistema?, ¿cómo se deben verificar los resultados?
Cuando estos elementos se estructuran, el modelo obtiene no más conocimiento, sino un método ejecutable y repetible.
Por eso las «habilidades (skills)» se están convirtiendo en un activo clave en el ecosistema de agentes. Un buen archivo de habilidad puede encapsular años de experiencia tácita de un equipo. Le dice al modelo qué hacer primero ante cierto tipo de problemas, qué errores son más comunes, en qué herramientas se puede confiar y qué resultado significa que la tarea está completada.
La diferenciación futura de las empresas probablemente no solo exista en los pesos del modelo, sino también en esta experiencia codificada en los flujos de trabajo.
六、Por qué los agentes empiezan a descontrolarse alrededor del paso 30
Casi todos los equipos que han trabajado de verdad con agentes han visto la misma escena.
Los primeros pasos van bien. El modelo puede leer requisitos, usar herramientas, escribir código. Alrededor del paso 30 o 50, empieza a olvidar el objetivo, malinterpretar el estado, repetir acciones o alejarse cada vez más en una dirección errónea.
Jeff Dean atribuye una de las causas al problema de distribución fuera del dominio (out-of-distribution).
El modelo ha visto muchas tareas comunes durante el entrenamiento. Mientras la tarea permanezca en el «camino iluminado» que conoce, suele rendir bien. Pero una vez que las operaciones consecutivas lo llevan a estados desconocidos, el rendimiento cae de repente. Cuanto más se desvía de la zona de confort, más se acumulan los errores.
Una solución es proporcionar habilidades y prompts que mantengan al modelo lo más cerca posible de caminos familiares. Otro método es usar sistemas multiagente.
Múltiples agentes pueden probar diferentes enfoques, y luego otro modelo actúa como evaluador, juzgando qué direcciones son más prometedoras. Las ramas que fallan se descartan, las exitosas continúan. Esto es, en esencia, realizar búsqueda durante la fase de inferencia.
No es ajeno a la forma de trabajar de los equipos humanos. Ante un problema complejo, una persona propone una solución, otra revisa los riesgos, una tercera ejecuta el experimento. El equipo no apuesta todas sus esperanzas en la primera idea, sino que reduce el error puntual a través de la división del trabajo y la retroalimentación.
Cuanto más tiempo se ejecute un agente, menos se podrá confiar en que el diseño del sistema acierte a la primera.
Un agente de larga ejecución realmente fiable necesita puntos de control (checkpoints), gestión de estado, reversión (rollback), exploración de ramas, evaluación externa, control de permisos y recuperación ante fallos. Se parece más a un sistema distribuido que a una ventana de chat muy larga.
Aquí es donde el trasfondo de Jeff Dean vuelve a resultar clave.
Uno de los problemas centrales que MapReduce resolvió fue cómo lograr que muchas máquinas poco fiables realizaran un cálculo fiable. Hoy, los sistemas de agentes enfrentan una contradicción similar: una sola invocación del modelo no es perfecta, las herramientas también fallan, pero la tarea completa aún debe completarse de la forma más estable posible.
Las futuras plataformas de agentes excelentes podrían heredar muchas ideas de los sistemas distribuidos. Las tareas se pueden dividir, los resultados se pueden verificar, los fallos se pueden reintentar, el estado se puede recuperar, y un error local no debería destruir todo el flujo.
Cuando Jeff Dean dice que los agentes ejecutarán tareas durante días o incluso semanas, no está describiendo un chat más largo. Está describiendo una nueva infraestructura de cómputo.
七、Cómo pueden ganar dos o tres personas a Google: Buscando problemas donde la tasa de éxito del modelo es solo del 1%
En el contexto de Startup School, la pregunta que más interesa es, por supuesto, la oportunidad para emprender.
Google puede diseñar conjuntamente chips, centros de datos, modelos y productos. Modelos generales como Gemini siguen expandiendo rápidamente sus capacidades. ¿Cómo puede ganar un equipo de dos o tres personas?
La respuesta de Jeff Dean no es romántica.
La oportunidad para equipos pequeños suele existir en áreas específicas en las que los modelos generales no han puesto suficiente atención. Los emprendedores pueden combinar la interfaz del producto, datos propios, flujos de trabajo y habilidades del dominio para ofrecer una mayor precisión y una mejor experiencia en un escenario estrecho.
Pero inmediatamente da una advertencia: los modelos generales se están volviendo rápidamente más potentes. Una función de producto que hoy parece independiente, en seis o doce meses podría quedar cubierta directamente por el modelo base.
Por lo tanto, los emprendedores necesitan evaluar si su ventaja es duradera.
Jeff Dean ofrece un criterio de filtrado muy concreto: buscar aquellas tareas en las que la tasa de éxito actual de los modelos generales se acerca al 0% o 1%, no aquellas que ya pueden hacer en un 20%.
«Si el modelo falla por completo, puede ser una buena señal. Si ya puede hacer una parte, aunque no muy bien, eso puede que no sea una buena señal.»
La razón es simple. Un 20% significa que la capacidad ya está empezando a aparecer. Más datos, modelos más grandes y razonamiento más largo (longer reasoning) pueden impulsarla rápidamente hasta la viabilidad. Un 0% o 1% sugiere que la tarea puede carecer de datos clave, herramientas especiales, retroalimentación del dominio o requerir una capacidad que el modelo general no puede obtener a corto plazo.
Podría llamarse la «regla del 1%» de Jeff Dean.
No sugiere que los emprendedores elijan solo los problemas más difíciles, sino que busquen problemas donde los modelos generales tienen un punto ciego estructural.
Estos puntos ciegos se dividen aproximadamente en tres tipos.
El primero son los datos propietarios. Los modelos generales pueden organizar la información mundial, pero no necesariamente acceder a todos los datos personales de un usuario, los procesos internos de una empresa o los datos en tiempo real generados por un dispositivo. Un producto de startup, una vez que obtiene estos datos, puede formar una perspectiva diferente a la del modelo base.
El segundo es la evaluación experta. Muchas industrias no carecen de capacidad de generación, sino de juicio fiable. Medicina, ciencia de materiales, chips, manufactura e investigación científica requieren verificadores (evaluadores) de alta calidad. Quien pueda definir «qué es correcto» podrá hacer que los agentes optimicen continuamente.
El tercero son los modelos estrechos pero profundos. AlphaFold no es un modelo de chat general; construyó una capacidad altamente especializada para el problema de la estructura de proteínas. La ciencia de materiales, el diseño de chips y otros campos especializados también pueden ofrecer oportunidades similares.
Este juicio no es fácil para los emprendedores. Requiere que el equipo entienda tanto los límites de capacidad de los modelos como los problemas profundos de la industria. Solo saber de IA puede llevar a crear funciones que la plataforma absorba rápidamente. Solo conocer la industria puede hacer subestimar la velocidad de progreso de los modelos.
La verdadera oportunidad está en la intersección de ambos.
八、Cuando el código deje de ser escaso, las especificaciones, el gusto y la selección de problemas serán más valiosos
Diana plantea una hipótesis: si en el futuro cada fundador pudiera gestionar simultáneamente 50 o 100 agentes, y todo el código lo escribieran agentes, ¿qué capacidad se volvería escasa?
La respuesta de Jeff Dean es el «gusto».
O más exactamente, el criterio para decidir qué deberían hacer los agentes.
Cree que la mayor parte del valor del trabajo de investigación no está en ejecutar el experimento de forma impecable, sino en si se elige un problema que merezca la pena investigar. Un equipo puede usar el método más exquisito para completar una investigación irrelevante. También puede identificar un problema clave que, al resolverlo, cambie todo el campo.
Cuando los agentes reduzcan el coste de ejecución, la importancia de la selección del problema aumentará aún más.
En el pasado, una idea vaga desaparecía naturalmente porque el coste de desarrollo era demasiado alto. En el futuro, siempre que se movilicen suficientes agentes, muchas ideas podrán convertirse rápidamente en prototipos. El mundo no tendrá automáticamente más buenos productos, solo más productos.
Las especificaciones también se volverán más importantes.
Jeff Dean dice que, al colaborar con agentes virtuales, cuanto más claro sea el objetivo, mayor será la tasa de éxito. Antes, un requisito ambiguo se daba a un ingeniero senior, que podía hacer preguntas y también completar la intención basándose en un contexto compartido. Aunque un agente también puede preguntar, es más propenso a hacer suposiciones por su cuenta cuando carece de contexto.
Una tarea típica de alta tasa de éxito es migrar software de un lenguaje de programación a otro. La razón no es que la migración sea simple, sino que las especificaciones son extremadamente completas. El código antiguo define el comportamiento, las pruebas definen los límites, y el agente puede comparar punto por punto hasta que la nueva versión se comporte igual.
«Ahora los agentes pueden escribir software por ti, pero explicar exactamente lo que quieres se ha vuelto más importante.»
Esta frase tiene implicaciones directas para las llamadas organizaciones nativas de IA.
Los futuros gestores no solo asignarán tareas, sino que tendrán que escribir objetivos y criterios de aceptación más claros. Los documentos de diseño dejarán de ser solo material de comunicación interna para convertirse también en la entrada para la ejecución de la máquina. Las pruebas, métricas, restricciones y ejemplos pasarán del final del flujo de desarrollo a la fase de definición de la tarea.
En cuanto a cómo entrenar el «gusto», el método que da Jeff Dean es muy práctico.
Escribe una lista de cosas que crees que serán importantes en los próximos 12 meses. No tienes que hacerlas todas. Al cabo de 12 meses, revisa qué predicciones se cumplieron, cuáles hicieron realidad otros y cuáles no progresaron en absoluto. Al acumular constantemente muestras de predicciones, las personas van calibrando gradualmente su criterio.
El gusto no es completamente innato. También se puede entrenar mediante revisión.
九、Un buen experimento mental empieza eliminando la premisa más arraigada de la industria
En la segunda mitad de la entrevista, Jeff Dean compartió un experimento mental bastante loco.
En los últimos 60 años, la industria de los chips ha perseguido transistores más pequeños, estables y con menor tasa de error. Se da por sentado que los chips fabricados con un mismo diseño deben ser lo más idénticos posible, y que cuantos menos errores de bit (bit flips), mejor.
Pero en los grandes sistemas distribuidos, los ingenieros ya aceptan que los componentes individuales fallarán. Los discos se estropean, las máquinas se caen, los switches tienen problemas. La fiabilidad del sistema no proviene de que cada parte no falle nunca, sino de la replicación, verificación, redundancia y recuperación.
Así que Jeff Dean pregunta: ¿y si un transistor tuviera 20 errores al día, en lugar de uno cada varios millones de años?
Esto no es un plan de producto realista. Solo intenta eliminar una premisa que damos por sentada. Quizás los transistores extremadamente poco fiables podrían fabricarse de una manera completamente diferente, y el sistema garantizaría los resultados mediante múltiples caminos y redundancia a alto nivel.
La mayoría de los experimentos mentales finalmente no se convierten en productos. Muchas prácticas industriales perduran durante décadas por buenas razones. Pero Jeff Dean cree que aún deberíamos revisar periódicamente esas razones.
MapReduce surgió de un proceso similar.
Los primeros sistemas de rastreo e indexación de Google contenían mucho código paralelo manual, puntos de control y lógica de recuperación ante fallos. El cálculo real del negocio a menudo era simple, como leer todas las páginas web y determinar el idioma. Pero mucho código del sistema ahogaba la intención simple.
Jeff Dean y Sanjay Ghemawat encontraron inspiración en la programación funcional. Abstrajeron muchas tareas en Map y Reduce, y trasladaron la paralelización, planificación, tolerancia a fallos y reintentos a un marco unificado. Los desarrolladores del negocio solo tenían que expresar el cálculo en sí.
Este diseño no hizo que las máquinas fueran infalibles. Hizo que los errores pudieran ser absorbidos por el sistema.
La ingeniería de agentes de hoy puede estar en una etapa similar. Muchos equipos aún orquestan manualmente prompts, lógica de reintento e invocaciones de herramientas para cada tarea. En el futuro, ¿aparecerá una abstracción tan limpia como MapReduce, que convierta la descomposición, verificación, recuperación y exploración paralela de agentes de larga ejecución en una capacidad de base?
Quizás esta sea precisamente la oportunidad para la próxima generación de empresas de infraestructura.
十、La IA empieza a construir mejor IA, el método científico se comprime en ciclos de alta velocidad
La dirección que más entusiasma a Jeff Dean para el futuro es automatizar el propio método científico.
El flujo de investigación tradicional es plantear una hipótesis, diseñar un experimento, ejecutarlo, analizar los resultados y generar la siguiente hipótesis. La velocidad de este ciclo siempre ha estado limitada por el costo de los experimentos y la latencia de la verificación.
La IA puede cambiar dos partes.
Una es proponer y ejecutar automáticamente más experimentos. Otra es convertir verificadores costosos en modelos aproximados baratos.
Jeff Dean puso el ejemplo de la química cuántica. Para determinar las propiedades de una configuración molecular, los investigadores pueden ejecutar simulaciones de teoría del funcional de la densidad. Una simulación puede llevar toda una noche. Los investigadores de Google entrenaron un aproximador neuronal con muchas entradas y salidas de simulaciones. Se acercaba a la precisión del simulador original, pero era unas 300,000 veces más rápido.
Cuando cambia la velocidad de verificación, también cambia la forma de los problemas científicos.
Antes, cribar 10 millones de candidatos podía ser un proyecto que requería meses de capacidad de cómputo. Ahora, mientras el investigador almuerza, el sistema puede completar el cribado inicial. El experimento deja de ser una apuesta única y preciosa para convertirse en una búsqueda de alta frecuencia.
Esta es también la lógica compartida detrás de sistemas como AlphaEvolve, AlphaChip, etc. El modelo propone una solución, las herramientas la ejecutan, el evaluador criba los resultados, y los resultados buenos pasan a la siguiente ronda. Mientras el ciclo cerrado sea suficientemente rápido, el sistema puede explorar continuamente un espacio de soluciones enorme.
El aprendizaje automático en sí también se convertirá en objeto de esta ciencia automatizada.
Hoy, los grandes equipos de investigación suelen tener a personas que proponen nuevas arquitecturas o métodos de entrenamiento, primero ejecutan experimentos a pequeña escala y luego amplían los enfoques prometedores. Jeff Dean cree que no hay barreras fundamentales que impidan que los modelos se hagan cargo de cada vez más de estos pasos. Las personas dan la dirección de alto nivel, el sistema explora automáticamente estructuras, recetas de datos y estrategias de entrenamiento, y luego combina los experimentos exitosos en nuevos modelos.
En el futuro, la métrica para medir la eficiencia de la investigación puede no ser solo los FLOPS por segundo, sino «cuántos descubrimientos efectivos se generan por unidad de capacidad de cómputo».
La capacidad de cómputo es importante, por supuesto. Pero cómo convertirla en descubrimientos, es más importante.
十一、El artículo sobre destilación rechazado por NeurIPS, y cómo ver el fracaso
En 2014, Jeff Dean, Geoff Hinton y Oriol Vinyals enviaron un artículo sobre destilación de conocimiento (knowledge distillation). Hoy, la destilación de conocimiento es un método fundamental en la compresión de modelos y la transferencia de capacidades. Un modelo grande actúa como profesor, transfiriendo su capacidad a un modelo estudiante más pequeño, rápido y económico.
Este artículo, que luego tendría una gran influencia, fue rechazado ese año por NeurIPS.
Un revisor consideró que era «poco probable que tuviera un impacto significativo». Los lectores interesados pueden visitar [enlace al artículo original].
Jeff Dean, al contar esta experiencia, no mostró enojo. Dijo que el revisor probablemente no comprendía los problemas reales a los que se enfrentan los servicios de IA a gran escala. Para Google, convertir modelos grandes y costosos en modelos pequeños que pudieran servir a cientos de millones de usuarios era claramente muy importante. Para un revisor que solo se centraba en la novedad teórica, puede que no pareciera lo suficientemente «fundamental».
Después del rechazo, el equipo lo subió a arXiv. La industria lo leyó igualmente y también empezó a usarlo.
Hoy, el modelo Flash de Gemini puede mantener una gran capacidad con un tamaño más pequeño y una latencia más baja, y la destilación es uno de los métodos importantes detrás de esto.
Esta historia no es solo un material motivacional de «persistir lleva al éxito». Demuestra que los sistemas de evaluación siempre tienen puntos ciegos. El valor de una solución a veces solo lo ve de inmediato quien ha sufrido realmente ese cuello de botella en el sistema.
Para los emprendedores, esto también es importante.
El rechazo del mercado, los inversores o los colegas puede significar que la dirección es errónea, o simplemente que los demás no están en el mismo escenario del problema. La diferencia está en si el equipo tiene evidencia concreta suficiente para saber por qué ese problema es importante y por qué se puede resolver ahora.
Jeff Dean no anima a persistir ciegamente. Lo que anima es: comprender el problema, verificar continuamente, y luego no tomar una revisión como el juicio final del mundo.
十二、¿Qué haría hoy el joven Jeff Dean?
Cuando la entrevista se acercaba a su fin, Diana planteó una pregunta con imaginación.
Si el joven Jeff Dean de 1999, recién llegado a Google, fuera transportado a 2026, ¿se uniría a un laboratorio de vanguardia o fundaría una empresa con dos o tres amigos?
Jeff Dean no dio una respuesta estándar.
Las grandes organizaciones tienen estructura, plataforma y muchos colegas excelentes. Una persona en ellas puede acceder a conocimientos que no tiene y también usar productos maduros para impactar a usuarios globales. Los equipos pequeños tienen más libertad, pero también asumen más riesgos. Los fundadores deben creer realmente en un problema y estar dispuestos a soportar la incertidumbre durante años.
El criterio que dio es más fundamental que «unirse a una gran empresa o emprender».
«Si resuelvo este problema, y el mejor resultado realmente ocurre, ¿el mundo mejoraría notablemente? ¿O la gente solo diría, 'eh, qué guay', y se quedaría así?»
Si la respuesta es solo «qué guay», puede que no valga la pena invertir el tiempo más valioso.
También enfatizó la importancia de los compañeros. Hay que buscar personas con habilidades complementarias, pero también con poco ego, dispuestas a colaborar y con las que sea agradable trabajar. Los problemas realmente difíciles a menudo requieren trabajar juntos durante mucho tiempo. Es mejor que los miembros del equipo tengan herramientas que los demás no tengan, y sigan ampliando su «cinturón de herramientas» durante el trabajo conjunto.
Estas palabras tienen una cualidad sencilla y clásica de ingeniero.
A la industria de la IA le gusta hablar de crecimiento exponencial, superinteligencia y grandes rondas de financiación. Jeff Dean termina reduciendo la elección a tres cosas pequeñas: trabajar en un problema que realmente te importe, trabajar con gente que te guste y esforzarte por hacer del mundo un lugar mejor.
Conclusión: En la era de la IA, lo más escaso sigue siendo ver el problema con claridad
En la carrera de Jeff Dean hay muchas leyendas que se cuentan repetidamente.
Él y Sanjay Ghemawat reescribieron el sistema de búsqueda en unos días, metiendo el índice en memoria. Un cálculo sobre tres minutos de voz impulsó a Google a crear el TPU. MapReduce ocultó el paralelismo masivo y la tolerancia a fallos en una abstracción unificada. La destilación de conocimiento pasó de un artículo rechazado a una tecnología base de la industria.
Estas historias pueden hacer fácilmente que lo imaginen como un genio que recibe inspiración constantemente.
Pero a juzgar por esta entrevista, su método es en realidad muy consistente.
Primero, calcular los órdenes de magnitud. Luego, encontrar el cuello de botella real. Después, cuestionar las suposiciones por defecto y establecer una abstracción más simple. Finalmente, usar medición y retroalimentación para impulsar la iteración continua del sistema.
La industria de la IA actual está pasando por una transición similar.
Los modelos ya son lo suficientemente potentes como para asumir tareas de nivel de ingeniero junior. A partir de ahora, lo que determine la productividad real no será solo el coeficiente intelectual del modelo, sino el costo de inferencia, la organización del contexto, la calidad de las herramientas, la velocidad de verificación y la fiabilidad de la ejecución de larga duración.
Los agentes se parecerán cada vez más a miembros del equipo. Pero necesitan especificaciones claras, habilidades, puntos de control, evaluadores y también un sistema capaz de absorber el fracaso.
La oportunidad para las startups tampoco desaparecerá, solo se volverá más exigente. Mejor no hacer cosas que los modelos generales ya pueden completar en un 20%, sino buscar aquellos problemas cuya tasa de éxito aún se acerque al 0% o 1%. Allí pueden esconderse datos propietarios, evaluadores expertos, modelos de dominio estrecho o nuevas abstracciones de sistema.
Cuando la generación de código sea cada vez más barata, lo realmente caro será el problema en sí.
¿Qué merece la pena hacer? ¿Qué restricciones están obsoletas? ¿Qué cambio acaba de cruzar un punto de inflexión? ¿Qué sistema, si fuera 50 veces más rápido, se convertiría en un producto completamente diferente?
Jeff Dean no dio una lista de oportunidades a los 6,000 emprendedores. Dio una forma de pensar más duradera.
No te apresures a perseguir la respuesta más candente.
Primero, calcula el problema.
Enlaces de referencia
https://x.com/ycombinator/status/2082938685071491219
https://www.ycrootaccess.com/p/jeff-dean-the-1-rule-for-building
Este artículo procede del cuenta de WeChat oficial «机器之心» (ID:almosthuman2014), autor: Panda
