Technology Radar

Um guia de opinião sobre o universo de tecnologia atual

O Thoughtworks Technology Radar é um panorama semestral de ferramentas, técnicas, plataformas, linguagens e frameworks. Essa ferramenta de compartilhamento de conhecimento é baseada na experiência de nossas equipes globais e destaca coisas que você pode querer explorar em seus projetos.

Novo
Modificado
Sem alteração

Sem blips

techniques platforms tools languages-and-frameworks .all-quadrants.js-enabled { display: none; }

Cada insight que compartilhamos é representado por um ponto. Os pontos podem ser novos no Radar mais recente, ou podem mudar de anel conforme nossa recomendação muda.

Os anéis são:

Adote: Pontos que achamos que você deve considerar seriamente usar.
Experimente: Opções que achamos que estão prontas para uso, mas não tão comprovadas quanto as do anel Adote.
Avalie: Opções para observar atentamente, mas não necessariamente experimentar ainda, a menos que você ache que seja um encaixe particularmente bom para você.
Cautela: Proceda com cuidado. Esses items envolvem receios significativos que exigem uma avaliação criteriosa alinhada ao seu contexto

Explore a versão interativa por quadrante ou baixe o PDF para ler o Radar completo. Se quiser saber mais sobre o Radar, como usá-lo ou como ele é construído, consulte as Perguntas Frequentes (FAQ).

Baixe o PDF

English | Português

Inscreva-se para receber a newsletter do Technology Radar

Seja assinante

Temas para este volume

Em cada volume do Radar Tecnológico, buscamos padrões emergentes nos pontos que discutimos. Esses padrões formam a base de nossos temas.

O desafio de avaliar tecnologia em um mundo de agentes

A IA está mudando não apenas a tecnologia, mas também como a analisamos e avaliamos. Ao montar esta edição do Technology Radar, notamos que avaliar tecnologia está se tornando mais difícil à medida que a indústria adota a IA. Um dos fatores que contribuem para isso é a difusão semântica: o rápido surgimento de novos termos para práticas em evolução, frequentemente antes que seus significados se estabilizem. Por exemplo, termos como o desenvolvimento orientado a especificações e a harness engineering às vezes são usados de forma inconsistente ou se sobrepõem em significado. Sem definições compartilhadas, é difícil determinar se estamos vendo técnicas distintas ou simplesmente rótulos diferentes para ideias semelhantes. Distinguir uma metodologia de engenharia madura e autônoma, com guardrails claras, do uso cotidiano de ferramentas de IA, como assistentes de programação, é uma dificuldade contínua.

O desafio vai além da semântica. O ritmo das mudanças agrava essa incerteza. Encontramos várias ferramentas com menos de um mês de existência — algumas promissoras, mas, em última análise, jovens demais para serem avaliadas. Em muitos casos, essas ferramentas eram mantidas por uma única pessoa contribuidora trabalhando com um agente de IA para programação. A IA diminuiu a barreira para a construção de ferramentas para pessoas desenvolvedoras, criando um fluxo constante de novas ferramentas. Isso força o ritmo tradicional do Radar: se dermos tempo para que as ferramentas amadureçam, nossas recomendações correm o risco de se tornar desatualizadas; se nos movermos rápido demais, corremos o risco de destacar tendências que desaparecem na mesma velocidade. Isso também levanta questões sobre sustentabilidade: quando algo pode ser criado rapidamente e com relativamente pouco esforço, o que garante o investimento contínuo para mantê-lo e evoluí-lo?

Esse ambiente também corre o risco de criar dívida cognitiva da base de código. À medida que mais código é gerado por IA, fica mais fácil adotar soluções sem desenvolver os modelos mentais necessários para entender como elas funcionam. Com o tempo, essa lacuna de entendimento se acumula, tornando os sistemas mais difíceis de entender, depurar e evoluir.

Mantendo princípios, abandonando padrões

Uma consequência interessante da IA no desenvolvimento de software é que ela não está apenas nos forçando a olhar para o futuro; ela também está nos levando a revisitar os fundamentos do nosso ofício. Ao montar esta edição, nos vimos retornando a muitas técnicas estabelecidas, da programação em par à arquitetura de confiança zero, e dos testes de mutação às métricas DORA. Revisitamos princípios centrais da maestria em software, como clean code, design intencional, testabilidade e acessibilidade como uma preocupação prioritária. Isso não é nostalgia, mas um contrapeso necessário à velocidade com que as ferramentas de IA podem gerar complexidade. Também observamos um ressurgimento da linha de comando: após anos abstraindo-a em nome da usabilidade, as ferramentas baseadas em agentes estão trazendo as pessoas desenvolvedoras de volta ao terminal como uma interface principal.

Dito isso, esta não é apenas uma história de continuidade. O desenvolvimento de software assistido por IA representa uma mudança fundamental na prática de engenharia, exigindo que repensemos — e, em alguns casos, descartemos — suposições mantidas há muito tempo. Em particular, a forma como colaboramos e estruturamos os times precisará evoluir à medida que entendermos melhor o que é possível com sistemas baseados em agentes. Talvez precisemos considerar topologias de agentes em conjunto com as topologias de times, e repensar os ciclos de feedback de acordo. Várias técnicas nesta edição refletem essa mudança. Por exemplo, a medição da qualidade da colaboração com agentes de programação aponta para uma redefinição mais ampla do que significa ser uma pessoa desenvolvedora de software. Em última análise, provavelmente estamos apenas no começo de uma transformação mais profunda na forma como construímos, entendemos e interagimos com sistemas de software.

No centro disso está o desafio de gerenciar a dívida cognitiva em um ambiente impulsionado por IA. Devemos reter os princípios da boa engenharia de software sem permitir que as ferramentas de IA amplifiquem a complexidade ou acelerem a fadiga de decisão. Nossa tradição de craftsmanship há muito tempo defende que a velocidade sem disciplina multiplica os custos — um princípio ao qual vale a pena nos apegarmos à medida que os sistemas baseados em agentes tornam mais fácil do que nunca avançar rapidamente e entender o que construímos.

Protegendo agentes ávidos por permissões

"Ávido por permissões" descreve o dilema no centro do atual momento dos agentes: os agentes que valem a pena construir são aqueles que precisam de acesso a tudo. O OpenClaw e o Claude Cowork supervisionam tarefas de trabalho reais; o Gas Town coordena enxames de agentes em bases de código inteiras. Esses agentes exigem amplo acesso a dados privados, comunicação externa e sistemas reais — cada um argumentando que a recompensa justifica isso.

No entanto, como um esquiador que acabou de aprender a fazer curvas e se lança com confiança na pista mais difícil, as salvaguardas não acompanharam essa ambição. O apetite por acesso colide com problemas não resolvidos. A injeção de prompt significa que os modelos ainda não conseguem distinguir de maneira segura instruções confiáveis de entradas não confiáveis. A definição de "tríade letal" de Simon Willison para um agente inseguro — dados privados, conteúdo não confiável, ação externa — agora descreve a maioria dos agentes úteis por padrão, não por erro de configuração. A injeção não é a única ameaça. O comportamento do modelo ainda é inconsistente: uma tarefa concluída com sucesso uma vez não oferece garantia de que será bem-sucedida na próxima, muito menos em escala. Os agentes encontram caminhos criativos de exfiltração, fazem push para branches que não deveriam tocar e enfraquecem os pontos de controle de aprovação/negação sem nenhuma intenção maliciosa ou prompting explícito.

O que podemos fazer hoje? Confiança zero, privilégio mínimo, melhorias de modelo e defesa em profundidade agora são requisitos básicos, mas não há bala de prata. Esperamos que sistemas de agentes seguros sejam compostos não por agentes monolíticos, mas por pipelines de agentes mais restritos, com forte monitoramento e controle. Práticas emergentes, a exemplo de skills de agentes como uma alternativa controlada ao MCP, agentes duráveis e técnicas para prevenir o inchaço de instruções de agentes, apontam todas nessa direção. O espaço está evoluindo rapidamente, o que é empolgante — mas, por enquanto, a cautela é essencial para evitar um erro que custe caro.

Mantendo agentes de programação sob controle

À medida que os agentes de programação se tornam mais capazes e produzem melhores resultados, os humanos estão cada vez mais tentados a sair do loop. Para mitigar os riscos da redução da supervisão humana, os times estão começando a investir em harnesses para agentes de programação: controles que guiam o comportamento dos agentes antes que o código seja gerado e fornecem feedback depois, para permitir a autocorreção.

Controles de antecipação (feedforward) antecipam o que o agente precisa para aumentar a probabilidade de acertar já na primeira tentativa. As skills de agentes têm sido um grande avanço recente, ajudando a modularizar instruções e convenções, e a carregá-las sob demanda. O Superpowers é um exemplo de um catálogo de skills úteis para times de software, e o conceito emergente de marketplaces de plugins está tornando mais fácil distribuir skills e outras configurações de contexto. Nossos times também viram valor em frameworks de desenvolvimento orientado a especificações, como o GitHub Spec-Kit e o OpenSpec, que estruturam workflows e guiam os agentes através do planejamento, design e implementação.

Controles de feedback, por outro lado, observam o comportamento após o agente agir e criam um ciclo para autocorreção. Essa abordagem é capturada pelos sensores de feedback para agentes de programação: quality gates determinísticos — compiladores, linters, verificadores de tipos e suítes de testes — integrados diretamente aos workflows dos agentes, para que falhas disparem a correção automática antes da revisão humana. Exemplos deste Radar incluem o cargo-mutants e outras ferramentas de testes de mutação, ferramentas de fuzz testing como o WuppieFuzz e ferramentas de análise de qualidade de código como o CodeScene. Além do feedback no loop, alguns de nossos times também reduziram o desvio de arquitetura combinando regras estruturais determinísticas com avaliação baseada em LLM.