Radar da Thoughtworks v34: O Quinto Tema Que Ficou de Fora

Em 15 de abril, a Thoughtworks publicou o Volume 34 do Technology Radar. Quatro temas organizam o documento: reter princípios e abrir mão de padrões, proteger agentes famintos por permissão, colocar coleira em agentes de codificação e o desafio de avaliar tecnologia em um mundo agêntico.

Os quatro são úteis. Os quatro são honestos. E os quatro descrevem, sem exceção, o que acontece dentro de um time de engenharia.

Esse recorte é o ponto deste texto. Não porque o Radar esteja errado. Está certo sobre o que diz. Mas porque, ao nomear com precisão a governança que engenharia precisa construir, deixa em silêncio uma realidade maior: os mesmos quatro padrões já estão atravessando as fronteiras do time de engenharia. E os departamentos que recebem esses padrões (marketing, jurídico, vendas, RH, finanças) não têm pipelines de deploy, testes automatizados, mutation testing nem cultura de code review para absorver a nova disciplina.

O que o Radar acerta

Vale registrar onde a Thoughtworks pisa firme. Rachel Laycock, CTO da empresa, resume a tese do Volume 34 em uma frase que merece atenção: “O ponto de inflexão em que estamos não é tanto sobre tecnologia — é sobre técnica.”

A frase reposiciona o debate. O gargalo de 2026 não é capacidade do modelo. É disciplina de engenharia. E o Radar materializa essa tese em anéis verificáveis: arquitetura zero trust no anel Adopt, Agent Skills e mutation testing no Trial, spec-driven development e métricas de qualidade de colaboração humano-agente no Assess, dívida cognitiva de codebase e inchaço de instruções de agente no Caution.

A organização dos anéis não é acessória. É a espinha dorsal do argumento. Zero trust não é promessa: é postura mínima. Mutation testing não é exótico: é mecanismo de feedback para agentes errarem menos antes da revisão humana. Spec-driven development não é silver bullet: é superfície de controle que ainda precisa ser avaliada com ceticismo.

Para qualquer CTO lendo o Radar em abril de 2026, a mensagem é clara. A engenharia está com um vocabulário novo para um problema antigo. O vocabulário vem com métricas, ferramentas e anéis de maturidade.

O que o Radar não é

Aqui começa o problema que ninguém dentro da Thoughtworks tem incentivo para nomear.

O Technology Radar é, por construção, um documento de engenharia de software. A Thoughtworks declara isso abertamente. Cada blip, cada tema, cada caso é avaliado pelo impacto em times que escrevem código. O recorte é legítimo. É o negócio da empresa.

Mas quando o Radar nomeia “dívida cognitiva” no anel Caution, está amplificando um termo cunhado por Margaret-Anne Storey em 9 de fevereiro de 2026 e estendido por Martin Fowler em 13 de fevereiro. Fowler é Chief Scientist da Thoughtworks desde 2000, o que significa que o termo nasceu fora da casa e foi adotado dentro dela — um caminho que merece ser nomeado para entender a autoridade do Radar. Como argumentamos em Dívida Cognitiva: O Custo Invisível Que Nenhum Benchmark Mede, o conceito descreve um problema organizacional, não um problema de codebase. A perda de entendimento compartilhado acontece onde houver output gerado por IA e humanos responsáveis por decisões. Não apenas em repositórios.

E quando o Radar adota “difusão semântica” como tema 4, está aplicando a agentes um termo que o próprio Martin Fowler cunhou em 2006 para descrever o que aconteceu com palavras como “ágil” e “Web 2.0”. Ou seja: a Thoughtworks tem precedência sobre o conceito, não o está importando. O fenômeno é real. Aplicá-lo a agentes faz sentido. Mas a difusão semântica não é um problema exclusivo de times que avaliam ferramentas de desenvolvimento. É uma patologia de qualquer área que compre, contrate ou implante tecnologia cujo vocabulário mude mais rápido do que a compreensão compartilhada.

O Radar, ao manter o recorte de engenharia, deixa um convite em aberto. Quem vai nomear o que acontece fora do repositório?

O quinto tema

Os quatro padrões que a Thoughtworks descreve já estão sangrando para funções que não têm as ferramentas de absorção da engenharia. Vale fazer o mapeamento com cuidado.

Reter princípios, abrir mão de padrões. Em engenharia, isso significa preservar zero trust, DORA e testabilidade enquanto arquiteturas se adaptam ao código gerado. Em marketing, o análogo já chegou: guardrails de marca. Como a ComplexDiscovery descreveu em 2026, “diretrizes de marca” estão virando “guardrails de marca” porque a voz de marca precisa ser aplicada em tempo de execução por agentes que geram dezenas de ativos criativos por dia. O princípio (consistência de marca) continua. O padrão (revisão humana peça por peça) está sendo abandonado por necessidade operacional. Quem escreve o guardrail? Quem valida que o guardrail não vaza? Nenhuma dessas perguntas tem equivalente funcional ao code review.

Proteger agentes famintos por permissão. Em engenharia, zero trust responde. Em vendas, a pergunta ganha uma forma diferente e mais urgente. CRMs agênticos (Salesforce Agentforce, HubSpot Breeze e dezenas de menores) já enviam follow-ups, atualizam registros de oportunidade e respondem a leads sem intervenção humana. Como Kai Waehner documentou em abril de 2026, “políticas one-size-fits-all falham para IA agêntica”. A superfície de ataque é o histórico do cliente, o pipeline de receita, a reputação da marca. Não existe sandbox de execução. Não existe least-privilege configurado. O equivalente de vendas ao blip de zero trust do Radar ainda não foi inventado.

Colocar coleira em agentes. Em engenharia, Agent Skills e mutation testing formam o par feedforward + feedback que o Radar nomeia. No jurídico, o problema é outro e mais caro. Mais de 700 casos judiciais no mundo, segundo rastreamento do National Law Review em 2026, já envolvem alucinações de IA: citações inventadas, precedentes fabricados, sanções de cinco dígitos em dólar. A coleira jurídica existe, mas ela é uma pessoa humana. Revisão obrigatória por advogado antes do filing. Não há mutation testing de pareceres. Não há spec-kit de petições. A única feedback control é o juiz. E o custo de descobrir o erro no juiz é alto.

O desafio de avaliar tecnologia em um mundo agêntico. Em engenharia, a difusão semântica complica avaliação de fornecedores. Em RH, a complicação é regulatória. O AI Act europeu entra em aplicação plena para sistemas de alto risco em 2 de agosto de 2026. Sistemas de IA em empregabilidade (triagem de currículos, pontuação de candidatos, monitoramento de desempenho) tornam-se categoria de alto risco. Auditorias anuais de viés, avaliações de risco, disclosures de transparência. Penalidades: €15 milhões ou 3% do faturamento global, o que for maior. Como Crowell & Moring documentou na visão legal de 2026 para RH na União Europeia, o problema do CHRO não é escolher o fornecedor certo. É avaliar fornecedores cujo vocabulário (“agente”, “humano no loop”, “explicabilidade”) significa coisas diferentes para cada vendedor e precisa bater com um regulamento que não negocia definição.

Quatro padrões. Quatro áreas. Zero ferramentas maduras em qualquer uma delas.

O que engenharia tem e o resto não tem

A assimetria importa. Quando uma equipe de engenharia decide adotar qualquer blip do Radar v34, ela não começa do zero. Existe uma pilha embaixo: sistema de controle de versão, pull request, testes unitários, CI/CD, observabilidade de produção, playbooks de incidente, rituais de post-mortem. Novo controle encaixa em processo existente. Quem nunca fez code review ainda assim opera num contexto onde code review é vocabulário.

Nas outras funções, não existe essa pilha.

Marketing não tem equivalente ao pull request para aprovação de campanha. Existe Slack. Existe reunião. Existe, na melhor hipótese, um fluxo de Asana.

Jurídico não tem equivalente ao CI. Existe revisão de sênior. Existe checklist. Existe, novamente na melhor hipótese, um workflow de contract lifecycle management que ninguém usa com rigor.

Vendas não tem observabilidade. O CRM registra o que o vendedor registrou. Não registra o que o agente agêntico decidiu quando reescreveu a mensagem no meio do envio.

RH, como exploramos em Engenharia Tem Cloudflare. Marketing Não Tem Nada., opera com ATS que não foi desenhado para auditoria de viés algorítmico em escala. E o prazo do AI Act não negocia maturidade.

Finanças tem o oposto do problema: cultura de controle robusta, vocabulário regulatório sólido, e fornecedores de IA que não falam esse vocabulário. A difusão semântica do lado do fornecedor esbarra na precisão semântica que o compliance exige.

O quinto tema, se existisse no Radar, descreveria essa assimetria. Não como reclamação. Como diagnóstico. Os mesmos quatro padrões que engenharia está aprendendo a governar já estão instalados em funções que não têm a infraestrutura para absorvê-los.

Por que o próximo Radar precisaria disso

Vale imaginar, por exercício, o que um Technology Radar ampliado incluiria se reconhecesse o escopo maior.

Um anel para “agente em função de negócio”. Separado dos blips de engenharia. Avaliaria CRMs agênticos, plataformas de marketing autônomo, revisores jurídicos de IA, ATS com pontuação algorítmica, assistentes financeiros agênticos. Cada um com seu próprio perfil de risco, seu próprio vocabulário, sua própria curva de adoção.

Um tema transversal sobre “governança como disciplina organizacional, não apenas ferramental”. Reconheceria que adotar zero trust no backend enquanto marketing envia campanhas sem aprovação equivale a trancar a porta da frente com a janela aberta. A defensibilidade não é por função. É do sistema inteiro.

Um blip Caution para “mandato funcional sem infraestrutura”. Quando o CEO diz “cada área precisa ter um plano de IA em 90 dias” e a função alvo não tem pipeline, testes, revisão nem vocabulário de governança, o plano vai virar teatro ou acidente. Como registramos em Padrões de Equipe Como Infraestrutura, Não Como Tradição Oral, codificar o conhecimento tácito é precondição para escalar. Fora da engenharia, o conhecimento tácito nunca foi codificado. E a pressão agora é para automatizá-lo antes da codificação.

Um tema explícito: “semântica compartilhada entre jurídico, compliance, RH e engenharia”. A difusão semântica entre fornecedores é o problema que o Radar nomeia. A difusão semântica entre funções internas é o problema que o Radar deixa de fora. Quando jurídico entende “agente” como “fornecedor de software” e engenharia entende como “loop autônomo com credenciais”, os dois times operam num mesmo projeto com definições incompatíveis. O risco não é técnico. É contratual, regulatório e reputacional.

Nada disso é crítica à Thoughtworks. É o que um Radar com escopo organizacional, não apenas de engenharia, teria que incluir para ser acionável em 2026.

A posição da Victorino

O que o Radar v34 nomeia é metade do problema. A outra metade é governança como disciplina organizacional que atravessa funções.

Essa posição não é postura. É consequência do que temos visto na prática. Como documentamos em O Acerto de Contas da Governança no Marketing, profissionais de marketing estão descobrindo que LLMs fabricam dados, mentem sobre verificação e produzem outputs convincentes sem verdade. Não é falha de modelo. É ausência de processo. E processo não se instala com compra de ferramenta.

Como argumentamos em A Governança de IA Saiu da Engenharia, Adobe, Klaviyo e até Jack Dorsey convergem independentemente para o mesmo vocabulário (guardrails, controle de versão, quality gates) aplicado a domínios que nunca tiveram esse vocabulário. A convergência valida o diagnóstico. A ausência de ferramentas maduras valida a urgência.

O Radar v34 é uma contribuição séria. A Thoughtworks nomeia quatro temas que CTOs precisam levar ao comitê executivo na próxima semana. O problema é que o comitê executivo, ao ouvir, vai perguntar: “E para as minhas outras funções?”

A resposta honesta hoje é: as outras funções ainda estão montando o vocabulário. Montar o vocabulário, antes de escolher a ferramenta, antes de adotar o blip, antes de responder ao mandato do CEO, é o trabalho que define quem sai de 2026 com governança real e quem sai com checklist.

Governança não é uma feature. É uma disciplina. E disciplina, como Laycock lembra, é técnica, não tecnologia.

---

Fontes

• Thoughtworks. “Technology Radar Volume 34.” Abril 2026.
• Storey, Margaret-Anne. “Cognitive Debt.” Fevereiro 2026.
• Fowler, Martin. “Semantic Diffusion.” 2006.
• Crowell & Moring. “AI and HR in the EU: 2026 Legal Overview.” 2026.
• ComplexDiscovery. “From Brand Guidelines to Brand Guardrails.” 2026.

Governança que atravessa funções começa com disciplina organizacional, não com ferramentas isoladas. Vamos conversar: contato@victorino.com.br | www.victorino.com.br