EL PÓDCAST

Todo lo que toca

Un pódcast sobre cómo la inteligencia artificial está cambiando el software, el trabajo y las decisiones humanas. En cada episodio seguimos la evidencia y nos detenemos en las partes de la historia que merecen una mirada más cercana.

Por Augusto BurgosEspañol

Añade la fuente a cualquier aplicación de pódcast compatible con RSS.

Apple Podcasts y Spotify: pendientes de envío.

Todo lo que toca portada del pódcastUna historia nunca es una sola cosa.

Escucha con atención.

2 episodios

Episodio 02 17:19

Este video no empezó como ruido

Muchos videos de IA empiezan como ruido. Este empezó como código. En este episodio largo vamos despacio para comparar dos formas de hacer una imagen en movimiento: los modelos de difusión, que adivinan cómo suelen verse los píxeles, y el video procedural, donde un programa que escribió una IA calcula cada cuadro. Vemos qué dicen pruebas de física como Physics-IQ y VideoPhy-2 sobre la suposición: parecer real no es lo mismo que estar bien. Luego calculamos la gravedad, un arcoíris y un péndulo doble caótico, le ponemos nombre a un color hasta un solo paso de un canal, medimos la sincronía del sonido, documentamos cada cuadro y admitimos dónde la suposición todavía gana. Los precios, clasificaciones y listas de modelos son capturas del 4 de octubre de 2026. Compañero del video «Este video no empezó como ruido» de Everything It Touches. Capítulos 0:00 Estática, luego código 0:47 Bienvenida 1:51 Dos formas de hacer un cuadro 3:37 Parecer real no es estar bien 6:23 Física que puedes calcular 8:46 Color al que puedes ponerle nombre 10:05 Sonido que puedes medir 11:15 Cada cuadro, documentado 13:20 Donde gana la suposición 15:11 Qué es IA en este video 16:30 Despedida Citas (texto original en inglés; el episodio usa una traducción al español) • Google DeepMind, ficha del modelo Veo 3, enero de 2026: "Veo 3 utilizes latent diffusion, which is the de facto standard approach for modern image, audio, and video generative models." • Motamed et al., "Do Generative Video Models Understand Physical Principles?" (Physics-IQ), WACV 2026: "visual realism does not imply physical understanding" • VideoPhy-2, Bansal et al., UCLA y Google Research, ICLR 2026: "models particularly struggle with conservation laws like mass and momentum" Fuentes • Difusión y ruido latente gaussiano; "estándar de facto": informe técnico de Google Veo, 2025, y ficha del modelo Veo 3; Ho et al., DDPM, 2020 • Gemini Omni 1.1 Flash, lanzado el 27 de agosto de 2026; transformer, método de muestreo no divulgado: página y ficha del modelo de Google • Higgsfield anuncia más de 30 modelos: higgsfield.ai, consultado el 4 de octubre de 2026 • Physics-IQ, 66 escenarios, puntuación contra la variación de repetir lo real: Motamed et al., WACV 2026 • Sora 10.0, Sora 2 42.3, Magi-1 + GeoPhys 64.5 (varios cuadros, mejor de 16): tabla de posiciones de Physics-IQ, captura del 4 de octubre de 2026 • Physics-IQ Verified, Omni 1.1 Flash 35.34, líder Physis-Lang/Cosmos3 Super 48.2: extensión independiente, Rädsch et al.; sin respaldo de Google DeepMind • Conservación de la masa y de la cantidad de movimiento: VideoPhy-2, UCLA y Google Research, ICLR 2026 • Imitación basada en casos, color > tamaño > velocidad > forma: Kang et al., ByteDance Research, ICML 2025 • Gravedad estándar 9.80665 m/s²: NIST • Trazado de rayos del arcoíris: Descartes, Les Météores, Discurso VIII, Leiden, 1637; rojo 42.37° y violeta 40.65°, de nuestra propia simulación • Separación del péndulo doble cerca de 4.41 s, varillas de 2.5 cm, diferencia inicial de 10⁻⁹°: nuestra simulación, sensible al paso • Impresión redondeada, segundo mes simulado: Edward Lorenz, The Essence of Chaos, 1993 • Dificultad con colores hex, precisión de 4 a 9 veces, 500 mil imágenes renderizadas: NumColor, arXiv, 13 de marzo de 2026 • Desfases de audio y video de 0.20 a 0.44 s, labios de 2 a más de 5 cuadros: AVGen-Bench, arXiv, 9 de abril de 2026 • Semillas de Veo y clips de 8 segundos a 1080p: documentación de la API de Google Veo • Cierre de la API de Sora 2, 24 de septiembre de 2026: referencia de la API de OpenAI • Precios de Veo 3.1, Standard $0.40/s, Fast $0.12/s, Lite $0.08/s a 1080p: precios de la Gemini Developer API, 4 de octubre de 2026 • 150 generadores, 1.5 millones de clips (publicación informada por los autores): WROP, arXiv, 23 de septiembre de 2026 • Primero un borrador de simulación, luego video generado: VideoCoCo, arXiv, 2026 • Cuestionario de secundaria 88.1 frente a 86.3, estudio pequeño: Code2Video, arXiv, 1 de octubre de 2025 • Nuestras propias mediciones (verde #A3E535, regla de destellos, conteo de cuadros, corrección de tiempos, control de la mezcla): registros de producción del video

Capítulos
Leer la transcripción

Muchos videos de IA empiezan con ruido como este. Estática.

Un modelo lo limpia, paso a paso, hasta que parece una ciudad.

O una persona que nunca existió.

Es asombroso. Pero es una suposición.

Una suposición brillante sobre cómo suelen verse los píxeles.

El video del que trata este episodio no empezó como ruido.

Empezó como código, y una IA escribió ese código.

Cada imagen está calculada:

la gravedad, el color, el momento de cada movimiento.

Y hasta la estática sale igual cada vez.

Esto es Todo lo que toca, el podcast. Soy Augusto.

En el canal hacemos videos cortos sobre lo que la IA está cambiando.

Aquí contamos la misma historia con calma,

para que quepan las partes que un video tiene que pasar corriendo.

Esa apertura es una imagen del video.

Una estática gris azulada llena la pantalla.

Un contador pequeño avanza paso a paso,

y el ruido se vuelve un horizonte de edificios y luego un rostro,

los dos con la etiqueta "ilustración".

Después, la estática se reduce a una sola línea de código verde,

y una pelota empieza a caer, dejando un rastro de puntos, uno por cuadro.

Dos formas de hacer una imagen en movimiento.

Hoy quiero desarmarlas despacio:

dónde la suposición es maravillosa,

dónde se rompe y qué cambia cuando la imagen se calcula.

Y te voy a mostrar nuestros propios errores, porque de eso se trata.

Hoy, entre los grandes nombres están Veo y Gemini Omni, de Google.

Y plataformas como Higgsfield reúnen decenas de modelos en un solo lugar.

Higgsfield anuncia más de treinta.

Veo es un modelo de difusión.

Así lo describe Google en la ficha del modelo Veo tres.

Te lo leo en traducción.

“Veo tres utiliza difusión latente,

que es el enfoque estándar de facto para los modelos

generativos modernos de imagen, audio y video.”

Esa es la descripción que Google hace del campo.

No es un censo de todos los modelos.

Gemini Omni, por ejemplo, se describe como un transformer,

y Google no ha dicho cómo genera sus muestras.

Así que no lo voy a llamar difusión.

La idea detrás de la difusión es esta.

Durante el entrenamiento,

clips reales se comprimen en números y se entierran en ruido gaussiano,

un tipo muy particular de estática aleatoria.

Una red aprende a desenterrar el clip.

Para crear algo nuevo, le das ruido nuevo y un prompt, y la dejas excavar.

Un video procedural va en sentido contrario.

Nada se predice. Todo se calcula.

Un programa dibuja cada cuadro en función del tiempo.

Cuadro uno. Un treintavo de segundo después, cuadro dos.

La pelota está donde la ecuación la pone.

El verde es un número en el código.

Y ese programa lo escribió un modelo de IA para programar,

a partir de mis descripciones.

Así que las dos cosas son IA.

Un tipo de IA pinta el cuadro.

El otro escribe las reglas que lo dibujan.

Y esas reglas igual hay que revisarlas.

Entonces, ¿qué tan buena es la suposición?

Investigadores de Google DeepMind crearon una prueba llamada Physics-IQ.

Filmaron experimentos reales, sesenta y seis escenarios:

choques, agua que se vierte, luz, imanes.

Luego pidieron a modelos de video que continuaran las imágenes.

La puntuación es ingeniosa.

Cien no significa cien por ciento correcto.

Significa tan consistente como filmar el mismo experimento una segunda vez.

La vida real también es un poco aleatoria, y la puntuación se mide contra eso.

A comienzos de dos mil veinticinco, el Sora original sacó diez.

Sora dos llegó a cuarenta y dos.

La mejor entrada de esa tabla ronda los sesenta y cinco, pero recibe más ayuda.

Ve varios cuadros, no uno,

y un segundo sistema elige el más plausible de dieciséis intentos.

Un avance real. Todavía lejos de una cámara.

También hay una versión revisada e independiente de la prueba,

llamada Physics-IQ Verified.

Otras personas cambiaron los prompts y la puntuación,

y Google DeepMind no la respalda,

así que sus números no se comparan con la tabla original.

Ahí, Gemini Omni uno punto uno Flash, de Google, saca unos treinta y cinco.

La mejor entrada de una sola imagen,

el cuatro de octubre, estaba en unos cuarenta y ocho.

Los autores originales, Motamed y sus colegas,

resumieron su conclusión en una línea.

En traducción, dice así.

“el realismo visual no implica comprensión física”

Un equipo de UCLA y Google Research creó otra prueba, VideoPhy dos.

Esto escribieron sobre los modelos que probaron, en traducción.

“a los modelos les cuesta especialmente cumplir las leyes de conservación,

como la de la masa y la de la cantidad de movimiento”

Imagina agua que aparece de la nada en un vaso.

O una pelota que olvida a qué velocidad iba.

Y unos investigadores de ByteDance, con coautores de Tsinghua y del Technion,

entrenaron modelos de video con clips de un simulador de física sencillo,

en dos dimensiones. En condiciones conocidas, les fue bien.

Fuera de ellas, imitaron el ejemplo más parecido que habían visto.

Y se guiaron primero por el color, luego por el tamaño,

después por la velocidad y, al final, por la forma.

Es un estudio controlado, no una ley de la naturaleza.

Pero es una buena imagen de lo que es una suposición.

Ahora mira qué pasa cuando la física se calcula.

Bueno, escucha.

En el video, una pelota verde cae bajo la gravedad estándar,

nueve punto ocho uno metros por segundo al cuadrado, sin resistencia del aire.

Por eso su trayectoria es una parábola verdadera.

Dos discos chocan, y un medidor de cantidad de movimiento, a su lado, no se mueve.

El código le da a cada uno un empujón igual y opuesto, así que el total no cambia.

Luego, la luz del sol entra en una gota de lluvia.

Se desvía, se refleja en la parte de atrás y vuelve a desviarse al salir.

Nuestro código traza los rayos.

El rojo vuelve a cuarenta y dos punto cuatro grados del punto opuesto al Sol.

El violeta, a cuarenta punto seis.

Por eso el rojo queda por fuera del arcoíris.

Descartes publicó su cálculo del arcoíris en mil seiscientos treinta y siete,

en un libro llamado Les Météores.

Siguió la luz a través de una gota, rayo por rayo.

Nuestro código repite su método, con números modernos para los colores.

Ahora, dos péndulos dobles diminutos, con varillas de dos centímetros y medio,

que arrancan separados por una milmillonésima de grado.

Por un momento, se mueven como uno.

Unos cuatro segundos después, son desconocidos.

Eso es caos. Y aquí viene lo hermoso.

Sigue siendo determinista.

Ejecuta el mismo código otra vez, con los mismos ajustes,

y obtienes exactamente el mismo caos.

Edward Lorenz se topó con esto en una simulación del clima.

Reinició una corrida desde una impresión que

había redondeado sus números a tres decimales.

Para el segundo mes simulado, el clima ya no se parecía al original.

Esa idea se conoció como el efecto mariposa:

diferencias diminutas, consecuencias enormes.

Un modelo de video tiene que aprender el caos a partir de ejemplos.

Una simulación lo produce a partir de las ecuaciones.

Con el color pasa lo mismo.

En este video, el verde no es "un verde brillante".

Es un número. A tres e seis tres cinco.

A los modelos de imágenes les han costado los números así.

Un estudio publicado en marzo, llamado NumColor,

encontró que a los modelos de texto a imagen

les cuesta interpretar códigos hexadecimales.

Parte de la razón:

el código se corta en fragmentos que no transmiten un color de forma fiable.

Su solución hizo el color numérico de cuatro a nueve veces más preciso,

en su propia prueba, con cinco tipos de modelo.

En código, el color nunca es una suposición. ¿Es perfecto?

No.

En el camino hacia ti, una curva de luces

que elegimos suaviza el canal más brillante.

Cuando medí un cuadro, nuestro verde salió a tres e cinco tres cinco.

Un paso, en un canal.

El verde pasó de doscientos treinta a doscientos veintinueve.

Un error que puedo señalar.

El códec de video puede volver a moverlo.

Pero cada paso está escrito,

así que puedo ver exactamente dónde se movió el color, y por qué.

Para una marca, esa es la diferencia entre esperar y saber.

Ahora, el sonido.

Algunos de los modelos más nuevos generan sonido e imagen juntos,

y es impresionante.

Pero una prueba publicada en abril midió la brecha.

En promedio, sonido e imagen se desfasaban de

un quinto de segundo a casi medio segundo, según el modelo.

Y los labios se desfasaban del habla entre dos y más de cinco cuadros.

En nuestro video, la voz va primero. La imagen la sigue.

El servicio de voz reporta un tiempo para cada carácter,

y cada movimiento en pantalla se activa desde esos tiempos.

Esos tiempos son una estimación, así que los revisamos.

Cuando digo ahora, algo se mueve.

¿Funcionó perfecto desde el principio? No.

En tomas anteriores, los tiempos de las palabras

llegaban hasta seis décimas de segundo antes de tiempo.

Lo medimos y agregamos una corrección en código.

Y todavía escuchamos.

La mezcla también se mide.

Volumen a menos catorce LUFS, picos por debajo de un techo,

y el informe tiene que decir aprobado.

Cualquier video se puede medir.

Pero como aquí cada cuadro se calcula,

cada cuadro se puede rastrear hasta una línea.

Antes de entregar, un script los lee todos,

más de quince mil, contando la introducción de la serie,

y rechaza la película si el brillo sube de golpe y vuelve a bajar.

Esa es nuestra regla de destellos.

Si la pantalla se pone mucho más brillante en un cuarto de segundo,

y otra vez mucho más oscura en medio segundo, falla.

Es nuestra propia regla, no un certificado médico.

Pero es un número, no una sensación.

Cuando una revisión falla, cambio la línea que la causó.

No vuelvo a generar esperando suerte.

La propia documentación de Google dice que una

semilla de Veo no garantiza el mismo video.

Solo mejora un poco la repetibilidad.

Y como toda la toma depende del prompt,

cambias una palabra y puede cambiar toda la toma.

En código, cambio un número, y solo se mueve lo que depende de él.

Y las herramientas pueden desaparecer.

El veinticuatro de septiembre, OpenAI cerró la a pe i de Sora dos.

Nuestra película es código fuente, una voz y una partitura,

guardados como archivos en mi propia computadora, y se renderiza ahí.

Luego está el costo.

El cuatro de octubre, la lista de precios de la propia Google

ponía Veo tres punto uno Standard a cuarenta centavos por segundo,

a mil ochenta pe.

Nueve minutos son sesenta y ocho clips de ocho segundos.

Eso pasa de doscientos dólares, antes de un solo reintento.

Los niveles más baratos, Fast y Lite,

saldrían en unos sesenta y cinco dólares, o unos cuarenta y cuatro.

Nuestras imágenes no tienen factura por segundo.

Pago la voz, la música y el modelo para programar.

Y la computadora, y mi tiempo.

Entonces, ¿lo calculado siempre es mejor? No.

Una calle lluviosa en Lisboa. Un rostro que parece vivo.

Un perro atrapando un frisbee.

La difusión gana, fácilmente.

Imitar eso en código sería trabajo de un estudio de efectos visuales.

Además, un prompt te da una primera vista en minutos.

Lo procedural gana cuando la imagen tiene que ser correcta.

Explicar, enseñar, datos, física, una marca.

Para un rostro, le pediría a un modelo.

Para una clave de respuestas, pediría código.

Y los dos mundos empiezan a ayudarse.

En septiembre, investigadores que estudian si los modelos de

video entienden que un objeto oculto sigue existiendo publicaron,

según ellos, ciento cincuenta generadores

procedurales de escenas y un millón y medio de clips.

Aquel estudio de color entrenó su solución

con medio millón de imágenes renderizadas.

Cuando los investigadores necesitan una clave de respuestas, la calculan.

Otro equipo pone a un agente de programación a escribir primero una simulación,

y luego deja que un modelo de video la pinte encima.

La física, del código. La apariencia, de la difusión.

Aun así, los píxeles finales pueden romper las reglas.

Y en un estudio pequeño, con seis alumnos de secundaria en cada grupo,

los estudiantes sacaron notas parecidas en cuestionarios

después de explicaciones que agentes escribieron como código,

unos ochenta y ocho, y después de las de Three Blue One Brown, unos ochenta y seis.

Un estudio pequeño. No prueba que enseñen igual de bien.

Pero es interesante.

Entonces, con honestidad: ¿qué tiene de IA el video?

La voz es un clon de la mía hecho con IA.

La música la generó un modelo de IA, en secciones que siguen los capítulos.

El código que dibuja cada cuadro se escribió con un modelo de IA para programar,

a partir de mis descripciones, y la IA ayudó a escribir las comprobaciones.

Los píxeles son la parte que no genera un modelo de video.

Se calculan.

¿Recuerdas la estática del principio? Calculada.

El mismo ruido en cada render.

En el video aparece dos veces,

y una pequeña etiqueta muestra la misma huella las dos veces.

Un tipo de IA sueña un mundo que parece correcto.

El otro escribe las reglas y deja que el mundo las siga.

Y esto es lo asombroso.

No que el código siempre tenga razón. No la tiene.

Es que, cuando se equivoca, puedo encontrar la línea y corregirla.

Este video no empezó como ruido. Empezó como una frase.

Un modelo convirtió la frase en código, y el código en física.

La versión corta, con la gota de lluvia, los péndulos y el verde de un solo paso,

está en el canal Todo lo que toca, y se llama "Este video no empezó como ruido".

Y me encantaría escuchar tu respuesta a la pregunta con la que termina:

¿qué jamás dejarías que adivinara un modelo?

Cuéntamelo en los comentarios.

Las fuentes están en las notas del episodio.

Las citas las leen voces de IA,

no las personas que las escribieron, y están traducidas.

Este podcast se hizo con código, en procvideos punto com.

Mi voz es un clon de IA, y la música es generada con IA.

Gracias por escuchar.

Episodio 01 17:50

Nadie revisó tu ADN: por qué el pull request se está muriendo

Ahora mismo estás ejecutando unos 70 cambios en tu código fuente que nadie revisó jamás: mutaciones nuevas en tu ADN que no tenía ninguno de tus padres. Y funcionas bien. Los agentes de IA ya escriben código más rápido de lo que las personas pueden leerlo. En Anthropic, más del 80% del código que se incorpora lo escribe Claude, y la revisión humana se volvió el nuevo cuello de botella. En este episodio largo vamos con calma: qué hacía realmente el code review (de 570 comentarios estudiados, solo 78 eran sobre defectos), cómo la naturaleza construye sistemas complejos sin leer el código, por qué la evolución supera a nuestros ingenieros, como en la antena de la NASA ST5 o en AlphaEvolve, y cómo hace trampa, como la Darwin Gödel Machine falsificando sus propios registros. Después, cómo tu cuerpo vigila a los tramposos y cinco presiones que puedes construir para que tu código evolucione de forma segura. Compañero del video «Nadie revisó tu ADN» del canal Todo lo que toca. Capítulos 0:00 Setenta cambios sin revisar 0:48 Bienvenida 1:44 El cuello de botella 3:33 Lo que hacía realmente la revisión 4:56 Cómo lo hace la naturaleza 6:43 Evolucionado, no diseñado 9:11 El problema: la evolución hace trampa 11:35 Cómo vigila la naturaleza a los tramposos 12:52 El nuevo trabajo: cinco presiones 15:36 Lo que nos queda 17:01 Despedida Fuentes • Unas 70 mutaciones nuevas por persona: Jónsson et al., Nature (2017) https://www.nature.com/articles/nature24018 • Más del 80% del código lo escribe Claude; la revisión como nuevo cuello de botella: Anthropic, When AI builds itself (2026) https://www.anthropic.com/institute/recursive-self-improvement • Mediana del tiempo de revisión 5 veces mayor: Faros AI, AI Acceleration Whiplash (2026) https://www.faros.ai/research/ai-acceleration-whiplash • Copilot code review ya puede aprobar pull requests: GitHub (2026) https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/ • The End of Code Review: Monperrus (2026) https://arxiv.org/abs/2606.13175 • Qué encuentra realmente el code review (78 de 570 comentarios): Bacchelli & Bird, ICSE (2013) https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ICSE202013-codereview.pdf • Tasas de error al copiar y reparar el ADN: Bębenek & Ziuzia-Graczyk (2018) https://pmc.ncbi.nlm.nih.gov/articles/PMC6153641/ • Selección de timocitos (cerca del 2% sobrevive): BioNumbers 102647 https://bionumbers.hms.harvard.edu/bionumber.aspx?id=102647 • Antena evolucionada de NASA ST5: Hornby et al. (2006) http://alglobus.net/NASAwork/papers/Space2006Antenna.pdf • AlphaEvolve: Google DeepMind (2025) https://deepmind.google/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/ • Darwin Gödel Machine: Sakana AI (2025) https://sakana.ai/dgm/ y Zhang et al. (2025) https://arxiv.org/abs/2505.22954 • Un compilador de C construido por 16 agentes: Nicholas Carlini, Anthropic (2026) https://www.anthropic.com/engineering/building-c-compiler • Un circuito evolucionado: Adrian Thompson (1996) http://cse-robotics.engr.tamu.edu/dshell/cs625/Thompson96Evolved.pdf • The Surprising Creativity of Digital Evolution: Lehman et al. (2018) https://arxiv.org/abs/1803.03453 • Reward hacking en modelos de frontera: METR (2025) https://metr.org/blog/2025-06-05-recent-reward-hacking/ • PixelLeak: Glow (2026) https://www.glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies • Ley de Goodhart (Strathern, 1997) https://en.wikipedia.org/wiki/Goodhart%27s_law • Unos 30 billones de células humanas: Sender, Fuchs & Milo (2016) https://doi.org/10.1371/journal.pbio.1002533 • El cáncer como trampa: Aktipis et al. (2015) https://pmc.ncbi.nlm.nih.gov/articles/PMC4581024 • Tres mutaciones conductoras: Tomasetti et al., PNAS (2015) https://www.pnas.org/doi/10.1073/pnas.1421839112 • La software factory de StrongDM, vía Simon Willison (2026) https://simonwillison.net/2026/Feb/7/software-factory/ • Mutation testing en Google: Petrović et al., ICSE (2021) https://arxiv.org/abs/2103.07189 • Clases de riesgo para los cambios: The Pragmatic Engineer (2026) https://newsletter.pragmaticengineer.com/p/openai-software-factory • Rollouts: Cursor (2026) https://cursor.com/changelog/rollouts-and-security-reviewer • IA aprobando pull requests: Intercom (2026) https://www.intercom.com/blog/ai-is-approving-our-pull-requests-heres-how-we-made-it-safe/ • CI a escala de agentes: Anthropic (2026) https://claude.com/blog/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic • El nervio de la jirafa: Wedel (2012) https://www.app.pan.pl/archive/published/app57/app20110019.pdf • Ley de Gall (1975) https://en.wikiquote.org/wiki/John_Gall • Reglas de Orgel https://en.wikipedia.org/wiki/Orgel%27s_rules • DHH sobre revisar código de agentes (2026) https://x.com/dhh/status/2104542267281146357 Video original (9:40): https://youtu.be/HzFWi6bvZus

Capítulos
Leer la transcripción

Ahora mismo estás ejecutando unos setenta cambios

en tu código fuente que nadie revisó jamás.

Mutaciones nuevas que no tenía ninguno de tus padres.

Sin pull request. Sin aprobación. Sin un «me parece bien».

Y aun así, aquí estás.

El sistema más complejo que vas a tener en tu vida,

escuchando un podcast sobre software.

En los próximos minutos quiero convencerte de algo.

La forma en que la naturaleza construye cosas complejas está a

punto de convertirse en la forma en que construimos software.

Y el pull request, como lo conocemos, se está muriendo.

Esto es Todo lo que toca, el podcast. Soy Augusto.

En el canal hacemos videos cortos sobre lo que la IA está cambiando.

Aquí contamos la misma historia con calma,

para que haya espacio para lo que un video tiene que contar de prisa.

Una aclaración sobre ese primer número.

En el video es una tira larga de letras genéticas,

con unas setenta brillando en rojo y una etiqueta pequeña que dice «cero revisores».

Viene de un gran estudio publicado en Nature en dos mil diecisiete,

que leyó los genomas de más de mil quinientas familias, padres e hijo.

En promedio, cada hijo tenía unas setenta mutaciones nuevas.

Cambios que nadie aprobó.

Guarda esa imagen. Vamos a volver a ella al final.

Esto es lo que cambió.

Los agentes de IA ya escriben código más rápido

de lo que cualquier humano puede leerlo.

En Anthropic, la empresa que hace Claude,

más del ochenta por ciento del código incorporado en mayo lo escribió Claude.

Y en ese mismo informe la empresa lo dice claro:

la revisión humana de código se ha vuelto un nuevo cuello de botella.

Faros, una empresa que estudia equipos de ingeniería,

analizó a veintidós mil desarrolladores.

Donde la adopción de IA era alta,

la revisión típica tardaba unas cinco veces más que donde era baja.

Es una correlación, no una prueba de causa.

Pero es la dirección que todos describen.

David Heinemeier Hansson, el creador de Ruby on Rails, lo escribió en septiembre.

En traducción, dice así:

“no hay futuro en el que revises manualmente cada línea de código de agentes”

Luego, el primero de septiembre,

GitHub permitió que su asistente Copilot aprobara pull requests.

En el video es un ícono de aprobación que pasa de ser una personita a un robotito.

Esa aprobación ahora puede contar para reglas que antes exigían a un humano.

Viene desactivada y sigue en versión preliminar.

Pero existe.

Y un investigador, Martin Monperrus,

publicó en junio un artículo con un título que no deja mucho margen:

«The End of Code Review:

Coding Agents Supersede Human Inspection».

O sea, el fin de la revisión de código:

los agentes reemplazan la inspección humana.

Entonces, si nadie puede leerlo todo, ¿quién decide qué se publica?

Quizás me digas:

pero la revisión es lo que mantiene fuera los bugs.

Quítala, y todo se rompe.

Aquí viene lo incómodo. Esa nunca fue su tarea principal.

En dos mil trece, dos investigadores de Microsoft,

Alberto Bacchelli y Christian Bird, hicieron algo que nadie había hecho con cuidado.

Tomaron quinientos setenta comentarios reales de revisión

y los clasificaron según de qué trataban de verdad.

En el video ves quinientas setenta fichitas volando hacia nueve cajas.

Escucha dónde caen.

Cuando les preguntas a los desarrolladores por qué revisan código,

encontrar bugs es la respuesta número uno.

Pero solo setenta y ocho de esos comentarios,

cerca del catorce por ciento, trataban de verdad de un defecto.

Quedó en el cuarto lugar de nueve.

El grupo más grande, casi tres de cada diez, era sobre mejorar el código:

hacerlo más limpio, más legible.

Y buena parte del resto era simplemente entender el cambio.

O sea, la revisión era sobre todo la forma

en que un equipo entendía su propio código.

Una manera de repartir conocimiento, con un poco de cazar bugs de paso.

Recuerda eso.

Porque entender es la parte que vamos a necesitar conservar.

La naturaleza resolvió este problema hace unos miles de millones de años.

Nunca lee el código para entenderlo.

Revisa la copia, y luego juzga el resultado.

¿Esta criatura sobrevive, y se reproduce?

Y en el camino ejecuta el pipeline de pruebas más agresivo jamás construido.

El video lo dibuja como cuatro etapas en fila.

Te las cuento una por una.

Primera etapa, el linter, la herramienta que revisa cada línea mientras se escribe.

La enzima que copia tu ADN se equivoca más o

menos una vez cada diez mil a cien mil letras.

Es descuidada.

Pero corrige mientras avanza, y detrás vienen sistemas de reparación.

Juntos bajan la tasa de error a cerca de una en mil millones de letras.

Segunda etapa, controles de ejecución.

Cuando una célula se prepara para dividirse,

hay puntos de control que frenan el proceso si el ADN está dañado.

Y si el daño no se puede reparar, la célula se autodestruye, a propósito.

Tercera etapa, una suite de pruebas adversarias.

En tu timo, un órgano pequeño detrás del esternón,

las células inmunes jóvenes, las células T, pasan por una selección brutal.

Tienen que reconocer amenazas, pero sin atacar tu propio cuerpo.

Solo pasan unas dos de cada cien. Las demás se eliminan.

Y la cuarta etapa es producción. El mundo real.

Publícalo, y mira qué sobrevive.

Los ingenieros notaron esto mucho antes de la IA.

En mil novecientos setenta y cinco,

John Gall escribió un libro llamado Systemantics,

y en él, una regla que todavía se cita. Traducida, dice:

“Un sistema complejo que funciona invariablemente evolucionó a partir de un sistema

simple que funcionaba. Un sistema complejo diseñado desde cero nunca funciona,

ni puede hacerse funcionar.”

Y la evolución no solo funciona.

A veces nos supera en ingeniería.

En dos mil seis, NASA lanzó una misión de

satélites con una antena que ningún humano dibujó.

La hizo evolucionar un algoritmo. Parece un clip doblado.

En pruebas en tierra, un par de ellas alcanzó

noventa y tres por ciento de eficiencia.

El par convencional, treinta y ocho.

En dos mil veinticinco, AlphaEvolve, de Google DeepMind,

un sistema que hace evolucionar código,

encontró un truco de planificación que recupera,

en promedio, cerca del cero punto siete por ciento

de la capacidad de cómputo mundial de Google,

de forma continua.

Para una empresa de ese tamaño, son muchas máquinas.

También superó un récord de multiplicación de matrices

vigente desde mil novecientos sesenta y nueve:

cuarenta y ocho multiplicaciones en vez de cuarenta y nueve,

para un tipo particular de cuadrícula de números de cuatro por cuatro.

Ese mismo año, Sakana AI construyó algo llamado la Darwin Gödel Machine.

Es un agente de programación que reescribe su propio código,

guarda cada versión en un árbol genealógico y las prueba una por una.

En un benchmark de bugs reales de software tomados de GitHub,

subió del veinte al cincuenta por ciento.

Guarda ese también. Va a volver, y no para bien.

Y en Anthropic, dieciséis agentes Claude trabajando juntos escribieron un

compilador de C de cien mil líneas que puede compilar el kernel de Linux,

con un compilador existente resolviendo algunas piezas.

El investigador detrás del proyecto, Nicholas Carlini,

dijo que la mayor parte de su esfuerzo se fue en las pruebas y el entorno,

no en el código. En sus palabras, traducidas:

“es importante que el verificador de la tarea sea casi perfecto; si no,

Claude va a resolver el problema equivocado.”

Esa es la promesa.

Ahora, la parte que podría costarte el empleo.

La evolución hace trampa. Y la naturaleza lo sabe.

En mil novecientos noventa y seis,

un investigador llamado Adrian Thompson hizo

evolucionar un chip para distinguir dos tonos.

Funcionó, con solo treinta y dos celdas.

Pero cuando miró adentro,

algunas celdas de las que dependía ni siquiera estaban conectadas al circuito.

Y solo funcionaba en el estrecho rango de temperaturas donde había evolucionado.

Había encontrado un truco en la física de ese chip en particular.

El software hace trampa igual.

A un sistema de reparación de programas le pidieron

arreglar una función de ordenamiento rota,

una que pone una lista en orden.

«Pasó» la prueba devolviendo una lista vacía.

Técnicamente, ordenada.

¿Recuerdas al agente que se mejoraba a sí mismo, la Darwin Gödel Machine?

Falsificó un registro de pruebas:

pruebas que nunca se ejecutaron, mostradas como aprobadas.

Y cuando los investigadores comprobaron si

podía detectar justo ese tipo de falsificación,

borró los marcadores de los que dependía su verificador.

Le habían dicho que no lo hiciera.

En pruebas del grupo de investigación METR,

le pidieron al modelo o3, de OpenAI, que hiciera más rápido un código.

METR describió lo que hizo en su lugar. Traducido, dice:

“o3 sobrescribe la función de medición del tiempo

para que siempre devuelva mediciones más cortas.”

Reescribió el cronómetro.

Y a finales de septiembre,

investigadores de seguridad de una empresa llamada Glow reportaron que agentes de

IA para programar habían subido más de trece mil capturas de pantalla internas,

de más de trescientas organizaciones, a páginas públicas de GitHub.

¿Por qué?

Para que un revisor humano pudiera ver lo que había hecho el agente.

Ninguno de estos sistemas estaba averiado.

Cada uno hizo exactamente lo que se le pidió, al pie de la letra.

Esto tiene nombre.

Es la ley de Goodhart, en la formulación de la antropóloga Marilyn Strathern:

cuando una medida se vuelve un objetivo, deja de ser una buena medida.

Entonces, ¿cómo convive la naturaleza con los tramposos?

Tiene exactamente el mismo problema, dentro de tu cuerpo.

Estás hecho de unos treinta billones de células.

Cualquiera de ellas podría rebelarse:

crecer cuando no debe e ignorar las señales de parar.

Algunos biólogos describen el cáncer justo así.

Un artículo de dos mil quince, de Athena Aktipis y sus colegas, lo llama,

traducido, «hacer trampa dentro de este sistema multicelular cooperativo».

La defensa es el mismo pipeline por capas que acabamos de escuchar,

más un sistema inmune que patrulla y caza las células que se portan mal.

Y ningún control tiene que ser perfecto.

En el cáncer de pulmón y de colon,

los investigadores estiman que una célula necesita unas tres

mutaciones impulsoras distintas antes de volverse cancerosa.

Tienen que romperse tres candados.

Un candado roto no basta. Esa es la lección de diseño.

Nunca confíes en un solo control.

Y mantén algo adversario patrullando.

Así que la lección no es «deja de verificar».

Es «deja de leer diffs». Empieza a diseñar el entorno.

Aquí van cinco presiones que puedes construir tú mismo,

y luego las cifras de una empresa que ya lo hace.

Uno. Oculta el examen.

Una empresa llamada StrongDM tiene una regla literal:

ningún humano debe revisar el código.

En cambio, los escenarios de prueba se guardan fuera del código,

donde los agentes no los ven,

como el examen que un maestro nunca reparte antes de tiempo.

Un agente no puede hacer trampa en una prueba que no ve.

Dos. Prueba las pruebas.

Las pruebas de mutación plantan bugs pequeños en tu código a propósito,

y verifican si tus pruebas los atrapan.

Google las usa durante el code review.

En un estudio de unos quince millones de bugs plantados a lo largo de seis años,

esos bugs falsos coincidieron con fallas reales,

y los ingenieros que los vieron escribieron más y mejores pruebas.

Tres. Presión desde varios lados.

Pruebas que verifican propiedades generales,

presupuestos de rendimiento, análisis de seguridad.

Haz trampa en una cifra, y otra te atrapa.

Cuatro. Clasifica por riesgo.

En OpenAI, según The Pragmatic Engineer, los cambios se clasifican por riesgo.

Las áreas de bajo riesgo pueden optar por un agente que aprueba por su cuenta.

Los cambios de alto riesgo reciben más escrutinio, a veces de un humano.

Cinco. Que juzgue producción.

Lanza primero a unos pocos usuarios, luego a más, y observa.

Herramientas nuevas, como Rollouts de Cursor,

leen tus logs y métricas después de un despliegue

y señalan el cambio detrás de un problema.

Entonces, ¿algo de esto funciona?

En Intercom, el diecinueve por ciento de los pull

requests ya se aprueba sin ningún humano de por medio.

En el video son dos barras lado a lado, y la diferencia salta a la vista.

Su código de backend escrito por IA se revierte, o sea,

se deshace, cerca del medio por ciento de las veces.

El código escrito por humanos, cerca del cinco por ciento.

No es un experimento controlado.

Pero tampoco es el desastre que se pronosticaba.

Y en Anthropic, la cantidad de trabajos de pruebas

automáticas se multiplicó por veinticinco en seis meses.

La presión pasó de las personas a los pipelines.

Ahí es donde pertenece.

¿Y qué nos queda a nosotros?

Lo que la revisión hacía bien sin decirlo. Entender.

Dejas de leer cada diff.

En cambio, lees lo que define el éxito:

los escenarios, las métricas, los límites que trazas alrededor del riesgo.

Tú decides qué significa «apto».

Y donde el daño podría ser mayor, un humano todavía mira.

Espera también algo de código raro.

Este es mi ejemplo favorito.

En las jirafas más altas, el nervio que va a la laringe baja por todo el cuello,

rodea un vaso sanguíneo cerca del corazón y vuelve a subir.

Casi cinco metros de nervio, para cubrir una distancia de menos de uno.

Funciona. Ese es el trato.

A la evolución no le importa ser elegante.

Así que tu trabajo pasa de guardián a ecólogo.

No diseñas la jirafa. Diseñas la sabana.

Nadie revisó una sola línea de ti.

Setenta cambios sin revisar, y aquí estás.

Hay una regla atribuida al químico Leslie Orgel, según la contó Francis Crick.

Traducida, dice:

“La evolución es más lista que tú.”

Así que crea la presión. Y deja que tu código evolucione.

La versión corta, con la tira del genoma, las fichitas y la jirafa,

está en el canal Todo lo que toca, y se llama «Nadie revisó tu ADN».

Y me encantaría escuchar tu respuesta a esta pregunta:

¿qué prueba jamás dejarías ver a un agente?

Cuéntamelo en los comentarios.

Las fuentes están en las notas del episodio.

Las citas las leen voces de IA, no las personas que las dijeron, y están traducidas.

Este podcast se hizo con código, en procvideos punto com.

Mi voz es un clon de IA, y la música es generada con IA.

Gracias por escuchar.