Jeff Dean sobre la próxima fase de la IA: de TPU a agentes autoevolutivos

En la YC Startup School de 2026, la voz de Jeff Dean estaba un poco ronca.

Al inicio de la entrevista, explicó que había perdido la voz, por lo que sonaba diferente a lo habitual. Pero esto no afectó la atención de la audiencia. Diana Hu, socia de YC, sentada frente a él, enumeró sin pausa una serie de nombres que merecen un lugar en la historia de la informática: MapReduce, BigTable, TensorFlow, TPU, Gemini.

Cualquier proyecto sería suficiente para ser la obra maestra de la carrera de un ingeniero. Sin embargo, todos ellos aparecen concentrados en el currículum de Jeff Dean y un grupo de ingenieros de Google a su alrededor.

Diana no convirtió la entrevista en un resumen de logros. Le interesaba más otra pregunta: cuando la IA generativa ya ha invadido la industria del software, ¿qué está viendo Jeff Dean, la persona más hábil para reestructurar sistemas desde la base?

La respuesta no es un modelo más grande.

En esta conversación de casi una hora, Jeff Dean habló repetidamente sobre hardware de inferencia, energía, transferencia de datos, ingeniería de contexto, agentes de ejecución prolongada, sistemas automatizados de experimentación y cómo las startups pueden evitar el impacto directo de los modelos generales. Lo que dijo puede parecer disperso, pero detrás hay una línea directa muy clara: la próxima fase de la IA no se trata solo de entrenar modelos más inteligentes, sino de colocarlos dentro de un sistema que pueda funcionar a largo plazo, probar y errar continuamente, validar automáticamente y acumular habilidades 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".

En mayo de 2025, Jeff Dean hizo un juicio que generó un amplio debate: la capacidad de la IA ya está cerca de la de un ingeniero junior.

Un año después, Diana le preguntó cómo había ido esa predicción.

La respuesta de Jeff Dean fue directa. Considera que este juicio es "bastante preciso". El progreso del modelo en la agentización, la codificación de flujos largos y tareas complejas ha sido incluso más rápido de lo que él esperaba en ese momento.

“La capacidad del modelo para realizar tareas cada vez más complejas ha crecido más rápido de lo que esperaba,” dijo.

Más notable aún, esta capacidad ya no se limita a escribir código. Cada vez más sistemas de Agentes están ingresando en la ciencia, la ingeniería y otros campos profesionales. No solo responden preguntas, sino que descomponen tareas, utilizan herramientas, ejecutan experimentos, leen resultados y continúan actuando según los comentarios.

Comparar la IA con un ingeniero junior hace que la gente centre su atención en la sustitución de mano de obra. Pero Jeff Dean está más interesado en otro cambio: ¿qué sucede con la forma de organizar la producción cuando un «ingeniero junior» puede replicarse docenas o cientos de veces y trabajar en paralelo durante días e incluso semanas?

En un equipo tradicional, los ingenieros junior necesitan familiarizarse con el negocio, comprender las herramientas y recibir constantemente retroalimentación. Lo mismo ocurre con los agentes. Sin embargo, sus materiales de capacitación ya no son solo documentos, sino prompts, descripciones de herramientas, archivos de habilidades, sistemas de pruebas, evaluadores y todo el entorno de contexto.

Esto ha generado una nueva división del trabajo en la ingeniería de IA.

En el pasado, los ingenieros se encargaban principalmente de escribir código. En el futuro, más ingenieros se dedicarán a definir problemas, configurar entornos, redactar especificaciones, diseñar bucles de retroalimentación y luego coordinar a un grupo de Agentes para completar tareas.

La predicción de Jeff Dean para 2027 es exactamente así. 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. Dividirán los objetivos en subproblemas, ejecutarán automáticamente numerosos experimentos, compararán los resultados y combinarán las soluciones efectivas para formar nuevos sistemas más potentes.

Siempre que exista un objetivo medible en un campo, hay oportunidad de lograr grandes avances.

This sentence is the first key to the entire interview.

Lo primero en lo que la automatización de IA logra avances no es necesariamente el campo con más conocimientos, sino aquel con retroalimentación más clara. Si el código puede pasar las pruebas, si el diseño del chip puede reducir el área, si la estructura del modelo puede mejorar la precisión, si las propiedades del material cumplen con los requisitos: todas estas preguntas tienen criterios de evaluación relativamente claros. Si el evaluador es lo suficientemente confiable, la máquina puede realizar pruebas repetidas a una frecuencia extremadamente alta.

Por lo tanto, la unidad más importante en la era de la IA podría ya no ser una sola respuesta, sino un ciclo completo: proponer una solución, ejecutarla, medir los resultados y ajustar el rumbo.

Muchos de los trabajos representativos de Jeff Dean provienen de un punto de partida muy sencillo: primero calcular claramente las magnitudes.

En 2001, la búsqueda de Google aún dependía en gran medida de discos duros. Los discos duros tenían gran capacidad, pero velocidad de acceso lenta. Jeff Dean y Sanjay Ghemawat realizaron una estimación y descubrieron que el índice completo de búsqueda de Google en ese momento ya cabría en la memoria de todos los servidores.

Hoy suena como solo una actualización del medio de almacenamiento. Pero en ese momento, significaba un diseño de sistema completamente diferente.

Si el índice se mantenía principalmente en el disco duro, las consultas debían esperar la búsqueda mecánica. Al colocar el índice en la memoria, la latencia de acceso disminuyó drásticamente. Ambos escribieron rápidamente una nueva versión y la implementaron en producción en cuestión de días. La búsqueda de Google se volvió significativamente más rápida.

Esta historia se puede presentar fácilmente como un destello de genio. Sin embargo, la explicación de Jeff Dean suena más como la de un ingeniero describiendo una obviedad: cuando las condiciones del sistema cambian, una solución que antes no era válida puede volverse viable, por lo que se debe volver a calcular.

Muchas innovaciones industriales ocurren en estos momentos.

Un problema antiguo ha persistido durante mucho tiempo, y las personas se han acostumbrado a aplicar parches alrededor de él. Luego, el precio del hardware, la capacidad de memoria, el ancho de banda de la red o la capacidad del modelo cruzan un punto crítico, y las restricciones originales desaparecen. Sin embargo, la mayoría sigue utilizando la arquitectura antigua, porque ya se ha convertido en un conocimiento común.

Lo que Jeff Dean sabe hacer es convertir el sentido común de nuevo en suposición.

Él preguntará: ¿Por qué tiene que ser así? ¿El volumen de hoy es el mismo que el de ayer? ¿Si se reemplaza el paso más caro, ¿el sistema no adoptaría una forma completamente diferente?

Este también es su consejo para los emprendedores. No solo debes observar dónde fallan las soluciones actuales, sino replantearte el problema desde los primeros principios. ¿Puedes mejorar el rendimiento en un orden de magnitud? ¿Puedes reducir los costos en dos órdenes de magnitud? ¿Puedes dejar de seguir la ruta de implementación por defecto de la industria?

A veces, solo necesitas entrecerrar los ojos para ver un problema, no te ancles a la solución de hoy, sino piensa desde los principios primeros cómo debería resolverse.

Esta frase no suena misteriosa. Lo realmente difícil es que, una vez que la mayoría de las personas entran en una industria, aprenden rápidamente todas las respuestas predeterminadas de esa industria. La experiencia ayuda a mejorar la eficiencia, pero también hace que las personas pierdan la capacidad de volver a hacer preguntas.

En 2013, el reconocimiento de voz basado en aprendizaje profundo de Google comenzó a superar significativamente los sistemas anteriores. La tasa de error se redujo a la mitad, lo que equivalía a concentrar los avances en reconocimiento de voz de las últimas dos décadas en unos pocos meses.

El equipo de producto, por supuesto, estaba emocionado. Pero Jeff Dean primero hizo un cálculo.

Si el reconocimiento de voz realmente mejora, los usuarios estarán más dispuestos a usarlo. Suponiendo que cada usuario de Google use solo tres minutos de reconocimiento de voz al día, ¿cuántos servidores necesitaría Google para soportarlo?

Los resultados no son alentadores. Según la eficiencia de la CPU en ese momento, Google podría necesitar duplicar el tamaño de sus servidores.

This is the starting point of TPU.

No fue porque el equipo de investigación de repente quiso fabricar chips, ni para demostrar que Google tiene la capacidad de hacer hardware, sino porque un modelo exitoso estaba a punto de generar un costo de servicio insostenible.

Esta historia revela una ley a menudo ignorada en los productos de IA: el mejoramiento del rendimiento del modelo no siempre reduce los costos. Por el contrario, cuanto mejor sea el rendimiento, mayor será el uso y mayor la presión sobre el sistema.

Cuando el reconocimiento de voz no funciona bien, los usuarios lo invocan raramente. El costo del sistema no es un problema. Cuando la tasa de error disminuye significativamente, la demanda se libera repentinamente, y las restricciones de capacidad de cómputo que antes estaban ocultas en segundo plano emergen a la superficie.

La ruta elegida por TPU es crear hardware dedicado para el modelo de cálculo más fundamental del aprendizaje automático. No necesita ejecutar navegadores ni procesar todos los programas generales. Se destaca principalmente en álgebra lineal densa de baja precisión. Este tipo de cálculo se encuentra exactamente en el centro del aprendizaje automático moderno.

La primera generación de TPU generó mejoras de orden de magnitud. Según Jeff Dean, fue de 30 a 80 veces más eficiente en energía que los CPU y GPU de la época, y tuvo una latencia 20 a 30 veces menor.

Aquí hay otra escala de diseño que se suele pasar por alto.

TPU es 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 evolucionando rápidamente, por lo que diseñó el chip como un sistema lineal más general. Renunció a la capacidad de ejecutar Chrome o Word, pero conservó el espacio necesario para admitir la evolución futura de los algoritmos.

Es un equilibrio difícil de lograr. Si no se dedican suficientes recursos, los rendimientos no son notables. Si se dedican demasiados, un cambio en el algoritmo puede hacer que el hardware se vuelva obsoleto.

La evaluación de Jeff Dean sobre el hardware de inferencia de hoy resuena claramente con la de su TPU en su momento. Considera que la próxima gran oportunidad sigue radicando en la especialización, pero el enfoque se desplazará aún más hacia la inferencia de baja latencia y bajo consumo energético.

Imagina qué podrías hacer si la latencia mejorara 50 veces.

Cuando el modelo tarda varios segundos en responder, la gente lo considera una herramienta para consultas ocasionales. Cuando la latencia se acerca a lo instantáneo, entonces puede integrarse verdaderamente en interfaces interactivas, robots, video en tiempo real, sistemas operativos y flujos de toma de decisiones continuos.

Esperar no es un pequeño problema de experiencia. Esperar cambia la forma del producto.

Si se actualizara una versión de "Números de latencia que todo ingeniero debería conocer" para ingenieros de IA en 2026, Jeff Dean cree que el enfoque debería pasar de la búsqueda en disco duro, los fallos de caché y la latencia de red transcontinental hacia el flujo de datos dentro del chip.

Los ingenieros deben saber: ¿cuál es el ancho de banda entre la memoria principal y la memoria en chip, ¿cuál es el ancho de banda entre la memoria en chip y las unidades de multiplicación, ¿cuánta energía requiere una multiplicación, cómo se interconectan los chips y cómo disminuye la eficiencia de la red al escalar de 500 a 10.000 chips.

Estos números parecen estar lejos del producto, pero en realidad determinan qué productos pueden tener éxito.

Jeff Dean presentó una proporción extremadamente impactante. Realizar una multiplicación matemática requiere aproximadamente solo un picojulio de energía. Mover datos desde la memoria de alto ancho de banda hasta la unidad de cálculo puede tener un costo energético hasta 1000 veces mayor.

En otras palabras, las acciones costosas en los sistemas de IA hoy en día a menudo no son «calcular», sino «traer los datos que se deben calcular».

Esto también explica por qué el procesamiento por lotes es tan importante.

Cuando un conjunto de pesos del modelo se carga desde la memoria a la unidad de cálculo, si solo se procesa un token, todo el costo de transferencia de datos recae sobre ese único token. Si se procesan lotes más grandes simultáneamente, los mismos pesos pueden servir a más cálculos, distribuyendo así el costo energético y de ancho de banda.

Pero el procesamiento por lotes y la baja latencia son inherentemente contradictorios. Para reunir un lote de solicitudes, el sistema a menudo debe esperar. Aumenta el rendimiento, pero la respuesta para un usuario individual puede volverse más lenta.

Por lo tanto, muchos problemas que parecen pertenecer a la capa del modelo son en realidad problemas de hardware y sistema. La razón por la que el entrenamiento utiliza lotes grandes, la razón por la que la inferencia necesita KV Cache, la razón por la que el modelo busca baja precisión y la razón por la que el sistema requiere cuantización, todo ello está intrínsecamente ligado a la transferencia de datos y las restricciones energéticas.

Jeff Dean recientemente se ha enfocado más en la inferencia, precisamente porque la inferencia es extremadamente sensible a la latencia. Si una tarea de entrenamiento se ejecuta más lento, generalmente solo significa que el experimento termina más tarde. Pero cada segundo adicional de espera en una tarea de inferencia afecta directamente la experiencia del usuario y la eficiencia del agente.

Si un agente debe llamar al modelo 1000 veces consecutivas, reducir la latencia por llamada en un 50% puede generar una diferencia significativa en el tiempo total de finalización de la tarea. Por no mencionar que, en el futuro, los agentes deberán ejecutarse durante días o semanas.

Por lo tanto, el "problema energético" de la IA no es un tema ambiental distante. Determina directamente si los modelos pueden servir a más personas de manera económica, si los agentes pueden funcionar de forma continua y si los márgenes brutos de las startups son saludables.

En los últimos años, la industria de la IA ha medido el progreso mediante la cantidad de parámetros, los datos de entrenamiento y los puntajes de referencia. En 2026, Jeff Dean enfatiza aún más todo lo que rodea al modelo.

Un sistema de IA verdaderamente útil, además del modelo, requiere recuperación, herramientas, memoria, información histórica, entorno de ejecución y mecanismos de retroalimentación. El modelo debe saber qué herramientas están disponibles, cuándo llamarlas, cómo descomponer problemas complejos en una secuencia de acciones, y también debe poder comparar múltiples soluciones y determinar cuál tiene mayor probabilidad de éxito.

Esta es la razón por la que la "ingeniería de contexto" ha comenzado a tomar el centro del escenario.

Jeff Dean dice que la información que el modelo vio durante la fase de entrenamiento termina siendo "mezclada" en cientos de miles de millones o incluso trillones de parámetros. Son como una sopa espesa: el conocimiento está presente, pero no necesariamente claro. La información realmente introducida en el contexto actual es más directa para el modelo y más fácil de utilizar con precisión.

Esto deja una importante oportunidad para equipos pequeños.

Entrenar modelos base requiere una cantidad masiva de capital, datos y poder de cómputo. Sin embargo, la ingeniería de contexto puede comenzar con una API. Los emprendedores pueden organizar conocimiento del dominio, herramientas, procesos, datos de clientes y criterios de evaluación alrededor de un negocio específico, haciendo que los modelos generales sean más confiables en un escenario estrecho.

Jeff Dean compartió un ejemplo personal.

Él y Sanjay Ghemawat optimizan frecuentemente las bibliotecas subyacentes internas de Google. Estas estructuras de datos pueden ejecutarse en millones de procesos, una Punto punto Las diferencias de rendimiento se amplifican con la escala. El enfoque tradicional consiste en que los ingenieros primero escriban micropruebas, midan el rendimiento actual, luego modifiquen el código, vuelvan a ejecutar las pruebas, observen el uso de caché y los cambios en el rendimiento, y continúen iterando.

Ambas personas documentaron este método de trabajo como una habilidad de Agent. El modelo aprendió cómo ejecutar benchmarks, modificar código, comparar resultados y optimizar según las mediciones.

Solo le dimos el método que las personas usarían, en una forma que el modelo pueda utilizar.

This sentence can almost be considered a naive definition of context engineering.

No se trata de trucos misteriosos con palabras clave ni de acumular más material de fondo. Se trata de responder tres preguntas: ¿Qué pasos seguiría un experto?, ¿qué herramientas confiables tiene el sistema? y ¿cómo se debe verificar el resultado?

Cuando este contenido se estructura, el modelo no adquiere más conocimiento, sino un conjunto de métodos ejecutables repetidamente.

Por eso es que los "skills" se convierten en un activo clave en el ecosistema de Agentes. Un archivo de skill excelente puede encapsular años de experiencia implícita del equipo. Le dice al modelo qué hacer primero al enfrentarse a un tipo de problema, qué errores son más comunes, qué herramientas son confiables y qué resultados se consideran completos.

La diferenciación de las empresas futuras probablemente no solo existirá en los pesos del modelo, sino también en estas experiencias codificadas en los flujos de trabajo.

Casi todos los equipos que realmente han trabajado con Agentes han visto el mismo escenario.

Los primeros pasos fueron fáciles. El modelo podía leer los requisitos, utilizar herramientas y escribir código. Pero en el paso 30 o 50, comenzó a olvidar el objetivo, malinterpretar el estado, repetir acciones o alejarse cada vez más en una dirección incorrecta.

Jeff Dean atribuye una de las razones al problema de distribución externa.

El modelo ha visto una gran cantidad de tareas comunes durante el entrenamiento. Si la tarea sigue estando dentro de su «camino familiar», su rendimiento suele ser bueno. Sin embargo, una vez que operaciones consecutivas lo llevan a estados desconocidos, su rendimiento disminuye repentinamente. Cuanto más se aleje de su zona de confort, más fácil es que los errores se acumulen.

Una solución es proporcionar habilidades y sugerencias para restringir el modelo lo más posible a caminos que le resulten familiares. Otra opción es utilizar un sistema de múltiples agentes.

Varios Agentes pueden probar diferentes enfoques, y otro modelo actúa como evaluador para determinar qué direcciones tienen más potencial. Las ramas fallidas se descartan, mientras que las exitosas continúan avanzando. Esto es esencialmente una búsqueda realizada durante la fase de razonamiento.

No es ajeno al modo en que trabaja el equipo humano. Ante problemas complejos, una persona propone una solución, otra revisa los riesgos y una tercera ejecuta experimentos. El equipo no pone todas sus esperanzas en la primera idea, sino que reduce los errores puntuales mediante la división de tareas y la retroalimentación.

Cuanto más tiempo funcione el agente, menos el diseño del sistema puede depender de un solo intento correcto.

Un agente de largo alcance verdaderamente confiable requiere puntos de control, gestión de estado, rollback, exploración de ramas, evaluación externa, control de permisos y recuperación de excepciones. Es más como un sistema distribuido que como una ventana de chat extremadamente larga.

Este es precisamente el momento en que el trasfondo de Jeff Dean vuelve a volverse clave.

Uno de los problemas centrales que resuelve MapReduce es cómo lograr cálculos confiables mediante una gran cantidad de máquinas inconfiables. Los sistemas de Agentes actuales enfrentan una contradicción similar: las llamadas individuales al modelo no son perfectas, las herramientas pueden fallar, pero la tarea completa debe completarse de la manera más estable posible.

La plataforma de agentes excelente del futuro podría heredar muchas ideas de sistemas distribuidos. Las tareas pueden dividirse, los resultados pueden verificarse, los fallos pueden reintentarse, el estado puede recuperarse, y los errores locales no deben destruir todo el proceso.

Cuando Jeff Dean dice que los agentes funcionarán durante días e incluso semanas, no está describiendo una conversación más larga. Está describiendo una nueva infraestructura de cómputo.

En el contexto de Startup School, la pregunta más destacada es, por supuesto, la oportunidad empresarial.

Google puede diseñar conjuntamente chips, centros de datos, modelos y productos. Modelos generales como Gemini aún están ampliando rápidamente sus límites de capacidad. ¿Cómo puede un equipo de dos o tres personas ganar?

La respuesta de Jeff Dean no es romántica.

Las oportunidades para pequeños equipos suelen existir en áreas específicas que los modelos generales no han abordado adecuadamente. Los emprendedores pueden combinar la interfaz de producto, datos propios, flujos de trabajo y habilidades del sector para ofrecer mayor precisión y una mejor experiencia en un escenario limitado.

Pero luego advirtió: los modelos generales están volviéndose rápidamente más potentes. Las funciones de producto que hoy parecen independientes podrían ser cubiertas directamente por modelos básicos dentro de seis o doce meses.

Por lo tanto, los emprendedores deben evaluar si sus ventajas son duraderas.

Jeff Dean proporcionó un criterio de selección muy específico: buscar tareas en las que el éxito actual de los modelos generales esté cerca del 0% o del 1%, en lugar de tareas que ya logran un 20%.

Si el modelo falla por completo, esto podría ser una buena señal. Si ya puede hacer parte de la tarea, pero lo hace mal, entonces no necesariamente es una buena señal.

La razón es sencilla. Un 20% significa que ya están comenzando a aparecer capacidades. Más datos, modelos más grandes y razonamientos más largos probablemente lo llevarán rápidamente a ser utilizable. Un 0% o 1% indica que la tarea probablemente carece de datos clave, herramientas especiales, retroalimentación del dominio o una capacidad que un modelo general no puede obtener a corto plazo.

Esto puede llamarse la «regla del 1%» de Jeff Dean.

No se trata de sugerir a los emprendedores que elijan solo los problemas más difíciles, sino buscar aquellos donde los modelos generales presenten ciegas estructurales.

Hay tres tipos principales de estas zonas ciegas.

La primera categoría son los datos propios. Los modelos generales pueden organizar la información del mundo, pero no necesariamente pueden acceder a todos los perfiles personales de un usuario, a los procesos internos de una empresa o a los datos en tiempo real generados por un dispositivo. Una vez que un producto de startup obtenga estos datos, podrá desarrollar una perspectiva distinta a la del modelo base.

La segunda categoría es la evaluación profesional. Muchas industrias no carecen de capacidad de generación, sino de juicios confiables. La medicina, los materiales, los chips, la fabricación y la investigación científica requieren validadores de alta calidad. Quien defina «¿qué es lo correcto?» podrá hacer que los Agentes se optimicen continuamente.

La tercera categoría son modelos estrechos y profundos. AlphaFold no es un modelo de chat general; ha desarrollado capacidades altamente especializadas para el problema de la estructura de proteínas. Campos profesionales como la ciencia de materiales, el diseño de chips y otros podrían presentar oportunidades similares.

Esta evaluación no es sencilla para los emprendedores. Requiere que el equipo comprenda tanto los límites de las capacidades del modelo como los problemas profundos de la industria. Solo entender AI puede llevar a desarrollar funciones que los plataformas absorben rápidamente. Solo entender la industria puede hacer que subestimen la velocidad de los avances del modelo.

The real opportunity lies at the intersection of both.

Diana plantea una hipótesis: si en el futuro cada fundador puede gestionar simultáneamente 50 o 100 Agentes, y todo el código lo escribe el Agente, ¿qué habilidad se volverá escasa?

La respuesta de Jeff Dean es "gusto".

Más precisamente, determinar qué debe hacer el agente.

Él cree que el mayor valor del trabajo de investigación no radica en cuán bien se ejecuten los experimentos, sino en si se elige un problema digno de estudio. Un equipo puede utilizar los métodos más sofisticados para realizar una investigación insignificante. También puede abordar un problema clave que, al resolverse, cambie todo el campo.

Después de que el agente reduzca el costo de ejecución, la importancia de la selección de problemas aumentará aún más.

En el pasado, una idea vaga desaparecía naturalmente debido a los altos costos de desarrollo. En el futuro, con suficientes Agentes movilizados, muchas ideas podrán convertirse rápidamente en prototipos. El mundo no generará automáticamente más buenos productos, solo más productos.

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. En el pasado, las necesidades ambiguas se asignaban a un ingeniero experimentado, quien podía hacer preguntas y complementar la intención mediante un contexto compartido. Aunque los agentes también pueden hacer preguntas, tienden a hacer suposiciones por sí mismos cuando les falta contexto.

Una tarea típica de alta tasa de éxito es migrar un software de un lenguaje de programación a otro. La razón no es que la migración sea sencilla, 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 de manera consistente.

Ahora los agentes pueden escribir software por ti, pero explicar exactamente lo que quieres se vuelve aún más importante.

Esta frase tiene implicaciones directas para las organizaciones nativas de IA.

Los futuros gestores no solo asignarán tareas, sino que también definirán objetivos y criterios de aceptación más claros. Los documentos de diseño ya no serán solo materiales de comunicación para el equipo, sino también entradas para la ejecución por máquinas. Las pruebas, métricas, restricciones y ejemplos se trasladarán desde el final del proceso de desarrollo hasta la fase de definición de tareas.

En cuanto a cómo entrenar el "gusto", Jeff Dean ofrece un enfoque muy práctico.

Escribe una lista de cosas que crees que se volverán importantes en los próximos 12 meses. No necesitas hacerlas todas. Revisa después de 12 meses: ¿cuáles predicciones se cumplieron, ¿cuáles fueron realizadas por otros, y ¿cuáles no tuvieron ningún avance? A través de la acumulación constante de muestras de predicción, las personas gradualmente ajustan su juicio.

El gusto no es completamente un don. También se puede desarrollar mediante el análisis y la práctica.

En la segunda mitad de la entrevista, Jeff Dean compartió un experimento mental bastante loco.

Durante los últimos 60 años, la industria de los chips ha buscado transistores más pequeños, más estables y con menor tasa de errores. Se asume que los chips fabricados con el mismo diseño deberían ser lo más idénticos posible, con la menor cantidad posible de bit flips.

En sistemas distribuidos grandes, los ingenieros ya aceptan que los componentes individuales pueden fallar. Los discos duros pueden dañarse, las máquinas pueden caerse y los conmutadores pueden tener problemas. La confiabilidad del sistema no proviene de que cada componente nunca falle, sino de la replicación, la verificación, la redundancia y la recuperación.

Entonces Jeff Dean preguntó: ¿Qué pasaría si los transistores cometieran 20 errores por día, en lugar de un error cada varios millones de años?

Esto no es un plan de producto real. Solo está intentando eliminar una premisa habitual. Tal vez los transistores extremadamente inconfiables puedan fabricarse de una manera completamente diferente, y el sistema garantice los resultados mediante múltiples rutas y redundancia de alto nivel.

La mayoría de los experimentos mentales nunca se convierten en productos. Muchas prácticas industriales han persistido durante décadas, y realmente existen razones válidas para ello. Pero Jeff Dean cree que aún así se deben revisar periódicamente estas razones.

MapReduce proviene de un proceso similar.

Los sistemas de rastreo e indexación tempranos de Google contenían una gran cantidad de código paralelo manual, puntos de control y lógica de recuperación ante fallos. Los cálculos de negocio reales solían ser simples, como leer todas las páginas web y determinar el idioma de la página. Sin embargo, una gran cantidad de código del sistema ahogaba esta intención sencilla.

Jeff Dean y Sanjay Ghemawat se inspiraron en la programación funcional. Abstrajeron grandes tareas en Map y Reduce, y descentralizaron la paralelización, la programación, la tolerancia a fallos y los reintentos en un marco unificado. Los desarrolladores de negocio solo necesitan expresar el cálculo en sí.

Este diseño no hace que la máquina sea infalible. Hace que los errores puedan ser absorbidos por el sistema.

Hoy en día, los agentes también podrían estar en una etapa similar. Muchos equipos aún están configurando manualmente las indicaciones, la lógica de reintento y las llamadas a herramientas para cada tarea. ¿Existirá en el futuro una abstracción tan sencilla como MapReduce, que convierta la descomposición, validación, recuperación y exploración paralela de agentes de largo alcance en capacidades subyacentes?

This may be precisely the opportunity for the next wave of infrastructure companies.

La dirección que más entusiasma a Jeff Dean para el futuro es automatizar el propio método científico.

El proceso tradicional de investigación científica consiste en formular una hipótesis, diseñar un experimento, ejecutar el experimento y analizar los resultados, para luego generar la siguiente ronda de hipótesis. La velocidad de este ciclo ha estado limitada durante mucho tiempo por el costo de los experimentos y los retrasos en la validación.

La IA puede cambiar dos partes.

Una parte consiste en proponer y ejecutar automáticamente más experimentos. Otra parte consiste en convertir validadores costosos en modelos aproximados económicos.

Jeff Dean mencionó el ejemplo de la química cuántica. Los investigadores pueden ejecutar simulaciones de teoría funcional de densidad para determinar las propiedades de una configuración molecular. Una simulación puede requerir toda una noche. Los investigadores de Google entrenaron una red neuronal aproximadora con una gran cantidad de entradas y salidas de simulaciones. Esta aproximación alcanza una precisión cercana a la del simulador original, pero es aproximadamente 300,000 veces más rápida.

After the verification speed changes, the form of scientific questions also changes.

Antes, filtrar 10 millones de candidatos podría haber sido un proyecto que requería meses de poder de cómputo. Ahora, el sistema puede completar la primera filtración en el tiempo que un investigador tarda en almorzar. Los experimentos ya no son apuestas únicas y valiosas, sino búsquedas de alta frecuencia.

Esta es también la lógica común detrás de sistemas como AlphaEvolve y AlphaChip. El modelo propone soluciones, las herramientas las ejecutan, el evaluador filtra los resultados, y los mejores resultados pasan a la siguiente ronda. Si el bucle de retroalimentación es lo suficientemente rápido, el sistema puede explorar continuamente un espacio de soluciones enorme.

El aprendizaje automático también se convertirá en objeto de esta ciencia automatizada.

Hoy en día, los grandes equipos de investigación suelen tener personas que proponen nuevas arquitecturas o métodos de entrenamiento, realizan primero experimentos a pequeña escala y luego seleccionan las soluciones prometedoras para escalar. Jeff Dean considera que no existe ningún obstáculo fundamental que impida que los modelos asuman cada vez más etapas de este proceso. Las personas proporcionan una dirección de alto nivel, y el sistema explora automáticamente la estructura, las recetas de datos y las estrategias de entrenamiento, combinando luego los experimentos exitosos para crear nuevos modelos.

El indicador futuro para medir la eficiencia de la investigación podría no ser solo operaciones de punto flotante por segundo, sino «cuántos descubrimientos válidos se generan por unidad de poder de cómputo».

La potencia de cálculo es importante, por supuesto. Lo más importante es cómo convertir esa potencia de cálculo en descubrimientos.

En 2014, Jeff Dean, Geoff Hinton y Oriol Vinyals presentaron un artículo sobre destilación de conocimiento. Hoy en día, la destilación de conocimiento es un método fundamental en la compresión de modelos y la transferencia de capacidades. Los modelos grandes actúan como profesores, transfiriendo sus capacidades a modelos estudiantes más pequeños, rápidos y económicos.

Este artículo, que más tarde tuvo un impacto profundo, fue rechazado por NeurIPS ese año.

Un revisor consideró que «es poco probable que tenga un impacto significativo». Los lectores interesados pueden visitar «¡Rechazado ≠ fracaso! Estos artículos de alto impacto fueron rechazados por conferencias de primer nivel».

Jeff Dean no expresó ira al hablar de esta experiencia. Dijo que los revisores podrían no comprender los problemas reales que enfrentan los servicios de IA a gran escala. Para Google, convertir modelos grandes y costosos en modelos pequeños capaces de servir a cientos de millones de usuarios es claramente muy importante. Para revisores que solo se enfocan en la novedad teórica, esto quizás no parezca lo suficientemente "básico".

Después de que el artículo fuera rechazado, el equipo lo publicó en arXiv. La industria lo leyó igualmente y comenzó a usarlo.

Hoy, el modelo Flash de Gemini puede mantener una fuerte capacidad con menor volumen y menor latencia, y la destilación es uno de los métodos clave para lograrlo.

Esta historia no es solo un material motivacional de «la perseverancia lleva al éxito». Demuestra que los sistemas de evaluación siempre tienen ciegos. El valor de una solución a veces solo es inmediatamente visible para quienes han experimentado realmente el cuello de botella de ese sistema.

For entrepreneurs, this is equally important.

La negación del mercado, los inversores y los colegas puede significar un error de dirección, o simplemente que la otra parte no está en el mismo contexto del problema. La diferencia radica en si el equipo tiene evidencia suficientemente específica para entender por qué este problema es importante y por qué ahora se puede resolver.

Jeff Dean no anima a las personas a persistir ciegamente. Lo que anima es: comprender el problema, verificar continuamente, y no considerar una sola revisión como el juicio final del mundo.

Cuando la entrevista estaba llegando a su fin, Diana hizo una pregunta con imaginación.

Si se transportara al joven Jeff Dean que se unió a Google en 1999 hasta el año 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, plataformas y muchos excelentes colegas. Dentro de ellas, una persona puede acceder a conocimientos que desconoce y utilizar productos maduros para impactar a usuarios en todo el mundo. Los pequeños equipos son más libres, pero asumen mayores riesgos. El fundador debe creer verdaderamente en un problema y estar dispuesto a soportar la incertidumbre durante años.

El criterio que él proporciona es más fundamental que "unirse a una gran empresa o emprender".

¿Si resuelvo este problema y realmente ocurre el mejor resultado posible, ¿el mundo se volverá claramente mejor, o solo dirán: “Vaya, qué genial”, y listo?

Si la respuesta es solo «muy genial», probablemente no valga la pena invertir el tiempo más valioso.

También enfatizó la importancia de los compañeros: busca personas con habilidades complementarias, con bajo ego, dispuestas a colaborar y con las que te resulte agradable trabajar. Los problemas verdaderamente difíciles suelen requerir colaboración a largo plazo. Lo ideal es que cada miembro del equipo posea herramientas únicas que los demás no tengan, y que siga ampliando su "cinturón de herramientas" a través del trabajo conjunto.

Esta frase tiene una sencillez de ingeniero tradicional.

La industria de la IA habla mucho sobre crecimiento exponencial, inteligencia sobrehumana y financiación masiva. Pero al final, Jeff Dean vuelve a enfocarse en tres pequeñas cosas: abordar un problema que realmente te importe, trabajar con personas que te gusten y hacer todo lo posible por mejorar el mundo.

En la carrera de Jeff Dean, hay muchas leyendas que se cuentan una y otra vez.

Él y Sanjay Ghemawat reescribieron el sistema de búsqueda en pocos días para cargar el índice en memoria. Una estimación de tres minutos de voz impulsó a Google a crear TPU. MapReduce ocultó el paralelismo a gran escala y la tolerancia a fallos detrás de una abstracción unificada. La destilación del conocimiento pasó de un artículo rechazado a convertirse en una tecnología fundamental de la industria.

Estas historias hacen que sea fácil imaginarlo como un genio que constantemente obtiene inspiración.

Pero según esta entrevista, su método es en realidad muy consistente.

Primero, determina el orden de magnitud. Luego, identifica el cuello de botella real. A continuación, cuestiona las suposiciones por defecto y crea una abstracción más simple. Finalmente, impulsa la iteración continua del sistema mediante mediciones y retroalimentación.

La industria de la IA está experimentando un punto de inflexión similar hoy.

El modelo ya es lo suficientemente potente como para asumir tareas de nivel ingeniero junior. Lo que determina la productividad real a continuación no es solo el coeficiente intelectual del modelo, sino el costo de razonamiento, la organización del contexto, la calidad de las herramientas, la velocidad de validación y la confiabilidad en ejecuciones prolongadas.

Los agentes se volverán cada vez más como miembros del equipo. Pero necesitan especificaciones claras, habilidades, puntos de control, evaluadores y un sistema que permita el fracaso.

Las oportunidades para startups tampoco desaparecerán, solo se volverán más exigentes. Es mejor evitar hacer cosas que los modelos generales ya pueden completar en un 20%, y en su lugar buscar problemas cuya tasa de éxito aún se acerca al 0% o al 1%. Allí podrían ocultarse datos propietarios, evaluadores especializados, modelos de dominio estrecho o nuevas abstracciones de sistemas.

Cuando la generación de código se vuelve cada vez más barata, lo realmente caro será el problema en sí.

¿Qué vale la pena hacer? ¿Qué restricciones están obsoletas? ¿Qué cambios acaban de cruzar el punto crítico? ¿Qué sistema se convertiría en un producto completamente diferente si fuera 50 veces más rápido?

Jeff Dean no proporcionó una lista de oportunidades para 6000 emprendedores. Lo que ofreció fue una forma de pensar más duradera.

No te apresures a perseguir la respuesta más popular.

Primero, calcula la pregunta.

Enlace de referencia

https://x.com/ycombinator/status/2082938685071491219

https://www.ycrootaccess.com/p/jeff-dean-the-1-rule-for-building

Este artículo proviene del número de WeChat "Machine Heart" (ID: almosthuman2014), autor: Panda