El Último Ingeniero de Software

¿Qué tal AI Coding Summit? Mi nombre es Kent C. Dodds y estoy muy emocionado de hablar con ustedes sobre el último ingeniero de software. No, solo bromeo. Esto es una metáfora. No es realmente como si fuera el momento para que el último ingeniero de software presente su renuncia de dos semanas o lo que sea. Pero queremos hablar sobre habilidades duraderas.

Ahora, si estuviéramos en persona, entonces los invitaría a todos a ponerse de pie conmigo y haríamos sentadillas al aire juntos para hacer que la sangre fluya. Pero de forma remota eso es un poco incómodo. Así que no hacemos eso de forma remota. Pero si no te has movido en un rato, entonces necesitas mover tu cuerpo. Haz que la sangre fluya. Es bueno para tu cerebro y te ayudará a recordar de lo que hablamos hoy. Así que asegúrate de hacerlo.

Muy bien. ¿Lo hiciste? Genial. Sigamos adelante. Este es el trabajo que se debe hacer. Es todo el asunto, y se extiende a través de los dos zancos, los soportes. Y si no haces todo el trabajo, entonces esta caja se va a caer. Así que el trabajo que necesita hacerse puede ser hecho ya sea por ti manualmente o por ti usando las herramientas que tienes a tu disposición. Así que este es tu editor. Es tu C.I. y C.D. Es como todas las herramientas que construyes herramientas, herramientas por las que pagas. Todas estas herramientas te ayudan a lograr el trabajo que necesita hacerse. Y en los últimos años, las herramientas están haciendo más del trabajo que tradicionalmente hemos hecho, lo que nos deja con menos y menos que hacer, pero no realmente menos que hacer. Podemos lograr más trabajo. Así que puedes imaginar muchas de estas cajas para lograr más cosas. Así que no necesariamente estamos haciendo menos como no sé tú, pero siento que estoy trabajando mucho más de lo que solía. Pero estamos logrando más.

Pero el punto aquí es que las tareas que hacemos para lograr el mismo trabajo se han reducido porque el agente está asumiendo gran parte de lo que hacemos, la codificación diaria y ese tipo de cosas.

Entonces la pregunta aquí es, OK, bueno, ¿qué hacemos a medida que esto continúa reduciéndose? Como, ¿qué haces realmente aquí? Y si fueras a ver X.com o cualquier otro sitio, dirías, OK, bueno, es razonamiento. Oh, no, ingeniería de prompts.

OK, entonces, ¿qué sigue? Bueno, oh, no. Sabes, el fine tuning es en realidad mejor que la ingeniería de prompts, según esto. Así que, OK, espera un segundo. Ahora SWIGs está diciendo que es la ingeniería de flujo. Eso es lo que deberíamos estar haciendo y siguiendo. Oh, Dios, no. Ahora ni siquiera estamos escribiendo el código o la ingeniería de prompts. No estamos escribiendo los prompts. Ahora estamos haciendo que la IA escriba los prompts. Estamos en la ingeniería de bucles. Somos ingenieros de bucles ahora. No sé tú. Esto no es el final. Eso es seguro. Pero estoy agotado con todas estas cosas que se espera que sigamos.

Y es realmente irritante pasar mucho tiempo invirtiendo en una forma o flujo de trabajo particular solo para descubrir que ahora esa no es la forma en que lo hacemos más. Es de esta manera. Y esto no es solo un viejo gritando a la nube aquí. Esto es solo un tipo que quiere realmente entregar cosas buenas y no gastar mis ruedas en las diferentes actividades que podría hacer para realmente hacer el trabajo. Y entonces aquí está la pregunta, sí, los agentes de IA continúan mejorando. Y es por eso que estamos viendo esta rápida evolución de cómo usamos los agentes de IA. Pero la pregunta es, ahora, ¿cuál es el techo de los agentes de IA? ¿Qué tan buenos pueden llegar a ser estas cosas? ¿Es realmente hiperbólico? ¿O vamos a alcanzar AGI? ¿Ya estamos en AGI? No lo sé. Pero el hecho es que este es el futuro. No podemos predecirlo. Podría ser hacia, ya sabes, como directamente hacia la luna. O podríamos estar en una curva S. Y ahora estamos comenzando a estabilizarnos con las capacidades de estos modelos en estas herramientas. Si me hubieras preguntado hace un año qué tan buenos seríamos con nuestros agentes de codificación de IA, no habría predicho qué tan buenos somos ahora. Y eso me hace aún menos confiado en mi capacidad para predecir qué tan buenos seremos en el futuro. Así que nadie realmente sabe.

Si alguien te dice que así es como va a ser, sin reconocer que, como, en realidad no lo saben, entonces sospecharía. Necesito investigarlo. Entonces, ¿eventualmente será donde la IA haga todo el trabajo, y no seamos valiosos en ese caso en absoluto? Esa es una gran pregunta. No creo que realmente podamos responder a esta pregunta. Y honestamente, tampoco creo que sea una pregunta útil para obtener una respuesta. Porque, ¿qué vas a hacer en ese mundo, como, donde no queda nada para que hagas el trabajo?

Y, quiero decir, eso es un poco deprimente. Creo que algunos de ustedes pueden relacionarse conmigo habiendo tenido—he tenido dos crisis existenciales, y tal vez como dos y media en este punto desde el comienzo de este año, pensando, ¿qué hago? ¿Y cuál es mi futuro? ¿Cuáles son las cosas que podré hacer en el futuro? Y entonces lo que más o menos concluí fue, está bien, vamos a pretender por un momento que es posible que eventualmente todo el trabajo sea realizado por AGI. Eso no es realmente útil para planificar. ¿Quién sabe cómo será el mundo, cuál será mi papel allí? Entonces, ¿qué pasa si damos un paso atrás de eso?

Bueno, la IA, como, si no puede hacer todo el trabajo, entonces, por supuesto, va a fallar. Habrá algún tipo de porción sobrante. Habrá el último ingeniero de software que todavía está llenando el vacío. ¿Qué está haciendo ese último ingeniero de software? Eso es lo que estás haciendo. ¿Qué está pasando en esa porción? Y si podemos responder a esa pregunta, entonces podemos saber, en lugar de perseguir todas las cosas que están sucediendo en el mundo del software sobre cómo usar agentes y lo que sea, que cambian continuamente y los agentes continúan evolucionando y tomando más de nuestro trabajo para que todas las cosas que hiciste antes no sean necesarias.

Si eso fuera a suceder, damos un paso atrás, hay una fina capa de cosas que probablemente sean valiosas hoy y seguirán siendo valiosas entonces. Eso es lo que queremos aprender. Y eso, amigos míos, es lo que les voy a decir que se llama juicio. O lo encapsulo en el término de ingeniería de producto. Así que sigue siendo una disciplina de la ingeniería de software, pero hay muchas piezas de la ingeniería de software que están siendo absorbidas por la IA.

Y creo que el lado más humano de la ingeniería de software, que es la parte de ingeniería de producto y juicio, ese es el lado que será la porción que quede cuando terminemos. Así que hablemos de esto. Tengo una metáfora que realmente me gusta. Es este carcaj de flechas. Así que tengo un carcaj en mi espalda lleno de flechas y tengo estos diferentes objetivos que voy a alcanzar. Y alguien me dice, OK, alcanza ese objetivo. Y me he vuelto realmente bueno en alcanzar objetivos. Mira a este tipo. Ha pasado incontables horas volviéndose tan bueno que puede disparar una flecha a través de un anillo y dar en el blanco. ¿Eres un cazador con arco de vista de águila?

Estamos teniendo en cuenta la velocidad del viento y todo lo demás para que podamos clavar ese objetivo cada vez. Y el cambio que ha ocurrido en los últimos años es que donde solíamos tener un arco y flechas regulares, y sí, la tecnología para el arco y las flechas mejoraría. Hemos visto un cambio masivo reciente hacia flechas que son efectivamente como dispositivos de búsqueda donde va a dar en el objetivo cada vez. Ahora, no estamos del todo en ese punto. Todavía hay mucho que necesitas hacer. Y en esta conferencia y otras, tendrás que o aprenderás mucho sobre lo que puedes hacer para seguir mejorando la puntería y realmente dar en el objetivo.

Pero debido a que tenemos esto, ahora obtenemos un nuevo campo de tiro. Está lleno de objetivos. Puedes alcanzar cualquier cosa. Algunos de ellos están en movimiento. Son objetivos que nunca hubieras imaginado intentar alcanzar antes de llegar a este nivel.

Ahora tengo una pequeña ilustración divertida para ti. ¿Has oído hablar de la Flecha Patriota de Robin Hood Men in Tights? Vamos a ver esto muy rápido. Bien, tal vez nuestros agentes no sean tan buenos todavía. Pero tal vez eventualmente lleguen a ser tan buenos.

Así que en un mundo donde tu agente es como la Flecha Patriota que va a dar en el objetivo sin importar qué. La cuestión de qué tan bueno eres apuntando al objetivo se enfatiza menos. Importa mucho menos. Y la cuestión de saber a qué objetivo apuntar es mucho más importante.

Así que tengo un podcast llamado Become an Epic Product Engineer y tengo muchos invitados allí que tienen algunas ideas realmente geniales. Voy a leer un par de citas de ellos para ti aquí. Así que Wayne Allen dijo que construir lo correcto es posterior a construir lo correcto. No importa qué tan buena sea tu solución. Si construiste lo incorrecto, nadie lo va a usar. No importa. Y él da un ejemplo realmente bueno de un producto en el que trabajó que costó millones de dólares y nadie usó. Así que definitivamente escúchalo.

Luego dice que los ingenieros de producto se preocupan por la experiencia del cliente y los aspectos comerciales del producto, no solo por juguetear con la tecnología, sino por obtener un resultado. Así que ese es tu trabajo ahora. Deberías realmente preocuparte por obtener un resultado y medir las cosas para determinar si el resultado es bueno. Construir lo correcto es mucho más importante que construir la cosa correctamente. Ambos importan. Pero si fallas en uno, entonces fallas en todo. Así que construye lo correcto primero.

Bien, entonces Dax Rad, también genial. Dijo que tengo todas estas ideas que voy a enviar. El agente nunca va a oponerse. Solo va a igualar tu impulso. Y estamos viendo esto mucho donde la gente simplemente no está siendo reflexiva sobre lo que se está construyendo y solo están empujando, empujando, empujando. Y está resultando en slopware, que no es algo muy divertido para los usuarios. Solo estamos lanzando cosas a la pared y viendo qué se pega. Y eso no es muy amable con tus usuarios. Y la gente se está dando cuenta y van a seguir a aquellos donde el producto realmente está resolviendo sus problemas. Will King dijo que estás usando AI para traer cosas para que uses tu juicio.

Así que date tanta información como puedas para hacer un juicio. Así que ese es el punto aquí, que la IA no va a tomar tu papel como el que hace juicios, el que toma decisiones. Puedes usar AI para reunir la información que necesitas. Cuéntame sobre el sistema. ¿Cuáles son los elementos primitivos disponibles y la arquitectura y dónde están las limitaciones de las cosas y cuál sería el desafío si fuéramos en esta dirección versus esa dirección? Como reunir toda esa información. Pero al final del día, tú eres quien tiene la propiedad sobre este producto. Y es tu juicio el que va a decidir entre uno u otro. Y si todos tenemos esta herramienta, lo que diferencia un producto de otro es el que tiene un equipo de ingenieros de software que tienen un juicio realmente bueno. Así que ese juicio es una habilidad exclusivamente humana que te va a diferenciar de todos los demás que tienen las mismas herramientas que tú.

Y luego Ruben Costa dijo decidir qué construir. Creo que lo resumiré como simplemente ser curioso. Este es un tema que surge mucho en el podcast. Así que simplemente ser curioso. Ver qué problemas hay y simplemente probar cosas, crear prototipos y construir cosas para que puedas sentir lo que hacen. Y también, ¿realmente resuelven el problema para los usuarios? Así que Ruben está realmente interesado en este prototipado rápido y este es uno de los beneficios realmente agradables de los Agentes es que puedes hacer eso. Experimenta, observa a los usuarios usándolo y sé curioso. Solo intenta muchas cosas. Pero esto no significa como meter todo en el producto. No, no. Haz pruebas A/B, lo que sea, para que puedas iterar con los usuarios. Necesitas estar pensando en cómo este software impacta esa experiencia del usuario en lugar de solo como, wow, esta es una solución realmente genial. Como, amigo, ¿a qué problema? Esa es la pregunta que necesitas hacer.

Dylan Mulroy dijo que solo tienes que equivocarte suficientes veces para saber qué funciona y qué no funciona. Las decisiones sobre qué tiene un alto impacto se vuelven más fáciles con el tiempo. Y estoy completamente de acuerdo con esto. No hay atajos para la experiencia, pero hay actividades que te darán esa experiencia más rápido. Y ese juicio, ese sentido de diseño. Y así no solo el diseño visual, sino el sentido del diseño de sistemas. Y así tienes que iterar mucho. Tienes que pasar mucho tiempo probando diferentes cosas.

Si solo estás haciendo lo mismo una y otra vez, entonces eso no va a ser tan útil. Así que Dylan Mulroy, gran cita ahí. Y luego Jack Ryan, también un invitado increíble en el podcast. Dijo qué construir, cómo construirlo, cuándo construirlo. Esa sigue siendo nuestra elección. Los clientes no tienen que lidiar con las consecuencias de estar equivocados. Es muy importante que, al recibir este feedback de tus usuarios, no solo lo tomes y lo conviertas en una implementación. Jack tiene un ejemplo aquí donde hicieron eso y nadie terminó usándolo de todos modos. Te ignoran. Y así tienes que ser intencional sobre lo que estás construyendo y cómo encaja en la dirección y visión general del producto. Tienes que tener una visión.

Así que también es realmente clave aquí. Y luego Lucas Varga dijo que eres dueño de esa característica, lo que significa que podrías tener que ir y hablar con un montón de clientes y entender cómo esa característica de la que eres dueño impactará en última instancia las cosas. Y podrías tener que ir a hablar con las partes interesadas y personas de las que antes estabas totalmente protegido. Así que si has estado realmente cómodo y feliz con un gestor de producto interponiéndose entre tú y el cliente, esos días han terminado. Realmente necesitas estar muy involucrado. Ahora, el gestor de producto aún puede ser principalmente responsable de comunicarse con el cliente y otras partes interesadas clave. Pero si no entiendes de dónde vienen estos tickets y cuál es el propósito final y la visión y los trabajos a realizar de las características del software que estás implementando, si no entiendes qué son, entonces va a ser realmente difícil diferenciarte del agente de codificación de IA al que solo estás enviando tickets. Así que necesitas estar muy involucrado en los efectos aguas arriba y aguas abajo de tu implementación.

Así que la ingeniería de producto es la disciplina de crear decisiones de implementación para consecuencias de producto. Así que o conectar la decisión de implementación con la consecuencia del producto, ambas, como dije, aguas arriba y aguas abajo. Entonces, ¿de dónde vienen estos requisitos del producto? Y ¿cómo me aseguro de que caso la implementación o el diseño del sistema, la experiencia técnica que tengo con esa necesidad que tienen los usuarios para los que estamos tratando de construir este software? Así que para ser claro, el ingeniero de producto no es un gestor de producto. Estas son cosas distintas. Tu experiencia técnica es definitivamente necesaria en este espacio, pero no puedes simplemente tomar tickets y convertirlos en implementación. Nos estamos acercando más a lo que históricamente habrías pensado que es el trabajo del gestor de producto. Así que una o un par de las cosas que distinguen a un ingeniero de producto de un gestor de producto es que el ingeniero de producto hace preguntas como ¿para qué trabajo está contratando el usuario esto? Eso suena como una pregunta de gestor de producto, pero no, esta es una pregunta para ti ahora. Y luego el correlato de eso es, ¿cómo sirve nuestro sistema actual a ese caso de uso particular? ¿Cuáles son las brechas que tiene nuestro sistema? ¿Cómo sabremos que esto funcionó? ¿Cuáles son las salidas observables de nuestro sistema, y cómo podemos mejorarlas para saber que esto funcionó? Y ¿qué no debemos romper al hacer cambios en esas cosas, y cómo podemos asegurarnos de que esas cosas no se rompan a través de pruebas u otra validación? ¿Quién pierde si lanzamos esto? Así que hay otros usuarios que van a ser impactados por nosotros al agregar un botón aquí, y asegurémonos de entender esos compromisos. Así que tenemos métricas para nuestra aplicación. ¿Es esa métrica un proxy o el resultado real? Este tipo de preguntas necesitas poder tener la respuesta como ingeniero de producto. Y ¿cómo deshacemos esto si estamos equivocados? Siendo como las pruebas A/B, creo que esto se está volviendo mucho más valioso en esta era donde podemos lanzar cosas más rápido e iterar mucho.

No quieres simplemente enviar un montón de cosas mal hechas a todos tus usuarios. Tienes un conjunto particular de usuarios a los que estás tratando de resolver su problema. Haces una prueba A-B y les dejas experimentar con ello para que, una vez que sepas con certeza que estás resolviendo ese problema, entonces lo abres a todos los demás. Y luego es realmente fácil deshacerlo.

Dices, no, no, no, hicimos esto mal. Bien, hablemos de todas las afirmaciones que acabo de hacer. ¿Y si estoy equivocado sobre esto? ¿Y si en lugar de, ya sabes, como ir a la luna, estamos a punto de estancarnos? Bueno, la buena noticia es que ser un buen ingeniero de producto es algo útil, incluso si todavía estás disparando flechas regulares a objetivos como este. Poder saber cuál de esos objetivos golpear y cuál será el más valioso es realmente bastante útil. Y asegurarte de que estás golpeando el objetivo correcto y que lo estás golpeando en el centro, eso sigue siendo muy, muy útil.

Y honestamente, es el sello distintivo de los mejores ingenieros de software de la historia. Así que tienes a Drew Houston, que es como, ya sabes qué? Voy a hacer nuestro sync, pero más simple. Y tienes a Paul Butchett, que es como, ya sabes qué? Voy a hacer Yahoo, pero nunca tendrás que borrar un correo electrónico y puedes buscar tus correos electrónicos. Esa es una decisión de producto. La tecnología no era necesariamente mejor. Tal vez lo era, pero esa no es la razón por la que la gente se metió en Gmail. Fue porque el producto era mejor. Y luego Kevin Systrom construyó Bourbon, que era como un clon de Four Square. Y luego vi a los usuarios usarlo y me di cuenta de que a los usuarios realmente solo les importaba compartir fotos. Así que eso se convirtió en Instagram, y un usuario ganó mucho dinero haciendo eso. Y luego Juan Com, o Jean Com, construyó WhatsApp.

Y a pesar de que todos decían que necesitabas agregar todas estas características, él era notorio por decir no, no, no. No vamos a agregar todas estas características, siendo muy intencional sobre lo que está agregando, y también fue adquirido por mucho dinero.

Así que Sir Tim Berners-Lee, volvamos a Internet, decidiendo que, ¿sabes qué? Esto necesita ser un protocolo abierto. Esa fue una decisión. Y creo que miras a algunas de estas personas y piensas, oh, sí, pero todos son como personas de negocios. Bueno, lo son ahora. Son ingenieros. Y esto incluso se aplica al código abierto también.

Así que el código abierto es un producto. El estándar web, es un producto. Tienes que convencer a la gente. Y así, incluso si estás trabajando internamente, entonces lo que estás construyendo es un producto para los usuarios que tienes, que son internos. Entonces, ¿vas a ser el próximo gran ingeniero de producto? Tal vez no construyas un producto del que todos hayan oído hablar, pero lo que estás construyendo sigue siendo importante en el ámbito de tu contexto y los usuarios que tienes. Y necesitas ser reflexivo sobre eso.

Así que solo tengo un par de recursos para ti. The Last Software Engineer. Esta es la versión en blog de esta charla. También hago referencia al podcast Become an Epic Product Engineer. Definitivamente deberías echarle un vistazo. Y Epic Product Engineer es donde estoy haciendo formación sobre cómo convertirse en un ingeniero de producto épico. Así que échale un vistazo también. Y con eso, solo diré muchas gracias por escuchar. Y espero que tomes estas flechas que pueden dar en el blanco cada vez, tal vez en el futuro, y hagas los mejores productos que puedas. Que tengas un buen día. Nos vemos luego.

Bienvenido de nuevo. Bueno, primero que nada, muchas gracias por tu charla nuevamente. Fue realmente genial. Y creo que es uno de los temas más candentes y tal vez más importantes del último año o algo así. Así que muchas gracias. Eso da mucho que pensar. Y mientras esperamos algunas preguntas, tengo una. Básicamente, es la continuación de tu charla. Estamos observando cómo cambia el mundo, especialmente para nosotros, los ingenieros sordos. Y eso es realmente mucho. Y lo dijiste tú mismo. Así que me pregunto, desde tu experiencia, ¿ves este bombo alrededor de las técnicas de AI e incluso tal vez del software? ¿Está convergiendo en alguna dirección? Y si ves eso, tal vez puedas contarnos un poco más al respecto. ¿Cuáles son los productos principales que tal vez ves y cosas así?

Sí, creo que sin ninguna tecnología nueva, va a haber mucho caos alrededor de lo que estamos experimentando y tratando de hacer. Y el desafío con AI o un desafío con AI es que parece que es una tecnología nueva cada par de meses. Acabamos de recuperar Fable 5. Y eso ha sido – mi ambición es mucho mayor de lo que era antes con el tipo de cosas que le pido a los agentes de codificación AI que hagan. Y así que espero que eventualmente lleguemos a algún punto de normalidad. Pero ahora mismo, es realmente caótico. Y el consejo que la gente te da sobre flujos de trabajo de AI y cosas son geniales para hoy, pero probablemente cambiarán en los próximos meses, por lo que estoy tan interesado en enseñar habilidades duraderas.

Totalmente. Eso tiene mucho sentido. De hecho, veo que algunas de las preguntas aparecen ahora mismo. Comencemos con la primera. Se volvió tan fácil copiar ideas. ¿Cuál es tu opinión sobre eso? Imagina que alguien tiene una idea brillante, pero la gente simplemente la copia en un fin de semana. Supongo que continuando con la pregunta, ¿sería aún relevante intentar tus propias ideas? ¿O tal vez no merece ni siquiera el tiempo invertido? Sí, sabes, me temo que mi respuesta probablemente no será lo que mucha gente quiere escuchar. Y eso es – hay un par de facetas en esto. Una, la distribución y el marketing van a ser un gran diferenciador. Y así que, sí, a menudo eso va a requerir dinero para publicidad o lo que sea, o el apoyo de personas influyentes. Pero luego la otra cosa es que, incluso con AI, incluso con modelos de nivel fable, todavía necesitas saber cómo construir buenos primitivos. No puedes simplemente tomar la tecnología que tenemos ahora y dársela a una persona no técnica y esperar que pueda construir software mantenible a largo plazo. Simplemente no pueden hacer eso todavía. Así que sí, creo que eventualmente tal vez la AI sea capaz de construir software mantenible por sí misma, pero no es donde estamos ahora. Si llegamos a ese punto en el futuro, entonces como mostré, como todos esos objetivos a los que tienes la opción de apuntar, no creo que nadie pueda apuntar a cada uno de esos y disparar a todos. Y parte de la razón es técnica. Simplemente creo que costará demasiado. Pero la otra parte es que solo tienes tanto tiempo y energía para – o tus usuarios solo tienen tanto tiempo y energía para la atención. Y si apuntas a cada una de estas cosas, entonces tus canales de distribución se van a cansar. Y así que la gente todavía tendrá que elegir y seleccionar las ideas que implementan. Y ahora mismo, si los modelos son tan buenos, bueno, ¿por qué no simplemente reimplementas Google y vences a Google en su juego? Creo que todos podemos pensar en algunas razones por las que eso no funcionaría. Y creo que ese tipo de cosas van a continuar.

Eso es increíble. Totalmente. Veo que hay una pregunta popular en el chat ahora mismo. Como líder, ¿alguna idea sobre cómo inculcar esta mentalidad en mi equipo? Sí, gran pregunta. Así que uno de los desafíos aquí, uno de los más importantes, o una de las habilidades que más ayudará con eso es la propiedad y la responsabilidad. Y eso es realmente difícil de inculcar en las personas. Quiero decir, definitivamente es una habilidad aprendida, pero esto se reduce a la cultura que tienes en el equipo y la contratación. Lo que significa la propiedad es que alguien va a mirar una característica y sentir que tiene el poder y la autonomía y el permiso para poseer todo y ser responsable del resultado.

Y también obtener crédito por ello. Y simplemente sentirán que es muy importante que esa característica tenga éxito, lo cual es muy diferente de los tomadores de tickets del pasado que simplemente tomaban un problema, lo implementaban y luego pasaban al siguiente sin realmente preocuparse por los efectos aguas arriba o aguas abajo de lo que esa implementación implicaba. Entonces, ¿cómo inculcas esa mentalidad? Primero, se lo dices, y luego les das la autonomía para poder poseer algo. Y con suerte, con el tiempo, la gente comienza a asumir cierta propiedad.

Sí, muy bien. Propiedad y responsabilidad anotadas. Sí, pasemos al siguiente. Para acotarlo un poco si podemos, ¿dónde ves que va el rol de un ingeniero de desarrollo de software en pruebas? Oh, querido. He estado enseñando a la gente cómo probar durante más de una década. Probar es, creo, algo realmente valioso. Diría que la mayoría de los ingenieros de software se están moviendo hacia algo así como un ingeniero de fábrica, ingeniero de fábrica de software, donde estás construyendo. Y honestamente, esto es siempre lo que llamamos lo que estamos haciendo o lo que estamos tratando de hacer es construir una mejor fábrica. Solo que las piezas de nuestra fábrica eran trabajo manual de humanos. Ahora estamos automatizando mucho de eso.

Y así, para el lado de las pruebas, una de las partes realmente importantes para que un agente cierre el ciclo agéntico es hacer que el agente pueda verificar sus cambios. Y así, un ingeniero que se enfoca en las pruebas se centraría en construir primitivos realmente buenos para que los agentes verifiquen su trabajo. Y creo que los desarrolladores de software deberían estar usando agentes para ayudar a lograr eso. Pero esos son el tiempo y los tokens que están gastando. Sí, absolutamente. Y supongo que para terminar esta línea de pensamiento, una similar pero más sobre tu experiencia. ¿Cuál fue tu mayor desafío al adaptar tus habilidades de ingeniería de productos pre-AI al mundo de la codificación agéntica que siempre está emergiendo? Creo que muchas de las habilidades que son una especie de habilidades latentes que realmente no sabes que tienes y que simplemente surgen naturalmente de la experiencia se vuelven realmente valiosas e importantes con la IA.