Adaptándose al Futuro del Trabajo en Tecnología

El futuro es ahora. Voy a hablar sobre el cambio de paradigma en la programación asistida por IA. Así que todos nos vamos a quedar sin trabajo. Creo que necesitas buscar algo más que hacer en tu vida. Muchas gracias por asistir a mi charla técnica. No, solo estoy bromeando. Vamos a aclarar algunas cosas.

Mi nombre es Sebastian Drede. Soy un ingeniero de software senior en GitHub. Creo contenido técnico en mi tiempo libre trabajando los siete días de la semana. Mi pareja es una psicóloga holandesa y no, no me analiza psicológicamente, al menos eso creo. Esto es un poco sobre mí, pero quiero que retengan lo que voy a decir ahora en sus mentes durante toda esta charla. Les voy a hacer algunas preguntas y solo piensen en ellas mientras avanzamos en esta presentación.

¿Descubrimos el futuro? ¿Creamos el futuro? ¿O recreamos el pasado? Para algunas personas, esta puede ser una pregunta muy trivial. ¿De qué estás hablando? Para los filósofos entre nosotros, esto es muy profundo, probablemente se hayan sumergido en un deep dive ahora mismo, analizando lo que está sucediendo con esta pregunta y pensando en todas las posibles formas en que podríamos influir en el futuro y en las cosas que construimos en adelante. Así que tengan esto en mente mientras avanzamos.

Quiero que entendamos la tecnología porque entenderla nos permite usarla de manera efectiva. Muchas personas miran la tecnología y comienzan a usarla sin realmente entenderla a un nivel fundamental, y eso crea un mundo completamente nuevo de especulaciones sobre, ya sabes, el pesimismo, sobre lo que sucederá en el futuro, las personas tienen miedo. Para no tener miedo, primero debes entender. Y para que podamos entenderlo, voy a presentar mi argumento en tres partes diferentes que voy a explicar ahora. Y vamos a comenzar con el pasado.

Ninguna de estas cosas hubiera sido posible sin el gran trabajo de Grady Bush. Él es el creador y fundador de UML. Estoy bastante seguro de que has usado diagramas UML antes. Estos son el fruto del trabajo de Grady. Pero también Grady ha hecho un trabajo fantástico archivando y construyendo todo lo que vamos a ver ahora sobre la historia de la informática. Así que comencemos nuestro viaje en el año 1842. ¿Sabías que las computadoras solían referirse a personas reales? Algunos de ustedes pueden saberlo. Algunos de ustedes pueden no saberlo. Pero en esa época, el término `cómputo` comenzó con Annie Cannon y su grupo de computadoras de Harvard.

Y su trabajo era catalogar las estrellas que vemos en el cielo nocturno. En ese entonces, las computadoras solían referirse a seres humanos que realizaban algún trabajo de catalogación, alguna forma de cálculo, alguna forma de cálculo que a veces era un poco tedioso, a veces un poco difícil para otros hacer. Aquí es donde comenzó la informática en ese entonces.

Ahora no vamos a repasar todas estas fechas diferentes, pero quiero hablar sobre algunas de ellas, algunos aspectos destacados, porque quiero ilustrar un punto sobre la historia de la ingeniería de software. Conrad Zuse creó el lenguaje Planck Calcule, donde en otro universo, Alemania podría haber sido el líder en términos de cálculo y en términos de crear todo lo que vemos en el mundo. Y todas las compañías que Conrad ha creado han allanado el camino para muchas de las compañías tecnológicas que ahora están en nuestro mundo y las vemos en el mundo de hoy.

¿Quién no conoce a John van Neumann? Si has tomado algún curso de ciencias de la computación o ingeniería, probablemente hayas visto la architecture de la CPU, que fue la idea de este polímata y políglota en todos los sentidos de la palabra. John van Neumann fue un genio en su época y su impacto aún perdura hasta hoy. Roth Dietelbaum trabajó en la computadora ENIAC y co-desarrolló el sistema de programación para esa máquina. Y la razón por la que menciono a estas personas es que cada una de ellas ha introducido nuevos términos y nuevas palabras y nuevos conceptos en nuestro vocabulario. Han introducido nuevas formas de pensar sobre la programación, sobre code, sobre cómo interactuamos con las máquinas.

Morris Wilkis introdujo subrutinas. Grace Hopper introdujo COBOL. Muchos de ustedes que trabajan en el sector bancario probablemente aún trabajan con COBOL hasta cierto punto. Ahora algunos de estos desarrolladores son los más altamente remunerados, pero la idea de lenguajes de programación independientes de la máquina fue pionera por Grace Hopper. Antes de eso, teníamos lenguajes que eran muy específicos del hardware en el que realmente se ejecutaban.

Ahora, la razón por la que menciono todas estas cosas es porque quiero que piensen en los niveles de abstracción que estamos creando desde los puntos iniciales cuando comenzamos a introducir estas maquinaciones para que hagan algún trabajo en nuestro nombre. Tenemos a Margaret Hamilton, quien acuñó el término ingeniería de software por primera vez e lo introdujo en nuestro vocabulario común en esta industria. Antes de ese punto, el concepto de ingeniería de software no existía. Algunas personas pensaban que estábamos haciendo ingeniería, otras no. Tal vez las cosas estaban un poco confusas. La razón por la que hablo de estas cosas es para que reflexionen sobre esa progresión en la historia y lo que significa para la progresión que estamos experimentando en el mundo hoy en día.

Fred Brooks introdujo el Mes del Hombre Mítico. ¿Quién no ha leído ese libro? Si te estás adentrando en la gestión, este es el primer libro que todos te dicen que leas. Nuevamente, nuevo vocabulario. Ahora estamos en los Países Bajos. Edgar Dijkstra, quien no lo conoce, pero introdujo muchos de los conceptos fundamentales que vemos en nuestros lenguajes de programación hoy en día. Ahora, la razón por la que voy tan rápido es porque tengo 20 minutos. Esta es una charla de 60 minutos, pero solo aguántenme mientras recorremos rápidamente la historia de la informática.

Barbara Liskov. Me encanta el trabajo de Barbara porque todo lo que vemos en cualquier curso de ciencias de la computación hoy en día, cuando aprendes sobre abstracciones, tipos de datos abstractos, cuando aprendes sobre el principio SOLID, ¿quién sabe que la L en SOLID se refiere al trabajo de Barbara? El Principio de Sustitución de Liskov. Este es el trabajo de Barbara. Nuevamente, nuevos conceptos introducidos en nuestro vocabulario. Leslie Lamport trabajó en sistemas distribuidos. Cualquiera que trabaje en una empresa de SaaS hoy en día construyendo productos altamente distribuidos en su naturaleza, está trabajando o haciendo trabajo basado en el trabajo de Leslie. Tenemos a Brad Cox, Objective-C. Tenemos a Ed Yorton. Desarrolló técnicas de análisis estructurado. Tenemos los patrones de diseño. Eric Gama, fue parte del Grupo de los Cuatro, quienes introdujeron los patrones de diseño. ¿Quién no los conoce, los usa en el trabajo diario, en las bibliotecas, en los programas que construimos todos los días.

Mary Shaw abogó por reconocer la arquitectura de software. Nuevamente, se agregó un nuevo término a nuestro vocabulario. La arquitectura de software no existía antes de ese punto. Mary Shaw nos introdujo a este concepto.

Jeff Dean. Todo lo que estás viendo hoy en términos de big data, grandes tablas, todo el increíble trabajo que se hizo en Google, Jeff Dean tuvo un papel en ello. Todo lo que estás viendo en aprendizaje automático hoy en día, además del trabajo de Yann LeCun y otras personas influyentes, Jeff tuvo un papel en ello. Grandes cantidades de publicaciones excelentes salen de esta persona.

Kent Beck, desarrollo guiado por pruebas, Linus Torvalds, además de Linux también introdujo otra gran cosa que es Git, lo cual llevó a, ya sabes, la fundación de empresas como GitHub donde tengo la suerte de trabajar hoy en día. También tenemos, ya sabes, el término DevOps, Patrick Dubois, lo que sea. La idea es que nuestro campo ha evolucionado mucho a lo largo de los años. Pero si trazo todos estos cambios diferentes que han ocurrido desde el año 1800 hasta hoy, en realidad veo una línea de tendencia lineal. Veo que el campo de la ingeniería de software y el desarrollo de software y la programación no han evolucionado de manera exponencial, a pesar de que creamos internet, a pesar de que creamos enormes cantidades de maquinaciones altamente capaces. Nuestras computadoras en este momento son capaces de hacer cosas que eran inimaginables, inimaginables, inimaginables en ese entonces. Aún así, nuestro campo evolucionó de manera lineal. La forma en que hacemos las cosas no es tan diferente a la forma en que se hacían antes. Simplemente estamos haciendo las cosas a un nivel más alto de abstracción hoy en día. Mientras que la tecnología evolucionó de manera exponencial, nuestra metodología ha evolucionado de manera lineal. Ese es el primer argumento.

¿Qué es la ingeniería de software moderna? ¿Cómo escribimos code hoy? ¿Qué hacemos como ingenieros de software? Mucha gente incluso se queja y discute si lo que hacemos es ingeniería o no. Y este es el segundo argumento que voy a presentar ahora mismo.

Esto es un sistema. Un sistema puede ser prácticamente cualquier cosa que construyas en tu día a día. Puede ser un sitio web. Puede ser un sistema distribuido que hace mucho más que un simple sitio web. Puede ser una aplicación. Puede ser un sistema bancario completo. Puede ser un sistema HMS, lo que sea. Este sistema se construirá o ya está construido, y tiene muchas fuerzas diferentes que actúan sobre él. Y recuerda el término fuerzas.

Y digo fuerzas porque algunas de ellas están bajo nuestro control. Algunas de ellas no están bajo nuestro control. El contexto, la complejidad, la compatibilidad de nuestro sistema son algunas de estas fuerzas que actúan sobre nuestros sistemas. El costo, el cronograma y los recursos. ¿Quién no ha lidiado con la escasez de recursos? ¿Tenemos suficientes desarrolladores para construir nuestros sistemas? ¿Tenemos suficientes desarrolladores capaces de construir nuestros sistemas con el costo y el presupuesto que hemos definido para ello? ¿Tiene sentido construir estos sistemas según estos tres factores diferentes? Tenemos el trabajo de desarrollo, implementación y evolución que hacemos y que impactamos en nuestro sistema. Y esto es una fuerza en sí misma. Y la razón por la que hablo de esto en términos de fuerzas es porque quiero que tengas un modelo mental de cómo es la ingeniería de software. Quiero que pienses en el diseño de sistemas y la ingeniería de sistemas de esta manera en particular porque quiero ilustrar un punto.

Tenemos los aspectos legales y éticos. Y lamentablemente, nos preocupamos mucho más por lo legal y menos por lo ético. Y esto es algo que como ingenieros de software, creo que también necesitamos cambiar en nuestra forma de abordar la construcción de cosas. El componente ético es extremadamente importante, especialmente en esta época en la que estamos introduciendo cosas como AI en todo lo que hacemos. Security, seguridad, fiabilidad, performance y funcionalidad. Los llamamos requisitos no funcionales. Qué término tan loco. Pero también son cosas fundamentales para cómo construimos y design nuestros sistemas. Entonces, la ingeniería de software moderna es esto. Son estas diferentes fuerzas que afectan la forma en que construimos sistemas a diferentes ritmos. A diferentes capacidades.

Y nuestro trabajo como ingenieros de software es equilibrar todas estas fuerzas para que nuestros sistemas se mantengan en un estado de equilibrio. Para que nuestros sistemas permanezcan estables. Lo que enfrentamos en términos de sobrecarga operativa, en términos de luchar con el negocio, en términos de trabajar con los recursos que tenemos, simplemente intenta equilibrar esta ecuación complicada de todas estas fuerzas que actúan, ya sabes, tratando de provocar cambios y tratando de desestabilizar nuestro sistema. Entonces, nuestro trabajo como ingenieros de software es comprender realmente muchas de estas cosas, coordinar con muchas de las personas que ejercen estas fuerzas sobre nuestros sistemas e intentar mantener nuestros sistemas en un estado estable tanto como sea posible.

Ahora, obviamente, estos sistemas nunca serán tan estables como nos gustaría que fueran porque si son estables, eso significa que no estamos cambiando nada en ellos. Eso significa que no estamos alterando estos sistemas de ninguna manera, forma o manera. Construir sistemas es complicado. Por mucho que a muchas personas les gustaría que pensáramos, no somos monos code. No solo estamos escribiendo code y todo funcionará si simplemente escribimos el code para ello. Eso no es lo que hacemos. Estamos aquí para estabilizar nuestros sistemas.

Ahora la pregunta es, ¿cuánto de la ingeniería de software pueden hacer los LLMs? Has jugado con LLMs, has jugado con Chad GPT, has jugado con Copilot. Entonces, ¿cuánto de todas esas cosas que hemos visto pueden hacer los LLMs? Esta es la segunda pregunta que voy a responder y vamos a hablar sobre eso. Los LLMs autoregresivos tienen problemas. Los LLMs no pueden ser completamente factuales. No importa lo que diga alguien, el estado actual, esta architecture de los modelos de lenguaje grandes no puede ser completamente factual. Y la toxicidad se puede filtrar, pero no se puede eliminar por completo. No son controlables. La probabilidad de que los tokens producidos nos desvíen fuera del conjunto de respuestas correctas es bastante alta. Como puedes ver en este diagrama aquí, ya sabes, el gráfico espía. Tenemos muchas posibilidades, pero las respuestas correctas son bastante limitadas en el gran esquema de las cosas. Entonces, ¿cuánto de la ingeniería de software pueden hacer los LLMs? Una fracción del trabajo de desarrollo. Apenas. ¿Verdad? Ahí es donde estamos hoy. Incluso con la introducción de, ya sabes, agentes, incluso con la introducción de mucha automation construida sobre modelos de lenguaje grandes, no pueden hacer gran parte del resto. Todavía nos queda un largo camino antes de que los modelos de lenguaje grandes puedan reemplazar a los ingenieros de software. Eso se basa en el argumento que estoy presentando hoy para ti. Tómalo o déjalo.

Eso realmente depende de ti. Sin embargo, los modelos de lenguaje grandes siguen siendo muy útiles. En GitHub hemos construido muchas cosas excelentes basadas en ellos, y seguiremos construyendo muchas cosas excelentes utilizando estos modelos. Han demostrado ser grandes compañeros de programación. Son bastante útiles. Yo he estado usando Copilot incluso antes de que se lanzara públicamente, y ahora mismo no puedo imaginar trabajar sin él. Es una herramienta muy útil. ¿Por qué debería dejarla ir? Es como decir que quiero escribir un programa sin un compilador, o quiero escribir un programa sin un entorno de desarrollo integrado (IDE). ¿Por qué haría eso?

Pueden remix diferentes formas de arte. Ayer estuve utilizando la nueva versión de ChatGPT para generar ideas para nuevos videos que voy a crear. No voy a utilizar lo que genere para mis videos, pero lo utilizaré para generar ideas. Pueden ayudarte con tus bloqueos mentales, obviamente, y son muy útiles para hablantes no nativos de inglés o cualquier otro idioma, para ser honesto. ¿Has intentado hablar con ChatGPT en tu propio idioma nativo? Es realmente interesante. Gergely Oraz dice algo muy interesante. Si no conoces a Gergely, tiene un boletín de noticias genial. Solo ve y suscríbete. Tiene ideas muy profundas sobre muchas cosas que suceden en tecnología. Él dice que hay que reconocer al equipo de GitHub. Mientras que la mayoría de las herramientas de desarrollo de IA apuntan a un flujo de trabajo que toma una especificación y mucho más tarde genera code, sin ninguna entrada del desarrollador, GitHub creó un flujo de trabajo asistido por IA impulsado por los desarrolladores. Esto no es por error. Es muy intencional. Porque nos dimos cuenta de lo que los LLMs pueden hacer y lo que no pueden hacer. Esta es la estrategia que guía un poco cómo estamos trabajando e interactuando con estas herramientas y allanando el camino para el futuro. Estos son algunos mensajes de nuestro CEO y CEO en la misma línea. Los LLMs no son IA, por favor. Son muy útiles, pero no encapsulan todo el campo. Hay mucho más en IA además de los LLMs. La gran pregunta en este momento, que probablemente es por qué todos vinieron aquí a escucharme hablar durante 20 minutos, es cómo prepararse para el futuro. Hablamos del pasado, hablamos del presente, hablamos de las limitaciones y capacidades de estas herramientas. ¿Cómo podemos prepararnos para un futuro con una mayor proliferación de estas herramientas y para que estas herramientas estén más disponibles en nuestro futuro? Andrej Karpathy habla sobre Software 2.0.

Si no has leído su publicación en el blog, este es un artículo muy influyente sobre cómo este investigador ve el futuro de la programación. Él ve el futuro como un conjunto de datos que define un conjunto de comportamientos deseables, y luego construimos modelos utilizando estos conjuntos de datos para resolver problemas. Él ve nuestro trabajo como ingenieros de software como usuarios y constructores de modelos en lugar de escritores de secuencias de code con todas sus abstracciones intrincadas. La escritura de code será realizada por modelos y no necesariamente por seres humanos. Esta es la perspectiva de Andrej.

La razón por la que tenemos un horizonte de 5 a 10 años es porque nadie puede predecir realmente lo que sucederá más allá de este punto. Así que seamos un poco más prácticos y hablemos de lo que realmente podemos afectar y controlar en lugar de especular sobre lo que no podemos cambiar. En mi opinión, el cambio será gradual y esperado. No vamos a despertar un día y tener una superinteligencia artificial general dominando nuestra vida. No me importa lo que digan los pesimistas, no me importa lo que digan estas personas. Aprecio la conversación que debemos tener sobre las probabilidades de que esto suceda. Esto sigue siendo muy importante. Necesitamos hablar sobre regulación, necesitamos hablar sobre cumplimiento y leyes. Eso es muy importante. Pero no espero que esto surja en los próximos años. Los LLM no son eso. Necesitamos arquitecturas más orientadas a objetos, y comenzarán a fusionarse gradualmente con el tiempo. La IA a nivel humano está más allá del horizonte temporal que estamos discutiendo hoy, pero avanzaremos constantemente hacia ella. Debemos detener el impulso de competir con la máquina. A menudo escucho a la gente decir, ¿puede la IA hacer las cosas de manera más inteligente que los seres humanos? Sí, bueno, quiero decir, si vas a competir con una calculadora, las calculadoras pueden hacer cosas mejor que tú hoy, ¿verdad? Entonces, ¿por qué no tenemos miedo de las calculadoras? Lo mismo ocurre con los modelos de lenguaje grandes. De muchas maneras y en muchos campos, vamos a hacer cosas que ni siquiera somos capaces de hacer nosotros mismos como seres humanos. Tenemos una capacidad de mecanización muy limitada en nuestros cerebros. Así que solo necesitamos dejar de competir con la máquina y comprenderla por lo que es y utilizarla por lo que es. El desarrollo asistido por IA mejorará cada vez más con el tiempo, obviamente.

SAS está muerto. ¡Viva SAS! La razón por la que digo esto es porque hemos avanzado mucho en este campo en este momento. Siento que este es un problema resuelto. Debemos comenzar a enfocarnos en problemas más difíciles en el futuro. Hay muchas metodologías diferentes para construir sistemas distribuidos, mantenerlos, optimizarlos, escalarlos.

Hemos estado haciendo eso durante muchas, muchas décadas. Ya es hora de que desarrollemos nuevos problemas para resolver. Necesitas profundizar en los fundamentos y construir conocimientos en las ciencias duras, nuevamente, en mi opinión, porque si quieres participar en la conversación que se llevará a cabo en el futuro, necesitas estar informado. Y la única forma de estar informado es si comprendes lo que está sucediendo bajo el capó.

Entonces, si no estás recibiendo información de alguien más, no estás escuchando a personas como yo, necesitas desarrollar tu propia perspectiva sobre la tecnología. Y estás en una excelente posición para hacerlo, porque tú mismo eres tecnólogo, y nada de esto debería ser críptico o completamente místico para ti. Andrej Karpathy es un gran maestro. Tiene muchos videos fantásticos en YouTube donde desmitifica el proceso de construir tus propios modelos de lenguaje grandes desde la comodidad de tu hogar. Recomiendo encarecidamente ir a ver sus videos. También recomiendo el libro The Mathematics of Machine Learning. Ninguno de estos libros es mío. Solo estoy recomendando cosas que personalmente me gusta consumir. Siéntete libre de consumirlo o no. Estos son los códigos QR para ello. Tiwadar tuvo muchos problemas para aprender matemáticas cuando era más joven, así que creó este libro para las personas que también se sienten desafiadas o sienten que las matemáticas son un área un poco desafiante para ellos.

Menos enfoque en el azúcar sintáctico y más enfoque en lo que está sucediendo bajo el capó, la programación volverá a ser un pasatiempo para muchos de nosotros. No puedo esperar a ese día, para ser honesto. El foco estará en resolver problemas humanos. Eso solo se volverá más brillante, porque no se trata de la tecnología. Nunca lo fue. Todo lo que hacemos es resolver problemas humanos. Debemos recordar eso. Ahora, en el horizonte de diez años o más, honestamente nadie puede predecir qué sucederá más allá de la singularidad. Espero que seamos responsables acerca de lo que vamos a introducir en nuestras vidas en el futuro.

Finalmente, quiero dejarte con estas últimas palabras. De muchas maneras, vamos a descubrir el futuro, pero en este momento, tenemos la responsabilidad de intentar crear uno mejor juntos. Si volvemos a la pregunta inicial que te hice, ¿creamos el futuro, creamos el pasado o descubrimos el futuro? En mi perspectiva, vamos a influir en el futuro, pero también lo vamos a descubrir porque no podemos predecir realmente todo lo que todos haremos como todo lo que la humanidad hará. Pero lo que podemos hacer ahora mismo es ser más responsables acerca de lo que aportamos a nuestro futuro juntos. Muchas gracias por escuchar. Este es un código QR para todos los enlaces.

Vamos a abordar las preguntas. Recuerda, puedes hacer preguntas en Slido. Tenemos una pregunta que cita a una persona muy famosa en el mundo de la IA, y esa persona dijo que la codificación y el desarrollo de software ya no serán necesarios a corto plazo. ¿Estamos seguros? ¿Están seguros nuestros trabajos? ¿Qué opinas? Me encanta Jensen porque siempre tiene opiniones bastante controvertidas, y es una persona muy interesante Me encantan sus chaquetas de cuero también, pero eso no viene al caso. Siempre tiene estas opiniones controvertidas por una razón. Al mismo tiempo, quiere promocionar su propia empresa. Creo que es una opinión muy equivocada decir que las personas no deberían aprender a codificar porque hemos creado mejores herramientas que pueden ayudarnos a ser mejores ingenieros. En mi opinión, todos deberían aprender a codificar, incluso si tenemos herramientas que pueden abstraer eso por nosotros. Ahora, lo que Jensen menciona o a lo que se refiere es que las personas promedio que no son ingenieros, no son desarrolladores, no necesariamente deberían aprender a codificar a ese nivel, a el nivel en el que nosotros lo hacemos, y deberían poder beneficiarse enormemente al poder construir su propio software. ¿Por qué no? En mi opinión, todos deberían poder codificar, ya sea utilizando lenguajes de programación o utilizando modelos de lenguaje grandes y demás. No estoy de acuerdo en que nadie debería aprender a codificar. Deberías aprenderlo, pero simplemente elige las herramientas adecuadas y sabremos que estamos seguros por ahora. Genial. Estoy totalmente de acuerdo, especialmente porque también dijeron a corto plazo. Eso es diferente desde una perspectiva a largo plazo. Alguien también ha preguntado, para los desarrolladores junior, personas que recién están comenzando, que aún no han tenido tiempo para profundizar, como dijiste, y convertirse en esos expertos, ¿qué pueden hacer en este mercado para destacarse? Sí, eso es muy complicado. Pero para ser honesto, los modelos de lenguaje grandes y estas herramientas van a elevar el estándar de lo que necesitas construir a un nivel completamente nuevo, y creo que deberías aprovechar estas herramientas para construir cosas más complicadas, más impresionantes en lugar de rendirte. Entonces, básicamente, tu lista de tareas promedio en este momento, que es un proyecto que todos hacen cuando comienzan a aprender a programar, ya no va a ser suficiente. Así que comienza a adentrarte más, encuentra áreas en las que estés interesado, profundiza tanto como puedas en ellas y aprovecha las herramientas para obtener el conocimiento impresionante que normalmente no tendrías sin ellas, ¿verdad? Totalmente, totalmente. Otra cosa que también quería preguntar y resaltar, pero no yo, la audiencia, que es, por ejemplo, cuando aparecieron las redes sociales, las redes sociales cambiaron la forma en que los humanos se comportan, y los humanos de alguna manera dependen de las redes sociales. Por favor, sigan twitteando y usando el hashtag C3Defest. Pero aparte de eso, ¿sientes que la dependencia humana de la IA hará que la humanidad sea más tonta cada día y eventualmente la IA se convertirá en una necesidad para la vida en el futuro? Estoy pensando en la película de Pixar Wardy, donde dependen completamente de los robots.

Mira, evidentemente, si no somos conscientes de cómo consumimos tecnología, vamos a depender de ella. Esto es inevitable, ¿verdad? Pero lo que podemos hacer es establecer límites para cómo consumimos estas herramientas. Estas son herramientas que, al final del día, sin importar cuánto podamos externalizar nuestros problemas y culpar a las herramientas, si decimos eso, nunca vamos a progresar en absoluto, porque cualquier herramienta que elijas, puedes hacer cosas malas con ella. Se trata de cómo la consumimos, y creo que necesitamos crear más conciencia, ser un poco más vigilantes, introducir gradualmente estas herramientas en nuestros entornos y ser conscientes de cómo las estamos introduciendo y utilizando. Y sí, no creo que haya un atajo rápido para eso, simplemente necesitamos estar conscientes.

Absolutamente, y en realidad esto es más un comentario que una pregunta, pero realmente destaca lo que dijiste como alguien que dice, como un desarrollador junior, que desearía que Copilot no le diera la respuesta de inmediato, sino que le diera una pista. Como a menudo un profesor diría, estás cerca. Quiero decir, ¿por qué no apagar Copilot por un rato? Sí, eso es un buen ejercicio, pero también, ¿puedes decirle que no te dé la respuesta de inmediato? Ese podría ser un enfoque, incítalo a hacerlo. Claro. Casi se nos acaba el tiempo, pero hagamos algunas preguntas más. ¿Cuál es tu opinión sobre la generación aumentada por recuperación? Sí, quiero decir, está proliferando bastante. Cada herramienta que se está desarrollando ahora y que deseas personalizar y hacerla relevante para un entorno específico, vas a necesitar introducirle RAG. Es un mecanismo muy popular y efectivo para hacer que los LLM sean más adaptables al entorno en el que trabajamos. Creo que muchas empresas lo están utilizando ahora para personalizar sus productos sobre los modelos fundamentales, así que no creo que haya nada controvertido al respecto. Genial, genial. Bueno, sé que Dave, ya desconectamos tu computadora, pero ¿dónde pueden encontrarte las personas si quieren obtener las diapositivas o simplemente saber más? Claro. Si buscas mi nombre en Google, probablemente encontrarás algunos enlaces. Estoy en todas partes, porque me promociono en todas partes, pero también, si vas a glitch.stream y glitch sin la T, pensé que era gracioso. Fue una buena manera de design mi marca. Obviamente fue un error. Así que glitch sin la T.stream, encontrarás todos los enlaces de todo lo que tengo. Increíble, increíble. ¿Y qué libros estás leyendo actualmente? Recomendaste muchos buenos. ¿Qué libros estoy leyendo actualmente? Estoy leyendo un libro llamado 'Polymath' de Ahmed Waqas, y este libro trata sobre un catálogo de todos los polímatas que han existido en nuestra historia y las personas que han sido expertas en tantas disciplinas diferentes, en contraposición a la idea común de hoy de que todos necesitamos ser expertos en un solo dominio. Es un libro muy interesante sobre todas estas personas increíbles y lo que han logrado con la capacidad de extenderse a través de diferentes áreas de conocimiento, y creo que es una lectura interesante. Genial. Y el último comentario que tomaré no es una pregunta, sino un comentario con el que estoy totalmente de acuerdo. Bassem, muchas gracias por tu charla. Eso es todo lo que tenemos que decir. ¿Podemos aplaudirle una vez más? Muchas gracias por tenerme aquí. Gracias. Lo aprecio.