00:00:00[MÚSICA]
00:00:21Hola a todos, buenas tardes.
00:00:22Voy a empezar mi charla con una confesión.
00:00:26He enviado código que no terminaba de entender.
00:00:29Lo generé, lo probé, lo implementé, pero no sabía explicar cómo funcionaba.
00:00:33Y la cuestión es esta: apuesto a que todos ustedes también lo han hecho.
00:00:37[RISAS]
00:00:40Ahora que todos podemos admitir que ya no entendemos
00:00:41el código que lanzamos, quiero hacer un pequeño viaje
00:00:44para ver cómo hemos llegado a este punto.
00:00:46Primero, miremos atrás, porque la historia suele repetirse.
00:00:50Segundo, hemos caído en una especie de trampa.
00:00:52Hemos confundido lo fácil con lo simple.
00:00:55Y por último, hay una solución, pero requiere que no deleguemos nuestro pensamiento.
00:01:00Pasé los últimos años en Netflix impulsando la adopción de herramientas de IA.
00:01:05Y debo decir que la aceleración es totalmente real.
00:01:07Tareas pendientes que antes tomaban días, ahora se hacen en horas.
00:01:10Y grandes refactorizaciones planeadas por años finalmente se están ejecutando.
00:01:15Pero aquí está el detalle.
00:01:16Los grandes sistemas de producción siempre fallan de formas inesperadas.
00:01:19Miren lo que pasó con Cloudflare hace poco.
00:01:21Cuando eso ocurre, más vale que entiendas el código que estás depurando.
00:01:23El problema es que ahora generamos código a tal velocidad y volumen
00:01:28que a nuestro entendimiento le cuesta seguirle el ritmo.
00:01:29Vaya que lo sé, yo mismo lo he hecho.
00:01:34He generado un montón de código, lo he mirado y he pensado: "No tengo idea de qué hace esto".
00:01:39Pero como las pruebas pasaron y funcionaba, lo envié a producción.
00:01:41Lo cierto es que esto no es algo realmente nuevo.
00:01:44Cada generación de ingenieros de software acaba chocando contra un muro
00:01:48donde la complejidad del software supera su capacidad para gestionarla.
00:01:50No somos los primeros en enfrentar una crisis de software,
00:01:52pero sí los primeros en enfrentarla a esta escala infinita de generación.
00:01:56Así que retrocedamos un poco para ver dónde empezó todo.
00:01:58A finales de los 60 y principios de los 70, varios científicos informáticos brillantes
00:02:03se reunieron y dijeron: "Estamos en una crisis de software".
00:02:06Había una demanda enorme de software y no lográbamos dar abasto.
00:02:11Los proyectos tardaban demasiado y todo iba muy lento.
00:02:15No estábamos haciendo un buen trabajo.
00:02:16Entonces Dijkstra soltó una frase genial.
00:02:20Dijo —parafraseando una cita más larga— que cuando teníamos
00:02:23computadoras débiles, programar era un problema leve.
00:02:26Pero ahora que tenemos computadoras gigantes, programar es un problema gigante.
00:02:31Explicaba que mientras la potencia del hardware crecía por un factor de mil,
00:02:34las necesidades de software de la sociedad crecían en la misma proporción.
00:02:37Y nos tocaba a nosotros, los programadores, encontrar la forma
00:02:41de dar soporte a ese volumen de software cada vez mayor.
00:02:43Esto ocurre de forma cíclica.
00:02:47En los 70 nació el lenguaje C para escribir sistemas más grandes.
00:02:50En los 80 llegaron las computadoras personales y cualquiera podía programar.
00:02:53En los 90 tuvimos la programación orientada a objetos.
00:02:56Esas jerarquías de herencia infernales... gracias a Java por eso.
00:03:00En los 2000 llegó Agile, con sprints y Scrum Masters
00:03:03diciéndonos qué hacer; se acabó el modelo de cascada.
00:03:06En los 2010 tuvimos la nube, el móvil, DevOps, todo;
00:03:09el software realmente se devoró al mundo.
00:03:10Y hoy tenemos la IA: Co-Pilot, Cursor, Claude, Codex, Gemini, lo que quieran.
00:03:17Podemos generar código tan rápido como podamos describirlo.
00:03:19El patrón continúa, pero la escala ha cambiado; ahora es infinita.
00:03:23Fred Brooks, conocido por escribir "The Mythical Man-Month",
00:03:29también escribió un artículo en 1986 llamado "No Silver Bullet".
00:03:32Allí argumentaba que ninguna innovación aislada nos daría
00:03:36una mejora de un orden de magnitud en la productividad del software.
00:03:38¿Por qué?
00:03:40Porque decía que la parte difícil no era la mecánica de codificar, la sintaxis,
00:03:44el tecleo o el código repetitivo.
00:03:45Se trataba de entender el problema real y diseñar la solución.
00:03:49Ninguna herramienta puede eliminar esa dificultad fundamental.
00:03:52Cada técnica creada hasta hoy facilita la mecánica.
00:03:55Pero el reto principal,
00:03:57entender qué construir y cómo debe funcionar, sigue siendo igual de difícil.
00:04:00Si el problema no es la mecánica, ¿por qué seguimos optimizándola?
00:04:06¿Cómo terminan ingenieros expertos con código que no comprenden?
00:04:09La respuesta, creo, reside en dos palabras que solemos confundir: simple y fácil.
00:04:14Solemos usarlas indistintamente, pero
00:04:16realmente significan cosas completamente diferentes.
00:04:18En la cena de ponentes se supo que soy fan de Clojure, así que
00:04:21esto me resulta familiar.
00:04:23Rich Hickey, el creador del lenguaje de programación Clojure,
00:04:25explicó esto en su charla de 2011 llamada "Simple Made Easy".
00:04:29Definió "simple" como algo de un solo pliegue, una sola trenza, sin enredos.
00:04:33Cada pieza hace una cosa y no se entrelaza con las demás.
00:04:36Y definió "fácil" como lo que está adyacente, lo que está al alcance.
00:04:39¿A qué puedes acceder sin esfuerzo?
00:04:41Copiar, pegar y lanzar.
00:04:43Lo simple trata sobre la estructura.
00:04:45Lo fácil trata sobre la proximidad.
00:04:48La cuestión es que no podemos hacer algo simple solo con desearlo.
00:04:51La simplicidad requiere pensamiento, diseño y desenredar nudos.
00:04:54Pero siempre podemos hacer algo más fácil.
00:04:56Solo hay que ponerlo más cerca.
00:04:57Instalar un paquete, generarlo con IA o copiar una solución de Stack Overflow.
00:05:03Es la naturaleza humana tomar el camino fácil.
00:05:06Estamos programados para ello.
00:05:07Como dije, copias algo de Stack Overflow porque está ahí a la mano.
00:05:10Un framework que lo gestiona todo por arte de magia: instalar y listo.
00:05:14Pero fácil no significa simple.
00:05:15Fácil significa que puedes añadir cosas a tu sistema rápidamente.
00:05:18Simple significa que puedes entender el trabajo que has hecho.
00:05:20Cada vez que elegimos lo fácil, elegimos velocidad ahora y complejidad después.
00:05:24Y, sinceramente, ese intercambio solía funcionar.
00:05:27La complejidad en nuestro código se acumulaba lo bastante lento como para
00:05:31poder refactorizar, repensar y reconstruir cuando fuera necesario.
00:05:34Creo que la IA ha destruido ese equilibrio.
00:05:36Porque es el botón de "fácil" definitivo.
00:05:37Hace que el camino fácil sea tan fluido
00:05:38que ya ni siquiera consideramos el camino simple.
00:05:41¿Para qué pensar en arquitectura cuando el código aparece al instante?
00:05:44Permítanme mostrarles cómo ocurre esto.
00:05:47Cómo una tarea sencilla se convierte en un caos de complejidad
00:05:50a través de esa interfaz conversacional que tanto nos gusta.
00:05:52Es un ejemplo ficticio, pero digamos que en nuestra app
00:05:55queremos añadir autenticación.
00:05:57Pedimos "añadir auth" y obtenemos un archivo auth.js limpio.
00:06:01Iteramos un poco y para el mensaje cinco todo va bien.
00:06:02Luego decimos: "Vale, vamos a añadir OAuth también",
00:06:04así que ahora tenemos un auth.js y un OAuth.js.
00:06:07Seguimos iterando y descubrimos que las sesiones fallan.
00:06:11Y nos encontramos con un montón de conflictos.
00:06:12Al llegar al turno 20, ya no estás teniendo una conversación.
00:06:15Estás gestionando contextos que se han vuelto tan complejos que ni tú recuerdas
00:06:18todas las restricciones que has ido añadiendo.
00:06:20Código muerto de enfoques abandonados.
00:06:22Pruebas que se arreglaron solo para que pasaran.
00:06:25Fragmentos de tres soluciones distintas porque acabas diciendo: "Espera, mejor así".
00:06:28Cada nueva instrucción está sobrescribiendo patrones arquitectónicos.
00:06:31Pedimos que funcionara la autenticación, y funcionó.
00:06:33Pedimos arreglar este error, y lo hizo.
00:06:35No hay resistencia contra las malas decisiones de arquitectura.
00:06:38El código simplemente muta para satisfacer tu última petición.
00:06:40Cada interacción es elegir lo fácil sobre lo simple.
00:06:43Y lo fácil siempre implica más complejidad.
00:06:46Sabemos que no es lo ideal, pero cuando el camino fácil es tan accesible, lo tomamos.
00:06:50Y la complejidad se va acumulando hasta que es demasiado tarde.
00:06:52La IA lleva lo fácil a su extremo lógico.
00:06:58Decides lo que quieres y obtienes el código al instante.
00:07:00Pero ahí reside el peligro.
00:07:02El código generado trata todos los patrones de tu base de código por igual.
00:07:06Cuando un agente analiza tu código, cada línea se vuelve un patrón a preservar.
00:07:10Esa validación de autenticación en la línea 47 es un patrón.
00:07:13Ese código extraño de gRPC que imita a GraphQL que añadí en 2019,
00:07:18también es un patrón.
00:07:19La deuda técnica no se registra como deuda, solo como más código.
00:07:22El verdadero problema aquí es la complejidad.
00:07:25Sé que he repetido mucho esa palabra sin definirla realmente.
00:07:29La mejor forma de verla es como lo opuesto a la simplicidad.
00:07:31Simplemente significa estar entrelazado.
00:07:33Cuando las cosas son complejas, todo toca a todo lo demás.
00:07:36No puedes cambiar una cosa sin afectar a otras diez.
00:07:41Volviendo al artículo de Fred Brooks, "No Silver Bullet".
00:07:43En él identificó dos tipos principales de complejidad en cada sistema.
00:07:47Está la complejidad esencial, que es la dificultad fundamental
00:07:51del problema real que intentas resolver.
00:07:53Los usuarios deben pagar, los pedidos deben completarse.
00:07:56Es la complejidad de por qué tu sistema de software existe en primer lugar.
00:08:00Y segundo, está la idea de la complejidad accidental.
00:08:03Todo lo demás que hemos añadido: apaños, código defensivo,
00:08:06frameworks, abstracciones que tenían sentido hace tiempo.
00:08:09Es todo lo que montamos para que el código en sí funcione.
00:08:11En una base de código real, ambos tipos de complejidad están por doquier.
00:08:16Y se enredan tanto que separarlos requiere contexto,
00:08:19historia y experiencia.
00:08:20Lo que genera la IA no hace tal distinción.
00:08:24Y así, todos los patrones se siguen preservando.
00:08:26Aquí tienen un ejemplo real de un trabajo que estamos haciendo en Netflix.
00:08:32Tengo un sistema con una capa de abstracción situada entre nuestro antiguo
00:08:35código de autorización de hace unos cinco años y un nuevo sistema centralizado.
00:08:41No teníamos tiempo para rehacer toda la app, así que
00:08:42simplemente pusimos un puente o "shim" en medio.
00:08:44Ahora con la IA es una gran oportunidad para refactorizar y usar
00:08:47el sistema nuevo directamente; parece una petición sencilla, ¿verdad?
00:08:50Pues no; el código viejo estaba tan acoplado a sus patrones
00:08:56de autorización... teníamos permisos entremezclados con la lógica de negocio,
00:08:59roles implícitos en los modelos de datos y llamadas de auth por cientos de archivos.
00:09:03El agente empezaba a refactorizar, avanzaba unos pocos archivos,
00:09:07chocaba con una dependencia que no podía desenredar y perdía el control hasta rendirse.
00:09:10O peor, intentaba preservar lógica del sistema viejo
00:09:16recreándola en el sistema nuevo, lo cual tampoco es nada bueno.
00:09:19El problema es que no podía ver las costuras.
00:09:23No distinguía dónde terminaba la lógica de negocio y dónde empezaba la de auth.
00:09:26Todo estaba tan enredado que, incluso con información perfecta,”
00:09:30la IA no encontraba un camino limpio.
00:09:33Cuando tu complejidad accidental se enreda así,
00:09:35la IA no es la mejor ayuda para mejorar las cosas.
00:09:38He visto que solo añade más capas encima.
00:09:40Nosotros podemos notar la diferencia, al menos cuando nos detenemos a pensar.
00:09:45Sabemos qué patrones son esenciales y
00:09:47cuáles son solo la forma en que alguien lo resolvió hace años.
00:09:50Poseemos el contexto que la IA no puede inferir, pero
00:09:53solo si nos tomamos el tiempo de hacer esas distinciones antes de empezar.
00:09:56Entonces, ¿cómo se hace realmente?
00:10:01¿Cómo separas la complejidad accidental de la esencial
00:10:04cuando te enfrentas a una base de código enorme?
00:10:07El código en el que trabajo en Netflix tiene un millón de líneas de Java,
00:10:10y el servicio principal tiene unos cinco millones de tokens, la última vez que miré.
00:10:13No hay ventana de contexto a la que tenga acceso que pueda contenerlo.
00:10:17Así que cuando quise trabajar con él, primero pensé:
00:10:19"Tal vez pueda copiar grandes franjas de código en el contexto
00:10:23y ver si los patrones emergen",
00:10:24a ver si era capaz de entender qué estaba pasando.
00:10:26Y al igual que con la refactorización anterior, la respuesta se perdió en su propia complejidad.
00:10:29el resultado simplemente se perdió en su propia complejidad.
00:10:31Así que esto me obligó a hacer algo diferente.
00:10:34Tuve que seleccionar qué incluir: documentos de diseño, arquitectura, diagramas,
00:10:37interfaces clave, lo que se te ocurra.
00:10:39Y dedicar tiempo a redactar los requisitos de cómo debían interactuar los componentes
00:10:42y qué patrones seguir.
00:10:43Básicamente, estaba escribiendo una especificación.
00:10:45Cinco millones de tokens se convirtieron en 2000 palabras de especificación.
00:10:49Y para ir más allá, tomar esa especificación y
00:10:52crear un conjunto exacto de pasos de código para ejecutar.
00:10:55Sin instrucciones vagas, solo una secuencia precisa de operaciones.
00:10:58Descubrí que esto producía un código mucho más limpio y enfocado que yo podía entender.
00:11:02Así que lo definí primero y planifiqué su propia ejecución.
00:11:05Esto se convirtió en el enfoque que llamé "compresión de contexto" hace un tiempo.
00:11:11Pero ustedes lo llaman ingeniería de contexto, su espectro de desarrollo,
00:11:13como quieran llamarlo.
00:11:15El nombre no importa.
00:11:16Lo único que importa aquí es que pensar y planificar se vuelven la mayor parte del trabajo.
00:11:20Permítanme mostrarles cómo funciona esto en la práctica.
00:11:22Tenemos el paso uno, fase uno: investigación.
00:11:26Ya saben, le doy todo de antemano.
00:11:28Diagramas de arquitectura, documentación, hilos de Slack.
00:11:31Digo, ya hemos pasado por esto varias veces.
00:11:32Pero realmente, aporten tanto contexto como puedan que sea relevante
00:11:35para los cambios que van a realizar.
00:11:36Y luego usen al agente para analizar el código base y
00:11:39mapear los componentes y las dependencias.
00:11:42Esto no debería ser un proceso de un solo intento.
00:11:43Me gusta indagar, decir algo como: "¿qué hay del almacenamiento en caché?"
00:11:46"¿Cómo maneja esto los fallos?"
00:11:47Y cuando su análisis es erróneo, lo corrijo.
00:11:49Y si le falta contexto, se lo proporciono.
00:11:51Cada iteración refina su análisis.
00:11:55El resultado aquí es un único documento de investigación.
00:11:57Esto es lo que existe, esto es lo que se conecta con aquello,
00:11:59y esto es lo que afectará tu cambio.
00:12:01Horas de exploración se comprimen en minutos de lectura.
00:12:03Sé que Dex lo mencionó esta mañana, pero el punto de control humano aquí es crítico.
00:12:09Aquí es donde validas el análisis contra la realidad,
00:12:12el momento de mayor impacto en todo el proceso.
00:12:15Detecta errores aquí para prevenir desastres después.
00:12:17Pasemos a la fase dos.
00:12:20Ahora que tienes una investigación válida en mano,
00:12:22creamos un plan de implementación detallado: estructura de código real,
00:12:25firmas de funciones, definiciones de tipos, flujo de datos.
00:12:28Quieres que esto sea algo que cualquier desarrollador pueda seguir.
00:12:30Lo comparo con pintar siguiendo los números.
00:12:32Deberías poder dárselo a tu ingeniero más novato y decirle: "haz esto".
00:12:35Y si lo copian línea por línea, simplemente debería funcionar.
00:12:38En este paso es donde tomamos muchas de las decisiones arquitectónicas importantes.
00:12:43Asegurarse de que la lógica compleja sea correcta.
00:12:45Asegurarse de que los requisitos de negocio sigan las buenas prácticas.
00:12:50Asegurarse de que haya buenos límites de servicio, una separación limpia y
00:12:52evitar cualquier acoplamiento innecesario.
00:12:54Detectamos los problemas antes de que ocurran porque ya los hemos vivido.
00:12:57La IA no tiene esa opción.
00:12:59Trata cada patrón como si fuera un requisito.
00:13:01La verdadera magia en este paso es la velocidad de revisión.
00:13:05Podemos validar este plan en minutos y saber exactamente qué se va a construir.
00:13:10Y para mantener el ritmo al que queremos generar código,
00:13:13necesitamos ser capaces de comprender lo que estamos haciendo con la misma rapidez.
00:13:18Por último, tenemos la implementación, y ahora que tenemos un plan claro
00:13:22respaldado por una investigación sólida, esta fase debería ser bastante sencilla.
00:13:26Y ese es precisamente el objetivo.
00:13:28Cuando la IA tiene una especificación clara que seguir, el contexto se mantiene limpio
00:13:31y enfocado.
00:13:32Hemos evitado la espiral de complejidad de las conversaciones largas.
00:13:36Y en lugar de 50 mensajes de código evolutivo,
00:13:38tenemos tres resultados enfocados, cada uno validado antes de continuar.
00:13:41Sin enfoques abandonados, sin patrones conflictivos,
00:13:44sin momentos de "espera, en realidad..." que dejan código muerto por todas partes.
00:13:48Para mí, la verdadera recompensa de esto es que puedes usar un agente en segundo plano
00:13:52para hacer gran parte del trabajo, porque ya hiciste todo el pensamiento y el trabajo duro previo.
00:13:56Él puede simplemente comenzar la implementación, tú puedes irte a trabajar en otra cosa
00:13:59y regresar para la revisión.
00:14:01Y puedes revisar esto rápidamente porque solo estás verificando que se ajuste
00:14:04a tu plan, no tratando de entender si se inventó algo.
00:14:07El punto aquí es que no estamos usando la IA para que piense por nosotros.
00:14:12La estamos usando para acelerar las partes mecánicas
00:14:15mientras mantenemos nuestra capacidad de entenderlo.
00:14:17La investigación es más rápida, el plan más minucioso y la implementación más limpia.
00:14:21Sin embargo, el pensamiento, la síntesis y el juicio siguen siendo responsabilidad nuestra.
00:14:26¿Recuerdan aquel refactor de autorización que dije que la IA no podía manejar?
00:14:34Lo cierto es que ahora estamos trabajando en ello
00:14:37y estamos empezando a progresar bastante bien.
00:14:39Y no es porque hayamos encontrado mejores prompts.
00:14:42Descubrimos que ni siquiera podíamos lanzarnos a investigar, planificar
00:14:45e implementar.
00:14:46Tuvimos que realizar este cambio nosotros mismos a mano.
00:14:49Sin IA, solo leyendo el código, entendiendo las dependencias
00:14:52y haciendo cambios para ver qué se rompía.
00:14:53Esa migración manual fue, siendo sincero, un dolor de cabeza, pero fue crucial.
00:14:59Reveló todas las restricciones ocultas, qué invariantes debían mantenerse
00:15:02y qué servicios se romperían si cambiaba la autenticación.
00:15:05Cosas que ningún análisis de código nos habría revelado.
00:15:09Luego introdujimos ese pull request de la migración manual real en nuestra
00:15:14fase de investigación y lo usamos como semilla para cualquier investigación futura.
00:15:19Así, la IA pudo ver cómo es una migración limpia.
00:15:23El asunto es que cada una de estas entidades es ligeramente diferente, así que tenemos que
00:15:27interrogarla y decir: "Oye, ¿qué hacemos con esto?".
00:15:29Algunas cosas están encriptadas, otras no.
00:15:32Tuvimos que proporcionar ese contexto extra cada vez a través de mucha iteración.
00:15:35Entonces, y solo entonces, pudimos generar un plan que podría funcionar al primer intento.
00:15:41Y la palabra clave aquí es "podría", porque seguimos validando,
00:15:45ajustando y descubriendo casos extremos.
00:15:47El enfoque de las tres fases no es magia.
00:15:55Solo funciona porque hicimos esa primera migración a mano.
00:15:57Tuvimos que ganarnos el entendimiento antes de poder codificarlo en nuestro proceso.
00:16:01Sigo pensando que no hay balas de plata.
00:16:02No creo que existan mejores prompts, mejores modelos, o incluso mejores especificaciones.
00:16:06Solo existe el trabajo de entender tu sistema lo suficientemente a fondo
00:16:09como para realizar cambios en él de forma segura.
00:16:11Entonces, ¿por qué molestarse con todo esto?
00:16:15¿Por qué no simplemente iterar con la IA hasta que funcione?
00:16:18Eventualmente, los modelos serán lo bastante potentes y simplemente funcionará.
00:16:21Para mí, el hecho de que "funcione" no es suficiente.
00:16:24Hay una diferencia entre el código que pasa las pruebas y el código que sobrevive
00:16:27en producción.
00:16:28Entre sistemas que funcionan hoy y
00:16:31sistemas que pueden ser modificados por alguien más en el futuro.
00:16:34El verdadero problema aquí es una brecha de conocimiento.
00:16:38Cuando la IA puede generar miles de líneas de código en segundos,
00:16:41entenderlo podría llevarte horas, o quizás días si es complejo.
00:16:45Quién sabe, tal vez nunca si está así de enredado.
00:16:48Aquí hay algo de lo que no creo que mucha gente esté hablando
00:16:52todavía. Cada vez que dejamos de pensar para seguir el ritmo de la generación,
00:16:56no solo estamos añadiendo código que no entendemos.
00:16:58Estamos perdiendo nuestra capacidad de reconocer problemas.
00:17:00Ese instinto que te dice: "Oye, esto se está volviendo complejo",
00:17:03se atrofia cuando no entiendes tu propio sistema.
00:17:09El reconocimiento de patrones proviene de la experiencia.
00:17:11Cuando detecto una arquitectura peligrosa,
00:17:12es porque he sido yo quien ha estado despierto a las tres de la mañana lidiando con ella.
00:17:16Cuando insisto en soluciones más simples,
00:17:17es porque he tenido que mantener la alternativa de otra persona.
00:17:21La IA genera lo que le pides.
00:17:23No codifica lecciones de fracasos pasados.
00:17:25El enfoque de tres fases cierra esta brecha.
00:17:29Comprime el entendimiento en artefactos que podemos revisar a la velocidad de generación.
00:17:33Sin él, solo estamos acumulando complejidad más rápido de lo que podemos
00:17:37comprenderla.
00:17:39La IA cambia todo sobre cómo escribimos código, pero honestamente,
00:17:44no creo que cambie nada sobre por qué el software falla.
00:17:47Cada generación ha enfrentado su propia crisis de software.
00:17:50La generación de Dijkstra la enfrentó creando la disciplina de la ingeniería de software, y
00:17:54ahora nosotros enfrentamos la nuestra con la generación infinita de código.
00:17:56No creo que la solución sea otra herramienta o metodología.
00:18:01Es recordar lo que siempre hemos sabido: que el software es un esfuerzo humano.
00:18:05La parte difícil nunca fue escribir el código.
00:18:06Era saber qué escribir en primer lugar.
00:18:09Los desarrolladores que prosperen no serán solo los que generen más código.
00:18:13Serán los que entiendan qué están construyendo,
00:18:15los que aún puedan ver las costuras, los que puedan reconocer que están
00:18:18resolviendo el problema equivocado.
00:18:19Esos seguimos siendo nosotros.
00:18:20Eso solo seremos nosotros.
00:18:21Quiero terminar con una pregunta, y no creo que la pregunta sea si
00:18:25usaremos o no la IA.
00:18:26Eso es una conclusión inevitable.
00:18:28Ese tren ya partió.
00:18:30Para mí, la pregunta será si seguiremos entendiendo nuestros propios sistemas
00:18:33cuando la IA esté escribiendo la mayor parte de nuestro código.
00:18:35Muchas gracias.
00:18:37>> [APLAUSOS]
00:18:39[MÚSICA]