Techniques

Organizations actively adopt data product thinking as a standard practice for managing data assets. This approach treats data as a product with its own lifecycle, quality standards and focus on meeting consumer needs. We now recommend it as default advice for data management, regardless of whether organizations choose architectures like data mesh or lakehouse.

We emphasize consumer-centricity in data product thinking to drive greater adoption and value realization. This means designing data products by working backward from use cases. We also focus on capturing and managing both business-relevant metadata and technical metadata using modern data catalogs like DataHub, Collibra, Atlan and Informatica. These practices improve data discoverability and usability. Additionally, we apply data product thinking to scale AI initiatives and create AI-ready data. This approach includes comprehensive lifecycle management, ensuring data is not only well-governed and high quality but also retired in compliance with legal and regulatory requirements when no longer needed.

Fuzz testing , or simply fuzzing, is a testing technique that has been around for a long time but it is still one of the lesser-known techniques. The goal is to feed a software system all kinds of invalid input and observe its behavior. For an HTTP endpoint, for example, bad requests should result in 4xx errors, but fuzz testing often provokes 5xx errors or worse. Well-documented and supported by tools, fuzz testing is more relevant than ever with more AI-generated code and complacency with AI generated code. That means it’s now a good time to adopt fuzz testing to ensure code remains robust and secure.

Since our initial blip in 2021, Software Bill of Materials (SBOM) generation has transitioned from an emerging practice to a sensible default across our projects. The ecosystem has matured significantly, offering a robust tooling ecosystem and seamless CI/CD integration. Tools like Syft, Trivy and Snyk provide comprehensive SBOM generation from source code to container images and vulnerability scanning. Platforms such as FOSSA and Chainloop enhance security risk management by integrating with development workflows and enforcing security policies. While a universal SBOM standard is still evolving, broad support for SPDX and CycloneDX has minimized adoption challenges. AI systems also require SBOMs, as evidenced by the UK Government's AI Cyber Security Code of Practice and CISA's AI Cybersecurity Collaboration Playbook. We’ll continue to monitor developments in this space.

In the rapidly evolving AI-driven landscape of software development, threat modeling is more crucial than ever for building secure software while maintaining agility and avoiding the security sandwich. Threat modeling — a set of techniques for identifying and classifying potential threats — applies across various contexts, including generative AI applications, which introduce unique security risks. To be effective, it must be performed regularly throughout the software lifecycle and works best alongside other security practices. These include defining cross-functional security requirements to address common risks in the project's technologies and leveraging automated security scanners for continuous monitoring.

Tratar APIs como producto significa priorizar la experiencia del desarrollador(a), no sólo mediante un diseño razonable y estandarizado de dichas APIs sino también proporcionando una documentación completa y una experiencia de onboarding fluida. Aunque las especificaciones de OpenAPI (Swagger) pueden documentar interfaces de APIs de manera efectiva, el onboarding continúa siendo un desafío. Los desarrolladores(as) necesitan acceso rápido a ejemplos funcionales, con autenticación pre-configurada y datos de prueba realistas. Con la evolución de herramientas de clientes API (como Postman, Bruno e Insomnia), recomendamos tratar las colecciones de peticiones API como artefactos del producto API. Las colecciones de peticiones API deben ser diseñadas cuidadosamente para guiar a los desarrolladores(as) a través de flujos de trabajo clave, ayudándoles a comprender el lenguaje y funcionalidad del dominio de la API con el mínimo esfuerzo. Para mantener estas colecciones actualizadas, recomendamos almacenarlas en un repositorio e integrarlas dentro del pipeline de despliegue de la API.

Uno de los retos constantes en equipos grandes de software es determinar quién toma las decisiones arquitectónicas que dan forma a la evolución de los sistemas. El informe State of DevOps report revela que el enfoque tradicional de las Juntas de Revisión de Arquitectura es contraproducente, y a menudo obstaculiza el flujo de trabajo y se correlaciona con un bajo rendimiento organizacional. Una alternativa convincente es architectural advice process — un enfoque descentralizado donde cualquiera puede tomar una decisión arquitectónica, siempre que busque asesoramiento de los afectados y de aquellos con experiencia relevante. Este método permite a los equipos optimizar el flujo sin comprometer la calidad arquitectónica, tanto a pequeña como a gran escala. A primera vista, esta alternativa puede parecer controversial, pero prácticas como Architecture Decision Records y los foros de asesoramiento garantizan que las decisiones se mantengan informadas, mientras que también empoderan a quienes están más cerca del trabajo a tomar decisiones. Hemos visto este modelo tener éxito a escala en un gran número de organizaciones, incluyendo aquellas en industrias altamente reguladas

En nuestra última actualización de RAG, introdujimos GraphRAG , descrito originalmente en el artículo de Microsoft como un enfoque en dos pasos: (1) fragmentación de documentos y uso de análisis basado en LLM de los fragmentos para crear un grafo de conocimientos; (2) recuperación de fragmentos relevantes en el momento de la consulta mediante incrustaciones mientras se siguen las aristas del grafo de conocimiento para descubrir fragmentos relacionados adicionales, que se añaden al prompt aumentado. En muchos casos, este enfoque mejora las respuestas generadas por LLM. Hemos observado beneficios similares al utilizar IA generativa para comprender bases de código heredadas, donde utilizamos información estructural, como árboles sintácticos abstractos y dependencias, para construir el grafo de conocimiento. El patrón GraphRAG ha ganado adeptos, con herramientas y frameworks como el paquete en Python GraphRAG de Neo4j, que están surgiendo para soportarlo. También consideramos que Graphiti se ajusta a una interpretación más amplia de GraphRAG como patrón.

El principio de privilegio mínimo garantiza que los usuarios y sistemas solo tengan el acceso mínimo necesario para realizar las tareas. El abuso de credenciales privilegiadas es un factor clave en las brechas de seguridad, siendo la escalada de privilegios un vector de ataque común. Los atacantes suelen empezar con un acceso de bajo nivel y explotan vulnerabilidades del software o configuraciones erróneas para obtener privilegios de administrador, especialmente cuando las cuentas tienen permisos excesivos o innecesarios. Otro riesgo que a menudo se pasa por alto es el de los privilegios permanentes: accesos privilegiados disponibles de forma continua que amplían la superficie de ataque. La gestión de acceso privilegiado justo a tiempo mitiga este riesgo al conceder acceso solo cuando es necesario y revocarlo inmediatamente después, minimizando la exposición. Un modelo de seguridad de menor privilegio garantiza que los usuarios, aplicaciones y sistemas tengan únicamente los derechos imprescindibles durante el mínimo tiempo posible, un requisito fundamental para el cumplimiento normativo y la seguridad regulatoria. Nuestros equipos lo han implementado a través de un flujo de trabajo automatizado que activa un proceso de aprobación ligero, asigna roles temporales con acceso restringido e impone un tiempo de vida a cada rol, lo que garantiza que los privilegios expiren automáticamente una vez completada la tarea.

Las leyes de Escalabilidad han sido un factor clave del auge de la IA; el principio de que modelos más grandes, conjuntos de datos más extensos y mayores recursos de cómputo conducen a sistemas de IA más potentes. Sin embargo, el hardware de consumo y los dispositivos perimetrales a menudo carecen de la capacidad para soportar modelos a gran escala, lo que crea la necesidad de la destilación de modelos.

La destilación de modelos transfiere conocimiento de un modelo más grande y potente (maestro) a un modelo más pequeño y eficiente en coste (estudiante). El proceso suele implicar la generación de un conjunto de datos de muestra a partir del modelo maestro y el ajuste del modelo estudiante para que capture sus propiedades estadísticas. A diferencia de la poda o la cuantización, que se enfocan en la compresión de modelos suprimiendo parámetros, la destilación intenta retener conocimiento específico del dominio, minimizando la pérdida de precisión. También se puede combinar con la cuantización para una optimización adicional.

Propuesta originalmente por Geoffrey Hinton y otros, la destilación de modelos ha sido ampliamente adoptada. Un ejemplo destacado es Qwen/Llama la versión destilada de DeepSeek R1, que mantiene sólidas capacidades de razonamiento en modelos más pequeños. Con su creciente madurez, la técnica ya no se limita sólo a los laboratorios de investigación; ahora se aplica en una amplia variedad de proyectos, desde industriales hasta personales. Proveedores como OpenAI y Amazon Bedrock ofrecen guías para ayudar a los desarrolladores a destilar sus propios modelos de lenguaje reducido (SLMs, small language model, por sus siglas en inglés). Creemos que la adopción de la destilación de modelos puede ayudar a las organizaciones a gestionar los costes de despliegue de los LLM al tiempo que libera el potencial de la inferencia LLM en dispositivos.

Prompt engineering se refiere al proceso de diseñar y refinar los prompts (instrucciones) para modelos de IA generativa, con el objetivo de producir respuestas de alta calidad conscientes del contexto. Esto implica elaborar indicaciones claras, específicas y relevantes, ajustadas a la tarea o a la aplicación, para optimizar el resultado del modelo. A medida que las LLM evolucionan, particularmente con las llegada de los modelos de razonamiento, las prácticas del prompt engineering deben ser adaptadas. Basados en nuestra experiencia con la generación de código con IA, hemos observado que los prompts con pocos ejemplos pueden ofrecer un menor rendimiento comparado con prompts sin ejemplos al trabajar con modelos de razonamiento. Además, la técnica ampliamente usada de cadena de razonamiento o chain-of-thought (CoT) puede degradar el desempeño de los modelos de razonamiento, probablemente debido a que el aprendizaje por refuerzo ya ha afinado su mecanismo interno de CoT.

Nuestra experiencia práctica se alinea con lo que señala la investigación académica, que sugiere que “los modelos más avanzados podrían eliminar la necesidad del prompt engineering en el desarrollo de software”. No obstante, las técnicas tradicionales del prompt engineering seguirán teniendo un rol crucial en reducir alucinaciones y mejorar la calidad de las respuestas, especialmente considerando las diferencias en tiempos de respuestas y costos de tokens entre los modelos de razonamiento y los LLM generales. Al crear aplicaciones con agentes autónomos, recomendamos elegir los modelos estratégicamente, con base en las necesidades y seguir refinando tanto las plantillas de prompts cómo sus técnicas correspondientes. Encontrar el equilibrio entre la calidad, el tiempo de respuesta y el costo de los tokens sigue siendo clave para maximizar la efectividad de los LLM.

El reciente anuncio de DeepSeek R1 es un gran ejemplo de por qué los small language models (SLMs) siguen siendo interesantes. La versión completa de R1 tiene 671 mil millones de parámetros y requiere alrededor de 1.342 GB de VRAM para funcionar, algo que solo se logra utilizando unmini cluster de ocho GPUs NVIDIA de última generación. Pero DeepSeek también está disponible en versión distilled en Qwen y Llama — modelos más pequeños yopen-weight —, transfiriendo efectivamente sus capacidades y permitiendo que se ejecute en hardware mucho más modesto. Aunque el modelo sacrifica algo de rendimiento en esos tamaños reducidos, aún permite un gran salto en rendimiento respecto a los SLMs anteriores. El campo de los SLM sigue innovando en otros ámbitos, también. Desde el último Radar, Meta introdujo Llama 3.2 en tamaños de 1B y 3B, Microsoft lanzó Phi-4, ofreciendo resultados de alta calidad con un modelo de 14B, y Google presentó PaliGemma 2, un modelo de visión-lenguaje en tamaños de 3B, 10B y 28B. Estos son solo algunos de los modelos que se están lanzando actualmente en tamaños más pequeños y, sin duda, es una tendencia importante a seguir.

En los últimos meses, el uso de GenAI para comprender bases de código legado ha generado verdaderos progresos. Herramientas populares como GitHub Copilot se están promocionando como capaces de ayudar a modernizar bases de código legado. Herramientas como Cody de Sourcegraph facilitan a los desarrolladores la navegación y comprensión de bases de código completas. Estas herramientas utilizan multitud de técnicas de GenAI para proporcionar ayuda contextual, simplificando el trabajo con sistemas legados complejos. Además, frameworks especializados como S3LLM están mostrando cómo los modelos de lenguaje extensos (LLMs) pueden manejar software científico de gran escala -como los escritos en Fortran o Pascal- llevando la comprensión mejorada por GenAI a bases de código fuera de la TI empresarial tradicional. Creemos que esta técnica continuará ganando terreno dada la enorme cantidad de software legacy en el mundo.

Supervised software engineering agents are increasingly capable of identifying necessary updates and making larger changes to a codebase. At the same time, we're seeing growing complacency with AI-generated code, and developers becoming reluctant to review large AI-made change sets. A common justification for this is that human-oriented code quality matters less since AI can handle future modifications; however, AI coding assistants also perform better with well-factored codebases, making AI-friendly code design crucial for maintainability.

Fortunately, good software design for humans also benefits AI. Expressive naming provides domain context and functionality; modularity and abstractions keep AI’s context manageable by limiting necessary changes; and the DRY (don’t repeat yourself) principle reduces duplicate code — making it easier for AI to keep the behavior consistent. So far, the best AI-friendly patterns align with established best practices. As AI evolves, expect more AI-specific patterns to emerge, so thinking about code design with this in mind will be extremely helpful.

New techniques for AI-powered assistance on software teams are emerging beyond just code generation. One area gaining traction is AI-powered UI testing, leveraging LLMs' abilities to interpret graphical user interfaces. There are several approaches to this. One category of tools uses multi-modal LLMs fine-tuned for UI snapshot processing, allowing test scripts written in natural language to navigate an application. Examples in this space include QA.tech or LambdaTests' KaneAI. Another approach, seen in Browser Use, combines multi-modal foundation models with Playwright's insights into a web page's structure rather than relying on fine-tuned models.

When integrating AI-powered UI tests into a test strategy, it’s crucial to consider where they provide the most value. These methods can complement manual exploratory testing, and while the non-determinism of LLMs may introduce flakiness, their fuzziness can be an advantage. This could be useful for testing legacy applications with missing selectors or applications that frequently change labels and click paths.

The theory of graceful extensibility defines the basic rules governing adaptive systems, including the socio-technical systems involved in building and operating software. A key concept in this theory is the competence envelope — the boundary within which a system can function robustly in the face of failure. When a system is pushed beyond its competence envelope, it becomes brittle and is more likely to fail. This model provides a valuable lens for understanding system failure, as seen in the complex failures that led to the 2024 Canva outage. Residuality theory, a recent development in software architecture thinking, offers a way to test a system’s competence envelope by deliberately introducing stressors and analyzing how the system has adapted to historical stressors over time. The approaches align with concepts of anti-fragility, resilience and robustness in socio-technical systems, and we’re eager to see practical applications of these ideas emerge in the field.

Structured output from LLMs refers to the practice of constraining a language model's response into a defined schema. This can be achieved either by instructing a generalized model to respond in a particular format or by fine-tuning a model so it "natively" outputs, for example, JSON. OpenAI now supports structured output, allowing developers to supply a JSON Schema, pydantic or Zod object to constrain model responses. This capability is particularly valuable for enabling function calling, API interactions and external integrations, where accuracy and adherence to a format are critical. Structured output not only enhances the way LLMs can interface with code but also supports broader use cases like generating markup for rendering charts. Additionally, structured output has been shown to reduce the chance of hallucinations in model outputs.

AI is lowering the barriers for noncoders to build and integrate software themselves, instead of waiting for the IT department to get around to their requirements. While we’re excited about the potential this unlocks, we’re also wary of the first signs of AI-accelerated shadow IT. No-code workflow automation platforms now support AI API integration (e.g., OpenAI or Anthropic), making it tempting to use AI as duct tape — stitching together integrations that previously weren’t possible, such as turning chat messages in one system into ERP API calls via AI. At the same time, AI coding assistants are becoming more agentic, enabling noncoders with basic training to build internal utility applications.

This has all the hallmarks of the next evolution of the spreadsheets that still power critical processes in some enterprises — but with a much bigger footprint. Left unchecked, this new shadow IT could lead to a proliferation of ungoverned, potentially insecure applications, scattering data across more and more systems. Organizations should be aware of these risks and carefully weigh the trade-offs between rapid problem-solving and long-term stability.

As AI coding assistants continue to gain traction, so does the growing body of data and research highlighting concerns about complacency with AI-generated code. GitClear's latest code quality research shows that in 2024, duplicate code and code churn have increased even more than predicted, while refactoring activity in commit histories has declined. Also reflecting AI complacency, Microsoft research on knowledge workers found that AI-driven confidence often comes at the expense of critical thinking — a pattern we’ve observed as complacency sets in with prolonged use of coding assistants. The rise of supervised software engineering agents further amplifies the risks, because when AI generates larger and larger change sets, developers face greater challenges in reviewing results. The emergence of "vibe coding" — where developers let AI generate code with minimal review — illustrates the growing trust of AI-generated outputs. While this approach can be appropriate for things like prototypes or other types of throw-away code, we strongly caution against using it for production code.

Organizations remain wary of third-party AI coding assistants, particularly due to concerns about code confidentiality. As a result, many developers are considering using local coding assistants — AI that runs entirely on their machines — eliminating the need to send code to external servers. However, local assistants still lag behind their cloud-based counterparts, which rely on larger, more capable models. Even on high-end developer machines, smaller models remain limited in their capabilities. We've found that they struggle with complex prompts, lack the necessary context window for larger problems and often cannot trigger tool integrations or function calls. These capabilities are especially essential to agentic workflows, which is the cutting edge in coding assistance right now.

So while we recommend to proceed with low expectations, there are some capabilities that are valid locally. Some popular IDEs do now embed smaller models into their core features, such as Xcode's predictive code completion and JetBrains' full-line code completion. And locally runnable LLMs like Qwen Coder are a step forward for local inline suggestions and handling simple coding queries. You can test these capabilities with Continue, which supports the integration of local models via runtimes like Ollama.

When people talk about coding assistants, the topic of pair programming inevitably comes up. Our profession has a love-hate relationship with it: some swear by it, others can't stand it. Coding assistants now raise the question: can a human pair with the AI instead of another human and get the same results for the team? GitHub Copilot even calls itself "your AI pair programmer." While we do think a coding assistant can bring some of the benefits of pair programming, we advise against fully replacing pair programming with AI. Framing coding assistants as pair programmers ignores one of the key benefits of pairing: to make the team, not just the individual contributors, better. Coding assistants can offer benefits for getting unstuck, learning about a new technology, onboarding or making tactical work faster so that we can focus on the strategic design. But they don't help with any of the team collaboration benefits, like keeping the work-in-progress low, reducing handoffs and relearning, making continuous integration possible or improving collective code ownership.

We're seeing a worrying proliferation of so-called Reverse ETL. Regular ETL jobs have their place in traditional data architectures, where they transfer data from transaction processing systems to a centralized analytics system, such as a data warehouse or data lake. While this architecture has well-documented shortcomings, many of which are addressed by a data mesh, it remains common in enterprises. In such an architecture, moving data back from a central analytics system to a transaction system makes sense in certain cases — for example, when the central system can aggregate data from multiple sources or as part of a transitional architecture when migrating toward a data mesh. However, we're seeing a growing trend where product vendors use Reverse ETL as an excuse to move increasing amounts of business logic into a centralized platform — their product. This approach exacerbates many of the issues caused by centralized data architectures, and we suggest exercising extreme caution when introducing data flows from a sprawling, central data platform to transaction processing systems.

We see continued adoption of SAFe™ (Scaled Agile Framework®). We also continue to observe that SAFe's over-standardized, phase-gated processes create friction, that it can promote silos and that its top-down control generates waste in the value stream and discourages engineering talent creativity, while limiting autonomy and experimentation in teams. A key reason for adoption is the complexity of making an organization agile, with enterprises hoping that a framework like SAFe offers a simple, process-based shortcut to becoming agile. Given the widespread adoption of SAFe — including among our clients — we’ve trained over 100 Thoughtworks consultants to better support them. Despite this in-depth knowledge and no lack of trying we come away thinking that sometimes there just is no simple solution to a complex problem, and we keep recommending leaner, value-driven approaches and governance that work in conjunction with a comprehensive change program.

Scaled Agile Framework® and SAFe™ are trademarks of Scaled Agile, Inc.