Técnicas
Adote
-
1. Mentalidade de produto para dados
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.
-
2. Teste de fuzzing
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.
-
3. Lista de materiais de software
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.
-
4. Modelagem de ameaças
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.
Avalie
-
13. Design de código compatível com IA
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.
-
14. Teste de UI baseado em IA
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.
-
15. Envoltório de competência como um modelo para entender as falhas de um sistema
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.
-
16. Saída estruturada de LLMs
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.
Evite
-
17. TI invisível acelerada por IA
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.
-
18. Complacência com código gerado por IA
À 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.
-
19. Assistentes de programação locais
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.
-
20. Substituição da programação em pares por IA
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.
-
21. ETL reverso
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.
-
22. SAFe™
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.
Não encontrou algo que você esperava achar?
Cada edição do Radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um Radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.
