Thoughtworks Technology Radar Vol. 34: O que está em alta e como a engenharia de software está mudando após a virada 'agentic'
O Technology Radar Vol. 34 da Thoughtworks analisa as tendências em engenharia de software, destacando a importância de princípios básicos, segurança e a necessidade de controlar agentes de IA. O artigo enfatiza a mudança de foco da capacidade da IA para a criação de um ambiente de trabalho seguro e eficiente.
MundiX News·08 de maio de 2026·10 min de leitura·👁 10 views
Thoughtworks Technology Radar Vol. 34: O que está em alta e como a engenharia de software está mudando após a virada 'agentic'
Cada nova onda de discussão sobre inteligência artificial (IA) inicialmente provoca euforia, mas depois leva a uma avaliação mais sóbria das consequências e dos custos acumulados. Primeiro, vemos demonstrações espetaculares: um agente escreve código, um LLM resume requisitos, as ferramentas se tornam "mais inteligentes", e as integrações parecem desaparecer sob uma camada de novos protocolos e interfaces. Depois, vem a realidade do trabalho: as instruções se expandem, os direitos de acesso se tornam muito amplos, a revisão de código se transforma em análise de decisões alheias, e a qualidade do sistema começa a ser determinada não apenas pelo modelo, mas por todo o ambiente ao seu redor.
É por isso que o Thoughtworks Technology Radar Vol. 34 é importante não como mais um mapa de tendências, mas como um sinal de mudança na ótica da engenharia. Esta edição não se resume à tese "IA muda tudo". Ela mostra que a engenharia de software já está se afastando da discussão sobre as capacidades do modelo para o projeto do ambiente em que pessoas, agentes, ferramentas e contornos de controle alteram o sistema em conjunto.
O Radar ainda mantém sua estrutura habitual: quadrantes, anéis de maturidade, divisão em técnicas, ferramentas, plataformas, linguagens e frameworks. Mas na 34ª edição, o mais importante não é o próprio esquema, mas os quatro temas em torno dos quais toda a edição é construída. A Thoughtworks destaca diretamente a complexidade da avaliação de tecnologias no mundo 'agentic', o retorno aos princípios básicos de engenharia, os riscos de agentes 'permission-hungry' e a necessidade de restringir mais rigidamente os 'coding agents'.
Por que esta edição é importante
O Technology Radar sempre teve seu ponto forte: ele não tenta adivinhar o futuro, mas fornece uma linguagem para avaliar as mudanças tecnológicas. Na 34ª edição, essa abordagem se torna especialmente importante, porque não apenas a paisagem tecnológica começa a quebrar, mas também os próprios critérios para sua avaliação.
A Thoughtworks formula isso de forma bastante clara: a IA muda não apenas o conjunto de tecnologias usadas, mas também os critérios pelos quais tentamos entendê-las e compará-las. No ecossistema de ferramentas 'agentic', a ambiguidade semântica está crescendo muito rapidamente: há mais termos do que conteúdo estável por trás deles. Portanto, a mesma abordagem hoje pode ser chamada de desenvolvimento baseado em especificação, projeto de contornos de teste, orquestração de agentes ou composição de habilidades - e essas diferenças nem sempre esclarecem a essência, mas a mascaram.
Isso quebra o ciclo habitual do Radar. Se você esperar pela maturidade, as recomendações ficarão desatualizadas rapidamente. Se você reagir muito cedo, o ruído temporário entrará na imagem, e não um sinal estável.
Daí a principal conclusão da edição: a engenharia terá que trabalhar em um mundo onde a velocidade de surgimento de novas ferramentas aumentou drasticamente, e a transparência, a capacidade de manutenção e a capacidade da equipe de entender o que ela está construindo não acompanham essa velocidade.
Quatro sinais
Avaliar tecnologias se tornou mais difícil
Esta não é apenas uma história sobre o crescimento do número de startups de IA. A Thoughtworks escreve diretamente que a IA reduziu o limite para a criação de 'developer tooling' e lançou um fluxo constante de novas ferramentas, algumas das quais são muito jovens para serem avaliadas de forma sensata.
O problema não é apenas a quantidade. Tornou-se mais difícil distinguir uma nova ideia de engenharia de uma abordagem antiga com um novo nome, uma ferramenta viável de uma demonstração bem-sucedida e uma prática sustentável de uma onda curta de interesse. A isso se soma a questão da manutenção: se uma ferramenta pode ser montada rapidamente com a ajuda de um agente, quem e com base em que irá mantê-la em seis meses?
Em tal ambiente, há cada vez menos sentido em discutir a novidade e cada vez mais - sobre as propriedades de operação. A capacidade de manutenção, o modelo de segurança, a sustentabilidade, a presença de uma comunidade e a confirmação de que a prática funciona fora de alguns cenários demonstrativos são realmente importantes. Esta é uma das razões pelas quais a zona Caution está se fortalecendo no Radar.
Os antigos princípios de engenharia se tornaram mais valiosos
Um dos temas mais fortes da edição é "Mantendo os princípios, abandonando os modelos". A Thoughtworks na verdade diz algo simples: quanto mais rápido a IA ajuda a produzir código e soluções, mais importantes se tornam novamente as práticas básicas de engenharia - da arquitetura de confiança zero e testabilidade às métricas DORA e código limpo. A razão é que, em tal ambiente, o código aparece mais rápido do que a equipe consegue entendê-lo de verdade, razão pela qual a dívida de compreensão da base de código se acumula.
Portanto, a IA não cancela a disciplina de engenharia, mas aumenta seu custo. A velocidade de geração de código está crescendo, mas é por isso que as práticas que reduzem a ambiguidade, aumentam a observabilidade e ajudam a distinguir um sistema em funcionamento de uma imitação plausível de trabalho estão se tornando mais caras novamente.
'Permission-hungry agents' - já é uma tarefa de arquitetura de segurança
O terceiro tema da edição soa como um aviso direto. A Thoughtworks escreve que os agentes mais úteis são precisamente aqueles que precisam de amplo acesso a dados, canais externos e sistemas de trabalho reais. Este é o problema: o valor do agente puxa diretamente a expansão dos poderes.
Ao mesmo tempo, os mecanismos de proteção não conseguem acompanhar as ambições. A injeção de prompt continua sendo um problema não resolvido, o comportamento do modelo permanece inconsistente, e a conclusão bem-sucedida de uma tarefa uma vez não garante a repetibilidade nem na segunda, nem na centésima. A Thoughtworks enfatiza separadamente que os agentes podem encontrar maneiras inesperadas de exfiltração de dados, alterar o que não deveriam ter acesso e diluir os 'approve/deny chokepoints' habituais, mesmo sem más intenções.
Daí a conclusão bastante prática. Um sistema 'agentic' seguro, na opinião da Thoughtworks, deve ser construído não em torno de um único monólito "inteligente", mas em torno de um contorno de agentes mais limitados, com o princípio do menor privilégio, proteção em camadas, monitoramento forte e controle rígido, arquitetura de confiança zero como a norma básica. Não é por acaso que a arquitetura de confiança zero (zero trust architecture) nesta edição está em Adopt.
'Coding agents' precisam ser incluídos no contorno de gerenciamento
O quarto tema, talvez o mais útil para a prática diária de engenharia. A Thoughtworks escreve que, à medida que a qualidade dos 'coding agents' aumenta, as equipes estão tentando cada vez mais remover a pessoa do contorno de trabalho, e é por isso que começam a investir em contornos de gerenciamento.
A lógica aqui é simples. Antes da geração de código, são necessários 'feedforward controls', que aumentam a probabilidade de um primeiro passo correto. Após a geração, são necessários 'feedback controls', que permitem que o agente se corrija antes da revisão humana.
Isso ecoa bem com o artigo recente de Birgitta Böckeler sobre harness engineering, onde tal contorno é descrito como uma combinação de direcionamento antecipado e feedback: os mecanismos de direcionamento aumentam a probabilidade de uma primeira ação correta, e os sensores ajudam o agente a se corrigir antes mesmo da verificação humana.
No Radar, essa lógica se manifesta de forma muito consistente: 'Agent Skills' permitem formatar instruções e acordos de forma modular e carregá-los conforme necessário; OpenSpec e outras abordagens baseadas em especificação estruturam o fluxo de trabalho antes mesmo da geração de código; 'feedback sensors for coding agents' incorporam compiladores, linters, verificações de tipos, testes e outras barreiras de qualidade determinísticas diretamente no ciclo de trabalho do agente; e as abordagens para reduzir a deriva arquitetônica mostram que verificações semânticas podem ser adicionadas além das regras formais.
É aqui que se vê uma mudança importante de 2026. Estamos discutindo não apenas a capacidade do modelo de escrever código, mas as condições sob as quais o agente pode ser confiável para realizar essa ação.
O que levar para o trabalho
Da 34ª edição, já é possível levar para a prática várias direções.
Context engineering. A Thoughtworks o traduz da categoria de 'optimisation tactic' para a categoria de 'foundational architectural concern' para sistemas de IA modernos. O contexto aqui é entendido não como "texto próximo à solicitação", mas como um ambiente de informação projetado para o agente. Em vez de um grande prompt, é oferecido 'progressive context disclosure': primeiro, um índice leve do conhecimento disponível, depois, o carregamento apenas do que realmente é necessário durante o trabalho.
Curated shared instructions for software teams. A Thoughtworks chama de anti-padrão a situação em que cada desenvolvedor escreve seus próprios prompts do zero. As instruções devem se tornar um ativo de engenharia comum da equipe e ser incorporadas em modelos de serviços, repositórios e 'reference applications' por meio de arquivos como AGENTS.md, CLAUDE.md ou regras específicas do projeto. Esta é uma mudança organizacional importante: as configurações úteis para trabalhar com IA deixam de viver em notas pessoais e entram na entrega básica do projeto.
Structured output from LLMs. A Thoughtworks já considera isso um 'sensible default' para cenários em que as respostas do modelo são processadas por software. O valor aqui não está no amor pelo JSON como tal, mas na redução da ambiguidade e na capacidade de construir contratos verificáveis por máquina sobre a resposta. Quando isso é adicionado a 'deterministic quality gates', obtém-se um contorno de trabalho no qual o agente pode ser rapidamente e formalmente mostrado onde ele ultrapassou os limites permitidos.
Zero trust architecture - esta não é mais uma prática opcional do mundo da segurança, mas uma resposta básica de engenharia a sistemas autônomos com amplos poderes. Quanto maior a autonomia do agente, mais perigosa é a confiança por padrão. Portanto, 'identity-based control', 'least privilege', 'continuous verification' e observabilidade devem ser estabelecidos como propriedades obrigatórias do sistema, e não como uma atualização tardia.
O que experimentar com cautela
As categorias Trial e Assess nesta edição são especialmente interessantes. Elas soam não como "ainda é cedo", mas como "já é útil, mas apenas com um contorno de engenharia devidamente projetado".
Isso inclui 'Agent Skills', 'feedback sensors for coding agents', 'progressive context disclosure', 'sandboxed execution for coding agents' e 'semantic layer'. Em Assess, a Thoughtworks relaciona 'architecture drift reduction with LLMs', 'context graph', 'measuring collaboration quality with coding agents', MITRE ATLAS, 'role-based contextual isolation in RAG', 'skills as executable onboarding documentation', 'team of coding agents' e 'LLM evaluation using semantic entropy'.
À primeira vista, este é um conjunto heterogêneo. Mas, na verdade, quase todos esses elementos trabalham para o mesmo objetivo: tornar o comportamento do agente mais gerenciável, explicável e sustentável. E este é, talvez, o critério mais importante para ler o Radar hoje: olhar não para a "magia" da ferramenta, mas para como ela ajuda a construir um ambiente de engenharia controlado.
O que manter em Caution
A zona Caution no Vol. 34 é quase mais importante que a zona Adopt. É aqui que a Thoughtworks retorna a conversa sobre IA do nível de excitação do mercado para o nível de sobriedade da engenharia.
Em Caution, estão 'agent instruction bloat', 'AI-accelerated shadow IT', 'codebase cognitive debt', 'coding agent swarms', 'coding throughput as a measure of productivity', 'ignoring durability in agent workflows' e 'MCP by default'. A própria lista já diz muito. Não se trata de que os sistemas 'agentic' não sejam necessários, mas de que, sem disciplina, eles aumentam muito rapidamente a carga operacional e arquitetônica mais rápido do que a equipe consegue entendê-la.
O item sobre 'MCP by default' é especialmente revelador. O pensamento aqui é maduro e útil: protocolos e interfaces formais fazem sentido onde contratos rígidos, limites de acesso gerenciados e integração reproduzível são realmente necessários. Mas transformá-los em uma resposta universal para qualquer combinação de sistemas significa aumentar desnecessariamente o imposto de abstração.
Como a profissão está mudando
A engenharia de software agora parece um pouco menos com a profissão de escrever código e um pouco mais com a profissão de projetar um ambiente de mudança. Esta é uma mudança que já pode ser descrita de forma bastante prática.
Primeiro, o engenheiro projeta não apenas o código, mas também o ambiente ao redor do código: contexto, regras de acesso, 'quality gates', contornos de feedback e modos de escalonamento.
Em segundo lugar, novos artefatos de engenharia aparecem: 'context architecture', 'shared instructions', 'agent access model', 'eval catalog', 'harness templates' e 'audit trail' sobre o uso de ferramentas. Esses artefatos seguem diretamente o conjunto de práticas e técnicas que a Thoughtworks destaca em Adopt, Trial e Assess.
Em terceiro lugar, as funções de trabalho dentro da equipe estão mudando. Não necessariamente na forma de novas posições, mas certamente na forma de novas áreas de responsabilidade: alguém deve ser responsável pelo contexto, alguém pelo contorno de gerenciamento, alguém pela política de acesso e qualidade dos 'agent workflows'.
Em quarto lugar, a aceleração não pode mais ser avaliada apenas pelo volume de código produzido. A Thoughtworks adverte diretamente contra 'coding throughput as a measure of productivity' e, ao mesmo tempo, coloca as métricas DORA em Adopt. Isso significa uma conclusão gerencial bastante rígida: se a IA realmente melhora o desenvolvimento, isso deve se manifestar em 'lead time', 'deployment frequency', MTTR, 'change failure rate' e 'rework rate', e não em estatísticas bonitas de LOC geradas.
O que fazer nos próximos dias
Se traduzirmos o relatório para a prática, a lista de prioridades é a seguinte:
Introduzir instruções compartilhadas (shared instructions) como um ativo da equipe.
Implantar um contorno de gerenciamento mínimo para o agente que gera código:
contrato de tarefa (task contract),
contexto permitido (allowed context),
ações permitidas (allowed actions),
barreiras de qualidade (quality gates),
condições de parada (stop conditions),
log de auditoria (audit trail).
Mudar de 'prompt-first' (pensamento que começa com um prompt) para 'context-first' (pensamento que começa com o contexto).
Colocar o modelo de acesso do agente (agent access model) em um artefato de engenharia separado.
Adicionar 'feedback sensors' (sensores de feedback) ao ciclo de vida da mudança (change lifecycle).
Parar de medir o sucesso da IA pela quantidade de LOC geradas (linhas de código geradas).
Para segurança, use a arquitetura de confiança zero (zero trust architecture) e a lente de ameaças no estilo ATLAS (modelo de ameaças na lógica ATLAS), e não apenas a isolamento de execução otimista (sandbox otimista).
Conclusão
O Thoughtworks Technology Radar 34 é importante não porque lista itens da moda, mas porque fixa o amadurecimento da conversa de engenharia em torno da IA.
Esta edição mostra: o desenvolvimento de software após a transição para sistemas 'agentic' não é mais apenas programação com um modelo de apoio. Agora, trata-se de projetar um ambiente em que pessoas e agentes alteram o sistema em conjunto, o contexto é gerenciado como um recurso arquitetônico, as instruções se tornam um ativo comum da equipe, a segurança considera inicialmente a automação com amplos poderes, e os contornos de gerenciamento e os meios de feedback entram no conjunto usual de práticas de engenharia.
Portanto, o futuro aqui não se parece com a simplificação da engenharia, mas com sua complicação na direção certa: mais disciplina de engenharia, contexto melhor projetado, regras organizadas de forma mais inteligente e um preço muito maior para o erro na definição da tarefa.
A inteligência artificial realmente acelerou o desenvolvimento. Mas a principal tese do Vol. 34 é outra: agora é necessário acelerar não apenas a liberação de mudanças, mas também a maturidade da prática de engenharia.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Thoughtworks Technology Radar Vol. 34: O que está em alta e como a engenharia de software está mudando após a virada 'agentic'
Cada nova onda de discussão sobre inteligência artificial (IA) inicialmente provoca euforia, mas depois leva a uma avaliação mais sóbria das consequências e dos custos acumulados. Primeiro, vemos demonstrações espetaculares: um agente escreve código, um LLM resume requisitos, as ferramentas se tornam "mais inteligentes", e as integrações parecem desaparecer sob uma camada de novos protocolos e interfaces. Depois, vem a realidade do trabalho: as instruções se expandem, os direitos de acesso se tornam muito amplos, a revisão de código se transforma em análise de decisões alheias, e a qualidade do sistema começa a ser determinada não apenas pelo modelo, mas por todo o ambiente ao seu redor.
É por isso que o Thoughtworks Technology Radar Vol. 34 é importante não como mais um mapa de tendências, mas como um sinal de mudança na ótica da engenharia. Esta edição não se resume à tese "IA muda tudo". Ela mostra que a engenharia de software já está se afastando da discussão sobre as capacidades do modelo para o projeto do ambiente em que pessoas, agentes, ferramentas e contornos de controle alteram o sistema em conjunto.
O Radar ainda mantém sua estrutura habitual: quadrantes, anéis de maturidade, divisão em técnicas, ferramentas, plataformas, linguagens e frameworks. Mas na 34ª edição, o mais importante não é o próprio esquema, mas os quatro temas em torno dos quais toda a edição é construída. A Thoughtworks destaca diretamente a complexidade da avaliação de tecnologias no mundo 'agentic', o retorno aos princípios básicos de engenharia, os riscos de agentes 'permission-hungry' e a necessidade de restringir mais rigidamente os 'coding agents'.
Por que esta edição é importante
O Technology Radar sempre teve seu ponto forte: ele não tenta adivinhar o futuro, mas fornece uma linguagem para avaliar as mudanças tecnológicas. Na 34ª edição, essa abordagem se torna especialmente importante, porque não apenas a paisagem tecnológica começa a quebrar, mas também os próprios critérios para sua avaliação.
A Thoughtworks formula isso de forma bastante clara: a IA muda não apenas o conjunto de tecnologias usadas, mas também os critérios pelos quais tentamos entendê-las e compará-las. No ecossistema de ferramentas 'agentic', a ambiguidade semântica está crescendo muito rapidamente: há mais termos do que conteúdo estável por trás deles. Portanto, a mesma abordagem hoje pode ser chamada de desenvolvimento baseado em especificação, projeto de contornos de teste, orquestração de agentes ou composição de habilidades - e essas diferenças nem sempre esclarecem a essência, mas a mascaram.
Isso quebra o ciclo habitual do Radar. Se você esperar pela maturidade, as recomendações ficarão desatualizadas rapidamente. Se você reagir muito cedo, o ruído temporário entrará na imagem, e não um sinal estável.
Daí a principal conclusão da edição: a engenharia terá que trabalhar em um mundo onde a velocidade de surgimento de novas ferramentas aumentou drasticamente, e a transparência, a capacidade de manutenção e a capacidade da equipe de entender o que ela está construindo não acompanham essa velocidade.
Quatro sinais
Avaliar tecnologias se tornou mais difícil
Esta não é apenas uma história sobre o crescimento do número de startups de IA. A Thoughtworks escreve diretamente que a IA reduziu o limite para a criação de 'developer tooling' e lançou um fluxo constante de novas ferramentas, algumas das quais são muito jovens para serem avaliadas de forma sensata.
O problema não é apenas a quantidade. Tornou-se mais difícil distinguir uma nova ideia de engenharia de uma abordagem antiga com um novo nome, uma ferramenta viável de uma demonstração bem-sucedida e uma prática sustentável de uma onda curta de interesse. A isso se soma a questão da manutenção: se uma ferramenta pode ser montada rapidamente com a ajuda de um agente, quem e com base em que irá mantê-la em seis meses?
Em tal ambiente, há cada vez menos sentido em discutir a novidade e cada vez mais - sobre as propriedades de operação. A capacidade de manutenção, o modelo de segurança, a sustentabilidade, a presença de uma comunidade e a confirmação de que a prática funciona fora de alguns cenários demonstrativos são realmente importantes. Esta é uma das razões pelas quais a zona Caution está se fortalecendo no Radar.
Os antigos princípios de engenharia se tornaram mais valiosos
Um dos temas mais fortes da edição é "Mantendo os princípios, abandonando os modelos". A Thoughtworks na verdade diz algo simples: quanto mais rápido a IA ajuda a produzir código e soluções, mais importantes se tornam novamente as práticas básicas de engenharia - da arquitetura de confiança zero e testabilidade às métricas DORA e código limpo. A razão é que, em tal ambiente, o código aparece mais rápido do que a equipe consegue entendê-lo de verdade, razão pela qual a dívida de compreensão da base de código se acumula.
Portanto, a IA não cancela a disciplina de engenharia, mas aumenta seu custo. A velocidade de geração de código está crescendo, mas é por isso que as práticas que reduzem a ambiguidade, aumentam a observabilidade e ajudam a distinguir um sistema em funcionamento de uma imitação plausível de trabalho estão se tornando mais caras novamente.
'Permission-hungry agents' - já é uma tarefa de arquitetura de segurança
O terceiro tema da edição soa como um aviso direto. A Thoughtworks escreve que os agentes mais úteis são precisamente aqueles que precisam de amplo acesso a dados, canais externos e sistemas de trabalho reais. Este é o problema: o valor do agente puxa diretamente a expansão dos poderes.
Ao mesmo tempo, os mecanismos de proteção não conseguem acompanhar as ambições. A injeção de prompt continua sendo um problema não resolvido, o comportamento do modelo permanece inconsistente, e a conclusão bem-sucedida de uma tarefa uma vez não garante a repetibilidade nem na segunda, nem na centésima. A Thoughtworks enfatiza separadamente que os agentes podem encontrar maneiras inesperadas de exfiltração de dados, alterar o que não deveriam ter acesso e diluir os 'approve/deny chokepoints' habituais, mesmo sem más intenções.
Daí a conclusão bastante prática. Um sistema 'agentic' seguro, na opinião da Thoughtworks, deve ser construído não em torno de um único monólito "inteligente", mas em torno de um contorno de agentes mais limitados, com o princípio do menor privilégio, proteção em camadas, monitoramento forte e controle rígido, arquitetura de confiança zero como a norma básica. Não é por acaso que a arquitetura de confiança zero (zero trust architecture) nesta edição está em Adopt.
'Coding agents' precisam ser incluídos no contorno de gerenciamento
O quarto tema, talvez o mais útil para a prática diária de engenharia. A Thoughtworks escreve que, à medida que a qualidade dos 'coding agents' aumenta, as equipes estão tentando cada vez mais remover a pessoa do contorno de trabalho, e é por isso que começam a investir em contornos de gerenciamento.
A lógica aqui é simples. Antes da geração de código, são necessários 'feedforward controls', que aumentam a probabilidade de um primeiro passo correto. Após a geração, são necessários 'feedback controls', que permitem que o agente se corrija antes da revisão humana.
Isso ecoa bem com o artigo recente de Birgitta Böckeler sobre harness engineering, onde tal contorno é descrito como uma combinação de direcionamento antecipado e feedback: os mecanismos de direcionamento aumentam a probabilidade de uma primeira ação correta, e os sensores ajudam o agente a se corrigir antes mesmo da verificação humana.
No Radar, essa lógica se manifesta de forma muito consistente: 'Agent Skills' permitem formatar instruções e acordos de forma modular e carregá-los conforme necessário; OpenSpec e outras abordagens baseadas em especificação estruturam o fluxo de trabalho antes mesmo da geração de código; 'feedback sensors for coding agents' incorporam compiladores, linters, verificações de tipos, testes e outras barreiras de qualidade determinísticas diretamente no ciclo de trabalho do agente; e as abordagens para reduzir a deriva arquitetônica mostram que verificações semânticas podem ser adicionadas além das regras formais.
É aqui que se vê uma mudança importante de 2026. Estamos discutindo não apenas a capacidade do modelo de escrever código, mas as condições sob as quais o agente pode ser confiável para realizar essa ação.
O que levar para o trabalho
Da 34ª edição, já é possível levar para a prática várias direções.
Context engineering. A Thoughtworks o traduz da categoria de 'optimisation tactic' para a categoria de 'foundational architectural concern' para sistemas de IA modernos. O contexto aqui é entendido não como "texto próximo à solicitação", mas como um ambiente de informação projetado para o agente. Em vez de um grande prompt, é oferecido 'progressive context disclosure': primeiro, um índice leve do conhecimento disponível, depois, o carregamento apenas do que realmente é necessário durante o trabalho.
Curated shared instructions for software teams. A Thoughtworks chama de anti-padrão a situação em que cada desenvolvedor escreve seus próprios prompts do zero. As instruções devem se tornar um ativo de engenharia comum da equipe e ser incorporadas em modelos de serviços, repositórios e 'reference applications' por meio de arquivos como AGENTS.md, CLAUDE.md ou regras específicas do projeto. Esta é uma mudança organizacional importante: as configurações úteis para trabalhar com IA deixam de viver em notas pessoais e entram na entrega básica do projeto.
Structured output from LLMs. A Thoughtworks já considera isso um 'sensible default' para cenários em que as respostas do modelo são processadas por software. O valor aqui não está no amor pelo JSON como tal, mas na redução da ambiguidade e na capacidade de construir contratos verificáveis por máquina sobre a resposta. Quando isso é adicionado a 'deterministic quality gates', obtém-se um contorno de trabalho no qual o agente pode ser rapidamente e formalmente mostrado onde ele ultrapassou os limites permitidos.
Zero trust architecture - esta não é mais uma prática opcional do mundo da segurança, mas uma resposta básica de engenharia a sistemas autônomos com amplos poderes. Quanto maior a autonomia do agente, mais perigosa é a confiança por padrão. Portanto, 'identity-based control', 'least privilege', 'continuous verification' e observabilidade devem ser estabelecidos como propriedades obrigatórias do sistema, e não como uma atualização tardia.
O que experimentar com cautela
As categorias Trial e Assess nesta edição são especialmente interessantes. Elas soam não como "ainda é cedo", mas como "já é útil, mas apenas com um contorno de engenharia devidamente projetado".
Isso inclui 'Agent Skills', 'feedback sensors for coding agents', 'progressive context disclosure', 'sandboxed execution for coding agents' e 'semantic layer'. Em Assess, a Thoughtworks relaciona 'architecture drift reduction with LLMs', 'context graph', 'measuring collaboration quality with coding agents', MITRE ATLAS, 'role-based contextual isolation in RAG', 'skills as executable onboarding documentation', 'team of coding agents' e 'LLM evaluation using semantic entropy'.
À primeira vista, este é um conjunto heterogêneo. Mas, na verdade, quase todos esses elementos trabalham para o mesmo objetivo: tornar o comportamento do agente mais gerenciável, explicável e sustentável. E este é, talvez, o critério mais importante para ler o Radar hoje: olhar não para a "magia" da ferramenta, mas para como ela ajuda a construir um ambiente de engenharia controlado.
O que manter em Caution
A zona Caution no Vol. 34 é quase mais importante que a zona Adopt. É aqui que a Thoughtworks retorna a conversa sobre IA do nível de excitação do mercado para o nível de sobriedade da engenharia.
Em Caution, estão 'agent instruction bloat', 'AI-accelerated shadow IT', 'codebase cognitive debt', 'coding agent swarms', 'coding throughput as a measure of productivity', 'ignoring durability in agent workflows' e 'MCP by default'. A própria lista já diz muito. Não se trata de que os sistemas 'agentic' não sejam necessários, mas de que, sem disciplina, eles aumentam muito rapidamente a carga operacional e arquitetônica mais rápido do que a equipe consegue entendê-la.
O item sobre 'MCP by default' é especialmente revelador. O pensamento aqui é maduro e útil: protocolos e interfaces formais fazem sentido onde contratos rígidos, limites de acesso gerenciados e integração reproduzível são realmente necessários. Mas transformá-los em uma resposta universal para qualquer combinação de sistemas significa aumentar desnecessariamente o imposto de abstração.
Como a profissão está mudando
A engenharia de software agora parece um pouco menos com a profissão de escrever código e um pouco mais com a profissão de projetar um ambiente de mudança. Esta é uma mudança que já pode ser descrita de forma bastante prática.
Primeiro, o engenheiro projeta não apenas o código, mas também o ambiente ao redor do código: contexto, regras de acesso, 'quality gates', contornos de feedback e modos de escalonamento.
Em segundo lugar, novos artefatos de engenharia aparecem: 'context architecture', 'shared instructions', 'agent access model', 'eval catalog', 'harness templates' e 'audit trail' sobre o uso de ferramentas. Esses artefatos seguem diretamente o conjunto de práticas e técnicas que a Thoughtworks destaca em Adopt, Trial e Assess.
Em terceiro lugar, as funções de trabalho dentro da equipe estão mudando. Não necessariamente na forma de novas posições, mas certamente na forma de novas áreas de responsabilidade: alguém deve ser responsável pelo contexto, alguém pelo contorno de gerenciamento, alguém pela política de acesso e qualidade dos 'agent workflows'.
Em quarto lugar, a aceleração não pode mais ser avaliada apenas pelo volume de código produzido. A Thoughtworks adverte diretamente contra 'coding throughput as a measure of productivity' e, ao mesmo tempo, coloca as métricas DORA em Adopt. Isso significa uma conclusão gerencial bastante rígida: se a IA realmente melhora o desenvolvimento, isso deve se manifestar em 'lead time', 'deployment frequency', MTTR, 'change failure rate' e 'rework rate', e não em estatísticas bonitas de LOC geradas.
O que fazer nos próximos dias
Se traduzirmos o relatório para a prática, a lista de prioridades é a seguinte:
Introduzir instruções compartilhadas (shared instructions) como um ativo da equipe.
Implantar um contorno de gerenciamento mínimo para o agente que gera código:
contrato de tarefa (task contract),
contexto permitido (allowed context),
ações permitidas (allowed actions),
barreiras de qualidade (quality gates),
condições de parada (stop conditions),
log de auditoria (audit trail).
Mudar de 'prompt-first' (pensamento que começa com um prompt) para 'context-first' (pensamento que começa com o contexto).
Colocar o modelo de acesso do agente (agent access model) em um artefato de engenharia separado.
Adicionar 'feedback sensors' (sensores de feedback) ao ciclo de vida da mudança (change lifecycle).
Parar de medir o sucesso da IA pela quantidade de LOC geradas (linhas de código geradas).
Para segurança, use a arquitetura de confiança zero (zero trust architecture) e a lente de ameaças no estilo ATLAS (modelo de ameaças na lógica ATLAS), e não apenas a isolamento de execução otimista (sandbox otimista).
Conclusão
O Thoughtworks Technology Radar 34 é importante não porque lista itens da moda, mas porque fixa o amadurecimento da conversa de engenharia em torno da IA.
Esta edição mostra: o desenvolvimento de software após a transição para sistemas 'agentic' não é mais apenas programação com um modelo de apoio. Agora, trata-se de projetar um ambiente em que pessoas e agentes alteram o sistema em conjunto, o contexto é gerenciado como um recurso arquitetônico, as instruções se tornam um ativo comum da equipe, a segurança considera inicialmente a automação com amplos poderes, e os contornos de gerenciamento e os meios de feedback entram no conjunto usual de práticas de engenharia.
Portanto, o futuro aqui não se parece com a simplificação da engenharia, mas com sua complicação na direção certa: mais disciplina de engenharia, contexto melhor projetado, regras organizadas de forma mais inteligente e um preço muito maior para o erro na definição da tarefa.
A inteligência artificial realmente acelerou o desenvolvimento. Mas a principal tese do Vol. 34 é outra: agora é necessário acelerar não apenas a liberação de mudanças, mas também a maturidade da prática de engenharia.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
