Técnicas

Conformidade contínua é a prática de garantir que os processos e tecnologias de desenvolvimento de software atendam aos padrões regulatórios e de segurança de forma contínua por meio da automação. As verificações manuais de conformidade podem retardar o desenvolvimento e introduzir erros humanos, enquanto as verificações e auditorias automatizadas fornecem feedback mais rápido, evidências mais claras e relatórios simplificados. Ao integrar ferramentas de política como código, como o Open Policy Agent, e ao gerar SBOMs dentro dos pipelines de CD — alinhados às diretrizes do SLSA — os times podem detectar e resolver problemas de conformidade antecipadamente. Programar regras e melhores práticas impõe padrões de forma consistente entre os times, sem criar gargalos. O OSCAL também se mostra promissor como um framework para automatizar a conformidade em escala. As práticas e ferramentas para conformidade contínua estão agora maduras o suficiente para que sejam tratadas como um padrão sensato, e é por isso que movemos nossa recomendação para Adote. O uso crescente de IA na programação — e o risco associado de complacência com o código gerado por IA — torna a incorporação da conformidade no processo de desenvolvimento mais crítica do que nunca.

Para times que usam ativamente IA na entrega de software, o próximo passo é ir além do prompting individual em direção a instruções curadas para times de software. Essa prática ajuda a aplicar a IA de forma eficaz em todas as tarefas de entrega — não apenas na programação — compartilhando instruções comprovadas e de alta qualidade. A maneira mais direta de implementar isso é comitando arquivos de instrução, como um AGENTS.md, diretamente no repositório do seu projeto. A maioria das ferramentas de programação com IA — incluindo Cursor, Windsurf e Claude Code — suporta o compartilhamento de instruções por meio de comandos de barra ou workflows customizados. Para tarefas que não envolvem programação, você pode configurar bibliotecas de prompts em toda a organização, prontas para uso. Essa abordagem sistemática permite a melhoria contínua: assim que um prompt é refinado, todo o time se beneficia, garantindo acesso consistente às melhores instruções de IA.

Os Git hooks existem há muito tempo, mas sentimos que ainda são subutilizados. O surgimento da programação assistida por IA e agentes aumentou o risco de comitar segredos ou código problemático acidentalmente. Embora existam muitos mecanismos para a validação de código, como a integração contínua, os hooks de pré-commit são uma salvaguarda simples e eficaz que mais times deveriam adotar. No entanto, sobrecarregar os hooks com verificações lentas pode desencorajar as pessoas desenvolvedoras de usá-los, então é melhor mantê-los mínimos e focados nos riscos que são mais eficazmente capturados nesta fase do workflow, como a varredura de segredos.

Nos últimos meses, vimos evidências claras de que o uso de IA generativa para entender bases de código legadas pode acelerar significativamente a compreensão de sistemas grandes e complexos. Ferramentas como Cursor, Claude Code, Copilot, Windsurf, Aider, Cody, Swimm, Unblocked e PocketFlow-Tutorial-Codebase-Knowledge ajudam pessoas desenvolvedoras a revelarem regras de negócio, resumirem lógicas e identificarem dependências. Usadas em conjunto com frameworks abertos e prompting direto em LLMs, elas reduzem drasticamente o tempo necessário para entender bases de código legadas. Nossa experiência em múltiplos clientes mostra que a compreensão de sistemas legados assistida por IA generativa é agora um padrão prático, em vez de um experimento. O esforço de configuração varia, particularmente para abordagens avançadas como o GraphRAG, e tende a escalar com o tamanho e a complexidade da base de código sendo analisada. Apesar disso, o impacto na produtividade é consistente e substancial. A GenAI tornou-se uma parte essencial de como exploramos e entendemos sistemas legados.

AGENTS.md é um formato comum para fornecer instruções a agentes de programação de IA que trabalham em um projeto. Essencialmente um arquivo README para agentes, ele não tem campos ou formatação obrigatórios além do Markdown, confiando na capacidade dos agentes de programação baseados em LLM de interpretar orientações escritas e legíveis por humanos. Usos típicos incluem dicas sobre o uso de ferramentas no ambiente de programação, instruções de teste e práticas preferenciais para o gerenciamento de commits. Embora as ferramentas de IA suportem vários métodos para a engenharia de contexto, o valor do AGENTS.md reside na criação de uma convenção simples para um arquivo que atua como ponto de partida.

Migrações de código assumem muitas formas — desde reescritas de linguagem até atualizações de dependência ou framework — e raramente são simples, muitas vezes exigindo meses de esforço manual. Um de nossos times, ao atualizar a versão do seu framework .NET, experimentou o uso de IA para encurtar o processo. No passado, publicamos sobre o OpenRewrite, uma ferramenta de refatoração determinística e baseada em regras. O uso isolado de IA para tais atualizações muitas vezes se mostrou caro e propenso a interações sinuosas. Em vez disso, a equipe combinou pipelines tradicionais de atualização com assistentes agênticos de programação para gerenciar transições complexas. Em vez de delegar uma atualização completa, eles dividiram o processo em passos menores e verificáveis: analisar erros de compilação, gerar diffs de migração e validar testes iterativamente. Essa abordagem híbrida posiciona os agentes de de programação baseados em IA como colaboradores pragmáticos na manutenção de software. Exemplos da indústria, como a migração em grande escala de int32 para int64 do Google, refletem uma tendência semelhante. Embora nossos resultados sejam mistos em termos de economia de tempo mensurável, o potencial para reduzir o trabalho repetitivo da pessoa desenvolvedora é claro e vale a exploração contínua.

Liquid clustering é uma técnica para tabelas do Delta Lake que funciona como alternativa ao particionamento e ao Z-ordering. Historicamente, otimizar tabelas Delta para desempenho de leitura exigia a definição de chaves de partição e Z-order no momento da criação da tabela, com base em padrões de consulta esperados. Modificar essas chaves posteriormente exigia a reescrita completa dos dados. Em contraste, clustering utiliza um algoritmo baseado em árvore para agrupar os dados segundo chaves designadas, que podem ser alteradas incrementalmente sem precisar reescrever todos os dados. Isso proporciona maior flexibilidade para suportar diversos padrões de consulta, reduzindo os custos de computação e melhorando o desempenho de leitura. Além disso, o Databricks Runtime para Delta Lake oferece suporte ao automatic liquid clustering, que analisa workloads de consulta históricos, identifica colunas ideais e agrupa os dados de acordo. Tanto usuários do Delta Lake standalone quanto do Databricks Runtime podem aproveitar o Liquid Clustering para otimizar o desempenho de leitura.

Usamos a frase prototipagem de UI de autoatendimento com GenAI para descrever uma técnica emergente onde ferramentas como o Claude Code, Figma Make, Miro AI e v0 permitem que gerentes de produto gerem protótipos interativos e testáveis por pessoas usuárias diretamente a partir de prompts de texto. Em vez de criar wireframes manualmente, os times podem gerar artefatos funcionais de HTML, CSS e JS em minutos — oferecendo a velocidade de um esboço, mas com interatividade real e maior fidelidade. Esses protótipos "descartáveis" trocam o polimento pelo aprendizado rápido, tornando-os ideais para validação inicial durante as design sprints. No entanto, uma maior fidelidade pode levar a um foco equivocado em pequenos detalhes ou a expectativas irreais sobre o esforço de produção — tornando o enquadramento claro e o gerenciamento de expectativas essenciais. Usada em conjunto com a pesquisa com pessoas usuárias, essa técnica acelera a descoberta, transformando ideias abstratas em experiências tangíveis para que as pessoas usuárias possam reagir. No entanto, os times devem ter o cuidado de não deixar que essas ferramentas substituam o processo de pesquisa em si. Quando bem-feita, a prototipagem de autoatendimento encurta os ciclos de feedback, diminui as barreiras para quem não é designer e ajuda os times a iterarem rapidamente, mantendo um equilíbrio saudável entre velocidade e qualidade.

Saída estruturada de LLMs é a prática de restringir um modelo de linguagem de grande porte (LLM) para gerar respostas em um formato predefinido — como JSON ou uma classe de programação específica. Essa técnica é essencial para construir aplicações confiáveis e de nível de produção, transformando o texto tipicamente imprevisível do LLM em um contrato de dados determinístico e legível por máquina. Com base no uso bem-sucedido em produção, estamos promovendo esta técnica da fase de Avaliação (Assess) para a fase de Experimento (Trial). As abordagens variam desde a formatação simples baseada em prompt e saídas estruturadas nativas do modelo até métodos de decodificação restrita mais robustos, usando ferramentas como Outlines e Instructor, que aplicam máquinas de estados finitos para garantir uma saída válida. Temos usado com sucesso essa técnica para extrair dados complexos e não estruturados de diversos tipos de documentos e convertê-los em JSON estruturado para a lógica de negócio downstream.

Test && Comitar || Revert (TCR) é um workflow de programação derivado do desenvolvimento orientado a testes que incentiva passos muito pequenos e contínuos por meio de uma regra simples: após cada alteração, se os testes passarem, as alterações são comitadas; se falharem, as alterações são revertidas. Implementar o TCR é simples: você só precisa definir um script que automatize esse ciclo em sua base de código. Originalmente introduzido em um artigo canônico de Kent Beck, descobrimos que o TCR reforça práticas de programação positivas como YAGNI e KISS. Vale a pena avaliá-lo à medida que experimentamos novos workflows para construir software usando GenAI.

No Radar anterior, os testes de UI impulsionados por IA focavam, principalmente, em testes exploratórios, onde notamos que o não-determinismo dos LLMs poderia introduzir instabilidade. Com o surgimento do MCP, agora estamos vendo os principais frameworks de teste de UI como Playwright e Selenium introduzirem seus próprios servidores MCP (playwright-mcp, mcp-selenium). Eles fornecem uma confiável automação de navegador por meio de suas tecnologias nativas, permitindo que os assistentes de programação gerem testes de UI confiáveis em Playwright ou Selenium. Embora os testes de UI impulsionados por IA permaneçam um espaço em rápida evolução, — a versão mais recente do Playwright, por exemplo, introduziu os Playwright Agents — estamos entusiasmadas com esses desenvolvimentos e ansiosas para ver mais orientações práticas e experiência de campo surgirem.

No passado, publicamos sobre a técnica de modelos de serviço personalizados, que ajudou organizações na adoção de microsserviços, fornecendo padrões sensatos para o bootstrap de novos serviços e integrando-os de forma transparente com a infraestrutura existente. Com o tempo, no entanto, o desvio de código (code drift) entre esses templates e os serviços existentes tende a crescer à medida que novas dependências, frameworks e padrões arquitetônicos surgem. Para manter boas práticas e consistência arquitetônica — especialmente na era dos agentes de programação — temos experimentado ancorar agentes de programação a uma aplicação de referência. Esse padrão orienta os agentes de código generativo, fornecendo uma aplicação de referência viva e compilável em vez de exemplos de prompt estáticos. Um servidor de Model Context Protocol (MCP) expõe tanto o código do template de referência quanto os diffs de commits, permitindo que os agentes detectem desvios e proponham correções. Essa abordagem transforma templates estáticos em projetos vivos e adaptáveis que a IA pode referenciar de forma inteligente — mantendo a consistência, reduzindo a divergência e melhorando o controle sobre a geração de arquivos pela IA à medida que os sistemas evoluem.

Engenharia de contexto é o design sistemático e a otimização da informação fornecida a um modelo de linguagem de grande porte durante a inferência para produzir de forma confiável a saída desejada. Ela envolve a estruturação, seleção e sequenciamento de elementos contextuais — como prompts, dados recuperados, memória, instruções e sinais ambientais — para que as camadas internas do modelo operem em um estado ótimo. Diferente da engenharia de prompt, que foca apenas na formulação dos prompts, a engenharia de contexto considera toda a configuração do contexto: como o conhecimento relevante, as instruções e o contexto prévio são organizados e entregues para alcançar os resultados mais eficazes. Hoje, as pessoas de engenharia usam uma gama de técnicas discretas que podem ser agrupadas em três áreas: a configuração de contexto abrange táticas de curadoria, como o uso de prompts de sistema mínimos, exemplos few-shot canônicos e ferramentas eficientes em tokens para ações decisivas. O gerenciamento de contexto para tarefas de longo prazo lida com janelas de contexto finitas por meio da sumarização de contexto, anotações estruturadas para persistir memórias externas e arquiteturas de sub-agentes para isolar e resumir subtarefas complexas. A recuperação dinâmica de informação depende da recuperação de contexto just-in-time (JIT), onde os agentes carregam autonomamente dados externos apenas quando são imediatamente relevantes, maximizando a eficiência e a precisão.

IA generativa para engenharia direta é uma técnica emergente para modernizar sistemas legados por meio de descrições de bases de código legadas geradas por IA. Ela introduz um passo explícito focado no que o código legado faz (sua especificação), enquanto oculta deliberadamente como ele está implementado atualmente. Isso se relaciona com o desenvolvimento guiado por especificação, mas é aplicado especificamente à modernização de sistemas legados. Ao gerar e iterar sobre descrições funcionais antes de reescrever o código, os times podem usar a IA generativa para revelar lógicas ocultas, dependências e casos excepcionais que, de outra forma, poderiam ser ignorados. Enfatizar o espaço do problema em vez do sistema existente também permite que os modelos de IA generativa explorem soluções mais criativas e escaláveis. O workflow segue um ciclo de engenharia reversa → design/solução → engenharia direta, o que permite que tanto humanos quanto agentes de IA raciocinem em um nível mais alto antes de se comprometerem com uma implementação. Na Thoughtworks, estamos vendo múltiplos times aplicarem essa abordagem com sucesso para acelerar a reescrita de sistemas legados. O objetivo não é ocultar completamente os detalhes da implementação, mas introduzir uma abstração temporária que ajuda os times e os agentes a explorarem alternativas sem serem limitados pela estrutura atual. Essa técnica está mostrando resultados promissores na produção de código mais limpo, de fácil manutenção e pronto para o futuro, ao mesmo tempo que reduz o tempo gasto para entender as implementações existentes.

O GraphQL como padrão de acesso a dados para LLMs é uma abordagem emergente para criar uma camada de acesso a dados uniforme e amigável para modelos, que aprimora a engenharia de contexto. Ele permite que os times exponham dados estruturados e consultáveis sem conceder aos modelos acesso direto ao banco de dados. Diferente das APIs REST, que tendem a buscar dados em excesso ou a exigir novos endpoints ou filtros para cada caso de uso, o GraphQL permite que o modelo recupere apenas os dados de que precisa — reduzindo o ruído, melhorando a relevância do contexto e cortando o uso de tokens. Um schema GraphQL bem definido também fornece metadados que os LLMs podem usar para raciocinar sobre as entidades e os relacionamentos disponíveis, permitindo consultas dinâmicas e conscientes do schema para casos de uso com agentes. Esse padrão oferece um meio-termo seguro entre REST e SQL, equilibrando os controles de governança com o acesso flexível. No entanto, a abordagem depende de schemas bem estruturados e nomes de campo significativos. Interpretar a semântica do schema e navegar por estruturas complexas continuam sendo desafios — e o que é difícil para as pessoas raciocinarem, muitas vezes é igualmente difícil para os LLMs. Também é importante estar ciente dos vetores aumentados para ataques de DoS, bem como dos desafios típicos do GraphQL, como cache e versionamento.

Uma pergunta que nos fazem muito é "como podemos melhorar a forma como compartilhamos informações entre nossos times?" As técnicas para gerenciar o conhecimento organizacional continuam a evoluir, e uma perspectiva que consideramos valiosa vem do pensamento sistêmico: os conceitos de fluxos de conhecimento e estoques de conhecimento. Originalmente da economia, essa perspectiva incentiva os times a verem seu conhecimento organizacional como um sistema — estoques representando o conhecimento acumulado e fluxos representando como o conhecimento se move e evolui através da organização. Aumentar o fluxo de conhecimento externo para uma organização tende a impulsionar a inovação. Uma maneira comprovada para melhorar o fluxo é estabelecer comunidades de prática, que consistentemente mostram benefícios mensuráveis. Outra é buscar deliberadamente fontes diversas e externas de insight. À medida que as ferramentas de GenAI tornam os estoques de conhecimento existentes mais acessíveis, vale a pena lembrar que nutrir novas ideias e perspectivas externas é tão crucial quanto adotar novas tecnologias.

Usar um LLM como juiz — para avaliar a saída de outro sistema, geralmente um gerador baseado em LLM — tem chamado a atenção por seu potencial de oferecer avaliação automatizada e escalável em IA generativa. No entanto, estamos movendo este blip de Experimente para Avalie para refletir as complexidades e os riscos recém-reconhecidos. Embora essa técnica ofereça velocidade e escala, ela muitas vezes falha como um substituto confiável para o julgamento humano. As avaliações são propensas a viés de posição, viés de verbosidade e baixa robustez. Um problema mais sério é a contaminação de escala: quando o LLM como juiz é usado em pipelines de treinamento para modelagem de recompensa, ele pode introduzir um viés de auto-reforço — onde uma família de modelos favorece suas próprias saídas — e o vazamento de preferências, borrando a fronteira entre treinamento e teste. Essas falhas levaram a resultados super-ajustados que inflam as métricas de performance sem validade no mundo real. Há estudos que conduzem investigações mais rigorosas sobre esse padrão. Para combater essas falhas, estamos explorando técnicas aprimoradas, como o uso de LLMs como um júri (empregando múltiplos modelos para consenso) ou o raciocínio em cadeia de pensamento durante a avaliação. Embora esses métodos visam aumentar a confiabilidade, eles também aumentam o custo e a complexidade. Aconselhamos os times a tratar essa técnica com cautela — garantindo verificação humana, transparência e supervisão ética antes de incorporar juízes LLM em workflows críticos. A abordagem permanece poderosa, mas menos madura do que se acreditava anteriormente.

Recuperação de informação no dispositivo é uma técnica que permite que busca, consciência de contexto e geração aumentada por recuperação (RAG) rodem inteiramente nos dispositivos da pessoa usuária — mobile, desktop ou dispositivos de edge — priorizando a privacidade e a eficiência computacional. Ela combina um banco de dados local leve com um modelo otimizado para inferência no dispositivo. Uma implementação promissora une o sqlite-vec, uma extensão do SQLite que suporta busca vetorial dentro do banco de dados embarcado, com o EmbeddingGemma, um modelo de embedding de 300 milhões de parâmetros construído sobre a arquitetura Gemma 3. Otimizada para eficiência e ambientes com recursos restritos, essa combinação mantém os dados próximos ao edge, reduzindo a dependência de APIs na nuvem e melhorando a latência e a privacidade. Recomendamos que os times avaliem essa técnica para aplicações local-first e outros casos de uso onde a soberania de dados, a baixa latência e a privacidade são críticas.

SAIF (Secure AI Framework) é um framework desenvolvido pelo Google para fornecer um guia prático para o gerenciamento de riscos de segurança em IA. Ele aborda sistematicamente ameaças comuns, como envenenamento de dados (data poisoning) e injeção de prompt (prompt injection), por meio de um mapa de riscos claro, análise de componentes e estratégias práticas de mitigação. Consideramos seu foco na evolução nos riscos da construção de sistemas agênticos especialmente oportuno e valioso. O SAIF oferece um playbook conciso e acionável que os times podem usar para fortalecer as práticas de segurança para o uso de LLMs e aplicações impulsionadas por IA.

Como o custo e a complexidade operacional das malhas de serviço (service meshes) baseadas em sidecar persistem, estamos entusiasmadas em ver outra opção de malha de serviço sem sidecar surgir: o modo ambiente do Istio. O modo ambiente introduz uma arquitetura em camadas que separa as responsabilidades entre dois componentes principais: o proxy L4 por nó (ztunnel) e o proxy L7 por namespace (proxy Waypoint). O ztunnel garante que o tráfego L3 e L4 seja transportado de forma eficiente e segura. Ele potencializa o plano de dados ambiente buscando certificados para todas as identidades do nó e lida com o redirecionamento de tráfego de e para as cargas de trabalho habilitadas para o modo ambiente. O proxy Waypoint, um componente opcional do modo ambiente, permite recursos avançados do Istio, como gerenciamento de tráfego, segurança e observabilidade. Tivemos uma boa experiência com o modo ambiente em clusters de pequena escala e esperamos obter mais insights e melhores práticas em grande escala à medida que a adoção cresce.

Observamos um progresso constante no desenvolvimento de modelos de linguagem pequenos (SLMs) ao longo de vários volumes do Technology Radar. Com o crescente interesse na construção de soluções agênticas, estamos vendo cada vez mais evidências de que os SLMs podem potencializar agentes de AI de forma eficiente. A maioria dos workflows agênticos atuais está focada em tarefas repetitivas e de escopo restrito que não exigem raciocínio avançado, tornando-os uma boa combinação para os SLMs. Os avanços contínuos em SLMs como Phi-3, SmolLM2 e DeepSeek sugerem que eles oferecem capacidade suficiente para essas tarefas — com os benefícios adicionais de menor custo, latência reduzida e menor consumo de recursos em comparação com os LLMs. Vale a pena considerar os SLMs como a escolha padrão para workflows agênticos, reservando os LLMs maiores e mais intensivos em recursos apenas quando necessário.

Desenvolvimento orientado por especificação é uma abordagem emergente para workflows de programação assistidos por IA. Embora a definição do termo ainda esteja evoluindo, ele geralmente se refere a fluxos de trabalho que começam com uma especificação funcional estruturada e, em seguida, avançam por várias etapas para dividi-la em partes menores, soluções e tarefas. A especificação pode assumir diferentes formas — um único documento, um conjunto de documentos ou artefatos estruturados que capturem diversos aspectos funcionais. Temos observado muitas pessoas desenvolvedoras adotarem esse estilo (inclusive criamos uma versão interna na Thoughtworks). Três ferramentas, em particular, vêm explorando interpretações distintas do desenvolvimento orientado por especificação. O Kiro, da Amazon, orienta as pessoas usuárias por três estágios do fluxo — requisitos, design e criação de tarefas. O spec-kit, do GitHub, segue um processo semelhante em três etapas, mas adiciona uma orquestração mais rica, prompts configuráveis e uma “constituição” que define princípios imutáveis que devem ser sempre seguidos. Já o Tessl Framework (ainda em beta privado em setembro de 2025) adota uma abordagem mais radical, na qual a própria especificação se torna o artefato principal, em vez do código. Consideramos esse espaço fascinante, embora os workflows ainda sejam complexos e opinativos. Essas ferramentas se comportam de maneiras muito diferentes dependendo do tamanho e do tipo da tarefa; algumas geram arquivos de especificação longos e difíceis de revisar e, quando produzem PRDs ou histórias de usuário, nem sempre fica claro quem é o usuário final. Podemos estar reaprendendo uma lição amarga: que a elaboração manual de regras detalhadas para a IA, no fim das contas, não é escalável.

Time de agentes de programação refere-se a uma técnica na qual uma pessoa desenvolvedora orquestra múltiplos agentes de programação de IA, cada um com um papel distinto — por exemplo, arquiteta ou arquiteto, especialista de back-end, tester — para colaborar em uma tarefa de desenvolvimento. Essa prática é suportada por ferramentas como Claude Code, Roo Code e Kilo Code, que permitem o uso de subagentes e múltiplos modos de operação. Com base no princípio comprovado de que atribuir papéis e personas específicos a LLMs melhora a qualidade da saída, a ideia é alcançar melhores resultados coordenando múltiplos agentes especializados para cada papel, em vez de depender de um único agente de propósito geral. O nível ideal de granularidade dos agentes ainda está sendo explorado, mas pode se estender além de simples mapeamentos um-para-um com os papéis tradicionais de um time. Essa abordagem representa uma mudança em direção a pipelines de desenvolvimento assistidos por IA, orquestrados e compostos por múltiplos passos.

GPUs e LPUs não são mais "apenas um monte de dispositivos". Elas são redes de chips fortemente acoplados cujo desempenho depende de onde o trabalho é alocado. Por exemplo, sistemas em escala de rack como o NVL72 da Nvidia apresentam domínios NVLink de 72 GPUs que se comportam como um único acelerador massivo (pense em mais de 13 TB de VRAM compartilhada) apenas se o posicionamento mantiver os jobs dentro da mesma ilha de switch. Saltos entre ilhas transformam as operações coletivas no gargalo. O Groq, como outro exemplo, usa uma rede agendada por software em tempo de compilação, que assume a movimentação de dados determinística e cronometrada pelo compilador entre as placas. Quando os workloads são mal alocados ou agendados aleatoriamente, quebramos essas premissas e a previsibilidade. Além disso, as GPUs variam muito em seu desempenho, mesmo no mesmo data center e rack. Há uma demanda crescente para que os agendadores estejam cientes dessa variabilidade e posicionem os jobs em uma fatia da topologia que também leve essa variabilidade e o tipo de job em consideração ao agendar. Agendadores ingênuos que ignoram a topologia de NVLink/PCIe/NIC e a variabilidade das GPUs espalharão aleatoriamente os jobs multi-GPU e destruirão o tempo de passo e a eficiência; o posicionamento e o agendamento conscientes de topologia corrigem isso e, geralmente, você terá dois tipos de workloads. Treinamento: (síncrono, limitado por largura de banda): Favorece ilhas contíguas com caminhos uniformes e de alta largura de banda para estágios de all-reduce e pipeline; co-agenda a largura de banda do fabric; evita saltos entre switches; trata os limites de link/switch/nó como domínios de falha. E favorece blocos de alta variabilidade de desempenho. Inferência: (limitada por latência/SLO, elástica): Geralmente escolhe entre replicação (espalhar réplicas entre blocos de disponibilidade para alta disponibilidade) e sharding (manter os shards/experts de MoE e a localidade do cache KV nos caminhos mais curtos). Otimiza o posicionamento de prefill vs. decode, micro-batching, isolamento de tenants, etc. Em suma, acreditamos que a dependência dos aceleradores na topologia da rede e do data center continuará a aumentar, e com isso, também o agendamento consciente de topologia. Estamos avaliando projetos como o Kueue e outros neste espaço para alcançar um agendamento de topologia de maior desempenho em nossos clientes.

A piada agora familiar de que o S em MCP significa “segurança” esconde um problema muito real. Quando os agentes se comunicam uns com os outros — por meio da invocação de ferramentas ou chamadas de API — eles podem rapidamente encontrar o que ficou conhecido como a combinação letal (lethal trifecta): acesso a dados privados, exposição a conteúdo não confiável e a capacidade de se comunicar externamente. Agentes com os três atributos são altamente vulneráveis. Como os LLMs tendem a seguir as instruções em sua entrada, um conteúdo que inclua uma diretiva para exfiltrar dados para uma fonte não confiável pode facilmente levar a vazamentos de dados. Uma técnica emergente para mitigar esse risco é a análise de fluxo tóxico, que examina o grafo de fluxo de um sistema com agentes para identificar caminhos de dados potencialmente inseguros para investigação posterior. Embora ainda em seus estágios iniciais, a análise de fluxo tóxico representa uma das várias abordagens promissoras para detectar os novos vetores de ataque aos quais os sistemas com agentes e os servidores MCP estão cada vez mais expostos.

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.

A chave para o sucesso das práticas modernas de desenvolvimento de software é manter o foco no fluxo de trabalho. Times alinhados, ao se concentrarem em um único e valioso fluxo — como uma jornada de pessoa usuária ou produto — conseguem entregar valor de ponta a ponta com eficiência. No entanto, estamos observando uma tendência preocupante de desenvolvimento guiado por capacidade, em que times com essa organização assumem features de outros produtos ou fluxos quando têm capacidade ociosa. Embora isso possa parecer eficiente no curto prazo, é uma otimização local mais adequada para lidar com picos repentinos de demanda. Quando normalizada, essa prática aumenta a carga cognitiva e a dívida técnica e, no pior dos casos, pode levar a um colapso por congestionamento, à medida que o custo da troca de contexto entre produtos aumenta. É mais vantajoso para times com capacidade ociosa focar em melhorar a saúde do sistema. Para gerenciar a capacidade de forma eficaz, use limites de WIP para controlar o trabalho em fluxos adjacentes, considere cross-training para equilibrar os períodos de alta demanda e aplique técnicas de reformulação dinâmica de times quando necessário.

À medida que os assistentes e agentes de programação de IA ganham tração, também aumenta o corpo de dados e pesquisas que destacam preocupações sobre a complacência com o código gerado por IA. Embora haja ampla evidência de que essas ferramentas podem acelerar o desenvolvimento — especialmente para prototipagem e projetos greenfield — estudos mostram que a qualidade do código pode diminuir com o tempo. A pesquisa de 2024 da GitClear constatou que o código duplicado e o code churn aumentaram mais do que o esperado, enquanto a atividade de refatoração nos históricos de commit diminuiu. Refletindo uma tendência semelhante, a pesquisa da Microsoft sobre trabalhadores do conhecimento mostra que a confiança impulsionada pela IA muitas vezes ocorre em detrimento 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 programação amplifica ainda mais esses riscos, já que a IA agora gera conjuntos de alterações maiores que são mais difíceis de revisar. Como em qualquer sistema, acelerar uma parte do workflow aumenta a pressão sobre as outras. Nossos times estão descobrindo que usar a IA de forma eficaz em produção requer um foco renovado na qualidade do código. Recomendamos reforçar práticas estabelecidas como TDD e análise estática, e incorporá-las diretamente nos workflows de programação, por exemplo, por meio de instruções compartilhadas e curadas para times de software.

Organizações estão ansiosas para permitir que agentes de IA interajam com sistemas existentes, muitas vezes tentando uma conversão direta e transparente de APIs internas para o Model Context Protocol (MCP). Um número crescente de ferramentas, como o MCP link e o FastAPI-MCP, visa apoiar essa conversão. Desaconselhamos essa conversão ingênua de API para MCP. As APIs são tipicamente projetadas para pessoas desenvolvedoras humanas e muitas vezes consistem em ações granulares e atômicas que, quando encadeadas por uma IA, podem levar ao uso excessivo de tokens, poluição de contexto e baixo desempenho do agente. Além disso, essas APIs — especialmente as internas — frequentemente expõem dados sensíveis ou permitem operações destrutivas. Para pessoas desenvolvedoras humanas, tais riscos são mitigados por meio de padrões de arquitetura e revisões de código, mas quando as APIs são expostas ingenuamente a agentes via MCP, não há uma maneira confiável e determinística de impedir que um agente de IA autônomo use indevidamente tais endpoints. Recomendamos arquitetar um servidor MCP dedicado e seguro, especificamente adaptado para workflows com agentes, construído sobre suas APIs existentes.

Organizar times de engenharia de dados independentes para desenvolver e serem donos de pipelines e produtos de dados — separados dos domínios de negócio alinhados ao fluxo (stream-aligned) que atendem — é um antipadrão que leva a ineficiências e a resultados de negócio fracos. Essa estrutura repete erros do passado de isolar funções de DevOps, testes ou deployment, criando silos de conhecimento, gargalos e esforço desperdiçado. Sem uma colaboração próxima, as pessoas de engenharia de dados frequentemente não têm o contexto de negócio e de domínio necessário para projetar produtos de dados significativos, limitando tanto a adoção quanto o valor. Em contrapartida, os times de plataforma de dados devem se concentrar na manutenção da infraestrutura compartilhada, enquanto os times de negócio multifuncionais constroem e são donos de seus produtos de dados, seguindo os princípios de data mesh. Colocamos essa prática em Evite para desencorajar fortemente os padrões organizacionais em silos — especialmente à medida que a necessidade de dados ricos em domínio e prontos para IA continua a crescer.

O Text to SQL utiliza LLMs para converter linguagem natural em comandos SQL executáveis. No entanto, sua confiabilidade frequentemente fica aquém das expectativas. Movemos este blip para Evite, a fim de desencorajar seu uso em workflows não supervisionados — por exemplo, na conversão dinâmica de consultas geradas por pessoas usuárias quando a saída é oculta ou automatizada. Nesses casos, os LLMs costumam alucinar devido à compreensão limitada do schema ou do domínio, o que pode resultar na recuperação incorreta ou na modificação não intencional de dados. Além disso, a natureza não determinística das saídas dos LLMs torna a depuração e a auditoria de erros ainda mais desafiadoras.
Recomendamos tratar o uso de Text to SQL com cautela e sempre exigir revisão humana das consultas geradas. Para cenários de business intelligence agêntico, evite o acesso direto ao banco de dados e prefira uma camada semântica de abstração de dados governada — como a camada semântica do Cube ou do dbt — ou uma camada de acesso semanticamente rica, como o GraphQL ou o MCP.