Escalando la Adopción de AI: Los Desafíos Reales de Transformar a 300 Ingenieros

Hola a todos. Hoy hablaremos sobre cómo estamos escalando la adopción de IA en una empresa donde tenemos más de 300 ingenieros. Así que hablaremos sobre cuáles son los desafíos reales, cómo lo estamos haciendo, qué funcionó, qué no funcionó, y tal vez solo compartir algunos, como, consejos y trucos. Así que, antes que nada, lo siento, mentí. En realidad, somos más de 400 ingenieros en este momento. Así que el número cambió un poco. Pero los principios, por supuesto, siguen siendo prácticamente los mismos. Solo unas palabras sobre mí antes de comenzar. Soy Alfonso. Soy de Italia. Soy líder técnico en una empresa llamada NearForm. NearForm es básicamente una empresa que vende servicios a industrias altamente reguladas. Somos, como mencionaba, más de 400 ingenieros mientras hablamos. Estoy construyendo agentes de IA. Así que estoy en uno de nuestros proyectos de IA. Estoy apoyando a múltiples equipos en la adopción de ingeniería nativa de IA. Y también estoy escribiendo un libro llamado Learning AI Native Software Engineering. Pero solo les daré un poco más de información más adelante.

Así que hoy veremos un poco de un viaje. Así que podemos imaginar un equipo en la parte inferior izquierda, un equipo como usualmente un equipo multifuncional con ingenieros de software, PMs, diseñadores, todo tipo de profesionales que puedas necesitar. Y veremos cómo este equipo puede transformarse para convertirse en un equipo de IA. Veremos algunas trampas, algunos problemas, ya sabes, algo que aprenderán a lo largo del viaje. ¿Cuáles son las técnicas que estamos enseñando a esos ingenieros y esos equipos? Y sabes, con suerte, algo que será útil y reutilizable en tus equipos también.

Así que hay un desafío, un desafío muy común que estoy viendo en múltiples equipos, en múltiples de nuestros clientes, que es, está bien, compramos las licencias de copilot o cloud code, lo que sea que tu equipo esté usando, pero nada realmente cambió. Quiero decir, sí, podemos ver que algo cambió en términos de velocidad y lo que el equipo está produciendo, pero no estamos seguros de si vale la pena el precio, ¿verdad? Así que hemos visto que, sí, algo está sucediendo, pero no estamos seguros de qué realmente cambió una vez que obtuvimos las licencias de copilot o lo que sea. Y así, en realidad, lo que descubrimos es que mover en el departamento de ingeniería de un montón de ingenieros de solo experimentar con herramientas de IA a realmente desarrollo nativo de IA, es mucho más que solo herramientas, ¿verdad? Va a tomar cambios de mentalidad, herramientas, por supuesto, mejorar habilidades bastante, mucho aprendizaje entre pares. Así que hoy responderemos algunas preguntas. Así que responderemos por qué comprar herramientas no es suficiente. En primer lugar, ¿qué realmente cambia cuando los equipos se vuelven realmente nativos de IA, verdad? Cuando las cosas comienzan a funcionar y cómo escalas? ¿Cómo escalas todo a una organización completa sin romper personas, procesos, equipos, y todas estas cosas buenas? Muy bien, primero hablemos de una brecha de madurez. Así que esperaría que en tu organización tengas múltiples equipos, y estoy casi seguro de que puedes tomar cada equipo y ubicarlos en uno de esos cuadrantes.

Así que este es básicamente un diagrama muy simple. Y como podemos ver, tenemos la fluidez en IA individualmente como eje x. Así que como personas aprendiendo habilidades, implementando las herramientas adecuadas, usando SDD, usando verificación, construyendo arneses. Y luego en el eje y, tenemos la estandarización del equipo, porque lo que notamos es que no importa demasiado si un individuo tiene fluidez en IA si todo el equipo no adopta todas estas prácticas. Así que comenzando desde la parte inferior izquierda, todo está intacto, ¿verdad? Así que el equipo no tiene estandarización. Las personas no tienen fluidez en IA. No hicieron mejora de habilidades. Así que básicamente, todo está codificando en 2022, prácticamente intacto. Así que nada cambia.

Luego, en algunos casos, hemos visto equipos donde hay como posiblemente reglas, hay estandarización del equipo, pero realmente las personas no hicieron mejora de habilidades adecuadamente. Así que aunque las reglas en teoría están en su lugar, no podemos ver una gran cantidad de beneficios. Por otro lado, en la parte inferior derecha, podemos ver que hay como campeones. Así que hay individuos muy capacitados, pero no hay reglas compartidas, no hay estándares de equipo. Así que todos están más o menos haciendo lo suyo. Y así, aunque a nivel individual, las personas son inteligentes y están trabajando bien, no hay un efecto acumulativo a nivel de equipo y luego a nivel organizacional.

Lo que estamos buscando es mover a casi todos a la parte superior derecha, que es el equipo nativo de IA. Así que tenemos personas capacitadas, las herramientas adecuadas, las prácticas compartidas, y esos son los equipos que realmente queremos escalar. Esos son los equipos que estamos buscando. Por supuesto, no es solo, como mencionaba, no se trata solo de diferentes equipos en diferentes niveles en la escala de madurez. También se trata de dentro del mismo equipo. Dentro del mismo equipo, vamos a encontrar la misma brecha, prácticamente. Así que veremos, tendremos a alguien a quien llamamos un ingeniero de equipo de IA, que es una persona que sabe cómo aprovechar adecuadamente, las herramientas, las prácticas y todo de una manera nativa de IA. Y luego tenemos dentro del mismo equipo, podríamos tener gerente de producto, ingeniero, slidge, ingeniero de plataforma.

Así que todo lo que realmente necesitas en tu equipo. Y cada persona dentro del equipo estará en un nivel diferente en la escala de madurez. Así que alguien podría estar comenzando a experimentar con IA, alguien podría estar muy maduro en su camino. Alguien podría ser un poco reacio. Así que aunque estés en el mismo equipo, en realidad tienes diferentes puntos de partida.

Y por supuesto, lo que vas a necesitar hacer es, en primer lugar, mejorar las habilidades de las personas a nivel individual, pero luego también mejorarlas a nivel de equipo. Por supuesto, esto no sucede en el vacío, ¿verdad? Así que el equipo en sí no sucede en el vacío. Tienes equipos circundantes que interactuarán con este equipo, tendrás como estándares personalizados a nivel de la empresa, interactuarás con clientes, con liderazgo, con el departamento de ingeniería, el departamento de diseño, ya sabes.

Así que no se trata solo de construir el equipo, sino también de, a mayor escala, construir el contexto adecuado para que este equipo prospere y aprenda. Una cosa que notamos, especialmente al trabajar con ingenieros muy experimentados, es que hay un aspecto de resistencia. Notamos que al menos inicialmente, ¿verdad?, tal vez ahora está sucediendo cada vez menos. Pero estamos en un nivel diferente en la escala de madurez.

Y hay objeciones comunes que realmente tienen sentido, ¿verdad? Así que la primera es, está bien, pero lo intenté hace como seis meses y esto realmente no funciona para mi caso de uso, ¿verdad? Estoy haciendo algo muy específico, que es importante, que es crítico para la misión. Y esas herramientas de IA, sí, pueden hacer una aplicación de React elegante, pero no pueden hacerlo bien. No pueden funcionar bien en mi caso de uso. Y este es el miedo a perder precisión y calidad en sistemas complejos. Y eso es completamente normal. Como veremos, ese no es realmente el caso. Así que ahora tenemos evidencia de que los sistemas de IA son lo suficientemente buenos también para casos de uso muy complejos si podemos guiarlos correctamente y construimos el arnés adecuado.

La segunda cosa, la segunda objeción común que hemos visto múltiples veces es, está bien, dejaré de pensar, solo daré indicaciones todos los días, solo le diré al agente qué hacer y el agente lo hará. En realidad, no funciona así, ¿verdad? Así que cuando aprendes a usar estas herramientas correctamente, lo que descubres es que realmente estás pensando, estás diseñando el sistema, estás validando el sistema. Así que básicamente estás haciendo muchas cosas, como que tu pensamiento sigue ahí, solo te falta la parte de implementación en algunos casos. En otros casos, podrías querer intervenir e implementarlo tú mismo, ¿verdad? Así que no, nunca dejarás de pensar, ¿verdad? Si estás usando esas herramientas correctamente, si estás usando esas prácticas correctamente, pensarás bastante, ¿verdad? Solo cambia el nivel de abstracción en este caso.

Y luego el tercero es, me convertí en ingeniero para escribir código porque me apasionaba el código. Creo que todos hemos escuchado historias de ingenieros que comenzaron a escribir código cuando tenían como 13 años. Esa es mi historia, por ejemplo, comencé a programar cuando era muy joven y luego me convertí en ingeniero porque me encanta escribir código. Lo que descubrí en realidad, después de usar esas herramientas por un tiempo, es que realmente no me gusta escribir código por el simple hecho de escribir código. Pero me encanta escribir código porque me ayuda a resolver un problema, ¿verdad? Y así, si podemos construir las especificaciones, si podemos construir la arquitectura, si podemos construir la capa de verificación, todavía estamos resolviendo el mismo problema, ¿verdad? Es solo de una manera ligeramente diferente, solo con un nivel de abstracción ligeramente diferente. Así que mucho de esto, mucho de trabajar con esta resistencia de ingenieros capacitados es sobre replantear lo que estamos haciendo y cuál es nuestro trabajo y dónde podemos crear el verdadero valor.

Porque el valor se está moviendo de la implementación, como elegir una tarjeta, elegir una historia de Jira, a un juicio de alto nivel, por ejemplo, diseñar el sistema, siendo casi como un arquitecto. Y luego, por supuesto, descomponer problemas, construir especificaciones, la capa de verificación, como mencionaba, como pasar de escribir el código a revisar el código real para entender qué está haciendo para asegurar que todo sea estable. Y luego, por supuesto, muchos ingenieros muy capacitados dicen, oh, no quiero borrar código, ¿verdad? Y eso, por supuesto, tiene mucho sentido. Siento que hay una diferencia muy importante entre codificar o prototipar, como queramos llamarlo, y la ingeniería nativa de IA, donde queremos enviar código listo para producción, ¿verdad? Código de calidad de producción.

Hay un viaje de contribución individual, y luego hay un viaje de equipos. Comencemos con el propio contribuyente individual. Así que la ingeniería nativa de IA cambia la unidad de trabajo de código a intención. Y hablaremos de la intención en un minuto. Y luego, cuando intentamos reformular un poco y pensar en cómo queremos cambiar nuestra mentalidad, deberíamos pensar que los ingenieros de software están pasando de implementadores, ¿verdad? a orquestadores, a personas que construyen un entorno que puede ser optimizado no solo para humanos, sino también para agentes de IA. Déjame darte un ejemplo. Cuando estás incorporando a un nuevo colega, generalmente estás escribiendo documentación, creando scripts, haciendo sesiones de programación en pareja para que puedas incorporar a esta persona. Ahora, imaginemos que tienes que incorporar a un agente de IA, ¿verdad? Quieres darle a este agente de IA todas las herramientas, todo el contexto, hacer que el agente de IA pueda explorar todo para que pueda desempeñarse como debe.

Y eso es como construir el arnés. Así que el nuevo centro de gravedad, como se mencionaba, ahora es definir la intención, establecer las restricciones y construir la capa de verificación. Así que para la intención, es básicamente como decidir qué queremos construir antes de construirlo, dando objetivos claros, trabajando con nuestro equipo, ¿verdad? trabajando con gerentes de producto, trabajando con diseñadores. Así que en la primera fase, definir la intención es súper importante, y esa es una de las primeras partes del desarrollo de Spectre. Luego está la construcción de restricciones, que es lo que quiero que el sistema haga, lo que quiero que el sistema no haga, ¿verdad? Queremos crear límites para que podamos mantener nuestra IA en el camino, básicamente. Y luego está la capa de verificación, que es que necesitamos formas para que el agente, idealmente, se auto-valide lo que está construyendo para que aseguremos que el resultado final, para que podamos confiar en el resultado final, y luego podamos revisarlo adecuadamente. Solo quiero darte una comprensión muy rápida del desarrollo de Spectre. Sé que esta no es una charla sobre SDD, pero solo muy rápidamente, porque es uno de los aspectos importantes que estamos enseñando a nuestros equipos. Así que SDD es básicamente una metodología para trabajar con agentes donde, primero que todo, definimos nuestra intención, ¿verdad? Así que lo que queremos implementar. Creamos la especificación, creamos un archivo de especificación completo. Luego tenemos al humano en el bucle. Así que revisamos la especificación, aseguramos que esté alineada con lo que estamos buscando, y luego creamos un plan de implementación junto con el agente. Así que vamos a decirle al agente, OK, vamos a crear un plan de implementación juntos. Puedo guiarte un poco, puedo revisar lo que construyes. Y así iteramos hasta que el plan de implementación esté listo. Una vez que la implementación esté lista, las tareas han sido descompuestas y demás, podemos pedir al agente, implementamos cada tarea y sub-tareas, por supuesto.

Y luego hay un poco de sustrato, que es muy importante, súper importante, que es, en primer lugar, el contexto del proyecto, ¿verdad? Así que nuestro archivo de arquitectura, nuestro archivo PRD, lo que estamos construyendo, nuestras habilidades, todo lo que puede ser útil para que el agente lo guíe en la dirección correcta. Y luego, por otro lado, tenemos todo lo relacionado con la verificación y las barreras de protección. Así que solo para darte ejemplos muy simples, nuestras tareas unitarias, nuestras reglas de linchamiento, de formato, nuestros, no sé, barreras de protección de la aplicación, como todo lo que pueda dar retroalimentación al sistema mientras está creando el plan, mientras está implementando, ¿verdad? Para que casi pueda averiguar qué hizo mal y luego corregir la implementación antes de que la implementación nos sea devuelta para revisión.

Ahora, lo que estamos haciendo y lo que hicimos, que creo que ha sido muy exitoso en mejorar las habilidades de todos nuestros ingenieros, básicamente encontramos múltiples formas de hacer co-aprendizaje. Así que en lugar de simplemente darles, oye, esto es lo que tienes que aprender, adelante, diseñamos oportunidades de co-aprendizaje, que son básicamente momentos donde los ingenieros se enseñan entre sí, hablan entre ellos, comparten lo que funciona, lo que no funciona. Estamos construyendo juntos. Estamos teniendo muchas sesiones, especialmente porque este mundo se mueve tan rápido y no hay nada escrito en piedra. Así que queremos que los ingenieros aprendan de otros compañeros, que realmente están haciendo, y que están compartiendo lo que funciona y lo que no.

Así que lo primero que tenemos es, bueno, en realidad múltiples canales de soporte de capacitación donde las personas pueden compartir de manera asincrónica noticias, artículos de blog, en qué están trabajando, si tienen preguntas, si encontraron algo interesante y luego simplemente lo comparten. Así que esta forma asincrónica de compartir información ha demostrado ser muy, muy útil porque las personas pueden literalmente aprender unas de otras. Es como tener Stack Overflow, pero para aprender este tipo de prácticas y herramientas de ingeniería de IA y nativa. Así que eso ha sido muy útil. Aparte de la parte asincrónica, también tenemos una parte sincrónica, que son las sesiones comunitarias. Así que básicamente organizamos múltiples sesiones comunitarias, generalmente algunas por mes, pero en algunos casos, también tenemos múltiples sesiones comunitarias por semana, que son completamente gratuitas, por supuesto, no obligatorias, y grabadas en caso de que te hayas perdido algo que te interesaba.

Y básicamente, tenemos múltiples sesiones de desarrollo de espectro en vivo, pero sesiones de ingeniería nativa de IA en general. Y por supuesto, no es solo como una demostración. Es una discusión abierta sobre cosas que funcionaron, cosas que no funcionaron. Y por supuesto, como todo lo que está sucediendo bajo el capó, todo lo que nuestros equipos están haciendo.

Además de eso, también estamos involucrando y estamos pidiendo a las personas que hagan cosas prácticas. Así que un ejemplo de esto es una aplicación que organizamos, donde pedimos a las personas, creo que fue como durante Navidad, pedimos a las personas, OK, amigos, vamos a divertirnos. Construyamos proyectos secundarios locos con agentes de IA e ingeniería nativa de IA. Compartimos lo que aprendimos. Compartimos los proyectos. Y esta ha sido la oportunidad para que muchas personas lo prueben por primera vez en un problema no trivial, en algo que era real.

Y tuvimos tantas lecciones. Ha sido muy, muy divertido y útil. Por supuesto, todo esto va junto, va de la mano con una ruta de mejora de habilidades adecuadamente construida, una ruta de mejora de habilidades interna que tenemos. Esta ruta de mejora de habilidades es obligatoria para nuestros ingenieros. Por supuesto, si ya conoces algunas de las cosas, puedes omitir lo que ya sabes y puedes ir directamente a lo que estás buscando, para la mejora de habilidades. Pero la idea principal es que está dividida en múltiples módulos.

Entonces, el primer módulo es, por supuesto, ¿qué es la ingeniería nativa de IA, verdad? Así que básicamente recopilamos mucho material existente diferente, que es útil. Entonces, ¿qué es la ingeniería nativa de IA? ¿Cómo funciona? ¿Cuáles son las herramientas, las prácticas? Y luego vamos a lo básico, que es como, ¿qué es un LLM? ¿Qué es un agente? ¿Cómo funcionan las cosas? ¿Qué es la memoria? ¿Qué es el contexto? ¿Cuáles son las limitaciones? ¿Cuáles son los modos de falla? ¿Qué es una alucinación, por ejemplo? ¿Por qué es importante el humano en el bucle? Queremos que nuestros ingenieros sean competentes en lo básico primero, y luego pasamos a conceptos más avanzados. Luego, por supuesto, tenemos que saber cuál es el panorama de agentes de IA, ¿verdad? Entonces, cómo están evolucionando las cosas. ¿Cuáles son las herramientas que podemos aprovechar en diferentes proyectos? Así que se trata de explorar el espacio actual y lo que podemos usar. Y luego, por supuesto, todo lo relacionado con la ingeniería de contexto, cómo podemos construir el contexto adecuado para los agentes, eso es muy útil. Es una gran parte de nuestro trabajo, ¿verdad? Así que habilidades, herramientas, todo alrededor de eso. Así que la ingeniería de contexto es una parte muy importante de ello.

La siguiente gran parte es el desarrollo de espectro, que es la metodología que estamos usando ahora en la gran mayoría de nuestros proyectos para construir código listo para producción. Y así para SDD, estamos invirtiendo bastante tiempo en el desarrollo de espectro. Y durante esta parte de mejora de habilidades, algo que estamos pidiendo a nuestros colegas es construir un proyecto un poco similar al hackathon, pero construyendo un proyecto, uno real, con desarrollo de espectro. Y pueden elegir cualquier proyecto que quieran construir, como un proyecto secundario, y simplemente lo construyen, y el resultado es asombroso. Por supuesto, luego revisamos el proyecto, lo calificamos. Si hay algo que realmente no funcionó bien en la adopción, en el uso de SDD, damos una retroalimentación, y luego todo lo demás. Así que, por supuesto, esta hoja de ruta de mejora de habilidades está en continua evolución. Y también lanzamos una versión de código abierto de ella, una versión expandida de ella, en esta URL de GitHub. Así que en caso de que estés interesado, puedes echar un vistazo. Esta no es la interna que tenemos, pero es un poco más expandida y amplia.

Hay una cosa que notamos con el tiempo, que es que algunos de nuestros ingenieros muy fuertes están comenzando a orquestar múltiples agentes al mismo tiempo. Y hay una carga cognitiva al orquestar múltiples agentes al mismo tiempo. Así que creas diferentes árboles de trabajo, puedes trabajar con los agentes en diferentes problemas. Hay un problema de carga cognitiva que gestionar, que es después de cinco horas de hacer eso, tu cerebro simplemente se derrite, porque tienes muchos cambios de contexto. Así que tienes que gestionar eso. Solo menciono esto porque lo he visto en un par de contextos, y creo que es importante tener en cuenta que a veces solo tenemos que desacelerar y gestionar las prioridades correctamente. Ahora, hemos visto el viaje del contribuyente individual, ¿verdad? Pero la pregunta es, bien, hablamos de tres cosas, ¿verdad? Así que hablamos del contribuyente individual, el equipo único, y toda la organización. Ahora la pregunta es, bien, ¿cómo estamos escalando la ingeniería de IA y TI a través de múltiples proyectos? Y la forma en que lo estamos haciendo es con este enfoque iterativo de intentar algo, aprender, y luego escalarlo. Así que lo primero que hacemos es elegir un pequeño conjunto de proyectos piloto, ¿verdad? Así que intentamos algo, decimos, bien, este proyecto está comenzando. E identificamos algunos proyectos de luz, ¿verdad, que podrían ser un buen ajuste para lo que estamos tratando de entender. Los dotamos de un equipo muy pequeño y mejorado con algunos de los campeones de IA. Ejecutamos el proyecto con esta metodología.

Ejecutamos el proyecto con esta metodología. Así que ejecutamos el proyecto con todo lo relacionado con AI e ingeniería. Ejecutamos el piloto en condiciones reales. Recopilamos la mayor cantidad de retroalimentación posible. Idealmente, no sé, semanal o quincenalmente, recopilamos la mayor cantidad de retroalimentación posible a través de, no sé, grabaciones, retroalimentación cualitativa, métricas cuantitativas, como si obtuviéramos la mayor cantidad de datos y contexto posible. Intentamos obtener lo que funcionó y lo que no funcionó, algo que nos sorprendió, algo que el equipo comenzó a hacer, pero ahora ya no lo hace más. Así que solo intentamos aprender tanto como podamos.

Luego, por supuesto, el equipo está reflexionando. Así que solo estamos viendo qué funcionó, qué no funcionó. Estamos actualizando nuestras herramientas, nuestras prácticas, nuestras guías. Estamos obteniendo toda esta información y generando señales para los próximos equipos, comenzando desde toda esta información, ¿verdad?, comenzando desde todos estos datos. Básicamente resumimos todos estos datos en todos los aprendizajes. Y luego tomamos todos los aprendizajes y luego expandimos nuestra base de proyectos. Así que generamos, básicamente, un manual actualizado y damos toda esta información. Y, por supuesto, hay algunos momentos de intercambio de conocimientos. Damos todo esto a los otros equipos.

Y luego el ciclo, y luego, perdón, el ciclo se repite. Así que básicamente, expandimos, creamos, apuntamos a nuevos proyectos, intentamos probar nuevas ideas, intentamos probar nuevas suposiciones, miramos lo que está sucediendo en el mercado. Y luego decimos, está bien, aprendamos en esta nueva ola de proyectos. Y estamos haciendo eso múltiples veces ahora. Y está dando una verdadera ventaja competitiva porque cada vez que aprendes algo nuevo, cada vez que aprendes lo que está funcionando ahora que no estaba funcionando hace tres meses, ¿verdad?, y así puedes mantenerte muy al borde de lo que es posible ahora mismo con AI e inter-ingeniería, lo que está funcionando, lo que aún no está funcionando, lo que puedes prever que funcionará en unos meses. Y, por supuesto, todo lo relacionado con cómo estructuramos el equipo, cuáles son las reglas que queremos establecer para el equipo, cuál es la estructura ideal del equipo, y cómo podemos optimizar la velocidad del equipo, por supuesto, mientras mejoramos al mismo tiempo la calidad de los resultados, ¿verdad?

Ahora, la pregunta es, está bien, pero asumamos que nuestro equipo ha logrado aprender cómo funcionan AI e inter-ingeniería. Ahora estamos entregando código mucho más rápido que antes. ¿Qué sigue? Entonces, ¿dónde está ahora el cuello de botella? Porque ahora, asumiendo que tu equipo es muy bueno usando AI e inter-ingeniería, pueden construir código muy rápido, ¿verdad? Pueden aclarar requisitos. Pueden construir grandes productos. Ahora mismo, el cuello de botella entonces se desplaza de la implementación real a la revisión del código por un lado porque terminarás con muchos PRs, por supuesto. Y por otro lado, el cuello de botella es entender qué tenemos que construir. Entonces, dado el nivel de restricciones, el cuello de botella no desapareció. Simplemente se movió a diferentes lugares. Entonces, la pregunta, ¿qué sigue?, es, entendamos, basado en nuestro caso de uso y basado en nuestro contexto, dónde se movió el cuello de botella. Ya sea revisión, decisiones de negocio, o cualquier otra cosa. Y tratemos de trabajar en eso. Entonces, por ejemplo, cuando estamos trabajando en el cuello de botella de revisión, podríamos querer introducir un mejor arnés para nuestro agente. Queremos introducir revisiones de código automatizadas para PR. Queremos integrar un conjunto de capas apiladas una sobre otra para que podamos confiar más y más en el código generado por AI. Y necesitamos pasar menos tiempo en la revisión. Pero, por supuesto, eso está realmente en el límite de lo que es posible ahora mismo.

Y estoy seguro de que en los próximos meses, veremos mucho de esto cambiar. Ahora, en caso de que quieras aprender más, como mencioné inicialmente, estoy escribiendo un libro llamado Learning AI and Native Software Engineering, que será publicado por Uralis pronto. Y en caso de que quieras echar un vistazo, es 100% gratuito. Puedes escanear este código QR o ir a esta URL para obtener 30 días de lectura gratuita. Puedes leer el lanzamiento anticipado. En este momento, ya tenemos algunos capítulos disponibles sobre lo que mencionamos. Así como desarrollo de espectro, sobre ingeniería de contexto, el primer capítulo sobre qué es realmente AI y la ingeniería de software nativa y cómo cambia nuestro trabajo. Así que en caso de que estés interesado, simplemente inténtalo. Es 100% gratuito, y espero que encuentres algún valor en él. Así que muchas gracias por escuchar hasta ahora. Espero que esto haya sido interesante. Y estoy seguro de que las cosas cambiarán bastante. En esta charla, solo he tratado de compartir lo que hemos aprendido hasta ahora, pero estoy seguro de que dentro de un año, muchas de las cosas serán diferentes. Así que muchas gracias por ahora y que tengas un gran día.