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 vamos a quedarnos 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 Vassim Dredia, 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 que yo sepa. Esto es un poco sobre mí, pero quiero que retengan lo que voy a decir ahora en sus mentes durante toda esta charla, ¿de acuerdo? 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... Probablemente se hayan sumergido en un análisis profundo en este momento, pensando en todas las posibles formas en que podríamos influir en el futuro y en las cosas que construimos a partir de ahora. Así que tengan esto en cuenta a medida que avanzamos.

Quiero que comprendamos la tecnología, porque entenderla nos permite utilizarla 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 el futuro, el temor de las personas. Para no tener miedo, primero debes entender. Para que podamos entender, voy a presentar mi argumento en tres partes diferentes que voy a explicar ahora.

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 utilizado diagramas UML antes. Estos son la creación de Grady. Pero también Grady ha hecho un trabajo fantástico archivando y construyendo, lo que vamos a ver ahora, sobre la historia de la computación. Así que comencemos nuestro viaje en el año 1842. ¿Sabías que las computadoras solían referirse a seres humanos reales? Algunos de ustedes pueden saberlo. Algunos de ustedes pueden no saberlo. Pero en esa era, el término computación 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 computación, algún tipo de cálculo que a veces era un poco tedioso, a veces un poco difícil para otros. Y aquí es donde realmente comenzó la computación en ese entonces.

Ahora no vamos a repasar todas estas diferentes fechas. Pero quiero hablar sobre algunas de ellas, algunos aspectos destacados, porque quiero ilustrar un punto sobre la historia de la ingeniería de software. Konrad Zuse creó el lenguaje Planck Calcule, donde en otro universo, Alemania podría haber sido, ya sabes, el líder en términos de computación y en términos de crear todo lo que vemos en el mundo. Todas las compañías que Konrad ha creado han allanado el camino para muchas de las compañías tecnológicas que existen en nuestro mundo actual. 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 creación 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 todavía se siente hasta hoy. Roth Dietlbaum 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, nuevas palabras y nuevos conceptos en nuestro vocabulario.

Y la razón por la que menciono a estas personas es que cada una de ellas ha introducido nuevos términos, nuevas palabras y nuevos conceptos en nuestro vocabulario. Han introducido nuevas formas de pensar en la programación, en elcode , en cómo interactuamos con las máquinas. Maurice Wilkis introdujo las subrutinas. Grace Hopper introdujo COBOL. Muchos de ustedes que trabajan en el sector bancario probablemente todavía trabajen con COBOL hasta cierto punto. Ahora algunos de estos desarrolladores son los mejor pagados. Pero la idea de los 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. 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 hacer algún trabajo en nuestro nombre.

Tenemos a Margaret Hamilton, quien acuñó el término ingeniería de software por primera vez y 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. Y 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 actual. Fred Brooks, él introdujo El Mes Mítico del Hombre. ¿Quién no ha leído ese libro? Si estás incursionando 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 él 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 rápido es porque tengo 20 minutos. Esta es una charla de 60 minutos. Solo tengan paciencia mientras recorremos rápidamente la historia de la computación.

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 esté trabajando en una empresa 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. Formó parte del Grupo de los Cuatro, quienes introdujeron los patrones de diseño. Quien no los conoce, los utiliza en el trabajo diario en las bibliotecas y los programas que construimos todos los días.

Mary Shaw abogó por el reconocimiento de la arquitectura de software. Nuevamente, se agregó nuevo vocabulario a nuestro léxico. La arquitectura de software no existía antes de ese punto. Mary Shaw nos introdujo a este concepto.

Jeff Dean. Todo lo que ves 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 ves en el aprendizaje automático hoy en día, además del trabajo de Jan Lecun y otras personas influyentes, Jeff tuvo un papel en ello. Gran cantidad de publicaciones excelentes salieron 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 condujo a la fundación de empresas como GitHub, donde agradezco 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 todas estos diferentes cambios 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. Aunque creamos Internet, aunque creamos una gran cantidad de maquinaciones altamente capaces que nuestros ordenadores actuales son capaces de hacer cosas que eran inimaginables en aquel entonces, aún así nuestro campo ha evolucionado 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 de abstracción más alto hoy en día. Mientras que la tecnología ha evolucionado 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 código hoy en día? ¿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 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 se está construyendo, y tiene muchas fuerzas diferentes actuando sobre él.

Recuerda el término fuerzas. Digo fuerzas porque algunas de estas están bajo nuestro control, otras no lo están. El contexto, la complejidad, la compatibilidad de nuestro sistema son algunas de estas fuerzas que actúan sobre nuestros sistemas.

Costos, cronograma y recursos. ¿Quién no ha lidiado con escasez de recursos? ¿Tenemos suficientes desarrolladores para construir nuestros sistemas? ¿Tenemos suficientes desarrolladores capaces de construir nuestros sistemas con los costos 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.

Entonces hay fuerzas en sí mismas. Y la razón por la que hablo de ellas 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 el punto. Tenemos los aspectos legales y éticos. Y lamentablemente nos preocupamos más por lo legal y menos por lo ético. Y esto es algo que como ingenieros de software también necesitamos cambiar en nuestra forma de abordar la construcción de cosas.

Entonces, el componente ético es extremadamente importante, especialmente en esta época en la que estamos introduciendo cosas como la IA en todo lo que hacemos. La seguridad, la confiabilidad, el rendimiento y la funcionalidad. Los llamamos requisitos no funcionales. Qué término tan loco. Pero también son cosas fundamentalmente importantes para cómo construimos y diseñamos 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, con 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 se mantengan 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, es simplemente tratar de equilibrar esta complicada ecuación de todas estas fuerzas que intentan generar cambios y 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 y tratar de mantener nuestros sistemas en un estado estable tanto como sea posible.

Ahora, obviamente, estos sistemas nunca serán tan estables como nos gustaría, porque si son estables, eso significa que no estamos cambiando nada en ellos. Eso significa que no estamos perturbando estos sistemas de ninguna manera. Construir sistemas es complicado. Por mucho que a muchas personas les gustaría pensar, no somos monos de code. No solo estamos escribiendo code y ya está, 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 puede hacer LLM en la ingeniería de software? Has jugado con LLM, has jugado con chatGPT, has jugado con Copilot.

Entonces, ¿cuánto de todo eso que hemos visto pueden hacer los LLM? Esta es la segunda pregunta que voy a responder y vamos a hablar al respecto.

Los LLM agresivos tienen problemas. Los LLM no pueden ser totalmente precisos. No importa lo que diga alguien, el estado actual, esta arquitectura de los modelos de lenguaje grandes no puede ser totalmente preciso y la toxicidad puede ser filtrada pero no puede ser eliminada por completo. No son controlables. La probabilidad de que los tokens producidos nos lleven a respuestas incorrectas 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 hacen los LLM en la ingeniería de software? Una fracción del trabajo de desarrollo. Apenas. ¿Verdad? Así es como estamos hoy en día. Incluso con la introducción de agentes, incluso con la introducción de mucha automatización basada en modelos de lenguaje grandes, no pueden hacer gran parte del resto. Todavía nos falta mucho antes de que los modelos de lenguaje grandes puedan reemplazar a los ingenieros de software. Esa es la base del argumento que estoy presentando hoy. Tómalo o déjalo, eso depende de ti. Sin embargo, los modelos de lenguaje grandes autoregresivos siguen siendo muy útiles. En GitHub hemos construido muchas cosas geniales basadas en ellos y seguiremos construyendo muchas cosas geniales utilizando estos modelos.

Han demostrado ser excelentes compañeros de programación. Son muy útiles. He estado usando Copilot incluso antes de que se lanzara públicamente y ahora no puedo imaginar trabajar sin él. Es una herramienta muy útil. ¿Por qué debería dejarla? 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 remixar diferentes formas de arte. Ayer estuve usando 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 usaré para generar ideas. Pueden ayudarte con tus bloqueos mentales, obviamente, y son muy útiles para personas que no hablan inglés como lengua materna o cualquier otro idioma, para ser honesto. ¿Has intentado hablar con ChatGPT en tu propio idioma nativo? Es bastante interesante, de hecho. Gurgly Oraz dice algo muy interesante. Si no conoces a Gurgly, tiene un gran boletín informativo. Solo ve y suscríbete.

Muy profundos conocimientos sobre muchas cosas que suceden en tecnología. Él dice, hay que dárselo 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 desarrolladores. Esto no es por error. Esto es muy intencional. Porque nos dimos cuenta de lo que los LLM pueden hacer y lo que no pueden hacer. Y 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 LLM no son AI, por favor. Son muy útiles pero no encapsulan todo el campo. Hay mucho más en AI además de los LLM.

Entonces 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 más producción de estas herramientas y para que estas herramientas estén más disponibles en nuestro futuro? Andrei Karpathy habla de Software 2.0. Si no has leído su publicación en el blog, este es un artículo muy importante 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 por nosotros. É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 Andrei. Y la razón por la que tenemos un horizonte de 5 a 10 años es porque nadie puede predecir realmente qué 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 aparezca en los próximos años. LLMs no son la solución. Necesitamos más arquitecturas orientadas a objetos. Y gradualmente se fusionarán 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 dejar 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í. Pero no vamos a competir con la calculadora. Las calculadoras pueden hacer las cosas mejor que tú hoy, ¿verdad? Entonces, ¿por qué no tenemos miedo de las calculadoras? Lo mismo ocurre con los grandes modelos de lenguaje. En muchos aspectos y en muchos campos, estas cosas van a hacer cosas que nosotros como seres humanos no somos capaces de hacer. Tenemos una capacidad de cálculo muy limitada en nuestros cerebros. Así que solo necesitamos dejar de competir con la máquina, comprenderla por lo que es y utilizarla por lo que es. El desarrollo asistido por IA mejorará con el tiempo, obviamente. Si SAS está muerto, que 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 décadas. Ya es hora de que desarrollemos nuevos problemas para resolver. Necesitas fortalecer tus fundamentos y construir profundidad 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ó, no si te alimentan información de otra persona, no si escuchas 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 un tecnólogo. Y nada de esto debería ser críptico o completamente místico para ti. Andrei Karpathy es un gran maestro. Tiene muchos videos fantásticos en YouTube donde desmitifica el proceso de construir tus propios grandes modelos de lenguaje desde la comodidad de tu hogar. Recomiendo encarecidamente ir a ver sus videos. También recomiendo el libro Matemáticas del Aprendizaje Automático.

Estos no son ninguno de mis libros. Solo estoy recomendando cosas que personalmente me gusta consumir. Siéntete libre de consumirlo o no. Estos son los códigos QR para ello.

Tiwadhar 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 consideran que las matemáticas son un área un poco desafiante para ellos.

Menos enfocado en el azúcar sintáctico y más enfocado en lo que está sucediendo bajo el capó, la programación volverá a ser un pasatiempo para muchos de nosotros. No puedo esperar 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. Necesitamos recordar eso.

Ahora, en el horizonte de diez años o más, honestamente nadie puede predecir qué va a 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 ahora tenemos la responsabilidad de intentar crear uno mejor juntos. Si volvemos a la pregunta inicial que te hice, ¿creamos el futuro? ¿Recreamos 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 hacemos como todo lo que la humanidad hará. 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. Pasemos a las preguntas. Recuerda que puedes hacer preguntas en Slido. Tenemos una pregunta, que cita a una persona muy famosa en el mundo de la AI. 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 sus opiniones siempre son bastante controvertidas y él es una persona bastante interesante Me encantan también sus chaquetas de cuero, pero eso es aparte. 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 la gente no debería aprender a code porque hemos creado mejores herramientas que pueden ayudarnos a ser mejores ingenieros. En mi opinión, todos deberían aprender a code.

Incluso si tenemos herramientas que pueden abstraer eso por nosotros. Lo que Jensen menciona o a lo que se refiere es que las personas comunes que no son ingenieros, no desarrolladores, no necesariamente deberían aprender a code a ese nivel, al nivel 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 code, ya sea utilizando lenguajes de programación o utilizando grandes modelos de lenguaje y demás. No estoy necesariamente de acuerdo con que nadie debería aprender a code. Deberías aprenderlo, pero simplemente elige las tooling adecuadas y sabremos que estamos seguros por ahora. Genial. Estoy totalmente de acuerdo. Y especialmente porque también dijeron a corto plazo. Eso es diferente desde una perspectiva a largo plazo. Alguien también ha preguntado, como para los desarrolladores junior, personas que recién están comenzando, que aún no han tenido tiempo de profundizar, como dijiste, y convertirse en esos expertos. ¿Qué pueden hacer en este mercado para destacar? Sí, eso es muy complicado. Para ser honesto, los grandes modelos de lenguaje 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 será suficiente. Así que adéntrate más, encuentra verticales 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? No, totalmente, totalmente. Y otra cosa que también quería preguntar y resaltar, pero no yo, la audiencia, que es, por ejemplo, cuando las redes sociales aparecieron, cambiaron la forma en que los humanos se comportan, y los humanos de alguna manera dependen de las redes sociales. Por favor, sigan tuiteando y usando los hashtags C3Divest.

Pero aparte de eso, ¿sientes que la dependencia humana de la IA hará que la humanidad sea menos inteligente día a 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, WALL-E, donde son completamente dependientes de los robots. Mira, evidentemente, si no somos conscientes de cómo consumimos la tecnología, nos volveremos dependientes de ellos. Esto es inevitable, ¿verdad? Lo que podemos hacer es establecer límites para cómo consumimos estas herramientas. Al final del día, son herramientas, sin importar cuánto podamos externalizar nuestros problemas y decir que todo es culpa de las herramientas, ¿verdad? Si decimos eso, nunca progresaremos, 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, debemos ser un poco más vigilantes, debemos 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 debemos estar conscientes.

No, absolutamente. Y esto destaca realmente lo que dijiste, como alguien que dice, como un principiante sordo, desearían que Copilot no les dijera la respuesta de inmediato, sino que les diera pistas. Como a menudo un maestro diría, estás cerca. Quiero decir, simplemente apaga Copilot por un rato, tal vez. 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, pedirle que lo haga. 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 que deseas personalizar y hacerla relevante para un entorno determinado, vas a necesitar introducir RAG en ella, es un mecanismo muy popular y efectivo para hacer que los LLM sean más adaptables al entorno en el que trabajas. Creo que muchas empresas lo están utilizando ahora para personalizar sus productos sobre los modelos fundamentales. Así que no estoy seguro de que haya algo controvertido al respecto. Bueno, bien. De acuerdo, sé que Dave, ya desconectamos tu computadora, pero ¿dónde pueden encontrarte las personas si quieren obtener las diapositivas o simplemente obtener más información? Bueno, 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 eso era gracioso. Fue una buena manera de design mi marca. Obviamente fue un error. Entonces, en 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. Estoy leyendo un libro llamado Polymath de Ahmad Waqas. Este libro es un catálogo de todos los polímatas que están en nuestra historia, y las personas que han sido expertas en tantas disciplinas diferentes, en oposición a la idea común de hoy de que todos necesitamos ser expertos en un solo dominio.

Es un libro muy agradable e interesante sobre todas estas grandes personas y lo que han logrado con la capacidad de extenderse a través de diferentes habilidades. Y creo que es una lectura interesante.

Increíble. Y el último que tomaré no es una pregunta, sino un comentario con el que estoy totalmente de acuerdo, al 100%. 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. Gracias.