00:00:00(música animada)
00:00:02- Hola a todos, ¿cómo están?
00:00:23Es emocionante, soy Dex.
00:00:25Como dijeron en esa gran presentación,
00:00:27he estado trabajando con agentes por un tiempo.
00:00:29Nuestra charla, "12-Factor Agents", en AI Engineer en junio
00:00:32fue una de las más vistas de todos los tiempos.
00:00:34Creo que estuvo en el top ocho o algo así,
00:00:35una de las mejores de AI Engineer en junio.
00:00:38Puede que haya mencionado algo sobre la ingeniería de contexto.
00:00:41¿Por qué estoy aquí hoy? ¿De qué vengo a hablar?
00:00:44Quiero hablar sobre una de mis charlas favoritas
00:00:46de AI Engineer en junio,
00:00:47y sé que todos recibimos la actualización de Igor ayer,
00:00:49pero no me dejaron cambiar mis diapositivas,
00:00:50así que esto tratará sobre lo que Igor comentó en junio.
00:00:54Básicamente, encuestaron a 100,000 desarrolladores
00:00:56de empresas de todos los tamaños,
00:00:58y descubrieron que la mayor parte del tiempo
00:01:00que usas IA para la ingeniería de software,
00:01:01estás rehaciendo mucho trabajo, hay mucha rotación de código.
00:01:04Y realmente no funciona bien para tareas complejas,
00:01:07en bases de código heredadas o ya existentes.
00:01:08Y pueden ver en el gráfico que, básicamente,
00:01:10estás entregando mucho más,
00:01:11pero mucho es solo retocar la basura
00:01:14que entregaste la semana pasada.
00:01:15Por otro lado, está el hecho de que
00:01:18si haces algo desde cero, un pequeño panel de Vercel,
00:01:21algo así, entonces funcionará genial.
00:01:25Pero si vas a entrar en una base de código de Java de 10 años,
00:01:28quizás no tanto.
00:01:29Y esto coincidía con mi experiencia.
00:01:30Personalmente, y hablando con muchos fundadores
00:01:32y grandes ingenieros: demasiada basura,
00:01:35fábricas de deuda técnica, no va a funcionar en nuestra base de código.
00:01:37Tal vez algún día, cuando los modelos mejoren.
00:01:40Pero de eso trata la ingeniería de contexto.
00:01:42¿Cómo podemos sacar el máximo provecho de los modelos actuales?
00:01:44¿Cómo gestionamos nuestra ventana de contexto?
00:01:46Hablamos de esto en agosto.
00:01:48Tengo que confesar algo.
00:01:49La primera vez que usé Claude Code, no me impresionó.
00:01:53Fue como: "vale, esto es un poco mejor",
00:01:54"entiendo el punto, me gusta la interfaz".
00:01:56Pero desde entonces, como equipo, descubrimos algo
00:01:59con lo que realmente pudimos obtener
00:02:01de dos a tres veces más rendimiento.
00:02:02Y estábamos produciendo tanto que no tuvimos otra opción
00:02:06que cambiar la forma en que colaborábamos.
00:02:07Reestructuramos todo sobre cómo creamos software.
00:02:11Éramos un equipo de tres, tomó ocho semanas,
00:02:12fue malditamente difícil.
00:02:14Pero ahora que lo resolvimos, no hay vuelta atrás.
00:02:16De esto va lo de no generar código basura.
00:02:18Creo que llegamos a alguna parte con esto.
00:02:20Se volvió súper viral en Hacker News en septiembre.
00:02:23Tenemos miles de personas que han ido a GitHub
00:02:25a buscar nuestro sistema de prompts: investigar, planificar, implementar.
00:02:28Los objetivos aquí, a los que llegamos casi sin querer,
00:02:31son: necesitamos IA que funcione bien en bases de código heredadas.
00:02:35Que pueda resolver problemas complejos.
00:02:38Sin basura, ¿verdad? No más código mediocre.
00:02:40Y teníamos que mantener la alineación mental.
00:02:42Hablaré un poco más sobre
00:02:43lo que eso significa en un minuto.
00:02:44Y, por supuesto, queremos gastar, como con todo,
00:02:46la mayor cantidad de tokens posible.
00:02:47Lo que podemos delegar significativamente a la IA
00:02:50es realmente muy importante.
00:02:52Es un nivel de apalancamiento altísimo.
00:02:53Esto es ingeniería de contexto avanzada para agentes de programación.
00:02:56Empezaré por enmarcar esto.
00:02:58La forma más ingenua de usar un agente de programación
00:03:01es pedirle algo y luego decirle por qué está mal,
00:03:03redirigirlo y pedir, y pedir, y pedir,
00:03:05hasta que te quedas sin contexto, te rindes o te pones a llorar.
00:03:09Podemos ser un poco más inteligentes al respecto.
00:03:11La mayoría descubre esto bastante pronto
00:03:13en su exploración de la IA: que podría ser mejor
00:03:17si empiezas una conversación y vas por mal camino,
00:03:21simplemente iniciar una nueva ventana de contexto.
00:03:24Dices: "vale, fuimos por ese camino".
00:03:25"Empecemos de nuevo".
00:03:26Mismo prompt, misma tarea.
00:03:27Pero esta vez, iremos por este otro camino.
00:03:29Y "no vayas por allá porque eso no funciona".
00:03:31Entonces, ¿cómo saber cuándo es hora de empezar de cero?
00:03:34Si ves esto,
00:03:37(risas del público)
00:03:39probablemente sea hora de reiniciar, ¿verdad?
00:03:41Esto es lo que dice Claude cuando le dices que la está pifiando.
00:03:45Pero podemos ser aún más astutos.
00:03:47Podemos hacer lo que yo llamo compactación intencional.
00:03:50Y esto es, básicamente, si estás en el camino correcto o no,
00:03:53puedes tomar tu ventana de contexto actual
00:03:56y pedirle al agente que la comprima en un archivo markdown.
00:03:59Puedes revisarlo, puedes etiquetarlo.
00:04:00Y luego, cuando el nuevo agente comience,
00:04:02se pone a trabajar directamente en lugar de tener que
00:04:04hacer toda esa búsqueda y comprensión del código
00:04:05para ponerse al día.
00:04:07¿Qué se incluye en la compactación?
00:04:09La pregunta es qué es lo que ocupa espacio
00:04:11en tu ventana de contexto.
00:04:13Busca archivos, entiende el flujo del código,
00:04:17edita archivos, revisa resultados de pruebas y compilación.
00:04:20Y si tienes uno de esos MCP que vuelca JSON
00:04:22y un montón de UUID en tu ventana de contexto,
00:04:25que Dios te ayude.
00:04:26Entonces, ¿qué deberíamos compactar?
00:04:28Luego daré más detalles específicos,
00:04:30pero esto es una compactación muy buena.
00:04:31Es exactamente en lo que estamos trabajando,
00:04:33los archivos exactos y los números de línea
00:04:34que importan para el problema que estamos resolviendo.
00:04:37¿Por qué nos obsesiona tanto el contexto?
00:04:39Porque a los LLM los criticaron mucho en YouTube por esto.
00:04:42No son funciones puras porque son no deterministas,
00:04:45pero no tienen estado.
00:04:46Y la única forma de obtener un mejor rendimiento de un LLM
00:04:49es introducir mejores tokens
00:04:51y así obtendrás mejores tokens de salida.
00:04:52Y así, en cada paso del ciclo,
00:04:53cuando Claude está eligiendo la siguiente herramienta
00:04:55o cualquier agente está eligiendo el siguiente paso.
00:04:56Podría haber cientos de pasos siguientes correctos
00:04:58y cientos de pasos siguientes incorrectos.
00:05:00Pero lo único que influye en lo que saldrá después
00:05:03es lo que hay en la conversación hasta ahora.
00:05:05Así que vamos a optimizar esta ventana de contexto
00:05:07para que sea correcta, completa, tenga buen tamaño,
00:05:10y un poco de trayectoria.
00:05:11Lo de la trayectoria es interesante
00:05:12porque mucha gente dice:
00:05:13"bueno, le dije al agente que hiciera algo
00:05:16y lo hizo mal".
00:05:17"Así que lo corregí y le grité
00:05:18y luego volvió a hacerlo mal".
00:05:20"Y le volví a gritar".
00:05:21Y entonces el LLM mira esta conversación
00:05:23y dice: "vale, genial, hice algo mal
00:05:24y el humano me gritó,
00:05:25hice algo mal y el humano me gritó".
00:05:26"Así que el siguiente token más probable en esta charla
00:05:29es que mejor haga algo mal
00:05:31para que el humano me pueda gritar de nuevo".
00:05:33Así que ten cuidado con tu trayectoria.
00:05:35Si quisiéramos invertir esto,
00:05:36lo peor que puedes tener es información incorrecta,
00:05:39luego información faltante y finalmente demasiado ruido.
00:05:42Si les gustan las ecuaciones, hay una ecuación tonta
00:05:44si quieren pensarlo de esta manera.
00:05:47Jeff Huntley investigó mucho sobre agentes de programación.
00:05:51Él lo expresó muy bien.
00:05:51Cuanto más uses la ventana de contexto,
00:05:53peores resultados obtendrás.
00:05:55Esto nos lleva a un concepto.
00:05:56Un concepto muy, muy académico llamado "la zona tonta".
00:05:59Tienes tu ventana de contexto.
00:06:01Tienes unos 168,000 tokens aproximadamente.
00:06:03Algunos se reservan para la salida y la compactación.
00:06:05Esto varía según el modelo,
00:06:07pero usemos Claude Code como ejemplo aquí.
00:06:09Alrededor de la línea del 40% es donde empezarás
00:06:10a ver rendimientos decrecientes dependiendo de tu tarea.
00:06:14Si tienes demasiados MCP en tus agentes,
00:06:17estás haciendo todo tu trabajo en la zona tonta
00:06:18y nunca obtendrás buenos resultados.
00:06:21La gente ha hablado de esto.
00:06:21No voy a extenderme en eso.
00:06:22Tu experiencia puede variar.
00:06:23Ese 40% depende de lo compleja que sea la tarea,
00:06:26pero es una buena pauta general.
00:06:28Volviendo a la compactación, o como la llamaré de ahora en adelante,
00:06:31evitar inteligentemente la zona tonta.
00:06:33Podemos usar subagentes.
00:06:37Si tienes un subagente para el front-end, uno para el back-end,
00:06:39uno de QA y otro de ciencia de datos, por favor, detente.
00:06:44Los subagentes no sirven para antropomorfizar roles.
00:06:47Sirven para controlar el contexto.
00:06:49Y lo que puedes hacer es, si quieres averiguar
00:06:51cómo funciona algo en una base de código grande,
00:06:53puedes dirigir al agente de programación para que haga esto
00:06:55si es que admite subagentes,
00:06:56o puedes construir tu propio sistema de subagentes,
00:06:58pero básicamente dices: "ve a buscar cómo funciona esto".
00:07:00Y puede abrir una nueva ventana de contexto
00:07:03que se encargará de toda esa lectura y búsqueda
00:07:05y localización y lectura de archivos completos
00:07:07y comprensión de la base de código,
00:07:09y luego simplemente devolver un mensaje muy, muy sucinto
00:07:13al agente principal diciendo algo como:
00:07:14"oye, el archivo que buscas está aquí".
00:07:17El agente principal puede leer ese único archivo y ponerse a trabajar.
00:07:20Y esto es realmente potente.
00:07:22Si los manejas correctamente,
00:07:23puedes obtener buenas respuestas como esta,
00:07:25y así gestionar tu contexto realmente bien.
00:07:29Lo que funciona incluso mejor que los subagentes
00:07:30o una capa por encima de los subagentes,
00:07:32es un flujo de trabajo que llamo compactación intencional frecuente.
00:07:35Hablaremos de investigar, planificar e implementar en un momento,
00:07:37pero el punto es que estás constantemente
00:07:39manteniendo tu ventana de contexto pequeña.
00:07:41Estás construyendo todo tu flujo de trabajo en torno a la gestión del contexto,
00:07:45así que viene en tres fases: investigar, planificar e implementar,
00:07:48y vamos a intentar mantenernos en la "zona inteligente" todo el tiempo.
00:07:51La investigación se trata de entender
00:07:53cómo funciona el sistema, encontrar el archivo correcto,
00:07:55y mantenerse objetivo.
00:07:56Aquí hay un prompt que puedes usar para investigar.
00:07:58Aquí está el resultado de un prompt de investigación.
00:08:00Todos estos son de código abierto.
00:08:01Puedes ir a buscarlos y probarlos tú mismo.
00:08:04En la planificación, vas a delinear los pasos exactos.
00:08:06Incluirás nombres de archivos y fragmentos de líneas.
00:08:08Serás muy explícito sobre cómo vamos a probar las cosas
00:08:10después de cada cambio.
00:08:11Aquí hay un buen prompt de planificación.
00:08:12Aquí está uno de nuestros planes.
00:08:13Tiene fragmentos de código reales.
00:08:16Y luego vamos a implementar.
00:08:17Y si has leído uno de estos planes,
00:08:17verás fácilmente cómo hasta el modelo más tonto del mundo
00:08:20probablemente no va a arruinar esto.
00:08:23Así que simplemente avanzamos y ejecutamos el plan
00:08:24manteniendo el contexto bajo.
00:08:26Como prompt de planificación, como dije,
00:08:27es la parte menos emocionante del proceso.
00:08:30Quería poner esto en práctica.
00:08:31Así que, trabajando con nosotros, hago un podcast con mi amigo Vaibhav,
00:08:34que es el CEO de una empresa llamada Boundary ML.
00:08:37Y le dije: "Oye, voy a intentar arreglar de un solo intento
00:08:39tu base de código Rust de 300,000 líneas
00:08:41de un lenguaje de programación".
00:08:42Y todo el episodio trata de eso.
00:08:45Dura como una hora y media.
00:08:46No voy a explicarlo todo ahora,
00:08:47pero hicimos mucha investigación
00:08:48y luego la desechamos porque era mala.
00:08:49Luego hicimos un plan sin investigación
00:08:51y otro con investigación y comparamos todos los resultados.
00:08:53Fue divertido.
00:08:54Eso fue un lunes por la noche.
00:08:55Para el martes por la mañana, estábamos en el programa
00:08:57y el CTO ya había visto el PR (Pull Request)
00:08:59y no se dio cuenta de que lo estaba haciendo como una broma para el podcast.
00:09:03Básicamente dijo: "Sí, esto se ve bien.
00:09:04Lo incluiremos en la próxima versión".
00:09:05Estaba un poco confundido.
00:09:08Aquí está el plan.
00:09:09Pero bueno, sí, confirmado.
00:09:12Funciona en bases de código heredadas y sin errores de relleno.
00:09:14Pero quería ver si podíamos resolver problemas complejos.
00:09:17Vaibhav todavía estaba un poco escéptico.
00:09:19Nos sentamos como siete horas un sábado
00:09:21y enviamos 35,000 líneas de código a BAML.
00:09:24Uno de los PRs se fusionó como una semana después.
00:09:26Debo decir que parte de esto es generación de código.
00:09:28Actualizas el comportamiento,
00:09:29todos los archivos de referencia se actualizan y demás,
00:09:31pero enviamos mucho código ese día.
00:09:33Él estima que hicimos de una a dos semanas de trabajo en siete horas.
00:09:36Así que, genial, podemos resolver problemas complejos.
00:09:40Esto tiene sus límites.
00:09:41Me senté con mi amigo Blake.
00:09:42Intentamos eliminar las dependencias de Hadoop de Parquet Java.
00:09:46Si sabes lo que es Parquet Java,
00:09:47siento mucho lo que sea que te haya pasado
00:09:50para llegar a este punto de tu carrera.
00:09:53No salió bien.
00:09:55Aquí están los planes, aquí está la investigación.
00:09:57En cierto punto, lo desechamos todo
00:09:58y volvimos a la pizarra.
00:10:00Tuvimos que, una vez que aprendimos
00:10:01dónde estaban todas las trampas,
00:10:03volvimos a pensar:
00:10:05okay, ¿cómo va a encajar esto realmente?
00:10:06Y esto me lleva a un punto muy interesante
00:10:09del que Jake hablará más tarde.
00:10:11No externalices el pensamiento.
00:10:13La IA no puede reemplazar el pensamiento.
00:10:14Solo puede amplificar el pensamiento que ya has hecho
00:10:17o la falta de pensamiento que has tenido.
00:10:19Así que la gente pregunta: "Dex,
00:10:21¿esto es desarrollo impulsado por especificaciones, verdad?".
00:10:23No, el desarrollo impulsado por especificaciones está roto.
00:10:27No la idea, sino el término.
00:10:30No está bien definido.
00:10:33Esta es Brigetta, de ThoughtWorks.
00:10:35Y mucha gente simplemente dice "especificación"
00:10:37y se refieren a un prompt más detallado.
00:10:39¿Alguien recuerda esta imagen?
00:10:41¿Alguien sabe de dónde es?
00:10:43Vale, es una referencia muy rebuscada.
00:10:44Nunca habrá un "año de los agentes"
00:10:46debido a la difusión semántica.
00:10:47Martin Fowler dijo esto en 2006.
00:10:49Creamos un buen término con una buena definición,
00:10:52luego todo el mundo se emociona
00:10:53y cada quien empieza a darle un significado distinto,
00:10:56y al final acaba siendo inútil.
00:10:59Teníamos al agente como persona, como microservicio,
00:11:02agente como chatbot, agente como flujo de trabajo.
00:11:05Y gracias, Simon.
00:11:06Estamos de vuelta al principio.
00:11:07Un agente son solo herramientas en un bucle.
00:11:09Esto le está pasando al desarrollo basado en especificaciones.
00:11:11Al principio de esta charla solía poner la diapositiva de Sean,
00:11:15pero hizo que mucha gente
00:11:15se centrara en las cosas equivocadas.
00:11:17Su idea de "olvida el código, ahora es como ensamblador"
00:11:19y solo te enfocas en el markdown.
00:11:21Es una idea genial, pero la gente dice que el desarrollo por especificaciones
00:11:24es escribir un mejor prompt o un documento de requisitos del producto.
00:11:26A veces es usar bucles de retroalimentación verificables
00:11:28y contrapresión.
00:11:30Tal vez es tratar el código como lenguaje ensamblador,
00:11:32como nos enseñó Sean.
00:11:34Pero para muchos es solo usar un montón de archivos markdown
00:11:36mientras programas.
00:11:37O mi favorita, que descubrí la semana pasada:
00:11:39una especificación es la documentación de una librería de código abierto.
00:11:43Así que se acabó.
00:11:44El desarrollo basado en especificaciones está sobrevalorado, ya es inútil.
00:11:48Está semánticamente difundido.
00:11:49Así que quería hablar de cuatro cosas
00:11:52que realmente funcionan hoy, los pasos tácticos y prácticos
00:11:55que nos han funcionado internamente y con muchos usuarios.
00:11:59Hacemos la investigación, descubrimos cómo funciona el sistema.
00:12:02¿Recuerdan "Memento"?
00:12:03Es la mejor película sobre ingeniería de contexto,
00:12:05como dice Peter.
00:12:07Este tipo se despierta, no tiene memoria,
00:12:09tiene que leer sus propios tatuajes para saber quién es
00:12:11y qué es lo que está haciendo.
00:12:12Si no orientas a tus agentes, inventarán cosas.
00:12:17Y este es tu equipo; esto está muy simplificado
00:12:19para la mayoría de ustedes.
00:12:19La mayoría tienen organizaciones mucho más grandes que esta.
00:12:21Pero digamos que quieres trabajar en esta parte.
00:12:23Una cosa que podrías hacer es poner la orientación
00:12:26en cada repositorio.
00:12:27Pones un montón de contexto.
00:12:28"Aquí está el repo, así es como funciona".
00:12:29Esta es una compresión de todo el contexto de la base de código
00:12:32que el agente puede ver de antemano
00:12:34antes de ponerse a trabajar.
00:12:36Esto es un reto porque a veces se vuelve demasiado largo.
00:12:39A medida que tu base de código crece,
00:12:41o bien tienes que alargar esto
00:12:43o tienes que dejar información fuera.
00:12:45Y así, mientras estás leyendo esto,
00:12:48vas a leer el contexto
00:12:49de este gran monorepositorio de cinco millones de líneas
00:12:52y vas a agotar toda la "zona inteligente"
00:12:53solo para aprender cómo funciona, y no serás capaz
00:12:55de hacer buenas llamadas a herramientas en la "zona tonta".
00:12:57Así que puedes fragmentar esto a lo largo de la estructura.
00:13:02Estamos hablando de revelación progresiva.
00:13:04Podrías dividir esto, ¿verdad?
00:13:05Podrías poner un archivo en la raíz de cada repo
00:13:08y luego, en cada nivel, tienes contexto adicional
00:13:11basado en si estás trabajando ahí,
00:13:13esto es lo que necesitas saber.
00:13:15No documentamos los archivos en sí
00:13:17porque ellos son la fuente de la verdad.
00:13:18Pero luego, mientras tu agente trabaja,
00:13:19extraes el contexto de la raíz
00:13:21y luego extraes el subcontexto.
00:13:22No hablaremos de ninguna herramienta específica,
00:13:23podrías usar CloudMD para esto,
00:13:24o podrías usar Hoax, lo que sea.
00:13:26Pero así todavía tienes mucho espacio en la zona inteligente
00:13:28porque solo estás trayendo lo que necesitas saber.
00:13:31El problema de esto es que se queda desactualizado.
00:13:33Y así, cada vez que lanzas una nueva función,
00:13:35necesitas algo como cachear, validar
00:13:38y reconstruir gran parte de esta documentación interna.
00:13:42Y podrías usar mucha IA
00:13:43y hacer que sea parte de tu proceso el actualizar esto.
00:13:46¿Por qué no hago una pregunta?
00:13:48Entre el código real, los nombres de las funciones,
00:13:50los comentarios y la documentación,
00:13:51¿alguien quiere adivinar qué hay en el eje Y de este gráfico?
00:13:57- Basura. - Basura.
00:13:58En realidad es la cantidad de mentiras que puedes encontrar
00:14:01en cualquier parte de tu base de código.
00:14:03Así que podrías integrarlo en tu proceso para actualizarlo,
00:14:06pero probablemente no deberías porque seguramente no lo harás.
00:14:08Lo que preferimos es contexto comprimido bajo demanda.
00:14:11Si estoy creando una función relacionada con proveedores de SCM,
00:14:14JIRA y Linear,
00:14:15solo le daría un poco de orientación.
00:14:17Diría: "Oye, vamos a centrarnos
00:14:18en esta parte de la base de código de aquí",
00:14:21y un buen prompt de investigación o comando
00:14:24podría incluso usar tu habilidad,
00:14:27lanzar varios subagentes para tomar estas secciones verticales
00:14:30por el código y luego generar un documento de investigación
00:14:33que sea solo una instantánea de la realidad,
00:14:35basada en el propio código, de las partes que importan.
00:14:39Estamos sintetizando la verdad.
00:14:41Planificar es ganar ventaja.
00:14:43Planificar consiste en sintetizar la intención.
00:14:45Y en el plan vamos a detallar los pasos exactos.
00:14:48Tomamos nuestra investigación y el PRD, el ticket de error
00:14:50o lo que sea que estemos usando.
00:14:52Creamos un plan y un archivo de plan.
00:14:54Así que volvemos a compactar la información.
00:14:55Quiero hacer una pausa para hablar de la alineación mental.
00:14:58¿Alguien sabe para qué sirve la revisión de código?
00:15:00Alineación mental, alineación mental.
00:15:05Sirve para asegurar que las cosas estén bien y demás.
00:15:08Pero lo más importante es: ¿cómo logramos que todos
00:15:10en el equipo estén en la misma sintonía
00:15:11sobre cómo está cambiando el código y por qué?
00:15:14Y yo puedo leer mil líneas de Golang a la semana.
00:15:17Perdón, no puedo leer mil.
00:15:18Es difícil, pero puedo hacerlo.
00:15:19Aunque no quiero.
00:15:20A medida que el equipo crece, todo el código se revisa.
00:15:23No es que dejemos de leer el código.
00:15:24Pero yo, como líder técnico del equipo,
00:15:27puedo leer los planes y mantenerme al día.
00:15:29Y con eso me basta.
00:15:30Puedo detectar problemas a tiempo
00:15:32y entiendo cómo está evolucionando el sistema.
00:15:35Mitchell publicó un artículo muy bueno
00:15:36sobre cómo ha estado incluyendo sus hilos de AMP
00:15:38en sus pull requests para que no solo veas,
00:15:41ya sabes, un muro de texto verde en GitHub,
00:15:43sino los pasos exactos, los prompts usados,
00:15:44y el hecho de que ejecutó la compilación y pasó.
00:15:46Esto guía al revisor a través del proceso
00:15:49de una forma que un PR de GitHub no puede.
00:15:51Y a medida que entregas
00:15:52dos o tres veces más código que antes,
00:15:54depende de ti encontrar formas de que tu equipo
00:15:57esté coordinado y mostrarles los pasos que seguiste
00:16:00y cómo lo probaste manualmente.
00:16:01Tu objetivo es la eficiencia, así que buscas confianza
00:16:04en que el modelo realmente hará lo correcto.
00:16:06No puedo leer este plan y saber exactamente
00:16:08qué va a pasar ni qué cambios se harán en el código.
00:16:11Así que, con el tiempo, hemos evolucionado y ahora
00:16:14nuestros planes incluyen fragmentos del código real.
00:16:17Tu meta es tener ventaja.
00:16:18Buscas sintetizar la intención
00:16:19y una ejecución fiable.
00:16:22Bueno, yo tengo formación en física.
00:16:23Nos gusta trazar líneas por el centro de picos y curvas.
00:16:28Cuando los planes son más largos, la fiabilidad sube,
00:16:30pero la legibilidad baja.
00:16:31Hay un punto de equilibrio para ti, tu equipo
00:16:33y tu base de código; deberías intentar encontrarlo.
00:16:35Porque cuando revisamos la investigación y los planes,
00:16:37si son buenos, logramos esa alineación mental.
00:16:40No delegues el pensamiento.
00:16:42Lo he dicho antes, esto no es magia.
00:16:44No existe el prompt perfecto.
00:16:46Nada funcionará si no lees el plan.
00:16:50Diseñamos nuestro proceso para que tú, el desarrollador,
00:16:53estés en constante interacción con el agente,
00:16:55revisando los planes conforme se crean.
00:16:56Y luego, si necesitas una revisión por pares,
00:16:58puedes enviárselo a alguien y preguntarle:
00:16:58"Oye, ¿te parece bien este plan?
00:17:00¿Es el enfoque correcto?
00:17:00¿Es este el orden adecuado para abordar las tareas?"
00:17:03Jake también escribió un gran artículo sobre por qué
00:17:05el ciclo de investigar, planificar e implementar es valioso:
00:17:07porque tú, el humano, supervisas que todo sea correcto.
00:17:11Si solo se quedan con una idea de esta charla,
00:17:14que sea que una mala línea de código es solo eso.
00:17:17Pero un error en un plan pueden ser 100 líneas malas.
00:17:22Y un error en la investigación, como entender mal
00:17:25cómo funciona el sistema o dónde están las cosas,
00:17:27arruinará todo el proceso.
00:17:29Estarás enviando al modelo en la dirección equivocada.
00:17:31Así que, trabajando internamente y con usuarios,
00:17:34siempre intentamos centrar el esfuerzo humano
00:17:36en las partes de mayor impacto de este flujo.
00:17:39No delegues el pensamiento.
00:17:41Cuidado con las herramientas que generan montones
00:17:43de archivos Markdown solo para que te sientas bien.
00:17:45No voy a mencionar nombres aquí.
00:17:47A veces esto es excesivo.
00:17:49Y la forma en que me gusta verlo es:
00:17:51no siempre necesitas investigar, planificar e implementar.
00:17:54A veces necesitas más, a veces menos.
00:17:56Si solo vas a cambiar el color de un botón,
00:17:57simplemente habla con el agente y dile qué hacer.
00:18:00Si es un plan sencillo para una función pequeña,
00:18:04o si son funciones medianas en varios repositorios,
00:18:07entonces investiga un poco y luego crea un plan.
00:18:09Básicamente, la dificultad de los problemas que resuelves
00:18:10aumenta cuanta más ingeniería de contexto
00:18:13y síntesis de información estés dispuesto a hacer.
00:18:15Así que si estás en el nivel más complejo,
00:18:18probablemente tendrás que esforzarte más.
00:18:19Muchos me preguntan: "¿Cómo sé cuánta
00:18:21ingeniería de contexto debo aplicar?"
00:18:23Es cuestión de práctica.
00:18:24Te equivocarás, y tienes que hacerlo
00:18:26una y otra vez.
00:18:27A veces te pasarás y otras te quedarás corto.
00:18:29Elige una herramienta y empieza a practicar.
00:18:32No recomiendo intentar optimizarlo todo usando
00:18:35Claude, Codex y todas estas herramientas a la vez.
00:18:36No soy muy fan de las siglas.
00:18:40Dijimos que el desarrollo basado en specs no servía.
00:18:42No creo que investigar-planificar-implementar sea el final.
00:18:44Lo importante es la síntesis, la ingeniería de contexto
00:18:47y mantenerse en la zona de trabajo inteligente.
00:18:48Pero la gente lo está llamando RPI (por sus siglas en inglés)
00:18:50y no hay nada que pueda hacer al respecto.
00:18:52Así que ten cuidado, no hay un prompt perfecto
00:18:55ni soluciones milagrosas.
00:18:56Si quieren un término de moda,
00:18:58pueden llamarlo "harness engineering",
00:19:00que es parte de la ingeniería de contexto
00:19:01y trata sobre cómo te conectas con los puntos de integración
00:19:03en Codex, Claude, Cursor o lo que sea,
00:19:05y cómo personalizas tu base de código.
00:19:07¿Qué sigue ahora?
00:19:11Creo que los agentes de programación se van a
00:19:12convertir en algo estándar, una "commodity".
00:19:13La gente aprenderá a usarlos y mejorará.
00:19:15Lo difícil será cómo adaptar a tu equipo
00:19:17y tu flujo de trabajo en el SDLC en un mundo
00:19:21donde el 99% del código lo escriba la IA.
00:19:24Si no logras entender esto, estás perdido.
00:19:26Se está creando una brecha donde
00:19:27los ingenieros senior no adoptan la IA
00:19:29porque no les hace mucho más rápidos,
00:19:31mientras que los niveles junior y medios la usan mucho
00:19:33porque suple carencias de habilidades.
00:19:35Pero también genera código de baja calidad
00:19:36y los ingenieros senior lo odian cada vez más
00:19:38porque tienen que limpiar el desastre
00:19:40que Cursor generó la semana anterior.
00:19:42No es culpa de la IA,
00:19:44ni del ingeniero de nivel medio.
00:19:46El cambio cultural es muy difícil
00:19:48y tiene que venir desde arriba para que funcione.
00:19:50Si eres líder técnico en tu empresa,
00:19:52elige una herramienta y empieza a practicar.
00:19:54Si quieres ayudar, estamos contratando.
00:19:56Creamos un IDE agéntico para ayudar a equipos
00:19:59a llegar rápido al 99% de código generado por IA.
00:20:03Nos encantaría hablar contigo si quieres trabajar con nosotros.
00:20:06Visita nuestra web, envíanos un correo
00:20:08o búscame aquí en el pasillo.
00:20:09Muchas gracias a todos por su energía.
00:20:11(Aplausos de la audiencia)
00:20:13(Música electrónica animada)