Tus Plataformas Importan Más Que Nunca Con AI

El desarrollo de software impulsado por IA ha llegado para quedarse, y ha estado evolucionando muy rápido en los últimos meses. Si hablas con alguien y te dicen, como, el año pasado hicimos X, eso ya está desactualizado. Y es difícil mantenerse al día y es difícil estar al tanto de lo que está sucediendo, para tener un entendimiento compartido dentro de una organización. La presión viene de todas direcciones. Externamente, necesitas mantener tu cuota de mercado, necesitas seguir siendo competitivo contra otras personas en el negocio que intentan superarte con sus servicios. E internamente, probablemente tienes un CEO que dice, como, haz algo con la IA. Necesitamos hacer IA, más IA. Y además de eso, también tienes a tus desarrolladores que van adelante y hacen shadow AI porque sienten que no te estás moviendo lo suficientemente rápido con tus decisiones y con tu política y diciéndoles cómo trabajar. Así que usan su propio código o su propio copilot o cualquier herramienta que quieran usar. Además, el equipo de seguridad está empezando a molestarse mucho porque de repente no pueden controlar nada. Si también estás trabajando en algún tipo de negocio de cumplimiento, como finanzas, defensa o lo que sea o salud, entonces probablemente también tienes todas esas cosas que considerar. Y de repente la IA está afectando y cambiando todo eso.

Ya estamos haciendo más cosas. Del informe GitHub Octaverse, donde miran todos los repositorios públicos y ellos intentan resumir y hacer un resumen mensual promedio de la actividad del desarrollador, y están observando los issues cerrados, pull request fusionados y pushes de código. Y lo que podemos ver es que en general, hay un aumento del 25% en promedio mensual entre 2024 y 2025. Ya estamos haciendo mucho más. Así que corremos el riesgo de fallar a la velocidad de la máquina porque se está moviendo rápido y no estamos reaccionando lo suficientemente rápido. Y el riesgo es que tengamos fragmentación no intencional. Y la solución es que hagamos una estrategia intencional e invirtamos en plataformas internas para desarrolladores.

Y te diré por qué. Cuando digo que tu plataforma importa más que nunca, me refiero a la IA agentic porque hemos pasado de la finalización de código, hemos pasado de las sugerencias de chat y hemos pasado de la parte de explicar este código. Si todavía estás allí, lo siento por ti, pero eso no es de lo que estoy hablando en esta sesión. En los últimos siete meses, ha cambiado mucho. Estamos pasando de escribir código a orquestar el cambio. Si eres el tipo de desarrollador o si estás trabajando con el tipo de desarrollador que recibió la tarea refinada, y luego se sentaron y la implementaron, y luego la dejaron a alguien más, eso está desapareciendo porque la IA puede hacer eso ahora.

Ya no necesitamos eso. Necesitas adaptarte y necesitas cambiar y necesitas centrarte en cómo puedes impulsar ese cambio en lugar de solo implementar el código. La tendencia es que la producción está aumentando. No estoy diciendo valor. Ten en cuenta, no valor. La producción está aumentando. Esto significa que cada desarrollador tiene más código que gestionan o del que son responsables y responsables. Si miramos los Git pushes en GitHub, una vez más, parte del conjunto de datos público, resumido por trimestre desde 2020, podemos ver una tendencia creciente bastante clara. Y algunos números si no puedes leerlo porque sé que es muy pequeño es que en el Q4 2024, tuvimos 168 millones. Y en el Q4 2025, un año después, fueron 247 millones de pushes. En el Q1 2023, se lanzaron los primeros IDEs con IA como Cursor. En el Q1 2025, se lanzó el primer modelo más parecido a un comportamiento agentic de múltiples pasos en 3.7 Sonnet. En el Q4 2025, ya es Q4 2025, seis meses atrás. Opus 4.5 fue lanzado. La razón por la que lo menciono es que cuando se lanzó 4.5, muchas empresas comenzaron a hablar sobre, ya no estoy trabajando en el IDE.

Solo estoy integrando con cloud code o lo que sea. Así que esto es básicamente cuando los desarrolladores dejan de preocuparse por el código en sí. La razón por la que esto importa es porque Q4 2025 fue hace seis meses, y ese fue el último punto de datos público que pude encontrar cuando estaba buscando. La investigación está mirando hacia atrás, pero el futuro es desconocido. Y necesitamos tomar y trabajar con esta situación porque si basamos nuestras decisiones en lo que otras personas estaban haciendo hace seis meses, estaremos quedándonos atrás seis meses respecto a nuestra competencia. Así que cuando estamos construyendo una estrategia, necesitamos abordar lo desconocido. Pero también podemos averiguar qué es lo que realmente sabemos. Porque no todo es desconocido. Tenemos algunas cosas que realmente podemos saber con certeza. Y podemos saber que cada desarrollador será responsable de más código a medida que escribimos más código.

Escucho muchas historias sobre, oh, construimos esa cosa que antes nos tomaba dos meses, ahora nos toma dos días escribir el código. Y así estamos empujando los cuellos de botella. Anteriormente el código era la parte a largo plazo donde pasabas mucho tiempo. Pero estamos empujando eso tanto aguas arriba como aguas abajo ahora mismo. Así que de repente estamos sacando más cosas de los ciclos de planificación, refinamiento y diseño, y no estamos haciendo esas actividades lo suficientemente rápido para sostener un flujo de desarrollo activo. Así que también estamos empujando el cuello de botella más abajo. Escucho a muchas personas hablar sobre revisiones de código, cómo fusionar tu código es realmente algo que va muy lento. Y escuché sobre el aumento de carga en las pipelines de CICD y cómo realmente no pueden mantenerse al día y cómo de repente es como si explotara la cantidad de dinero que estás gastando y los recursos de CPU que estás gastando solo en construir y mantener software.

Otra cosa que podemos saber con certeza es que los modelos son estocásticos por diseño. Habrá aleatoriedad. Es por diseño cómo funcionan. Intentarán predecir estadísticamente cuál es el siguiente buen paso después de lo que he hecho aquí. Eso significa que sin ningún tipo de asistencia, lo siento, sin ningún tipo de presión añadida, crearemos fragmentación, y comenzará a divergir porque si ejecutas el mismo prompt dos veces, obtendrás dos respuestas diferentes. Y como multiplica esto con todos tus desarrolladores y todo el trabajo que están haciendo, de repente puedes obtener algo que se ve bastante diferente entre sí. Y sabemos que la base de código comenzará a fragmentarse a menos que realmente hagamos algo al respecto. Podemos saber, o al menos puedo afirmar, y puedes razonar sobre ello, que una base de código fragmentada empujará y explotará esa fragmentación a través de todos tus sistemas. Porque como alguien que ha trabajado mucho tiempo en ingeniería de plataformas, uno no simplemente introduce un nuevo lenguaje de programación en tus sistemas. Porque de repente tienes que arreglar bibliotecas, tienes que arreglar binarios y tiempo de ejecución, y oh, por cierto, todos estos bonitos runbooks que RSRE nos ha ayudado a escribir, ya no son válidos porque estas cosas funcionan de manera diferente. Y los sistemas, si estás en prem, compraste CPU y Rome y cosas, y ahora de repente no estás usando el mismo tipo de capacidades que estabas usando antes porque de repente todo cambió. Y así, con una fragmentación más compleja en tu base de código, podemos deducir que el resto de tus sistemas subyacentes también estarán más fragmentados y serán un sistema mucho más complejo. Así que, para resumir, sabemos que la producción aumentará.

Producción, no valor. Sabemos que la fragmentación es el estado predeterminado de los LLMs a menos que hagas algo al respecto. Y sabemos que la fragmentación aumentará la complejidad en tus sistemas. Lo bueno es que ya abordamos esto con IDPs o plataformas internas de desarrollo. En los días en que se introdujeron las plataformas internas de desarrollo, se introdujo como, diría yo, una continuación de DevOps. Sabíamos que queríamos que las personas asumieran más responsabilidad y estuvieran más involucradas en el ciclo de vida completo de la aplicación. Pero también sabíamos que había muchas cosas que conocer. Había una gran carga cognitiva para los desarrolladores y queríamos reducir eso. Así que introdujimos plataformas internas de desarrollo para resolver las necesidades comunes que los desarrolladores tenían.

Si fuera, una vez más, en una organización con mucho cumplimiento, tal vez también queríamos codificar restricciones que sabíamos que necesitábamos tener en nuestros sistemas, tal vez hacerlo más fácil para una revisión de auditoría, lo que sea que pudiera haber sido. Todas esas cosas las hicimos realidad en las plataformas internas de desarrollo. Otra parte importante de esto es, no estoy seguro en qué organizaciones has estado, pero he estado en este tipo de organización donde, si eras un desarrollador y querías hacer algo nuevo, tal vez querías lanzar una nueva aplicación o registrar un nuevo DNS o lo que sea, tenías que presentar un ticket, enviarlo al equipo responsable y esperar a que lo hicieran. Parte de hacer plataformas internas de desarrollo es la idea de asegurarse de que sea autoservicio, para que no haya bloqueos. No tienes los pasos manuales humanos en el medio. Eso es algo de lo que estamos hablando mucho y mucho estamos diseñando cuando hablamos de plataformas internas de desarrollo.

Así que, hasta cierto punto, son los mismos problemas, pero es un radio de explosión más grande porque, como hablamos antes, la producción ha aumentado. Así que estamos haciendo más, estamos haciendo más cambios, y esto crea una carga en los sistemas que ya tenemos. Así que, si tienes algunos de esos pasos manuales todavía en tu organización, probablemente sientas mucho dolor por eso ahora mismo. Si automatizaste mucho de eso antes, felicitaciones, estás en una buena posición. Algo que realmente creo que deberías llevarte de esta diapositiva que no está tan bien destacado como debería haber estado es el efecto espejo. Y eso es que la IA amplifica lo que ya está en su lugar. Si tienes algo en su lugar, ya sea una arquitectura deficiente con muchos conjuntos de herramientas diferentes y muchas formas diferentes de resolver el mismo problema, eso es lo que se va a amplificar. Si tienes un camino claro y una única forma clara de hacer las cosas, eso es lo que se va a amplificar. Así que, tenlo en cuenta y llévalo a casa. Creo que otra cosa importante es que cuando construimos plataformas internas de desarrollo, lo hicimos para los desarrolladores para reducir su carga cognitiva, pero ahora también estamos construyendo plataformas de desarrollo para agentes. Así que necesita funcionar tanto con humanos como con agentes. Porque cuando alguien rompe tu flujo de trabajo de agentes, aún quieres que tu humano pueda hacer lo que necesita hacer para arreglarlo. Así que no puedes excluir a los humanos solo porque estás atendiendo a los agentes. Necesita funcionar para ambos. Y así, como líderes tecnológicos, lo que necesitas hacer es definir una estrategia técnica que sea adaptable.

Porque, como dije, estamos en una era con muchas incógnitas, por lo que necesitas diseñar tu estrategia para manejar esas y atender esas incógnitas y ser capaz de cambiar cuando aprendas algo nuevo. Así que es importante que puedas tener una estrategia que no esté limitada a cómo se ven los modelos hoy. Porque hace dos días, Anthropic lanzó un nuevo modelo que está cambiando el juego en gran medida, y se está moviendo muy rápido. Así que si bloqueas algo, como una estrategia, a cómo crees que estás haciendo hoy, tendrás que cambiar eso muy rápido.

También necesitas comunicar, y no puedo enfatizar esto lo suficiente. Si quieres que todos en tu organización puedan cumplir con tu estrategia, todos necesitan estar al tanto de ella. Y si piensas que es suficiente decirle a alguien una vez y tenerlo escrito en algún lugar, entonces estás equivocado, porque así no es como funcionan las personas. Y las personas siguen siendo las que necesitan tomar decisiones y llevar las cosas adelante. Porque la IA no es inteligente. Es solo muy productiva. Así que sin ustedes, humanos, diciéndoles a dónde ir, no funcionará.

Así que comunica a menudo y asegúrate de que la información esté disponible para todos. Pero también, una vez que hagas esa opción, porque necesitas adaptar tu estrategia, asegúrate de comunicar eso también. Y no tiene que ser un fracaso. Tal vez algo salió mal, o tal vez aprendiste algo nuevo, y podrías tomar una nueva dirección que te ayudará a entregar aún más valor para tu empresa. Así que sé transparente sobre el cambio de dirección, y sé transparente sobre por qué está sucediendo esto, qué aprendiste y cómo progresarás desde aquí. Y eso debería ser parte de tu estrategia y de cómo trabajas.

Tu plataforma interna de desarrollo debe apoyar tu estrategia. Aquí es donde codificas y ejecutas tu estrategia. La estrategia es como una dirección de hacia dónde quieres ir. La plataforma es lo que apoya y ayuda a las personas a moverse en esa dirección, yendo en esa. Y creo que hay, además de muchas otras cosas que ya tenemos en la plataforma interna de desarrollo. No estoy diciendo que te deshagas de tu pipeline CICD de la plataforma interna de desarrollo. No, probablemente deberías seguir haciendo eso. Pero al adaptarse a la IA y al comportamiento de identidad, creo que hay tres cosas que vale la pena destacar y mencionar, y probablemente haya más cosas.

Pero una de ellas es el camino dorado. Así es como construyes tus cosas. La segunda es el contexto. ¿Qué necesita saber el agente para poder entregar valor? Y la tercera son las prácticas del agente. Y esto probablemente cae más, si sigues las topologías de equipo, probablemente cae más bajo el habilitamiento que en la plataforma. Pero creo que tiene sentido ponerlo al menos cerca de esa función. Así que ten eso en mente también.

Así que el camino pavimentado o el camino dorado es esta idea de así es como construimos sistemas en nuestra organización. He trabajado en algunas organizaciones diferentes. He hablado con muchas más personas de otras organizaciones, y lo que he aprendido es que nadie está haciendo lo mismo de la misma manera. Nadie. Todos tienen su propio estilo. Probablemente, cuanto más grande sea la organización tecnológica, más específico será el estilo. Creo que es bueno tratar de inclinarse más hacia el código abierto y seguir prácticas abiertas y demás. Pero la verdad sea dicha, probablemente tengas algo muy específico para ti. Así que conoce cuál es tu camino dorado.

Conoce cómo quieres que sea tu plan para una aplicación. Si eres un líder técnico, probablemente no seas solo tú, pero debería ser parte de lo que sabes cuando construyes estas cosas. Un contexto es lo que permite a tu IA seguir el camino dorado o tu camino pavimentado. Y esto es, probablemente hay otras personas que tienen muchas cosas, pero trato de capturar algunas de ellas. Creo que mencionar lo mencionado anteriormente hoy es como cerrar el ciclo de retroalimentación.

Un ejemplo muy concreto que he escuchado que ayudó a las personas a cerrar realmente ese ciclo de retroalimentación es un linter. Si codificas, no escribimos basura en TypeScript y agregas eso a tu linter para que simplemente falle cada vez que intenta compilar localmente. Genial. Ahora tienes un ciclo de retroalimentación muy rápido para evitar que tu IA intente escribir todo en TypeScript. Eso es genial. Eso es parte de tu estrategia, tal vez. O podría ser Python o lo que quieras.

Y esos ciclos de retroalimentación rápidos son realmente buenos y algo en lo que deberías intentar enfocarte para lograr. Pero también recuerda que tu código existente es parte de tu contexto. Vuelvo una vez más, si tu código existente no es bueno, eso será difícil para ti. Si tienes un gran código, podría estar en un monorepo, podría estar en un polyrepo, no creo que importe. Hazlo disponible para tu IA de alguna manera. Tal vez asegúrate de tenerlo clonado localmente y disponible como un contexto en vivo o hazlo buscable de alguna manera. E integra todas estas cosas.

Pero cuando trabajas con contexto, también asegúrate de no darle a la IA demasiado contexto. Por eso necesitamos hacerlo intencional también, porque si simplemente lo saturas con todo, perderá efectividad. También creo que al establecer, cuando se trata de prácticas del agente, necesitamos establecer límites. He oído hablar de empresas que simplemente dijeron, oh, aquí está la tarjeta de la empresa, ve a comprarte una licencia de IA. Y he oído hablar de otras empresas que tienen demasiado miedo de dejar sueltos a sus desarrolladores en absoluto. Creo que hay un punto medio, pero creo que una gobernanza donde te asegures de que no filtras tus datos internos al proveedor es probablemente algo bueno. Así que asegúrate de que estás mirando tus límites. Podría ser datos, podría ser acceso, lo que sea. Tal vez no quieras darle a la IA acceso de escritura a producción. Tal vez debería tener acceso de lectura, lo que sea que pueda ser. Ten eso centralizado y escalonado como parte de tu plataforma.

Y asegúrate de aumentar la conciencia y el aprendizaje y difundirlo por toda la organización, porque podrías tener como 5, 10 personas que están súper emocionadas y están probando tantas cosas. Están fallando mucho, pero también están aprendiendo muchas cosas. Y asegúrate de que ese aprendizaje llegue al resto de la organización que podría no estar tan emocionada, pero dispuesta a aprender y captar. Y asegúrate de llevar a todos contigo.

Y una vez más, los modelos cambiarán. No sobreajustes. En resumen, a medida que aumenta la producción, la carga cognitiva debe disminuir. Y lo hacemos a través de menos variabilidad, valores predeterminados más fuertes y contexto justo a tiempo. Y la complejidad de los sistemas debe disminuir a medida que aumenta el volumen de código. Ten una estrategia intencional. Utiliza tu plataforma para ejecutarla. Y acelerarás y asegurarás tus sistemas.

Llamado a la acción, tres cosas que quiero que hagas el lunes. Si aún no lo has hecho, tal vez actualiza de nuevo. ¿Cuál es tu postura sobre la IA? Comunícalo. Asegúrate de que sea claro y visible para todos. Como hacer que tu contexto interno sea accesible para la IA. E invierte en plataformas internas de desarrolladores de calidad, porque dará frutos a largo plazo. Porque las plataformas internas de desarrolladores son la base para tener éxito en la era de la IA.

Soy Jessica. Soy una Fractional CTO y Platform Engineering Leader. Y este es un código QR con enlaces a los recursos que utilicé en esta presentación. Muchas gracias por invitarme. En primer lugar, un gran conjunto de recomendaciones, ejemplos. Y lo que es realmente bueno, por ejemplo, si hablas de aplicar controles de contexto deterministas políticas, todo lo que contribuye al menos en dos direcciones, dos niveles. Calidad del agente, como lo que te da como resultado. Y también costo. Así que esto también es un gran, gran impulsor de costos. Qué tan bien instrumentas tu base de código, tu proyecto con controles deterministas. Como mencionaste, linters, verificadores de tipos, todo. Así que ten esto en mente, amigos.

Pero ahora, tus preguntas. La primera es, la IA generativa está aumentando la velocidad de la ingeniería, pero no conocemos su impacto a largo plazo en la calidad del código. Entonces, ¿deberían los líderes optimizar para la máxima reducción de costos o el menor tiempo de producción o tomar caminos más conservadores hacia un software sostenible? ¿Cuáles son tus pensamientos? Quiero decir, obviamente, depende. Es la respuesta más aburrida de todas, pero depende totalmente. Si estás trabajando en defensa o tal vez en cosas de coordinación de aeródromos, tal vez quieras optar por la seguridad o asegurarte de que siempre mantienes la misma operabilidad. Pero si estás explorando un área nueva con algo muy no peligroso, entonces tal vez quieras optimizar para la velocidad. Personalmente, he estado de guardia y realmente no me gusta que me despierten a las 2 a.m. Así que lo que sea que hagas, no me llames a las 2 a.m. y tal vez tampoco llames a tus desarrolladores. Así que creo que tiene que haber... Es un nuevo triángulo de costo, tiempo y calidad que necesitamos considerar. Tal vez no todos los sistemas tienen el mismo valor. Tal vez tienes algunos sistemas críticos. Sé más cuidadoso con esos. Y luego con los sistemas menos críticos, intenta ser un poco más salvaje y loco y ve a dónde te lleva eso. Sé adaptable, ¿verdad? Sé adaptable, sí. No seas rígido. No vueles.

Una regla no se ajusta a todos. Mentalidad fija que realmente... ¿Qué duele? Mentalidad de crecimiento. Ese es tu objetivo. Así que marquemos esto como ninguno.

Y la inteligencia artificial es excelente para la creatividad. La experiencia de usuario para juniors puede crear los backends o personas que son como diseñadores y personas de experiencia de usuario. Pero no pueden programar. No pueden programar backend. Y a veces se ve mal y crea más fragmentación. Si no, sobrecarga de revisión.

¿Cómo abordar esto pero aún así mantener los beneficios y la velocidad? Sí. Creo que podríamos tomarlo de manera más general. ¿Cuáles son tus pensamientos sobre permitir que los no desarrolladores contribuyan a... No solo herramientas de un solo uso, sino a algo que podría ser más prominente, más... Y debería ser escalable y seguro. ¿Cuál es tu opinión al respecto?

Volviendo al camino pavimentado y caminos dorados. Si ya estás construyendo aplicaciones escalables y seguras con una mentalidad clara de API-first y demás, probablemente tengas eso codificado en tus aplicaciones existentes. Pero también tal vez tengas tu contexto disponible. Tal vez tengas... Así es como hacemos APIs. Así es como hacemos aplicaciones escalables. Así es como gestionamos la carga de trabajo a gran escala, lo que sea.

Y eso será parte del contexto que la IA utiliza cuando escriben ese código. Y si ese contexto está disponible para un desarrollador que no es de backend, también podrán escribir un buen servicio de backend. Pero necesitas tener la base en su lugar para que eso suceda. Y ahí es donde pones a tus desarrolladores senior, desarrolladores senior de backend. Ellos deberían estar trabajando para hacer eso disponible para todos para que puedas traer a más personas al desarrollo. En mi opinión.

Sí. Justo. 100%. Desde mi experiencia, actualmente trabajo con dos clientes que crean plataformas específicas. Así que podemos llamarlo ingeniería de plataformas en su sentido clásico para simplificar lo que sucede a continuación con las herramientas creadas por ingenieros que no son de software. Porque requieren tal vez un poco más de atención. Y amigos, sorpresa, sorpresa. Esto se convierte en una plataforma de aplicación más genérica que es igualmente relevante tanto para no desarrolladores como para desarrolladores. Así que en ese sentido, no hay un cambio demasiado grande, una disrupción demasiado grande. Esto es desde mi experiencia personal. Y por supuesto, sí.

Invertir en tu plataforma de desarrollo siempre vale la pena. Y tomemos este. Quiero que mi equipo incorpore más IA y nuestro producto de implementación de IA en casos de uso internos. ¿Cómo negocio con mis líderes de ingeniería para dedicar recursos a eso? Sí. Así que hay una especie de ejercicio de ancho de banda de recursos, interno versus externo. Y en ese sentido, la ingeniería de plataformas parece, oh, es muy interno, ¿verdad? Entonces, ¿cuál es tu opinión sobre eso? ¿Cómo convencer? Quiero decir, es, en mi experiencia, siempre difícil convencer a alguien de invertir en tus plataformas internas de desarrollo.

Creo que algo que he dicho antes, la era de la IA, que creo que puede usarse como un motivador de por qué vale la pena, es si estamos mirando las métricas DORA, y estoy hablando de el Accelerate DORA, entonces tienes, ¿cuánto tiempo lleva implementar un cambio? ¿Cuánto tiempo lleva construir un tipo de software? ¿Con qué frecuencia falla cuando estamos implementando nuevo software? ¿Y con qué frecuencia, cuánto tiempo lleva antes de que podamos hacer una recuperación? Usando esas métricas, puedes mostrar que cuando inviertes en tu plataforma, esas métricas también pueden mejorar. Y eso puede ser tu indicador y tu motivador de por qué esto es importante. Pero también creo que si inviertes en tu plataforma interna de desarrollo en la era de la IA, y puedes mostrar que puedes hacerla disponible y segura para usar y experimentar para no desarrolladores, creo que eso también podría ser un buen motivador, porque hay muchas organizaciones ahora mismo que no están buscando adopción de IA en sus departamentos de desarrollo de software. Están buscando adopción de IA fuera de los departamentos de I+D. Están buscando llevarla a las operaciones financieras, la están llevando a RRHH y todos los demás departamentos para hacerlos más eficientes y utilizar ese tipo de herramientas. Así que si tus plataformas internas de desarrollo pueden apoyar ese tipo de casos de uso también, creo que podrás obtener más inversión de todas las suites ejecutivas.

Respuesta súper perspicaz. Y creo que la palabra clave aquí es inversión, ¿verdad? No es gasto. Así que debería ser tu centro de beneficios, no centro de costos. Y quién sabe, por cierto, amigos, hay suficientes, si no pivotes, al menos historias muy públicas sobre una empresa que construyó su propia plataforma de desarrollo, y fue tan buena y tan popular, que simplemente la hicieron de código abierto y si no se convirtió en una nueva fuente de ingresos, al menos obtuvieron mucha atención extra de la comunidad de desarrolladores. Quiero decir, de un ejemplo muy conocido, es backstage de Spotify, ¿verdad? Así que es un ejemplo clásico aquí. Y sí, tenemos tiempo para más preguntas. Eso es increíble. Y esta recibió cinco pulgares arriba.

¿Debería la IA revisar el código de IA? ¿Usar múltiples modelos o quedarse con solo uno? Básicamente, dos preguntas en una. IA revisando IA y tu opinión sobre los modelos de IA? Creo que se trata de la criticidad de los sistemas. Creo que en general, no es una mala idea utilizar más IA en el ciclo de retroalimentación y asegurar que estás obteniendo un nuevo modelo, un nuevo contexto revisando cualquier código que se haya escrito. Tal vez con algunos otros requisitos. No estoy seguro sobre, he escuchado de todo, como que deberías usar el mismo modelo, deberías usar cinco modelos diferentes, deberías tenerlos con una mentalidad diferente y diferentes directrices, lo que sea. Creo que tienes que probar y errar. Y supongo que la mejor manera es poner algunas cosas en marcha, y luego tener una revisión humana del código y luego tal vez hacer su propia revisión. Lo que sea. Esta sigue siendo una fase de aprendizaje. Cuando la gente dice que lo ha descubierto, probablemente estén mintiendo. Sí, en ese sentido, todos aprendemos, todos tratamos de acumular y compartir mejores prácticas y solo piezas de conocimiento, en ese sentido. Así que desde mi perspectiva personal, la IA podría revisar el código generado por IA, pero seguro, no debería ser la última parte que toma la decisión, ¿verdad? Así que necesitamos algo un poco más determinista o humano en el bucle. A menos que no sea importante. Y eso es cierto.

Y sí, tomemos tal vez la última pregunta. Y será esta, también bastante popular entre nuestra audiencia. ¿Qué componentes del pipeline de desarrollo de software deberíamos más o menos estandarizar y qué parte deberíamos mantener flexible? Quiero decir, todos ellos. Como, ¿por qué no estandarizar? Nos gustan las tecnologías aburridas, ¿verdad? Quiero decir, bromeando aparte. En realidad, estoy a favor de estandarizar todo lo que puedas. Pero también creo en dejar espacio y flexibilidad para la experimentación, porque a veces realmente vale la pena renovar algo. Y necesitas tener el espacio y la capacidad para hacer ese tipo de experimentación que podría significar realmente introducir un nuevo lenguaje de programación.

Pero lo que sí creo es que antes de convertir eso en algo que se ejecute en producción y que adoptes completamente, necesitas realmente evaluarlo y ser crítico al respecto. ¿Vale la pena romper nuestra estandarización para hacer este movimiento? ¿Qué nos aporta a corto plazo y qué nos aporta a largo plazo? ¿Cuál será el costo de este movimiento con el tiempo? Y entonces, quiero decir, soy súper aburrido. Me gusta la estandarización. Cada vez que trabajo con desarrolladores y dicen algo como, se me ocurrió algo nuevo, yo digo como, oh, no, oh, no, otra vez no.

Y a veces también lo digo. No es bueno decirlo, pero eso es lo que pasa. Sí, exactamente. Exactamente. Y también podría ser un poco de malabarismo de definiciones, ¿verdad? Porque en el panorama general, estandarizado no significa de alguna manera restringido. Digamos que estandarizado aún podría ser flexible. Así que no es obligatorio, como codificado rígidamente. Correcto. Entonces, estándar podría ser, digamos, tenemos un estándar que es un estándar flexible. Podría ser como a menos que tengas un caso de uso realmente bueno para no hacer esto, entonces probablemente deberías estar haciendo esta cosa que es el estándar. Exactamente. Muchas gracias, Jessica. Muchas gracias por tenerme. Demos un gran aplauso a Jessica. Gracias.