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.

Agentes de engenharia de software supervisionados estão cada vez mais capazes de identificar atualizações necessárias e fazer alterações maiores em uma base de código. Ao mesmo tempo, vemos uma crescente complacência com código gerado por IA e desenvolvedoras demonstrando resistência em revisar grandes conjuntos de mudanças feitas por IA. Uma justificativa comum para isso é a ideia de que a legibilidade do código voltada para humanos importa menos, já que a IA pode lidar com modificações futuras. No entanto, assistentes de código baseados em IA também têm um desempenho melhor em bases de código bem estruturadas, tornando o design de código compatível com IA essencial para a manutenção.

Felizmente, boas práticas de design de software para humanos também beneficiam a IA. Nomes bem definidos fornecem contexto de domínio e funcionalidade; modularidade e abstrações mantêm o contexto da IA gerenciável ao limitar as mudanças necessárias; e o princípio DRY (“don’t repeat yourself”, ou “não se repita”) reduz a duplicação de código, facilitando para a IA manter a consistência do comportamento. Até agora, os melhores padrões compatíveis com IA estão alinhados às boas práticas já estabelecidas. À medida que a IA evolui, mais padrões específicos devem surgir, por isso, considerar o design de código com isso em mente será extremamente útil.

Técnicas novas de assistência baseada em IA para equipes de software estão surgindo além da simples geração de código. Uma área que está ganhando destaque é o teste de UI baseado em IA , aproveitando a capacidade dos modelos de linguagem de grande porte (LLMs) de interpretar interfaces gráficas de usuário. Existem várias abordagens para isso. Uma categoria de ferramentas utiliza LLMs multimodais ajustados para o processamento de snapshots, permitindo que scripts de teste sejam escritos em linguagem natural para navegar em uma aplicação. Exemplos nessa área incluem QA.tech ou LambdaTests' KaneAI. Outra abordagem, vista no Browser Use, combina modelos fundacionais multimodais com Playwright, oferecendo insights sobre a estrutura de uma página em vez de depender de modelos ajustados.

Ao integrar testes de UI baseados em IA em uma estratégia de testes, é crucial considerar onde eles agregam mais valor. Esses métodos podem complementar os testes exploratórios manuais e, embora ao não determinismo dos LLMs possa introduzir instabilidades, sua flexibilidade pode ser uma vantagem. Isso pode ser útil para testar aplicações legadas com seletores ausentes ou aplicações que frequentemente mudam rótulos e caminhos de cliques.

A teoria da extensibilidade graciosa define as regras básicas que regem os sistemas adaptativos, incluindo os sistemas sociotécnicos envolvidos na criação e operação de software. Um conceito fundamental nessa teoria é o envoltório de competência - o limite dentro do qual um sistema pode funcionar robustamente diante de uma falha. Quando um sistema é levado além de seu envoltório de competência, ele se torna frágil e tem maior probabilidade de falhar. Esse modelo fornece uma lente valiosa para entender a falha do sistema, como visto nas falhas complexas que levaram à interrupção do Canva em 2024. A Teoria da Residualidade, um desenvolvimento recente no pensamento da arquitetura de software, oferece uma maneira de testar o envoltório de competência de um sistema introduzindo deliberadamente fatores de estresse e analisando como o sistema se adaptou aos fatores de estresse históricos ao longo do tempo. As abordagens se alinham com os conceitos de antifragilidade, resiliência e robustez em sistemas sociotécnicos, e estamos ansiosas para ver aplicações práticas dessas ideias no setor.

Saída estruturada de LLMs se refere à prática de restringir a resposta de um modelo de linguagem a um esquema definido. Isso pode ser alcançado tanto através de um modelo generalizado, para que ele responda em um formato específico, quanto ajustando um modelo para que ele nativamente produza um JSON, por exemplo. A OpenAI agora suporta saídas estruturadas, permitindo que as desenvolvedoras forneçam um esquema JSON, pydantic ou um objeto Zod para restringir as respostas do modelo. Essa capacidade é especialmente valiosa para permitir chamadas de função, integração com APIs e integrações externas, onde a precisão e conformidade com o formato são críticas. A saída estruturada não apenas aprimora a maneira como as LLMs podem interagir com o código, mas também suporta casos de uso mais amplos, como a geração de marcação para renderizar gráficos. Além disso, a saída estruturada demonstrou reduzir a probabilidade de erros nas respostas do modelo.

A IA está diminuindo as barreiras para que pessoas que não programam construam e integrem software por conta própria, em vez de esperar que o departamento de TI atenda às suas necessidades. Embora estejamos entusiasmadas com o potencial que isso desbloqueia, também estamos atentas aos primeiros sinais da TI invisível acelerada por IA. Plataformas de automação de fluxo de trabalho sem código agora oferecem suporte à integração de API de IA (por exemplo, OpenAI ou Anthropic), tornando tentador usar a IA como tapa-buraco — unindo integrações que antes não eram possíveis, como transformar mensagens de chat em chamadas de API de ERP via IA. Ao mesmo tempo, assistentes de programação de IA estão se tornando mais “agênticos", ou autônomos, permitindo que pessoas com treinamento básico construam aplicativos de utilidade interna.

Isso tem todas as características da próxima evolução das planilhas que ainda alimentam processos críticos em algumas empresas — mas com uma pegada muito maior. Se não for controlada, essa nova TI invisível pode levar a uma proliferação de aplicativos não regulamentados e potencialmente inseguros, espalhando dados por cada vez mais sistemas. As organizações devem estar cientes desses riscos e avaliar cuidadosamente as compensações entre a resolução rápida de problemas e estabilidade a longo prazo.

À medida que os assistentes de programação de IA continuam a ganhar força, o mesmo acontece com o crescente conjunto de dados e pesquisas que destacam as preocupações sobre a complacência com código gerado por IA. A mais recente pesquisa de qualidade de código da GitClear mostra que, em 2024, códigos duplicados e a rejeição de códigos aumentaram ainda mais do que o previsto, enquanto a atividade de refatoração nos históricos de commit diminuiu. Também refletindo isso, uma pesquisa da Microsoft sobre “trabalhadoras do conhecimento” descobriu que a confiança impulsionada pela IA geralmente ocorre às custas do pensamento crítico (um padrão que observamos à medida que a complacência se instala com o uso prolongado de assistentes de programação). O surgimento de agentes de engenharia de software supervisionados amplia ainda mais os riscos, pois quando a IA gera conjuntos de alterações cada vez maiores, as desenvolvedoras enfrentam desafios maiores na revisão dos resultados. O surgimento da “vibe coding”, em que desenvolvedoras permitem que a IA gere código com revisão mínima, ilustra a confiança crescente nos resultados gerados pela IA. Embora essa abordagem possa ser apropriada para coisas como protótipos ou outros tipos de código descartável, advertimos fortemente contra seu uso para código de produção.

As organizações continuam cautelosas em relação aos assistentes de programação com IA de terceiros, especialmente devido a preocupações com a confidencialidade do código. Como resultado, muitas desenvolvedoras estão considerando o uso de assistentes de programação locais — IAs que rodam inteiramente em suas máquinas — eliminando a necessidade de enviar código para servidores externos. No entanto, os assistentes locais ainda ficam atrás das versões baseadas na nuvem, que utilizam modelos maiores e mais avançados. Mesmo em máquinas de alto desempenho, os modelos menores continuam apresentando limitações. Observamos que eles têm dificuldades com prompts complexos, não possuem uma janela de contexto suficientemente grande para problemas mais amplos e, muitas vezes, não conseguem ativar integrações de ferramentas ou chamadas de funções. Essas capacidades são especialmente cruciais para os workflows baseados em agentes, que representam o estado da arte na assistência à programação atualmente.

Portanto, embora seja importante ter expectativas moderadas, algumas funcionalidades ainda são viáveis localmente. Algumas IDEs populares agora incorporam modelos menores em seus recursos principais, como a conclusão preditiva de código do Xcode e a completação de código de linha inteira da JetBrains. Além disso, LLMs que podem ser executados localmente, como o Qwen Coder, representam um avanço para sugestões inline locais e o manuseio de consultas simples de programação. Você pode testar essas capacidades com o Continue, que suporta a integração de modelos locais por meio de runtimes como o Ollama.

Quando as pessoas falam sobre assistentes de programação, o tópico programação em pares inevitavelmente aparece. Nossa profissão tem uma relação de amor e ódio com isso: algumas pessoas acreditam veemente, outras não suportam. Assistentes de programação agora imploram pela pergunta: pode um ser humano parear com uma IA, ao invés de outro ser humano, e obter os mesmos resultados para o time? O GitHub Copilot chama a si mesmo de seu programador em par de IA. Enquanto acreditamos que um assistente de programação pode trazer alguns dos benefícios da programação em pares, nós desaconselhamos totalmente substituir programação em pares por IA. Visualizar assistentes de código para o pareamento ignora um dos benefícios chave da programação em pares: tornar o time, não apenas os indivíduos que contribuem, melhor. Assistentes de programação podem oferecer benefícios para se desbloquear, aprender sobre uma nova tecnologia, integrar ou tornar o trabalho tático mais rápido para que possamos focar em design estratégico. No entanto, eles não contribuem para os benefícios da colaboração em equipe, como manter o trabalho em andamento em um nível baixo, reduzir handoffs e reaprendizados, possibilitar a integração contínua ou melhorar a propriedade coletiva do código.

Estamos observando uma proliferação preocupante do chamado ETL reverso. Os processos tradicionais de ETL têm seu lugar nas arquiteturas de dados convencionais, onde transferem dados de sistemas de processamento de transações para um sistema centralizado de análise, como um data warehouse ou um data lake. Embora essa arquitetura tenha limitações bem documentadas — muitas das quais são abordadas por uma abordagem de malha de dados —, ela ainda é comum em empresas. Numa arquitetura desse tipo, mover dados de volta de um sistema central de análise para um sistema de transações faz sentido em certos casos — por exemplo, quando o sistema central pode agregar dados de várias fontes ou como parte de uma arquitetura transicional ao migrar para uma malha de dados. No entanto, estamos observando uma tendência crescente em que fornecedoras de produtos usam ETL reverso como uma desculpa para mover cada vez mais lógica de negócios para uma plataforma centralizada — o produto delas. Essa abordagem agrava muitos dos problemas causados pelas arquiteturas de dados centralizadas, e sugerimos extrema cautela ao introduzir fluxos de dados de uma plataforma centralizada e abrangente para sistemas de processamento de transações.

Vemos uma adoção contínua do SAFe™ (Scaled Agile Framework®). Também continuamos a observar que os processos de SAFe, padronizados em excesso e com etapas faseadas, criam fricção, podem promover silos e que seu controle de cima para baixo gera desperdício no fluxo de valor e desestimula a criatividade dos talentos de engenharia, ao mesmo tempo em que limita a autonomia e a experimentação das equipes. Um dos principais motivos para a adoção do SAFe é a complexidade de tornar uma organização ágil, com empresas esperando que um framework como esse ofereça um atalho simples, baseado em processos, para alcançarem a agilidade. Dada a adoção generalizada do SAFe — inclusive entre nossas clientes — treinamos mais de 100 consultoras da Thoughtworks para oferecer melhor suporte a elas. Apesar desse conhecimento aprofundado e de muita tentativa, chegamos à conclusão de que, às vezes, simplesmente não existe uma solução simples para um problema complexo e continuamos a recomendar abordagens e governança mais enxutas e orientadas por valor que funcionem em conjunto com um programa abrangente de mudança.

Scaled Agile Framework® e SAFe™ são marcas registradas da Scaled Agile, Inc.