Técnicas

Las organizaciones adoptan activamente pensamiento de producto de datos como práctica estándar para gestionar activos de datos. Este enfoque trata los datos como un producto con su propio ciclo de vida, estándares de calidad y un enfoque en conocer las necesidades del consumidor. Ahora lo recomendamos como la elección predeterminada para la gestión de datos, independientemente de si las organizaciones eligen arquitecturas como data mesh o lakehouse.

Enfatizamos la orientación al consumidor en el pensamiento de producto de datos para impulsar un mayor adopción y generación de valor. Esto significa diseñar productos de datos trabajando desde los casos de uso hacia atrás. También nos enfocamos en capturar y gestionar tanto metadatos relevantes del negocio como metadatos técnicos usando catálogos de datos modernos como DataHub, Collibra, Atlan e Informatica. Estas prácticas mejoran el descubrimiento y usabilidad de los datos. Adicionalmente, aplicamos el pensamiento de producto de datos para escalar iniciativas de IA y crear datos listos para IA. Este enfoque incluye una gestión integral del ciclo de vida, asegurando que los datos no solo estén bien gobernados y sean de alta calidad, sino que también se retiren en cumplimiento con los requisitos legales y regulatorios cuando ya no sean necesarios.

Fuzz testing , o simplemente fuzzing, es una técnica de pruebas que ha existido durante mucho tiempo, pero sigue siendo una de las técnicas menos conocidas. El objetivo es proporcionar a un sistema de software todo tipo de entradas inválidas y observar su comportamiento. Para un endpoint HTTP, por ejemplo, las solicitudes incorrectas deberían resultar en errores 4xx, pero el fuzz testing a menudo provoca errores 5xx o peores. Bien documentado y soportado por herramientas, el fuzz testing es más relevante que nunca con mayor cantidad de código generado por IA y Complacencia con el código generado por IA. Esto significa que ahora es un buen momento para adoptar el fuzz testing y asegurar que el código siga siendo robusto y seguro.

Desde nuestro primer blip sobre Software Bill of Materials (SBOM) en 2021, la generación de SBOM ha pasado de ser una práctica emergente a una práctica por defecto en nuestros proyectos. El ecosistema ha madurado significativamente, ofreciendo un conjunto de herramientas robusto y una integración fluida con CI/CD. Herramientas como Syft, Trivy y Snyk permiten la generación integral de SBOM, desde el código fuente hasta las imágenes de contenedores, además de escaneo de vulnerabilidades. Plataformas como FOSSA y Chainloop mejoran la gestión de riesgos de seguridad al integrarse con los flujos de desarrollo y reforzar políticas de seguridad. Aunque un estándar universal para SBOM sigue en evolución, el amplio soporte para SPDX y CycloneDX ha reducido los desafíos de adopción. Los sistemas de IA también requieren SBOM, como lo demuestran el AI Cyber Security Code of Practice del gobierno del Reino Unido y el AI Cybersecurity Collaboration Playbook de CISA. Seguiremos monitoreando los avances en este ámbito.

En el panorama en rápida evolución del desarrollo de software impulsado por IA, el modelado de amenazas es más crucial que nunca para crear software seguro, manteniendo la agilidad y evitando el security sandwich. El modelado de amenazas; un conjunto de técnicas para identificar y clasificar potenciales amenazas, se aplica en diversos contextos, incluyendo aplicaciones de IA generativa, que introducen riesgos de seguridad únicos. Para que sea eficaz, debe realizarse con frecuencia a lo largo del ciclo de vida del software y funciona mejor junto con otras prácticas de seguridad. Entre ellas se incluye la definición de requisitos de seguridad interfuncionales para abordar riesgos comunes en las tecnologías del proyecto y el aprovechamiento de escáneres de seguridad automatizados para monitoreo continuo.

Los agentes de ingeniería de software supervisados son cada vez más capaces de identificar actualizaciones necesarias e implementar cambios más extensos en una base de código. Al mismo tiempo, se observa un mayor nivel de complacencia con el código generado por IA, con desarrolladoras y desarrolladores que se resisten a revisar conjuntos de cambios extensos realizados por IA. Una justificación típica para esta actitud es la percepción de que la calidad del código orientado a humanos no es tan crítica porque la IA podrá encargarse de futuras modificaciones; sin embargo, los asistentes de codificación basados en IA funcionan mejor con bases de código bien estructuradas y diseñadas, lo que hace que un código amigable hacia la IA sea crucial para su mantenibilidad. Afortunadamente, un buen diseño de software para humanos también beneficia a la IA. Los nombres significativos proporcionan contexto de dominio y funcionalidad; la modularidad y las abstracciones permiten a la IA gestionar mejor el contexto al limitar las modificaciones necesarias; y el principio DRY (Don’t Repeat Yourself o No te repitas) reduce el código duplicado, ayudando a que la IA tenga un comportamiento más predecible. Hasta ahora, los patrones más amigables con la IA coinciden con las mejores prácticas establecidas en el desarrollo de software. A medida que la IA siga evolucionando, es probable que surjan patrones aún más específicos para su optimización, por lo que tener esto en cuenta al diseñar código será de gran utilidad.

Están surgiendo nuevas técnicas de asistencia impulsadas por IA en equipos de desarrollo de software, más allá de la mera generación de código. Un área que está ganando tracción es la de pruebas de IU impulsadas por IA , que se apoyan en la capacidad de los LLMs para interpretar interfaces gráficas de usuario. Existen diversas aproximaciones para esto. Hay una categoría de herramientas que usan LLMs multimodales ajustados para el procesamiento de instantáneas de la IU, que permiten a los scripts de prueba escritos en lenguaje natural, navegar por la aplicación. Ejemplos en este espacio son QA.tech o LambdaTests' KaneAI. Otro enfoque, visto en Browser Use, combina modelos de base multimodal con las perspectivas que Playwright extrae de la estructura de la pagina web, en lugar de apoyarse en modelos finamente ajustados.

Al integrar pruebas de IU impulsadas por IA en una estrategia de pruebas, es crucial considerar donde producen más valor. Estos métodos pueden complementar las pruebas manuales exploratorias, y aunque la falta de determinismo de los LLMs puede introducir fallos aleatorios, su imprecisión puede ser una ventaja. Esto puede ser útil para probar aplicaciones heredadas con selectores faltantes o aplicaciones que cambian frecuentemente sus etiquetas y rutas de clic.

La Teoría de la Extensibilidad Grácil define las reglas básicas que gobiernan sistemas adaptativos, incluyendo los sistemas socio-técnicos involucrados en software de construcción y operación. Un concepto clave en esta teoría es el de Competence envelope — el límite en el que un sistema puede funcionar robustamente frente a fallas. Cuando un sistema es llevado más allá de su competence envelope, se vuelve frágil y es más propenso a fallar. Este modelo provee un lente valioso para comprender fallas sistémicas, como se pudo observar en las fallas complejas que llevaron a la caída de Canva de 2024. La Teoría de la Residualidad, un desarrollo reciente en Software Architecture Thinking, ofrece una forma de poner a prueba el Competence Envelope de un sistema a partir de la introducción deliberada de factores de estrés a dicho sistema, y el posterior análisis de cómo éste se ha adaptado a estos estresores de manera histórica a lo largo del tiempo. Los enfoques se alinean con los conceptos de anti-fragilidad, resiliencia y robustez en sistemas socio-técnicos, y nos entusiasma ver aplicaciones prácticas emerger en este campo.

La salida estructurada de LLMs se refiere a la práctica de restringir la respuesta de un modelo de lenguaje, a un esquema definido. Esto se puede lograr ya sea a través de instruir a un modelo generalizado que responda en un formato particular o realizando fine-tuning a un modelo para obtener una salida “nativa”, por ejemplo, JSON. OpenAI ahora soporta salida estructurada, permitiendo a los desarrolladores proporcionar un esquema JSON, pydantic o un objeto Zod para limitar las respuestas de un modelo. Esta capacidad es particularmente valiosa ya que permite llamadas a funciones, interacciones con una API e integraciones externas, donde la precisión y el cumplimiento de un formato son críticas. La salida estructurada no solo mejora la forma en que los LLMs pueden interactuar con el código, sino que también soporta un mayor cantidad de casos de uso, como generación de markup para el renderizado de gráficos. Adicionalmente, la salida estructurada ha demostrado reducir las posibilidades de alucinaciones en la salida de un modelo.

La IA está reduciendo las barreras para que quienes no codifican puedan crear e integrar software por sí mismos, en lugar de esperar a que el departamento de TI se encargue de sus necesidades o requisitos. Aunque nos entusiasma el potencial que esto desbloquea, también nos preocupan los primeros indicios de TI en la sombra acelerado por IA. Las plataformas de automatización de flujos de trabajo sin código ahora admiten la integración de API de IA (por ejemplo, OpenAI o Anthropic), lo que hace tentador usar la IA como cinta adhesiva — uniendo integraciones que antes no eran posibles, como convertir mensajes de chat de un sistema en llamadas a la API de un ERP mediante IA. Al mismo tiempo, los asistentes de codificación impulsados por IA se están volviendo más autónomos, lo que permite a quienes no codifican, pero tienen una formación básica, la posibilidad de crear aplicaciones de utilidad internas.

Esto tiene todas las características de la próxima evolución de las hojas de cálculo que aún impulsan procesos críticos en algunas empresas — pero con un alcance mucho mayor. Si no se controla, esta nueva TI en la sombra podría provocar la proliferación de aplicaciones no gobernadas y potencialmente inseguras, dispersando los datos en cada vez más sistemas. Las organizaciones deben ser conscientes de estos riesgos y evaluar cuidadosamente las ventajas y desventajas entre la rápida resolución de problemas y la estabilidad a largo plazo.

A medida que los asistentes de IA para escritura de código ganan peso, también lo hace el número de investigaciones y datos que traen a la luz la preocupación por la complacencia con el código generado por IA. El último estudio de calidad de código de GitClear's (https: //www.gitclear.com/aiassistantcodequality2025_research)‌) muestra que, en el 2024, el código duplicado y la rotación de código aumentaron más de lo previsto, mientras la actividad de refactorización en el historial de commits disminuyó. Además, como reflejo de la complacencia en el código generado por IA, un estudio de Microsoft (https: //www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/)‌) sobre trabajadores de conocimiento mostró que la confianza generada por la IA suele venir a costa del pensamiento crítico, un patrón que hemos observado a medida que la complacencia se instala con el uso prolongado de asistentes de programación. El auge de los agentes de ingeniería de software supervisados (https: //www.thoughtworks.com/es/radar/techniques/software-engineering-agents)‌) amplifica aún más los riesgos, ya que, cuando la IA genera conjuntos de cambios cada vez más grandes, los desarrolladores se enfrentan a mayores desafíos a la hora de revisar los resultados. La aparición de la codificación por vibras, donde los desarrolladores permiten que la IA genere código con una revisión mínima, ilustra la creciente confianza en los resultados generados por la IA. Si bien este enfoque puede ser adecuado para prototipos u otros tipos de código descartable, recomendamos encarecidamente no usarlo para código de producción.

Las organizaciones se mantienen cautelosas con respecto a las IAs asistentes de código de terceros, particularmente debido a preocupaciones con respecto a la confidencialidad del código. Como resultado, muchos desarrolladores están considerando asistentes de código locales , IAs que corren completamente en sus propias máquinas, eliminando la necesidad de enviar código a servidores externos. Sin embargo, los asistentes locales aún se quedan atrás de sus contrapartes de nube, que confían en modelos más grandes y más capaces. Incluso en máquinas de desarrollo de alta gama, los modelos más pequeños mantienen capacidades limitadas. Hemos encontrado que tienen dificultades con prompts complejos, carecen de la ventana de contexto necesaria para problemas más grandes y a menudo no pueden gatillar integraciones de herramientas o llamadas a funciones. Estas capacidades son especialmente esenciales para los flujos de trabajo agentivos, los cuales son la vanguardia en asistencia de código actualmente.

Así que, si bien recomendamos proceder con bajas expectativas, existen algunas capacidades que son válidas a nivel local. Ciertos IDEs populares actualmente incorporan modelos más pequeños en sus características centrales, tales como el completado de código predictivo de Xcode y el completado de líneas completas de código JetBrains. Y LLMs que puedan correr localmente como Qwen Coder son un paso hacia sugerencias locales en línea y manejo de queries simples de código. Se puede probar estas capacidades con Continue, que soporta la integración de modelos locales vía tiempo de ejecución como Ollama.

Cuando se habla de codificación en pares, inevitablemente surge el tema de pair programming. Nuestra profesión tiene una relación de amor-odio con ella: algunos la adoran, otros no la soportan. Los codificadores en pares plantean ahora la siguiente pregunta: ¿puede un humano trabajar en par con la IA, en lugar de con otro humano, y obtener los mismos resultados para el equipo? GitHub Copilot incluso se llama a sí mismo «tu codificador en parejas de IA». Aunque creemos que un asistente de programación puede aportar algunas de las ventajas de la programación en parejas, desaconsejamos totalmente reemplazar la programación en parejas por la IA. Enmarcar a los asistentes de programación como codificadores en pareja ignora uno de los principales beneficios de la programación en pareja: mejorar el equipo, no sólo a los colaboradores individuales. Los asistentes de programación pueden ser útiles para desbloquearse, aprender sobre una nueva tecnología, incorporarse o agilizar el trabajo táctico para que podamos centrarnos en el diseño estratégico. Pero no contribuyen a ninguno de los beneficios de la colaboración en equipo, como mantener bajo el trabajo en curso, reducir los traspasos y el re-aprendizaje, hacer posible la integración continua o mejorar la propiedad colectiva del código.

Estamos observando una preocupante proliferación del llamado Reverse ETL. Los procesos ETL tradicionales tienen su lugar en las arquitecturas de datos convencionales, donde transfieren información desde sistemas de procesamiento transaccional hacia un sistema de análisis centralizado, como un data warehouse o un data lake. Si bien esta arquitectura tiene limitaciones bien documentadas, muchas de las cuales son abordadas por un data mesh, sigue siendo común en las empresas. En este contexto, mover datos desde un sistema de análisis centralizado de vuelta a un sistema transaccional puede tener sentido en ciertos casos, como cuando el sistema central puede agregar datos de múltiples fuentes o como parte de una arquitectura transicional en el proceso de migración hacia un data mesh. Sin embargo, estamos viendo una creciente tendencia en la que proveedores de productos utilizan Reverse ETL como excusa para trasladar cada vez más lógica de negocio a una plataforma centralizada: su propio producto. Este enfoque agrava muchos de los problemas que generan las arquitecturas de datos centralizadas, por lo que recomendamos tener extrema precaución al introducir flujos de datos desde una plataforma de datos centralizada y expansiva hacia sistemas de procesamiento transaccional.

Observamos una adopción continua de SAFe™ (Scaled Agile Framework®). También seguimos observando que los procesos excesivamente estandarizados y basados en fases de SAFe generan fricción, que puede promover silos y que su control de arriba hacia abajo genera desperdicios en el flujo de valor y desalienta la creatividad del talento de ingeniería, mientras limita la autonomía y experimentación en los equipos. Una razón clave para su adopción es la complejidad de hacer que una organización se vuelva ágil, con empresas que esperan que un marco como SAFe ofrezca un atajo simple y basado en procesos para volverse ágiles. Dada la amplia adopción de SAFe -incluso entre nuestros clientes- hemos capacitado a más de 100 consultores de Thoughtworks para apoyarlos mejor. A pesar de este conocimiento profundo y los múltiples intentos, nuestra impresión es que a veces simplemente no hay una solución simple para un problema complejo, y seguimos recomendando un enfoque ágil, basado en entrega de valor y gobernanza que funcionen en conjunto con un programa integral de cambio.

Scaled Agile Framework® y SAFe™ son marcas comerciales de Scaled Agile, Inc.