Friends Don’t Let Friends Agent Alone

Muy bien, entonces estamos bien. Si no has oído hablar de nosotros, construimos un editor de código similar a Sublime o VS Code o JetBrains o elige el que prefieras. Esperamos que seas tu próximo editor. Así que si nos pruebas y te quedas con nosotros. Y nos importa mucho la colaboración, tanto con humanos como ahora con AI.

Así que tenemos formas de ejecutar agentes y compartir tus proyectos con tus compañeros de equipo, interactuar con el código como si estuviera en tu propia máquina. Y ahí, lo que hago, soy un ingeniero de Rust. Envío mucho código. También soy un gerente de ingeniería y también soy un líder de proyecto para nuestro equipo de agentes. Llevo muchos sombreros.

Y como se mencionó, también soy un mantenedor principal del protocolo del cliente del agente, lo cual es la capacidad de incrustar demasiados agentes para contar en este punto en tus productos, como editores de código como Zed. Así que puedes traer tu propio arnés. Puedes usar nuestro agente o puedes traer tu propio arnés o el arnés de otra persona y usarlo. No hace falta decir que tengo algunas ideas sobre cómo deberíamos estar usando agentes porque paso mucho tiempo pensando en ellos.

Y un estribillo común que escucho es como, todo ha cambiado. Y creo que a veces nos sentimos así, ¿verdad? Todo ha cambiado. Y si miras, como en los últimos años, pasamos de, no sé, solo escribir código a mano para aquellos de nosotros que recordamos. Y como, tal vez obtuviste algo de tu LSP. Eso fue genial. Y como tab, tab, tabs, teníamos como chats, luego agentes. Y ahora estamos como, no sé. Tienes tu open claw enviando mensajes a tus amigos y enviando correos electrónicos por ti. Y hay agentes ejecutándose por todas partes y quién sabe qué sigue.

Así que obviamente mucho ha cambiado en un período de tiempo muy corto. Pero también quiero decir que creo que nada ha cambiado. He escuchado esto algunas veces hoy. ¿Y qué quiero decir con esto? Creo que todo sobre cómo hacemos nuestro trabajo diario, lo que tal vez nos identificamos como, como ingenieros en términos de lo que hago y en mis tareas diarias. Sí, mucho ha cambiado. Pero también creo que en el mismo período de tiempo, nada ha cambiado fundamentalmente sobre nosotros como humanos. Creo que somos criaturas muy adaptables. Así que nos hemos adaptado a muchas externalidades que están cambiando a nuestro alrededor. Pero creo que fundamentalmente seguimos siendo los mismos humanos que tienen algunas de las mismas luchas que tal vez se amplifican o sentimos de manera diferente. Pero creo que si miramos hacia atrás, creo que en realidad hemos luchado con algunas de estas cosas en nuestros equipos incluso antes de que los agentes de codificación de AI llegaran a bordo.

Creo que una es muy obvia. Ahora es como la carga cognitiva, ¿verdad? Al igual que estos modelos, nuestros cerebros tienen esta ventana de contexto finita. Solo podemos mantener tanto en nuestras cabezas a la vez. Y creo que siempre sentimos esto, como queremos hacer tantas cosas. Hay tantas cosas que queremos hacer y tratamos de hacer multitarea. Pero hay límites a lo que podemos mantener y seguir y mantenernos enfocados. Y creo que ahora que tenemos estos agentes, ahora finalmente puedo quemar todo mi backlog. Y voy a generar cien agentes y haré todos estos tickets. Y puedes intentarlo. Pero creo que en última instancia, en realidad, no siempre terminas todo bien, si intentas hacer cien cosas a la vez. Porque no sé tú, pero cuando intento hacer esto, vuelvo y encuentro como este diff de un agente y estoy como, oh, ¿qué estaba pasando aquí? ¿Qué qué qué estaba tratando de resolver esto? ¿Es este diff bueno? No lo sé.

Voy a volver a este otro hilo y luego una y otra vez y otra vez. Y luego tal vez tuviste una buena demostración en el día de la demo con tu equipo y recibiste, ya sabes, aplausos por, oh, eso fue realmente genial. Pero nunca pude realmente llegar a tus usuarios. ¿Verdad? Y no lo terminaste. Y así creo que sentimos esto más agudamente ahora que tenemos todos estos tokens para gastar.

Y creo que al pensar en esto, como, sí, hacer que el código sea barato de generar no hace que la comprensión sea barata de omitir. Como nuestro trabajo es realmente comprender el trabajo que estamos haciendo. Y creo que para hacer eso, necesitamos poder enfocarnos y usar la limitada carga cognitiva que tenemos para completar una tarea. Y luego en el libro de topologías de equipo, incorporan algunas otras investigaciones sobre diferentes tipos de carga cognitiva. Y uno de ellos es el intrínseco. Así que como fundamental para el espacio del problema. Entonces, ¿cómo creo un nuevo método? Como si quisiéramos hacer nuestro trabajo, necesitamos saber cómo funciona mi lenguaje. ¿Verdad? Así que necesitas esto para completar tu tarea. Lo bueno es que la IA es buena en esto. ¿Verdad? Así que podemos obtener algo de ayuda aquí. Esta es un área de carga cognitiva que queremos reducir.

Y tenemos la externa, como, ¿cómo hago para completar mis tareas? Como, ¿cómo lo despliego? ¿Qué configuración necesito cambiar? Nuevamente, tal vez la IA o simplemente la automatización normal que hemos estado haciendo durante años también puede ayudar en esto. Así que no tengo que pensar en ello. ¿Y qué estamos tratando de optimizar? Estamos tratando de pensar más en esta carga cognitiva germana. O como en el artículo de Brooks "no silver bullet". Como hay esta complejidad accidental, que son las otras dos en la complejidad esencial. ¿Cuál es la cosa que realmente estás tratando de lograr? Y y esto es lo que necesitamos. Necesitamos esta carga cognitiva germana enfocada en algo para que realmente podamos aprender para que podamos pensar en cómo funciona el servicio A con el servicio B.

Como si pensamos que todos están tratando de hacer más y más agentes, ¿verdad? Y queremos orquestarlos. Como, bueno, si estás encantador, si te estás moviendo hacia arriba, necesitas pensar en estos problemas. ¿Y realmente crees que puedes resolver 100 de estos problemas a la vez? Como, probablemente no. Así que necesitas el enfoque. Necesitas poder aprender cuáles son los problemas que estás tratando de resolver. Y creo que al menos para mí, como la cosa que estoy tratando de averiguar cuando estoy usando estos agentes es cómo puedo seguir teniendo enfoque y compromiso. ¿Cómo puedo seguir entrando en ese estado de flujo al que solía entrar cuando tenía esas sesiones de codificación nocturnas?

Incluso cuando no estoy escribiendo el código, ¿cómo puedo al día siguiente estar en la ducha y haber entendido el problema tanto, incluso si no escribí miles de líneas de código para tener un pensamiento de como, ah, necesitamos cambiar esto. Y creo que si estoy saltando entre 20 chats diferentes a la vez, resolviendo 20 problemas diferentes, al menos tengo muchas dificultades para hacer esto. Y así creo que necesitamos pensar en cómo podemos crear este enfoque para nosotros mismos y en nuestros equipos. Porque creo que este ha sido siempre nuestro trabajo. ¿Verdad? A medida que construimos, aprendemos el problema que estamos tratando de resolver. Y creo que siempre ha habido algo muy táctil, muy tangible mientras escribimos el código.

¿Verdad? Experimentamos esto. Pero ahora tenemos que adaptarnos. ¿Verdad? Hay una nueva forma de esto. ¿Y cómo seguimos aprendiendo? ¿Cómo seguimos creciendo y no solo hacemos clic en merge en lo que sea que nos dé? Creo que otra lucha que hemos tenido es la alineación. Esto ha estado en varias charlas hoy, ¿verdad? Como podríamos estar haciendo a los individuos más rápidos, pero si la empresa en sí no está realmente alineada, entonces como que no vas a moverte más rápido. Vas a tener personas encontrando estos cuellos de botella más rápido porque están esperando alguna decisión, alguna aprobación, lo que sea.

Y creo que mucho de esto es como si la IA, si los tokens están llevando a muchas personas en diferentes direcciones, en realidad no estás avanzando. Entonces, ¿cómo puedes alinear la empresa? Para que todos estén enfocando todo este gasto de tokens de IA en una dirección que realmente mueva la aguja. Porque creo que la IA es un multiplicador de las partes buenas y malas de nuestros equipos. Creo que si alguien es realmente bueno construyendo un producto, supongo que los hará más rápidos. Pero si tu equipo no puede alinearse o no puede averiguar qué deberíamos construir, ¿verdad?, entonces podrías estar construyendo las cosas equivocadas más rápido. Podrías estar generando una base de código heredada de 10 años en 10 semanas. Correcto.

Como podríamos estar creando un gran lío que nadie entiende. Y creo que esto también se ha mencionado varias veces hoy, que el cuello de botella nunca fue escribir el código. Si miro hacia atrás en mi carrera, la mayor parte de mi trabajo como ingeniero de software fue en realidad tratar de averiguar qué código deberíamos escribir, ir por ahí, averiguar qué quiere hacer este negocio, cuáles son los objetivos que estamos tratando de lograr. Y luego quiero codificar eso en líneas de código que realmente lleven a cabo como el código es como la especificación definitiva, ¿verdad? Tiene líneas de código para expresar el estado de lo que va a suceder. Pero averiguar cuáles son esas cosas.

Eso siempre fue nuestro trabajo. Y creo que esto siempre fue el caso y simplemente lo sentimos más ahora porque ahora no estamos realmente escribiendo el código. Podemos obtenerlo en 30 segundos. Pero, ¿es correcto? Ahí es donde tenemos que averiguar cómo alinearnos como empresa. Y la otra lucha, creo que siempre hemos enfrentado, son los silos, este factor autobús. Como, ah, esta persona siempre hace una base de datos. Será más rápido si simplemente les damos el mismo ticket, lo harán más rápido. Necesitaría cargar todo este contexto para averiguar cómo resolverlo. Pero luego se van de vacaciones por una semana, bueno, supongo que no podemos tocar eso por una semana.

Y no tienes eso en tu computadora. Entonces, ¿estamos creando más y más silos? Y de nuevo, creo que tener la capacidad de que una sola persona haga más, creo que esto es genial, pero también puede ser más doloroso porque esa única persona ahora también es a su manera un cuello de botella. La buena noticia es que, como dije, creo que en realidad hemos estado luchando con estos problemas durante un tiempo y algunas personas realmente inteligentes, mucho más inteligentes que yo, han propuesto soluciones para ellos.

Así que repasaré algunas que creo que son útiles. Una es la programación en pareja, que hace unos años, no hacía en absoluto. No solo en los últimos cinco años, la he adoptado. Y ahora la impulso bastante en mis equipos porque creo que proporciona ciertos beneficios. Y creo que el mayor es que obtienes esta cosa de alineación gratis. No del todo, pero creo que parte de la programación en pareja es tener que explicar tu idea a otro humano.

Y el problema con los agentes es que pueden funcionar como pareja y los uso a veces cuando estoy trabajando solo de esta manera. Están muy ansiosos por complacer y no te van a cuestionar. Van a decir, ah, tienes razón. Y luego señalarás algo. Tienes razón de nuevo. Creo que puedes usar habilidades y hacerlo más confrontacional. No lo sé. Pero creo que tener que convencer a otra persona de tu idea, agudiza tu propia comunicación de la misma, te hace pensar en ella y ellos pueden proporcionar algo de resistencia. Y creo que a través de esto, ambos pueden explorar una idea juntos y alinearse en ella.

Y creo que a través de esto, ambos pueden explorar una idea juntos y alinearse en ella. Y también creo que hay algo en tener a otra persona trabajando contigo, ya sea de forma remota o literalmente, Adam sentado a tu lado, que proporciona este enfoque y responsabilidad. Al menos encuentro que es mucho menos probable que vaya a revisar Twitter o Slack o el trabajo de CI o lo que sea, pasar por todas mis pestañas porque hay alguien más con quien estoy trabajando. Y no se trata de que alguien me esté observando. Creo que es solo que ahora estamos trabajando en el objetivo juntos y respeto a esta persona, ellos me respetan a mí y ambos nos estamos entregando al trabajo. Y creo que esto es útil. Tal vez soy realmente malo en la multitarea y todos ustedes están como, esto no es un problema para mí, pero al menos para mí, esto me ayuda a mantenerme en la zona para realmente lidiar con el problema, pensar en él y obtener este aprendizaje y compromiso que quiero. Y esto ha sido cierto antes y he encontrado que sigue siendo cierto con los agentes.

Y creo que lo importante ahora es que la programación en pareja también fue útil para compartir conocimientos sobre diferentes partes de la base de código. Pero ahora también puedo ver cómo incitas a tu agente. ¿Qué habilidades estás usando? Lo que sea, todos podemos compartir estos conocimientos juntos. No es como si todos estuviéramos trabajando en nuestras propias formas de trabajar de esta manera. Todos estamos aprendiendo, ¿verdad? Todos estamos aprendiendo. Pero creo que la programación en pareja, para aquellos de ustedes que lo han intentado, tenemos que ajustarnos ahora que no estamos haciendo la escritura. Creo que hay algunas cosas que funcionaron bien cuando uno de nosotros estaba escribiendo. Correcto. Había como una especie de cuello de botella allí. Ese cuello de botella se ha ido. Entonces, ¿cómo hacemos esto? Mi colega está aquí a quien obligué a hacer esto conmigo. Espero que lo disfrute. Pero de todos modos, entiendo que iniciaremos un agente durante la noche en una gran tarea o, ya sabes, nos sentaremos y pondremos en marcha el agente juntos. ¿Qué problema queremos resolver? Escribe el aviso, ponlo en marcha. Y luego nos sentamos y revisamos juntos. Y puedo compartir mi proyecto y podemos compartir el mismo diff y editar el diff juntos. Y he encontrado que esto es realmente agradable porque entonces estoy interrogando este código con otra persona. Estamos haciendo diferentes preguntas.

Y luego, ya sabes, ¿por qué es así? Bueno, preguntemos al agente. Así que el agente está como corriendo para responder la pregunta de por qué lo hice de esta manera. Bueno, estamos hablando más sobre qué queremos. ¿Qué problema estamos resolviendo? ¿Cómo queremos hacer esto? Y también he encontrado que asegura que no me conforme con lo aceptable, al menos para mí. Correcto. A veces lo inicio y compila.

Realmente quiero terminar con esta tarea. Sí, creo que lo hace. Es lo suficientemente bueno. Como vamos a fusionar. Y encuentro que cuando estoy emparejando con alguien, uno de nosotros dirá, hmm, no creo que eso fuera lo suficientemente bueno. Creo que podríamos llevarlo más lejos. ¿Y sabes qué? Solo toma un par de minutos más pedirle al agente que lo cambie. Así que no es una gran diferencia de tiempo. Pero hay algo con lo que creo que nosotros, como humanos, nos comprometemos de manera diferente cuando estamos con otros humanos que nos ayuda a lograr lo que como equipo hemos decidido que queremos lograr.

Así que les animaría a todos a tomarse un tiempo para revisar un PR. No solo como lanzar tu agente cinco cosas codificadas a alguien más en GitHub y esperar a que presionen el botón verde. Invítalos a revisarlo juntos y hablar sobre ello. Tal vez puedas explicar cómo incitaste al agente. Por qué es de esta manera. ¿Qué preguntas te hizo el agente? Y puedes hablar sobre estos compromisos y decidir. ¿Y adivina qué? La otra cosa realmente genial acerca de que este código sea realmente barato de escribir es que puedes desecharlo y simplemente comenzar de nuevo porque, como, pero toma otros cinco minutos. Como, sí.

Así que creo que, como, comprométete con tus compañeros de equipo de esta manera. Y creo que esto es, creo, como lo que ayuda a nivel de equipo. Y luego creo que para que esto tenga éxito, ¿cuál es el entorno en el que está el equipo? ¿Cuál es el entorno de tu empresa para que esto tenga éxito? Y he pasado la mayor parte de mi carrera en empresas de tamaño pequeño y mediano. Creo que varios de ustedes están en empresas mucho más grandes que la mía. Honestamente, me gustaría que pudieras simplemente leer este libro, leer este libro. Explica, tomo mucho de este libro, y explican cómo aplicar esto, estos tipos de principios de una manera mucho más amplia. Cómo tomar el diseño orientado al dominio sorprendentemente funciona muy bien a nivel organizacional. Y hay toneladas de estudios de caso aquí de empresas reales que parece que les funciona. No puedo decir, pero no sé. Confío en ellos. Y el libro es realmente bueno. Y principalmente se trata de identificar lo que hace cada equipo y realmente reducir la comunicación entre esos equipos o al menos identificar los tipos de comunicación que deberían ocurrir entre equipos dentro de tu empresa. Y, sí, todos pensamos que la colaboración es buena.

Realmente valoro mucho la colaboración. Pero no toda colaboración es buena, porque si todos en tu empresa tienen que colaborar para hacer cualquier cosa, eso no es bueno. Correcto. Y especialmente cuando hay tanto sucediendo. Así que creo que todavía hay mucho por aprender de esto. Así que ve y lee el libro. Te dará muchas formas prácticas de organizar tus equipos. Pero el punto principal es, ¿cómo optimizamos para un flujo rápido de valor? Y creo que tenemos que optimizar para esto ahora porque las compuertas se han abierto y es como si se estuviera derramando por todas partes.

Entonces, ¿cómo podemos dirigir toda esta energía y estos tokens de una manera que podamos beneficiarnos? Y creo que escondido en la conclusión de este libro es que explican, aquí está cómo puedes organizar toda tu organización. Pero esto no es suficiente. Ninguno de estos cambios hace nada a menos que tengas algunos requisitos previos. Uno es una cultura organizacional saludable. ¿Confías en los ingenieros de tu equipo? ¿Les das autonomía para tomar decisiones? Porque si realmente quieres que la gente se mueva más rápido, creo que esa es realmente la clave. Confías en ellos. ¿Y cómo puedes fomentar esa confianza? Eso es lo que vas a averiguar con tu organización. Pero si confías y les dejas hacer algo por su cuenta y tomar decisiones por su cuenta y confías en que van a hacer lo correcto, entonces pueden moverse. Y luego puedes corregir potencialmente después.

¿Cómo les das la información que necesitan para entender la dirección del negocio para realmente lograr esa cosa? Pero creo que sin esta capa de confianza y autonomía, ninguna cantidad de tokens acelerará tu negocio. También creo que las buenas prácticas de ingeniería, esto se ha dicho múltiples veces hoy, son más importantes que nunca. Si quieres moverte rápido, está esto de que lento es suave, suave es rápido, ¿verdad? Necesitas asegurarte de que todo se desbloquee. Si CI está atascado o lo que sea, asegúrate de que CI esté funcionando sin problemas, que los despliegues estén funcionando sin problemas, que tengas las pruebas que necesitas para tener confianza en tu sistema y también las métricas para asegurarte si algo ha salido mal. Si tienes esto en su lugar, entonces también puedes moverte mucho más rápido.

Y creo que esto, de alguna manera, para mí es lo más importante. ¿Todos en tu empresa entienden la visión del negocio? ¿Cuál es la misión de tu empresa? ¿Y pueden asumir la responsabilidad de llevarla a cabo? Porque si todos queremos que todos comiencen a actuar como arquitectos y gerentes de ingeniería o CEOs de sus propios pequeños sistemas dentro de tu empresa, necesitan tener muy claro. Hacia dónde va esa empresa para asegurarse de que sus decisiones se muevan en esa dirección. Y creo que depende de nosotros como líderes asegurarnos de que todos estén alineados en esta dirección.

Ahora, estoy hablando con un grupo de líderes tecnológicos. Así que, por supuesto, esta tiene que ser una respuesta, ¿verdad? Tenemos que construir las herramientas. Resolverá todos nuestros problemas. Pero en realidad creo que todos sentimos esto, ¿verdad? Como si hubiera un montón de herramientas que hemos estado usando durante décadas que simplemente sienten que no pueden soportar el peso de todos estos, estos cambios en este código que se está escribiendo. Y esto es algo que en ZED nos apasiona mucho y estamos trabajando activamente para construir. Sé que muchos de ustedes también están haciendo esto. Creo que todos necesitamos seguir construyendo las herramientas que necesitamos para operar en este nuevo entorno.

Si alguien en tu equipo quiere, tenemos esta nueva cosa de ZED para negocios para que ustedes puedan colaborar juntos usando ZED. Y también revisen nuestro sitio web más tarde hoy. Pero estamos trabajando en algo que creo que va a ser realmente genial sobre cómo nosotros, como equipos, podemos colaborar juntos con múltiples agentes y llevar esa conversación a la base de código en sí. Para que esos aprendizajes que están teniendo puedan ser compartidos en todo su equipo. Y esto es algo que tomamos muy en serio como equipo. Y queremos ofrecerles a ustedes también. Sí, así que liderazgo tecnológico. Eso es lo que hacemos.

Pero creo que en muchos sentidos, en última instancia, somos líderes de personas. Y por muy conveniente que sería si pudiéramos simplemente optimizar y todos fuéramos como cerebros racionales en un palo todo el tiempo. También necesitamos otras cosas, ¿verdad? Y necesitamos cuidar a las personas con las que trabajamos. Y hay más que nos motiva que solo un montón de métricas o esto o aquello.

Creo que si quieres que las personas se muevan rápidamente y se preocupen por tu negocio, necesitas darles autonomía, maestría y propósito. Y creo que esto es en realidad al menos para mí un desafío, porque a veces es difícil para mí no hacer una analogía de estos agentes de codificación con una máquina tragamonedas donde hay como este fenómeno de casi aciertos. Me acerqué lo suficiente si solo lo vuelvo a intentar, funcionará esta vez. O, sí, seguiré presionando este botón y obtengo esta descarga de dopamina. Y se siente genial. Y me siento tan productivo.

Pero, ¿realmente lo estoy logrando? Y creo que por eso no sé si lo has sentido, pero a veces siento que solo necesito desconectarme y tomar un descanso porque es tan adictivo seguir. Siento que siempre debería estar trabajando. Y luego tienes personas que ahora sienten, ¿soy un vampiro de IA? ¿Todos tenemos psicosis de IA? Y creo que tenemos que estar atentos a esto en nuestros equipos. ¿Qué estamos incentivando? ¿Hacia qué estamos empujando a las personas? Porque en última instancia, si todos nos convertimos en cascarones quemados de nosotros mismos, tampoco seremos muy productivos.

Así que creo que necesitamos pensar, ¿es la IA un instrumento para desbloquear nuestro potencial? ¿Nos estamos dejando convertir en el instrumento que solo presiona el botón hasta que me automatizan por completo? Porque presionar el botón puede ser automatizado. Y creo que para resolver esto, creo que necesitamos hacerlo juntos. Y les animaría a todos a tomarse más tiempo en su trabajo diario para trabajar con los otros humanos que están con ustedes mientras todos navegamos lo que este nuevo mundo significa para nosotros. Gracias.

Sí. Así que vamos por este. Ese es un concepto real. Pero la realidad para nosotros dice que las limitaciones de tiempo son tan difíciles que tener dos personas en lugar de solo una en CodeReview sería realmente bueno. Pero simplemente no es posible cuando tenemos tanta presión de los clientes. ¿Cómo resolver eso? Sí, esto es exactamente lo mismo que me dijeron en una forma diferente. Por gerentes en el pasado, cuando impulsé la revisión por pares en mi equipo, ¿no podríamos tener dos personas escribiendo código? ¿No sería el doble de rápido? En realidad, creo que esto es más rápido. He encontrado que pasar por una revisión de código con personas es más rápido que esperar a que revisen y vuelvan con preguntas y pasar por el ciclo. Así que si estás optimizando para que un PR sea realmente revisado y fusionado, creo que este es en realidad un enfoque más rápido para hacerlo de manera sincrónica. Y creo que porque puedes alinearte más rápido y hay menos confusión. Así que diría que lo pruebes. Vas a tener personas que digan, sí, siempre he tenido personas que dicen esto, como que será más rápido con dos personas escribiendo. Pero cada vez que he trabajado en esa programación en pareja, se envió más rápido que las que no lo hicieron. Así que no sé. Eso es todo. Es anecdótico. Pero es todo lo que tengo para basarme.

Sí. Y por cierto, solo para seguir con eso y antes de que se me olvide mencionar, una cosa que mencionaste en tu sesión me recordó lo que escuché hace menos de una semana en San Francisco en el evento Microsoft Build. Y la sesión de Scott Hanselman y Mark Krasinovich de Microsoft. Así que toda su sesión estuvo dedicada a qué hacer con los desarrolladores junior. Porque es un verdadero desafío, ¿verdad? Las empresas, muchas de ellas simplemente dejan de contratar desarrolladores junior. Y lo que sugirieron, estas dos personas muy inteligentes que son mis colegas, escribieron en realidad una especie de artículo de libro blanco sobre el concepto. Creen que pueden resolver eso. Y eso es básicamente lo que acabas de mencionar, cuando el tipo especial de programación en pareja, podemos llamarlo así. Cuando un desarrollador senior y un desarrollador junior se sientan juntos y no solo codifican, sino que también guían al agente y el desarrollador senior explica su propia cadena de pensamientos, su intención, motivación, cómo usan este agente. Así que creo que está muy cerca de lo que acabas de mencionar.

Totalmente. Quiero decir, sí, este es el, encuentro que es la mejor manera de incorporar a nuevas personas. Incluso si he, uso Rust, he usado Rust durante un tiempo incorporando a nuevas personas al lenguaje Rust. Como lo que solía hacer es simplemente, oye, literalmente escribes F y espacio, como que no saben qué es esto, ¿verdad? Y les explicas. Y luego, eventualmente, como dentro de un par de semanas, están como, OK, escribe este método. Saben lo que eso significa. ¿Verdad? Y así, sí, creo que esto puede traducirse a estas nuevas habilidades de IA. Exactamente. Así que en lugar de simplemente dar tareas simples como implementar este algoritmo, implementar esto, porque estas tareas simples pueden ser manejadas por IA. Correcto. Así que no es algo que quieras enviar a tu desarrollador junior. En lugar de eso, es mejor verlo y hacerlo juntos y explicarlo.

Y luego llaman a este concepto preceptoría. Así que te recomiendo encarecidamente que veas esta sesión. Está disponible en línea ahora. Pero nosotros, creo que tenemos tiempo para más preguntas y siguen llegando. Por cierto, amigos, este acaba de recibir atención especial. Cómo motivar a los miembros del equipo a salir de sus pequeños silos y comenzar a programar en pareja más. Así que volviendo a este tema de nuevo. Sí. No, quiero decir, esto es como Zed, siempre hemos hecho programación en pareja. Y creo que pasamos por una fase en realidad, donde la gente tiene este pensamiento binario de como, bueno, ahora tengo el agente. Como que no queremos ver al agente juntos. No podemos programar en pareja más. Y fue ese tipo de decisión muy binaria. Y esto ha sido como todos nos hemos ajustado, todavía estamos resolviendo esto. Pero creo que como líderes, si quieres intentar esto, creo que la mejor manera de hacerlo es decir que quieres que la gente haga esto más. No creo que imponerlo funcione. Correcto. Pero creo que también involucrarse con tus compañeros de equipo e invitarlos a una sesión en pareja contigo.

Creo que la gente no entiende el beneficio hasta que lo prueban por sí mismos. Y creo que depende de nosotros liderar de esa manera. Y hay momentos, quiero decir, también hay momentos en los que no es la herramienta adecuada. Yo tampoco programo en pareja todo el tiempo. A veces necesito tiempo para formar mi propia opinión sobre un problema y luego llevarlo a un compañero de equipo. Así que creo que se trata de averiguar dónde es útil.

Creo que, sin embargo, es una herramienta útil para usar. Y al menos parte del tiempo. Y creo que sí, creo que todo lo que realmente puedes hacer es invitar a la gente a hacerlo. Como estoy haciendo hoy, te invito a probarlo e invitar a la gente a probarlo contigo.

Sí. Y por cierto, solo quiero hacer un seguimiento de eso. No siempre tenemos el privilegio de tener esta programación en pareja en tiempo real, ¿verdad?

¿Qué tal la programación en pareja asincrónica? Porque también creo que las herramientas no son muy buenas en ese campo. Así que tal vez para personas con mentalidad emprendedora, podría ser una idea a considerar. Por ejemplo, pasas por esta sesión de agente de un desarrollador senior y tienes la oportunidad de detenerte en este punto y hacer tu pregunta. Oye, ¿por qué optaste por esto? Y considerando que no hay personas que puedan responder, tal vez la IA pueda ayudar a rastrear la intención de tu sesión. ¿Verdad? Sí, creo que la respuesta son dos cosas. Hay formas en las que estamos explorando esto en Zedd, pero también creo que somos un equipo distribuido globalmente. No muchas personas viven en el mismo lugar. Así que hacemos emparejamiento sincrónico, pero también trabajamos en equipo. Tenemos personas en muchas zonas horarias. Y así tendremos personas en un equipo y una persona terminará. Tal vez haya como una hora de superposición para la entrega, luego trabajan, y luego la siguiente persona se conecta. Y tenemos este ciclo de 24 horas en el que todos seguimos enfocados en la misma tarea, pero trabajando juntos. Y creo que esto también es muy efectivo.

Sí, sí. Consejo súper práctico. Y literalmente tenemos 10 segundos. Así que sé muy, muy, muy rápido y conciso. ¿Cómo aumentas la velocidad para el resto de la empresa? Como decisiones empresariales y propietarios de productos traduciendo deseos a tickets? Sí, creo que es nuestro trabajo como líderes tecnológicos trabajar con la gestión de interesados. Creo que esto solo puede venir del liderazgo organizacional en sí. Creo que esto tiene que ser parte de tu cultura, que valores esto. Puedes impulsarlo desde tu lado. Pero creo que tiene que haber un cambio real y una necesidad real que supere la resistencia. Lo he hecho en el pasado en otras empresas. No siempre es divertido, pero creo que es en última instancia la forma más efectiva de desbloquear a tu equipo. Así que absolutamente. Sé inclusivo. Ese es un resumen muy, muy breve.

Muchas gracias, Ben. Gracias. Un gran aplauso para Ben.