Técnicas

As organizações adotam ativamente a mentalidade de produto para dados como uma prática padrão para gerenciar os ativos de dados. Essa abordagem trata os dados como um produto com seu próprio ciclo de vida, padrões de qualidade e foco em atender às necessidades da pessoa consumidora. Agora a recomendamos como padrão para o gerenciamento de dados, independentemente de as organizações escolherem arquiteturas como malha de dados (data mesh) ou lakehouse.

Enfatizamos a importância do foco na pessoa consumidora na mentalidade de produto para dados, com o fim de promover maior adoção e realização de valor. Isso implica projetar produtos de dados antes dos casos de uso. Também damos foco em capturar e gerenciar metadados relevantes para os negócios e metadados técnicos usando catálogos de dados modernos como DataHub, Collibra, Atlan e Informatica. Essas práticas melhoram a capacidade de descoberta e a usabilidade dos dados. Além disso, adotamos a mentalidade de produto para dados para escalar iniciativas de IA e criar dados prontos para IA. Essa abordagem inclui o gerenciamento abrangente do ciclo de vida, garantindo que os dados não sejam apenas bem administrados e de alta qualidade, mas também descartados em conformidade com os requisitos legais e regulamentares quando não forem mais necessários.

Teste de fuzzing, ou simplesmente fuzzing, é uma técnica de teste que existe há muito tempo, mas ainda é uma das menos conhecidas. O seu objetivo é fornecer a um sistema de software todos os tipos de entradas inválidas e observar o seu comportamento. Para um endpoint HTTP, por exemplo, requisições inválidas deveriam resultar em erros 4xx, mas o teste de fuzzing provoca erros 5xx ou piores. Bem documentado e suportado por ferramentas, o teste de fuzzing se tornou mais relevante do que nunca, especialmente com o aumento do código gerado por IA e sua complacência. Isto significa que é uma boa hora para adotar o teste de fuzzing para garantir que o código continue robusto e seguro.

Desde o nosso blip inicial em 2021, a geração de lista de materiais de software (SBOM) passou de uma prática emergente para um um padrão sensato em nossos projetos. O ecossistema amadureceu significativamente, oferecendo um conjunto de ferramentas robusto e integração perfeita com CI/CD. Ferramentas como Syft, Trivy e Snyk fornecem uma geração de SBOM, desde código fonte até imagens de contêineres e análises de vulnerabilidades. Plataformas como a FOSSA e a Chainloop aprimoram a gestão de riscos de segurança ao se integrarem com o fluxo de desenvolvimento e aplicarem políticas de segurança. Embora um padrão universal de SBOM ainda esteja evoluindo, o amplo suporte ao SPDX e ao CycloneDX minimizou os desafios de adoção. Sistemas de IA também exigem SBOMs, como demonstrado pelo Código de Prática de Cibersegurança em IA do governo do Reino Unido e pelo Playbook de Colaboração em Cibersegurança em IA da CISA. Continuaremos monitorando os avanços nesse espaço.

No cenário em constante evolução de desenvolvimento de software impulsionado por IA, a modelagem de ameaças é mais essencial do que nunca para construir software seguro, mantendo a agilidade e evitando o “sanduíche de segurança”. A modelagem de ameaças — um conjunto de técnicas para identificar e classificar ameaças potenciais — aplica-se em vários contextos, incluindo aplicações de IA generativa, que introduzem riscos de segurança únicos. Para ser eficaz, ela deve ser realizada regularmente ao longo do ciclo de vida do software e funciona melhor em conjunto com outras práticas de segurança. Essas incluem definir requisitos de segurança interfuncionais para abordar riscos comuns nas tecnologias do projeto e utilizar scanners de segurança automatizados para monitoramento contínuo.

Tratar APIs como produto significa priorizar a experiência da pessoa desenvolvedora, não apenas inserindo um design sensato e padronizado nas próprias APIs, mas também fornecendo documentações abrangentes e boas experiências de onboarding. Embora as especificações de OpenAPI (Swagger) possam documentar as interfaces de APIs efetivamente, o onboarding permanece um desafio. As desenvolvedoras precisam de acesso rápido a exemplos funcionais, com autenticação pré-configurada e dados de testes realistas. Com o amadurecimento de ferramentas de clientes de API (como Postman, Bruno e Insomnia), recomendamos tratar a coleção de requisições de API como um artefato do produto. Essas coleções devem ser cuidadosamente projetadas para guiar efetivamente as desenvolvedoras através dos principais fluxos de trabalho, auxiliando na compreensão da funcionalidade e linguagem de domínio da API com o mínimo de esforço. Para manter as coleções atualizadas, recomendamos armazená-las em um repositório e integrar ao pipeline de entrega das APIs.

Um dos desafios persistentes em grandes equipes de software é determinar quem toma as decisões arquiteturais que moldam a evolução dos sistemas. O Relatório sobre o Estado do DevOps revela que a abordagem tradicional dos Conselhos de Revisão de Arquitetura é contraproducente, muitas vezes prejudicando o fluxo de trabalho e correlacionando-se com baixo desempenho organizacional. Uma alternativa convincente é um processo de aconselhamento arquitetural — uma abordagem descentralizada onde qualquer pessoa pode tomar qualquer decisão arquitetural, desde que busque aconselhamento daqueles afetados e daqueles com experiência relevante. Este método permite que as equipes otimizem o fluxo sem comprometer a qualidade arquitetural, tanto em pequenas quanto em grandes escalas. À primeira vista, essa abordagem pode parecer controversa, mas práticas como Registros de Decisão de Arquitetura e fóruns consultivos garantem que as decisões permaneçam informadas, enquanto capacitam aqueles mais próximos do trabalho a tomar decisões. Temos visto este modelo ter sucesso em escala em um número crescente de organizações, incluindo aquelas em indústrias altamente regulamentadas.

Em nossa última atualização do RAG, introduzimos o GraphRAG, originalmente descrito no artigo da Microsoft como uma abordagem de duas etapas: (1) divisão de documentos em segmentos e uso de uma análise baseada em modelos de linguagem de grande porte (LLMs) dos segmentos para criar um gráfico de conhecimento; (2) recuperação de segmentos relevantes no momento da consulta por meio de embeddings, enquanto seguimos as bordas no gráfico de conhecimento para descobrir segmentos relacionados adicionais, que são então adicionados ao prompt aumentado. Em muitos casos, essa abordagem aprimora as respostas geradas pelo LLM. Observamos benefícios semelhantes ao usar o GenAI para entender bases de código legadas, em que usamos informações estruturais — como árvores de sintaxe abstratas e dependências — para criar o gráfico de conhecimento. O padrão GraphRAG ganhou força com o surgimento de ferramentas e estruturas como o pacote GraphRAG Python da Neo4j para oferecer suporte a ele. Também consideramos que o Graphiti se encaixa em uma interpretação mais ampla do GraphRAG como um padrão.

O princípio de menor privilégio garante que sistemas e usuárias tenham apenas o acesso mínimo necessário para realizar suas tarefas. O abuso de credenciais privilegiadas é um fator significativo por trás das violações de segurança, sendo a escalada de privilégios um vetor de ataque comum. Frequentemente, as invasoras começam com acesso de baixo nível e exploram vulnerabilidades de software ou configurações incorretas para obter privilégios de administrador, especialmente quando as contas têm direitos excessivos ou desnecessários. Outro risco negligenciado são os privilégios permanentes — acessos privilegiados disponíveis continuamente, que ampliam a superfície de ataque. O gerenciamento de acesso privilegiado sob demanda mitiga esse risco, concedendo o acesso privilegiado apenas quando necessário e revogando-o imediatamente após o uso, minimizando a exposição. Um modelo de segurança que aplica rigorosamente o princípio de menor privilégio garante que usuárias, aplicações e sistemas tenham apenas os direitos essenciais pelo menor tempo possível – um requisito crítico para conformidade e segurança regulatória. Nossas equipes implementaram essa abordagem por meio de um fluxo de trabalho automatizado, que aciona um processo leve de aprovação, atribui funções temporárias com acesso restrito e impõe um tempo máximo de validade (TTL) para cada função, garantindo que os privilégios expirem automaticamente assim que a tarefa for concluída.

As leis de escala têm sido um fator essencial no avanço da IA — o princípio de que modelos maiores, conjuntos de dados mais extensos e maior poder computacional resultam em sistemas de IA mais poderosos. No entanto, hardwares de consumo e dispositivos de borda frequentemente não possuem capacidade suficiente para suportar modelos em larga escala, criando a necessidade da destilação de modelos.

A destilação de modelos transfere conhecimento de um modelo maior e mais potente (professor) para um modelo menor e mais eficiente (aluno). O processo normalmente envolve a geração de um conjunto de dados amostral a partir do modelo professor e o ajuste fino do modelo aluno para capturar suas propriedades estatísticas. Diferente da poda ou da quantização, que reduzem modelos removendo parâmetros, a destilação busca preservar o conhecimento específico do domínio, minimizando a perda de precisão. Além disso, ela pode ser combinada com quantização para otimização adicional.

Originalmente proposta por Geoffrey Hinton et al., a destilação de modelos tem sido amplamente adotada. Um exemplo notável é a versão destilada do Qwen/Llama do DeepSeek R1, que mantém fortes capacidades de raciocínio em modelos menores. Com sua crescente maturidade, a técnica não está mais restrita a laboratórios de pesquisa; agora é aplicada em projetos industriais e pessoais. Provedores como OpenAI e Amazon Bedrock oferecem guias para ajudar desenvolvedoras a destilar seus próprios modelos de linguagem de pequeno porte (SLMs). Acreditamos que a adoção da destilação de modelos pode ajudar as organizações a gerenciar os custos de implantação de modelos de linguagem de grande porte (LLMs), ao mesmo tempo em que desbloqueia o potencial da inferência de LLM em dispositivos.

Engenharia de prompt se refere ao processo de projetar e refinar prompts de modelos de IA generativa para produzir respostas de alta qualidade e contextualizadas. Isso envolve a elaboração de prompts claros, específicos e relevantes para tarefas sob medida ou aplicações, para otimizar a saída do modelo. À medida que as capacidades dos modelos de linguagem de grande porte (LLMs) evoluem, particularmente com o surgimento dos modelos de raciocínio, as práticas da engenharia de prompt devem também se adaptar. Baseado em nossa experiência em geração de código com IA, nós observamos que o few-shot prompting pode ter uma performance inferior ao zero-shot prompting quando trabalhado com modelos de raciocínio. Adicionalmente, o amplamente utilizado chain-of-thought (CoT) pode degradar a performance de modelos de raciocínio — provavelmente porque a aprendizagem por reforço já tem ajuste fino embutido no macanismo CoT.

Nossa experiência prática está alinhada com as pesquisas acadêmicas, que sugerem que “modelos avançados podem eliminar a necessidade de engenharia de prompt na engenharia de software.” No entanto, técnicas de engenharia de prompt tradicionais ainda desempenham um papel crucial na redução de alucinações e na melhoria da qualidade das respostas, especialmente considerando as diferenças em tempo de resposta e custos de token entre modelos de raciocínio e LLMs genéricos. Ao construir aplicações de agente, nós recomendamos a escolha estratégica dos modelos com base nas suas necessidades, enquanto continua a refinar seus modelos de prompt e técnicas correspondentes. Encontrar o equilíbrio certo entre desempenho, tempo de resposta e custo de token continua sendo essencial para maximizar a eficácia dos LLMs.

O anúncio recente do DeepSeek R1 é um ótimo exemplo de por que modelos de linguagem de pequeno porte (SLMs) permanecem interessantes. O R1 em tamanho real tem 671 bilhões de parâmetros e requer cerca de 1.342 GB de VRAM para funcionar, o que só é possível usando um mini cluster de oito GPUs NVIDIA de última geração. Mas o DeepSeek também está disponível destilado em Qwen e Llama — modelos menores e de peso aberto — transferindo efetivamente suas habilidades e permitindo que seja executado em hardware muito mais modesto. Embora o modelo perca algum desempenho nesses tamanhos menores, ele ainda permite um grande salto de desempenho em relação aos modelos de linguagem de pequeno porte anteriores. O espaço dos SLMs continua a inovar em outros lugares também. Desde o último Radar, a Meta introduziu o Llama 3.2 nos tamanhos 1B e 3B, a Microsoft lançou o Phi-4, oferecendo resultados de alta qualidade com um modelo 14B, e o Google lançou o PaliGemma 2, um modelo de linguagem de visão nos tamanhos 3B, 10B e 28B. Esses são apenas alguns dos modelos menores que estão sendo lançados, consolidando uma tendência importante a ser acompanhada.

Nos últimos meses, o uso de GenIA para entender bases de código legadas tem avançado significativamente. Ferramentas populares, como o GitHub Copilot, estão sendo destacadas como capazes de ajudar na modernização de bases de código legadas. Ferramentas como o Cody, da Sourcegraph, estão facilitando a navegação e compreensão de bases de código inteiras. Essas ferramentas utilizam diversas técnicas de GenIA para fornecer ajuda contextual, simplificando o trabalho com sistemas legados complexos. Além disso, frameworks especializados como o S3LLM estão demonstrando como modelos de linguagem de grande porte (LLMs) podem lidar com softwares científicos em larga escala — como aqueles escritos em Fortran ou Pascal — trazendo uma compreensão aprimorada por GenIA para bases de código fora do tradicional ambiente corporativo de TI. Acreditamos que essa abordagem continuará ganhando força, dado o enorme volume de software legado existente no 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.