Radar Tecnológico

En la preparación de esta edición, tuvimos dos tipos de debate sobre licencias. En primer lugar, durante muchos años, el ecosistema de desarrollo de software de código abierto se apoyó en un conjunto de licencias, catalogadas por la Open Source Initiative (OSI), siendo un pequeño número de licencias populares las preferidas en la mayoría de los casos. Sin embargo, en los últimos tiempos hemos visto algo de movimiento en este panorama antes sereno. Varias herramientas destacadas han tenido mala prensa últimamente, cuando sus mantenedores cambiaron, en varios casos abruptamente, de una licencia de código abierto a un modelo comercial. No tenemos problemas con pagar por el software, y nos parece razonable usar licencias comerciales para funcionalidades adicionales. Sin embargo, consideramos problemático cuando la funcionalidad básica de una herramienta muy utilizada se coloca detrás de un muro de pago, especialmente cuando se ha desarrollado un ecosistema alrededor. En segundo lugar, otra situación interesante tiene que ver con el software que proclama ser de código abierto pero cuyas capacidades fundamentales sólo aparecen luego que los consumidores pagan suscripciones u otros cargos. Si bien este modelo de negocio ha existido antes, parece que se explota más con muchas de las nuevas y relucientes herramientas de IA, que ofrecen capacidades asombrosas un poco escondidas bajo la letra pequeña. Aconsejamos revisar con detenimiento las cuestiones de licenciamiento. Presta atención a las salvedades y asegúrate de que todos los archivos de un repositorio están cubiertos por la licencia del nivel superior.

El tema de la IA obviamente dominó nuestras conversaciones; un tercio de nuestros puntos del Radar se referían a algún aspecto de ella. Mientras discutíamos varias herramientas de IA centradas en los desarrolladores como GitHub Copilot, Codium AI, aider y Continuar, también tuvimos numerosas conversaciones sobre cómo el uso holístico de la IA en todo un equipo cambia aspectos del desarrollo de software. Hablamos sobre una variedad de herramientas que no llegaron a la versión final, incluyendo terminales asistidas por IA como Warp, la capacidad de convertir capturas de pantalla en código, ChatOps respaldado por LLMs y muchos otros temas. Aunque las herramientas de desarrollo tienden a alcanzar un mayor grado de madurez, sospechamos que todos los aspectos del desarrollo de software pueden beneficiarse gradualmente del uso pragmático de la IA y las herramientas derivadas, y estamos siguiendo activamente las innovaciones en el panorama del desarrollo. Por supuesto, las nuevas capacidades casi mágicas que ofrece la IA conllevan nuevos riesgos para la calidad y la seguridad del software. Esto requiere que los equipos permanezcan atentos, incluso manteniendo informados a los no desarrolladores sobre los peligros potenciales.

Los patrones son populares en el mundo de la tecnología porque proporcionan un nombre conciso para una solución a un problema particular. Con el creciente uso de los modelos grandes de lenguajes (Large Language Models, LLM), empezamos a ver el surgimiento de patrones de arquitectura específicos para apoyar contextos comunes. Por ejemplo, hemos hablado de NeMo Guardrails, que permite a las personas desarrolladoras construir políticas de gobernanza sobre la utilización de LLM. También hemos hablado de herramientas tal y como Langfuse que permite mayor observabilidad en los pasos que conducen a las salidas de un LLM y cómo lidiar con (y validar) bases de código excesivamente llenas de código generado. Hemos discutido cómo la retrieval-augmented generation (RAG) es nuestro patrón preferido para mejorar la calidad de las salidas de un LLM, especialmente en el ecosistema empresarial. Adicionalmente, hemos discutido técnicas como por ejemplo utilizar un LLM menos potente (y de menor coste) para producir material que es revisado de forma selectiva por un LLM más potente (y caro). Los patrones forman un vocabulario importante para las tecnologías y esperamos ver una explosión de patrones (y de los inevitables anti-patrones) conforme la IA generativa continúe extendiéndose en el desarrollo de software.

Thoughtworks siempre ha sido una firme defensora de los ciclos de retroalimentación rápida durante el desarrollo de software y, por eso mismo, una gran partidaria de la integración continua (CI, del inglés: Continuous Integration). Para apoyar la adopción, construimos el primer servidor de CI — CruiseControl — que fue convertido en código abierto a finales de los años 90. Recientemente, nuestro director científico Martin Fowler actualizó la definición canónica de integración continua en su bliki para volver a poner el foco sobre esta práctica. Sin embargo, muchos de nuestros equipos se ven obligados a ignorar la parte CI de CI/CD porque se encuentran en situaciones en las que las pull requests (PRs) son obligatorias. Aunque la práctica con PRs se desarrolló originalmente para gestionar equipos de código abierto ampliamente distribuidos y contribuyentes poco confiables, se han convertido en un sinónimo de revisión por pares (del inglés: peer review) habitual incluso en equipos de desarrollo pequeños y muy cohesionados. En estas circunstancias, muchos desarrolladores anhelan la misma sensación de fluidez que obtienen al practicar CI real. Examinamos varias herramientas que intentan aliviar los problemas de los procesos de revisión de PRs, incluidas gitStream y Github merge queue. También discutimos técnicas como stacked diffs que prometen alinearse con los principios básicos de la CI al permitir un control más granular sobre el proceso de integración y discutimos métodos de métricas derivadas de PRs para identificar ineficiencias y cuellos de botella durante la entrega de software. Estas herramientas son de gran ayuda en este espacio debido a la tendencia hacia la IA generativa para el desarrollo de software. Con los asistentes de IA en la programación, el rendimiento del desarrollo aumenta, lo que lleva a una tendencia a crear PRs más grandes. Esto ejerce aún más presión sobre los procesos de revisión de código asíncrono. Aunque todavía preferimos la práctica original de CI, alentamos a los equipos que no pueden utilizarla debido a limitaciones externas a encontrar formas de mejorar la precisión de la integración y la velocidad de su ciclo de retroalimentación.