# Artigos de Maurício Aniche Fonte: https://mauricioaniche.com/blog Textos completos em Markdown, com as referências originais. --- # Mais código gerado por IA não resolve o gargalo da operação Data: 2026-10-16T00:00:00-03:00 URL: https://mauricioaniche.com/blog/mais-codigo-gerado-por-ia-nao-resolve-o-gargalo-da-operacao/ Idioma: pt-BR Post interessante da AWS: gerar mais código com IA não significa que sua equipe vai entregar mais rápido. Pode até atrasá-la, quando o trabalho se acumula na hora de publicar, depurar e manter o software funcionando. Sem dúvida, gerar código nunca foi o gargalo. Operar ele, sim. [Falei sobre isso recentemente](https://mauricioaniche.com/blog/ia-no-desenvolvimento-precisamos-comecar-pela-operacao/): precisamos começar a colocar IA da direita pra esquerda no fluxo de desenvolvimento, automatizando deploy, monitoramento e rollback. Quem trabalha com sistemas em produção sabe que o desafio não termina quando o código fica pronto. É preciso subir uma versão nova, verificar se ela funciona, perceber quando algo quebra e conseguir voltar atrás com segurança. Se continuarmos fazendo tudo isso manualmente, gerar mais código só aumenta a fila. Precisamos usar IA também para cuidar do software depois que ele sai do editor. ## Referências - [Post original da AWS no X](https://x.com/awscloud/status/2064449711155589396) --- # O julgamento do engenheiro continua indispensável na era dos agentes Data: 2026-10-15T15:26:00-03:00 URL: https://mauricioaniche.com/blog/o-julgamento-do-engenheiro-continua-indispensavel-na-era-dos-agentes/ Idioma: pt-BR A Anthropic recentemente blogou sobre o seu novo serviço de source control, "Scion", que visa substituir o Git. O ponto deles é que Git foi feito para um universo onde humanos escrevem código e não escala para um mundo de agentes. Dito isso, não vim aqui escrever sobre o Scion, mas sim sobre um parágrafo muito interessante que aparece no post. A tradução literal do parágrafo: > "Os engenheiros continuam sendo valiosos, mas o trabalho deles está mudando. Todos os engenheiros que trabalharam neste sistema hoje considerariam o Claude melhor do que eles na escrita de código. No entanto, nossos engenheiros forneceram o conhecimento indispensável sobre os componentes de alto nível do sistema e as decisões de projeto que envolviam concessões (*trade-offs*), fazendo escolhas fundamentadas em relação aos problemas que queríamos resolver e à escala que sabíamos ser necessária. Muitas vezes, o papel dos engenheiros era dizer "não" ao Claude. Agentes podem, por vezes, violar restrições fundamentais do sistema para atender a um padrão que jamais deveria ter sido permitido. Isso foi particularmente comum durante nossa migração. Por exemplo, havia vários sistemas que tentavam identificar, por força bruta, o momento em que uma alteração era integrada à ramificação principal (*main*), lendo linearmente o registro de *commits* em vez de consultar nossa ferramenta de revisão de código. A Anthropic também utiliza extensivamente a revisão adversarial; embora essa prática seja extremamente eficaz sob muitos aspectos, ela pode levar a uma visão limitada. Por isso, engenheiros qualificados precisavam orientar o Claude para evitar a criação de soluções excessivamente complexas (*over-engineering*) em resposta a preocupações hipotéticas. Um exemplo disso foi uma revisão que demonstrava desconfiança excessiva em relação a outro serviço interno, levando o Claude a adicionar validações e complexidade desnecessárias. Os membros da nossa equipe continuam analisando todas as solicitações de alteração do sistema, mas agora examinam a intenção da mudança, em vez de lerem cada linha de código." A IA pode até escrever linhas de código melhor do que nós, humanos, mas ela ainda não substitui o nosso julgamento altamente afiado. Nosso trabalho como engenheiro de software só está subindo um nível de abstração. Continue investindo na sua educação em ciência da computação e engenharia de software, pois é essa base que vai sustentar esse julgamento. ## Referências - [Post original](https://www.anthropic.com/engineering/redesigning-source-control) --- # Testando sistemas agênticos: aprendendo com o passado para testar o futuro Data: 2026-10-15T00:00:00-03:00 URL: https://mauricioaniche.com/blog/testando-sistemas-agenticos/ Idioma: pt-BR Por muitos anos, testar software significou executar um programa com entradas determinadas e verificar se os resultados observados eram aqueles que esperávamos. Também aprendemos que fazer isso de maneira natural não escalava, e passamos a automatizar essas entradas e a verificação da saída. Aprendemos também a testar sistemas mais complexos que envolviam estados, propriedades, contratos, integrações, desempenho, segurança e sistemas distribuídos inteiros. Mas uma ideia sempre continuou no centro de quase tudo: testamos um grande conjunto de “hipóteses” para aumentar nossa confiança de que o software se comporta como deveria. **Sistemas baseados em agentes de IA, ou “sistemas agênticos”, não mudam esse princípio.** A disciplina de teste de software não morreu porque começamos a usar LLMs. Na verdade, muitos dos problemas que estamos discutindo hoje em torno de avaliação de agentes são velhos conhecidos de quem trabalha com testes de software: - O problema do oráculo: como eu sei se a saída de um programa de computador para uma dada entrada é a saída correta? - Geração de casos de teste e adequação da suíte: como criar suítes de testes que realmente revelam problemas no sistema? - Não determinismo: como testar programas cuja saída não é tão determinística? - Testes instáveis: testes que às vezes passam e às vezes falham, sem uma razão clara - Observabilidade e isolamento do ambiente: como ter visibilidade completa sobre as centenas de execuções desses testes e dar ao desenvolvedor o máximo de informação possível para facilitar o debugging? A natureza do “sistema sob teste” mudou, e esse é o novo grande desafio. Uma função tradicional pode ser descrita, de maneira simplificada, assim: ```text entrada → programa → resultado ``` Funções essas que eram razoavelmente determinísticas. Mesmo se olharmos para pedaços maiores do sistema, como um módulo inteiro, um sistema inteiro, ou um sistema distribuído inteiro, aumentamos o desafio de passar entradas relevantes e de verificar que a saída é correta, mas ainda assim é algo muito parecido com o desenho acima, onde você passa uma entrada, uma série de sistemas de software trabalha nessa requisição, novamente de maneira razoavelmente determinística, e retorna uma resposta. Um sistema agêntico se parece mais com: ```text objetivo → modelo + contexto + harness + ferramentas + ambiente → sequência de ações → resultado ``` Entre a entrada e o resultado existe agora uma trajetória inteira que pode mudar completamente conforme a entrada. O modelo “raciocina”, escolhe ferramentas, recebe novos dados, altera o ambiente, reconsidera decisões e eventualmente decide que terminou. Isso nos força a adaptar tudo o que conhecemos sobre teste de software. Ainda queremos testar o comportamento end-to-end do sistema, ainda queremos testar algum detalhe interno de como esse sistema chega no resultado, ainda queremos bons casos de teste que aumentem nossa chance de encontrar um eventual problema, ainda queremos suítes de testes que rodam rápido e que nos deem um sinal confiável. Só precisamos mudar ou adaptar a forma como fazemos isso. Ao mesmo tempo, é justamente aqui que a IA também nos amplifica. Podemos gerar centenas de variações de uma tarefa, executar o agente repetidamente, inspecionar registros de execução, comparar diferentes harnesses, simular usuários, gerar falhas de ferramentas e ter outro modelo analisando milhares de execuções. É uma história parecida com o que está acontecendo em outras áreas da engenharia de software: os fundamentos continuam os mesmos, mas a IA mudou radicalmente a forma como fazemos engenharia de software. ## O que exatamente estamos testando? Na prática, em um sistema agêntico, temos muito mais do que simplesmente um prompt e uma resposta de uma LLM. Temos algo mais próximo disto: ```text Agente = Modelo + Instruções + Contexto + Harness + Ferramentas + Ambiente ``` - O **modelo** pode ser GPT, Claude, Gemini ou qualquer outro. - As **instruções** incluem instruções que são passadas para o modelo, como exemplos e regras específicas da aplicação. - O **contexto** contém documentos, histórico da conversa, memória, resultados de recuperação de informação e informações produzidas durante a própria execução. - As **ferramentas** definem quais ações o modelo consegue executar no mundo. - O **ambiente** contém o estado real sobre o qual essas ações operam. - E o **harness** é a “cola” que coloca tudo isso para funcionar. É o harness que decide, por exemplo, como montar o contexto, como expor ferramentas, quantos passos o agente pode executar, como lidar com erros, quando tentar novamente, como persistir memória, qual modelo utilizar em cada momento e quando considerar a tarefa terminada. Isso significa que trocar apenas o harness pode alterar significativamente o desempenho, mesmo mantendo exatamente o mesmo modelo. Ao avaliar um agente, estamos avaliando o modelo e esse harness em conjunto. O harness, aliás, é um detalhe importante também do ponto de vista experimental. Se estamos comparando versões do nosso sistema, não basta registrar: ```text modelo = X ``` Precisamos registrar algo mais próximo de: ```text modelo X + instruções P + harness H + ferramentas T + política de contexto C + orçamento B ``` Esse conjunto é nosso verdadeiro sistema sob teste. ## Um modelo mental para testar agentes Há pelo menos cinco atributos diferentes que podemos (ou devemos) observar ao testar sistemas agênticos. | **Superfície** | **Pergunta principal** | **Exemplo** | | --- | --- | --- | | **Resultado** | O agente resolveu a tarefa? | A reserva do hotel realmente foi criada? | | **Estado e efeitos colaterais** | O mundo terminou no estado correto? | O banco de dados foi alterado corretamente? | | **Trajetória** | O caminho seguido foi aceitável? | Usou a ferramenta correta? Seguiu a política? | | **Confiabilidade** | Ele consegue fazer isso consistentemente? | Acerta nove de dez execuções ou apenas três? | | **Eficiência** | Quanto custou chegar ao resultado? | Tokens, tempo, passos e chamadas de ferramentas | Essas dimensões não têm o mesmo peso em todos os sistemas, e você deve levar sempre o contexto do que está criando em consideração. Por exemplo: - Para um agente que faz reservas, o estado final do sistema é provavelmente mais importante que o texto de parabéns da confirmação que ele escreveu para o usuário. - Para um agente financeiro, algumas propriedades da trajetória podem ser obrigatórias: talvez ele precise verificar a identidade antes de executar determinada transação. - Para um agente de pesquisa, por outro lado, o resultado pode ser muito mais difícil de avaliar deterministicamente. Correção, cobertura das fontes, qualidade das evidências e clareza da síntese podem exigir avaliações diferentes. Essa distinção entre **registro da execução**, que contém a trajetória completa, e **resultado**, que representa o estado final do ambiente, parece óbvia, mas evita um erro bastante comum: avaliar o que o agente **disse que fez**, e não o que **ele realmente fez**. Um agente pode afirmar que reservou um restaurante, mas o resultado verdadeiro é se a reserva de fato apareceu no banco de dados ou no sistema terceiro que controla a reserva. ## Comece pela caixa-preta Nos primórdios dos métodos ágeis e testes automatizados, nos apaixonamos rapidamente por testes de caixa branca, com o teste de unidade sendo a concretização desse tipo de teste. E não à toa. Testes de unidade são fáceis e baratos de serem escritos, rodam rápido, e por consequência, eles conseguem se multiplicar muito rapidamente na base de códigos. Um outro fator que ajudou demais a adoção foi que escrever testes de maior escopo, como testes de componente, integração ou end-to-end dava muito mais trabalho, e esses testes eram muito mais instáveis. As ferramentas não estavam prontas ainda. No entanto, 20 anos depois, nós aprendemos que de nada adiantam centenas de milhares de testes que funcionam bem isolados, mas que não pegam problemas básicos. As ferramentas para testes de maior escopo também evoluíram bastante, e agora testar um sistema inteiro (e não só uma classe ou função) junto com seu banco de dados e cache é muito mais fácil. Eu advoco por testes de componente e sistema há muito tempo. E continuo advocando nessa nova era da IA. Comece pelo comportamento observável do sistema como um todo. Antes de analisar se instruções passadas pro modelo estão certas, se o raciocínio foi correto, se ele chamou as ferramentas certas, ou qualquer outro detalhe interno, tente escrever testes que respondam à seguinte pergunta: **Dada uma tarefa, o sistema entrega um resultado aceitável?** Esse é um teste mais perto do teste end-to-end, olhando o sistema agêntico como uma caixa fechada e preocupado somente com a saída gerada e não com os detalhes de implementação. Suponha um agente de atendimento cujo objetivo seja cancelar uma compra. Podemos (ou o agente de código pode) preparar inicialmente um cenário onde o sistema tem um pedido com o status ativo: ```text estado_inicial = pedido ATIVO ``` O teste então dispara a entrada do sistema: ```text usuário: "Quero cancelar minha compra" ``` O agente trabalha. Ao final, o teste verifica que: ```text estado_final = pedido CANCELADO reembolso CRIADO notificação ENVIADA ``` Esse é um excelente primeiro teste para o seu agente. Não precisamos inicialmente saber se o agente chamou `getOrder()` três vezes ou cinco. Não precisamos saber se primeiro consultou a política ou consultou o pedido. Não precisamos nem avaliar sua explicação intermediária. Primeiro queremos saber se a tarefa foi realizada. Isso é teste de software tradicional. O teste de caixa preta é uma solução elegante para esse tipo de teste justamente porque transforma (ou tenta transformar) um problema aparentemente subjetivo em um oráculo determinístico. O agente pode chegar ao estado final por caminhos diferentes. O teste não precisa se importar, desde que o resultado seja correto e as restrições importantes sejam respeitadas. ## E depois abra a caixa O problema é que saber apenas que o sistema agêntico falhou, não retornou a resposta esperada, não nos ajuda muito a entender **por que ele falhou**. É aí que começamos a olhar para dentro. Para conseguir fazer um teste de caixa branca e garantir um pouco do comportamento interno do agente, precisamos ter o registro inteiro da execução. Algo como: - Objetivo: qual foi o objetivo realmente passado para o sistema agêntico? - Raciocínio exposto pelo modelo: que explicação ele apresentou para chegar ao resultado? - Chamada de ferramentas: de quais ferramentas ele fez uso? - Resposta final: a qual resposta ele chegou? Com esse registro em mãos, podemos procurar por “decisões ruins”. Perguntas que podem fazer sentido em diferentes contextos: - O agente escolheu a ferramenta errada? - Escolheu a ferramenta correta, mas produziu parâmetros errados? - Interpretou incorretamente o resultado? - Recebeu uma mensagem de erro e não conseguiu se recuperar? - Perdeu uma informação importante porque o harness a removeu do contexto? - Utilizou uma memória antiga que já não deveria ser relevante? - Terminou cedo demais? - Continuou executando ações depois que a tarefa já estava resolvida? Não entrarei no detalhe de como fazer cada uma dessas verificações, pois cada sistema agêntico hoje é único. E as ferramentas também estão no mesmo momento das ferramentas de testes end-to-end do começo dos anos 2000: instáveis e mudando com frequência. É sua tarefa criar mecanismos para conseguir fazer asserções em cima de comportamentos do agente que façam sentido. Note também que aqui usei o termo teste de caixa branca e não teste de unidade. A ideia é tirar notas sobre como o sistema agêntico trabalha, mas ainda assim observando-o de maneira end-to-end. Eu falo mais de testes de unidade mais abaixo no texto. Uma lição que aprendemos de maneira dura com testes de caixa branca também se aplica aqui: cuidado para não acoplar demais o seu teste com detalhes internos da implementação do seu agente. Lembra daqueles testes de unidade cheios de mock, e depois quando você mudava a implementação mas sem mudar o resultado final, todos seus testes quebravam? Pois é, a mesma coisa pode acontecer aqui. Imagine que um agente precise encontrar um cliente, verificar um pedido e reembolsar uma cobrança. Hoje ele pode fazer: ```text buscar_cliente → consultar_pedido → reembolsar ``` Amanhã, um modelo melhor talvez encontre um caminho ainda melhor para se chegar no resultado: ```text buscar_pedido_por_email → reembolsar ``` Os dois caminhos podem estar corretos e produzir a mesma saída. No entanto, se o teste tiver verificações como as abaixo, acabamos de transformar uma solução autônoma em um fluxo programado indiretamente pelo teste. ```text assert primeira_chamada == buscar_cliente assert segunda_chamada == consultar_pedido assert terceira_chamada == reembolsar ``` Como disse, isso é equivalente a escrever um teste de unidade tradicional excessivamente acoplado à implementação. Nós já sabemos que isso é ruim. Uma refatoração muda a estrutura interna sem mudar o comportamento externo, mas dezenas de testes quebram porque conheciam detalhes demais da implementação. Portanto, é sempre melhor testar **propriedades importantes da trajetória** do que “fixar” uma trajetória inteira. No exemplo, talvez as propriedades relevantes sejam: - reembolso só pode acontecer depois de verificar_identidade - reembolso.valor <= pagamento_original.valor - excluir_cliente nunca pode ser chamado - nenhuma compra adicional pode ser criada - máximo de 15 chamadas de ferramentas Observe a diferença. Não estamos dizendo **como** o agente deve resolver o problema. Estamos dizendo quais **invariantes** ele precisa preservar enquanto resolve o problema. Isso é particularmente importante porque modelos melhores podem encontrar estratégias que não antecipamos. Estamos presenciando a evolução desses modelos quase que diariamente. Não é improvável observar agentes encontrando soluções válidas não previstas pela avaliação e sendo classificados como falha porque o conjunto de testes era rígido demais. O objetivo de um teste não deveria ser impedir que nosso sistema fique melhor. ## Nada se cria, tudo se transforma Há um paralelo que considero bastante útil com a maneira como testávamos sistemas baseados em algoritmos de aprendizado de máquina, antes da atual geração de LLMs. Pense em algoritmos como decision trees e random forests. Eles eram muito mais simples do que os sistemas agênticos de hoje, mas podemos sim aprender com eles. Imagine um algoritmo de classificação de fraude. Para testar o classificador, nós criávamos um conjunto de exemplos que sabíamos que eram verdade: ```text transação_1 → fraude transação_2 → legítima transação_3 → legítima transação_4 → fraude ``` Esses exemplos formavam nosso **conjunto de referência** (ou golden set, em inglês). Ao criar uma nova versão do algoritmo, executávamos o algoritmo sobre esse conjunto de referência e comparávamos os resultados do novo modelo com os resultados que sabemos ser corretos. Naturalmente, não esperávamos necessariamente que cada versão produzisse exatamente os mesmos resultados. Uma versão poderia melhorar algumas previsões e piorar outras. O que observávamos eram métricas agregadas como precisão, recall, F1, taxa de falsos positivos ou taxa de falsos negativos. Também tínhamos conjuntos separados para treinamento, validação e teste justamente para evitar otimizar inadvertidamente o sistema para os mesmos exemplos usados para avaliá-lo. Muito disso continua sendo uma boa ideia. A diferença é que agora nossos exemplos ficaram muito mais ricos. As entradas e saídas são muito mais complexas. O ambiente pode mudar durante a execução. O agente pode pedir mais informação ao usuário. O resultado pode ser texto, arquivos, alterações no banco, chamadas de API e dezenas de outros efeitos colaterais. E podem existir muitas soluções corretas. Mas, conceitualmente, a ideia continua surpreendentemente parecida: **mantemos um conjunto de tarefas que representem comportamentos importantes (tanto a entrada quanto a saída) e executamos o sistema agêntico com esse conjunto de tarefas sempre que o sistema mudar.** Ou seja, continuamos querendo nosso conjunto de referência. Precisamos apenas parar de pensar nele como um conjunto de pares `` e começar a pensar em um conjunto de **tarefas rotuladas**. ## Dados rotulados continuam sendo ouro Sempre houve uma tendência, dentro da inteligência artificial, de procurar maneiras de gerar automaticamente os dados de avaliação. Mesmo antes das LLMs. E isso é compreensível, claro, pois rotular dados é caro. Você geralmente precisa pagar humanos pra fazer isso. Se você tem bons exemplos de tarefas rotuladas, eles são extremamente valiosos para garantir a qualidade do sistema agêntico. Imagine um agente usado por um departamento jurídico. Um especialista pode escrever 200 tarefas representativas e, para cada uma, documentar: - o que seria uma resposta correta - o que obrigatoriamente deveria aparecer em uma resposta - O que não pode aparecer nunca - quais fontes deveriam ser consultadas - quais ações nunca deveriam ser tomadas. Construir esse conjunto pode custar caro. Mas ele passa a ser nossa suíte de regressão. Mudamos o modelo? Executamos novamente. Mudamos as instruções de sistema? Executamos novamente. Alteramos o mecanismo de recuperação de informação? Executamos novamente. Adicionamos memória? Executamos novamente. Mudamos o harness? Executamos novamente. É exatamente o papel que uma boa suíte de regressão de um algoritmo de aprendizado de máquina sempre exerceu. A dificuldade é que, em muitos domínios, não temos um resultado esperado exato. Isso nos leva novamente ao problema clássico do oráculo. ## O velho problema do oráculo de teste Em teste de software, chamamos de *oráculo de teste* o mecanismo que determina se o resultado de uma execução está correto. Às vezes ele é trivial e fácil de ser calculado. Saber que o resultado de dois mais dois é quatro é trivial: ```text 2 + 2 == 4 ``` Mas às vezes é simplesmente muito difícil determinar automaticamente se o resultado está correto. LLMs ampliam esse desafio ainda mais, pois é ainda mais difícil saber qual o resultado certo de um agente. Imagine a seguinte tarefa implementada por um agente: Analise estes dez documentos e produza uma recomendação para a empresa. Não existe uma única sequência de texto correta que possamos colocar em um `assertEquals`. Mesmo dois especialistas humanos podem escrever respostas bastante diferentes e ambas serem boas. Como saber o que verificar em um sistema como esse? Minha sugestão é para **usar o oráculo mais determinístico disponível antes de recorrer a um modelo.** - Se conseguimos verificar uma propriedade por código, verificamos por código. - Se conseguimos consultar o estado do banco, consultamos o banco. - Se conseguimos executar testes, executamos testes. - Se conseguimos validar um JSON contra um esquema, fazemos isso. - Se conseguimos garantir que todas as citações existem nos documentos consultados, fazemos essa verificação deterministicamente. Avaliações determinísticas são baratas, reproduzíveis e objetivas. ## LLM como juiz Mas talvez só a avaliação determinística não seja suficiente. Nossos sistemas agênticos produzem respostas complexas, com texto em linguagem natural, imagens, vídeos etc. Precisamos de mais do que “apenas” testes determinísticos. Precisamos ler o que o sistema escreveu, em linguagem natural, e garantir que esse texto também está correto. Quando não temos um oráculo determinístico suficientemente bom, uma alternativa óbvia é usar outro LLM para julgar se a saída do sistema agêntico é correta. É a IA resolvendo problemas que ela mesma criou. É o chamado **LLM como juiz**. Podemos entregar ao modelo avaliador: - Descrição da tarefa - Critérios esperados - Resposta do agente E pedir algo como: - Avalie a correção de 1 a 5 - Avalie a completude de 1 a 5 - Identifique afirmações sem suporte - Verifique se os requisitos A, B e C foram satisfeitos Isso funciona surpreendentemente bem em muitos cenários e torna avaliações que antes exigiriam milhares de horas humanas economicamente viáveis. O desafio aqui é lembrar que a LLM também pode errar. Ela pode dizer que o resultado está correto, mas ele não estar. Lembre-se de que o modelo avaliador também é um sistema probabilístico. Ele possui vieses. Ele pode preferir determinadas formas de escrita, ou favorecer respostas mais longas, ou ser influenciado pela ordem em comparações entre duas respostas, entre outros vieses. Portanto, se for usar uma LLM como juiz, o juiz também precisa ser testado. Precisamos testar o testador. Escreva uma suíte de testes para garantir que a saída do seu juiz satisfaz o seu critério de qualidade. Ainda bem que temos IA para nos ajudar nisso. Tudo isso é muito novo e ainda estamos aprendendo como testar juízes. Eu começaria com um pequeno conjunto de respostas corretas, incorretas e casos no limite entre as duas, avaliados por especialistas do domínio com critérios explícitos. No exemplo da recomendação para a empresa, uma resposta pode ser bem escrita e a LLM ainda sim inventar um dado decisivo. O juiz precisa detectar esse erro. Peça ao agente de código para montar e executar uma suíte que compare os julgamentos do modelo com essas avaliações humanas. Inspecione tanto respostas ruins que o juiz aprovou quanto respostas boas que ele rejeitou, já que divergências também podem revelar critérios ambíguos ou erros na própria avaliação humana. Ajuste a rubrica com esses exemplos, mas reserve outros para verificar se o juiz funciona além dos casos usados no ajuste. Manter um conjunto rotulado onde o modelo não vê nem durante o treino e nem durante o desenvolvimento e melhoria desse modelo, chamado de conjunto de validação, é também uma prática muito utilizada em aprendizado de máquina desde sempre; e aqui novamente mais uma ideia sendo reusada. Repita essa avaliação quando mudar o modelo ou as instruções do juiz e mantenha uma revisão humana periódica de uma amostra dos julgamentos. E aqui, ainda há uma evolução interessante dessa ideia. Às vezes avaliar a tarefa também exige trabalho. Imagine avaliar um agente de programação que recebeu a tarefa: Adicione autenticação OAuth a esta aplicação. Um LLM olhando apenas a diferença entre arquivos pode não conseguir determinar corretamente se aquilo funciona. Um avaliador melhor poderia: - abrir os arquivos - executar os testes - subir a aplicação - fazer uma requisição - inspecionar logs - consultar o banco e somente depois emitir seu julgamento. Nesse momento nosso juiz também virou agente. Essa abordagem tem sido chamada de **agente como juiz**. A ideia é permitir que o avaliador observe e interaja com os artefatos produzidos por outro agente antes de decidir se a tarefa foi realizada corretamente. Eu, aliás, acredito que agentes como juiz terão um papel revolucionário na própria prática de testes de software. Teremos agentes testando o código gerado por agentes. Isso é muito além do que usamos hoje nas ferramentas de revisão de código mais comuns, que basicamente mandam o código do pull request junto com um prompt caprichado pedindo para a LLM encontrar erros no código. ## Não execute uma vez só Outro ponto onde sistemas agênticos diferem de boa parte do software tradicional é a variabilidade entre execuções. Se executarmos o teste de unidade `testarReembolso()` cem vezes em uma aplicação Java tradicional, esperamos cem resultados iguais. O teste é determinístico e repetível. Execute a mesma tarefa cem vezes em um sistema agêntico e talvez obtenhamos cem trajetórias diferentes. Algumas podem terminar com sucesso e outras não. Por isso, uma única execução do teste é pouca evidência. Não queremos apenas saber: O agente consegue fazer isso? Queremos também saber: Com qual frequência ele consegue fazer isso? Uma métrica popular para resolver esse problema é a `pass^k`, que mede a probabilidade de o agente conseguir realizar uma tarefa corretamente em todas as `k` execuções. Esse é um conceito particularmente importante para sistemas reais. Imagine dois agentes: - Agente A: 90% de sucesso - Agente B: 95% de sucesso A diferença parece pequena. Mas, se um processo crítico exige dez ações independentes executadas corretamente, essas probabilidades se acumulam. Confiabilidade deixa de ser apenas uma característica estatística interessante e passa a ser parte central da qualidade do produto. Por isso precisamos pensar em algo próximo do que já fazemos com testes instáveis: medir distribuições, repetir execuções e entender variância. Uma suíte de avaliação de um sistema agêntico não deveria produzir apenas: `87% passou,` ela deveria conseguir nos mostrar também intervalos de confiança, variação entre execuções e quais tarefas apresentam comportamento instável. E note que isso não é novidade. Bons testes de carga e performance no mundo pré-LLMs também executavam o teste múltiplas vezes para só afirmar que, por exemplo, uma parte do sistema piorou em latência depois de coletar muitas amostras. De novo, nada se cria, tudo se transforma. ## Testando falhas no meio do processo Testar sistemas agênticos tem desafios análogos ao se testar um sistema distribuído. Em um sistema distribuído, serviços se integram e chamam outros serviços, que podem falhar no meio. E o sistema precisa garantir que o sistema não pega fogo quando isso acontece. Sistemas distribuídos precisam também lidar com possíveis dados desatualizados, respostas em formatos inesperados, etc. A mesma coisa em um sistema agêntico, que chama ferramentas, MCPs, entre outros. Ferramentas falham. APIs devolvem `500`. A autenticação expira. Uma busca retorna zero resultados. Outra retorna informação incompleta. Uma chamada demora demais. O usuário muda de ideia no meio da conversa. Uma ferramenta retorna JSON inválido. O contexto fica grande demais. Memória contém informação antiga. Pegue uma execução que normalmente seria: ```text agente → buscar_cliente → sucesso ``` e transforme em: ```text agente → buscar_cliente → tempo esgotado ``` O que acontece? O sistema agêntico tenta novamente? Tenta infinitamente? Escolhe outra estratégia? Inventa o resultado? Explica para o usuário que não conseguiu concluir? E se a API de pagamento retornar 500? E se a ferramenta de busca devolver uma resposta malformada? E se o banco de dados tiver algum dado desatualizado? São todos casos a serem pensados. Novamente, nada conceitualmente novo para teste de software. Injeção de falhas e testes de fronteiras são práticas há muito tempo conhecidas. A novidade é que agentes conseguem reagir dinamicamente ao problema, então queremos testar não apenas se o erro foi tratado por uma ramificação do código, mas se a estratégia de recuperação da falha continua aceitável. A IA também torna muito mais barato gerar essas variações automaticamente. Podemos pedir a outro agente para criar dezenas de perturbações plausíveis de uma mesma tarefa, por exemplo. Ou seja, injetar falhas e testar uma alta quantidade de casos extremos, que eram processos caros, agora são baratos. O agente é persistente e vai até o fim. ## E os testes unitários? Eles continuam existindo. Se seu harness possui uma função determinística responsável por validar um limite de reembolso, você se beneficiará de um teste unitário que cobre esse comportamento. Afinal, na próxima vez que a regra for alterada, o agente de código terá um mecanismo rápido de feedback pra garantir que não quebrou nada. Se uma regra de segurança pode ser expressa deterministicamente, implemente-a deterministicamente e teste-a deterministicamente. Quanto mais propriedades importantes conseguirmos retirar do espaço probabilístico e transformar em código determinístico, mais fácil o sistema fica de entender e testar. Dito isso, não podemos cair na falácia que mencionei anteriormente: meu sistema está inteiramente testado com testes de unidade, e portanto não preciso de testes end-to-end. O “coração” do sistema agêntico deve ser testado via testes de maior escopo, como discutido durante esse artigo inteiro. ## Isso é suficiente? Com certeza, não. Do mesmo jeito que testes de unidade e testes de sistema nunca foram suficientes para se testar sistemas determinísticos. E não à toa, pesquisadores de engenharia de software estão há décadas propondo técnicas para nos ajudar a encontrar bugs em nossos sistemas. Técnicas como testes de mutação, algoritmos de busca aplicados a testes de software, testes aleatórios, testes aumentados, etc, são tentativas da academia para nos ajudar nessa busca. Essas mesmas técnicas ainda fazem sentido quando falamos de se testar sistemas agênticos. E talvez mais ainda, dado o não-determinismo dos modelos. Por exemplo, “eu quero reservar o restaurante X”, “reserve-me o restaurante X”, e “reserve-me o restaurante X agora” deveriam produzir o mesmo efeito no sistema; mas será que produz mesmo? É ainda mais importante testar variações da entrada em sistemas agênticos. Pesquisa em testes de software só ficou ainda mais importante nesse mundo agêntico. ## Testar sistemas agênticos ainda é testar software Há um risco neste momento de reinventarmos toda a terminologia porque o software agora usa IA. Eu chamei aqui “casos de teste” de “tarefas”. Execuções viraram tentativas. Asserções viraram avaliadores. Resultados esperados viraram conjuntos de referência. Boa parte disso é útil porque o domínio realmente tem características diferentes. Mas não deveríamos perder a conexão com décadas de conhecimento acumulado em teste de software. Ainda precisamos de bons oráculos de teste. Ainda temos testes de regressão. Ainda precisamos pensar sobre cobertura. Ainda queremos gerar entradas interessantes que maximizem a chance de revelar problemas. Ainda temos ambientes difíceis de reproduzir. Ainda precisamos de observabilidade para diagnosticar falhas. Ainda precisamos evitar testes acoplados demais à implementação. E ainda precisamos decidir quando testamos o suficiente. O que sistemas agênticos fizeram foi expandir significativamente o espaço de comportamento que precisamos observar. E, curiosamente, a mesma IA que criou essa complexidade também nos dá ferramentas para lidar com ela. Podemos executar mais experimentos. Podemos analisar milhares de registros de execução. Podemos gerar casos adversariais. Podemos simular usuários. Podemos procurar automaticamente padrões nas falhas. Podemos transformar bugs de produção em novos casos da nossa suíte. Podemos usar agentes para avaliar agentes. Não precisamos jogar fora o que aprendemos sobre testes de software. Precisamos aplicar esses fundamentos a um sistema novo, muito mais dinâmico, e aproveitar a IA para fazer testes em uma escala que antes simplesmente não conseguíamos. A pergunta sobre qualidade continua sendo a mesma de sempre: **Temos evidência suficiente de que o sistema vai se comportar corretamente quando for pra produção?** Só que agora responder bem a essa pergunta ficou, ao mesmo tempo, mais difícil e muito mais interessante. ## Referências bibliográficas - **LANGCHAIN.** *Evaluating AI Agents at the Run, Trace, and Thread Level*. 23 jun. 2026. Disponível em: [https://www.langchain.com/resources/agent-evals](https://www.langchain.com/resources/agent-evals) - **ANTHROPIC.** *Demystifying Evals for AI Agents*. 9 jan. 2026. Disponível em: [https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) - **OPENAI.** *Trustworthy Third-Party Evaluations: Foundations*. Disponível em: [https://openai.com/pt-BR/index/trustworthy-third-party-evaluations-foundations/](https://openai.com/pt-BR/index/trustworthy-third-party-evaluations-foundations/) - **HUSAIN, Hamel.** *How Do I Evaluate Agentic Workflows?* Hamel's Blog. Disponível em: [https://hamel.dev/blog/posts/evals-faq/how-do-i-evaluate-agentic-workflows.html](https://hamel.dev/blog/posts/evals-faq/how-do-i-evaluate-agentic-workflows.html) - **HUSAIN, Hamel.** *Your AI Product Needs Evals*. Hamel's Blog. Disponível em: [https://hamel.dev/blog/posts/evals/](https://hamel.dev/blog/posts/evals/) - **HUSAIN, Hamel.** *AI Evals: Everything You Need to Know*. Hamel's Blog. Disponível em: [https://hamel.dev/blog/posts/evals-faq/](https://hamel.dev/blog/posts/evals-faq/) - **MICROSOFT.** *Agent Evaluators for Generative AI*. Microsoft Learn. Disponível em: [https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators?view=foundry](https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators?view=foundry) --- # Meat proxy e cognitive surrender: usar IA sem abrir mão do senso crítico Data: 2026-10-14T15:27:00-03:00 URL: https://mauricioaniche.com/blog/meat-proxy-e-cognitive-surrender-usar-ia-sem-abrir-mao-do-senso-critico/ Idioma: pt-BR Meat proxy, cognitive surrender. Estamos vendo o surgimento de termos relacionados aos problemas que o uso indiscriminado da IA pode nos causar. Meat proxy é quando você simplesmente repassa pra frente o que a IA gera sem qualquer senso crítico. Cognitive surrender é quando você simplesmente para de pensar; o que a LLM te dá, você aceita como verdade. Como fazer bom uso de IA sem perder o senso crítico é sim um desafio. ## Referências - [Addy Osmani falando sobre isso](https://www.linkedin.com/posts/addyosmani_ai-programming-softwareengineering-ugcPost-7463838669163053057-zkpm/) --- # O fim do code review ou uma oportunidade para repensá-lo? Data: 2026-10-13T14:16:26-03:00 URL: https://mauricioaniche.com/blog/o-fim-do-code-review-ou-uma-oportunidade-para-repensa-lo/ Idioma: pt-BR O professor Christian Kästner, que tive o prazer de conhecer, escreveu um texto muito legal sobre code review, chamado "O fim da revisão de código ou uma oportunidade para repensá-la?" Meu resumo do texto: 1. **Code review moderno não foi otimizado principalmente para encontrar bugs.** Comparado às inspeções formais, da década de 80 e 90, o code review moderno é relativamente pouco eficaz na detecção de defeitos profundos, mas ganhou escala por ser barato e aplicável a praticamente todas as mudanças. Seus benefícios incluem legibilidade, disseminação de conhecimento, ownership coletivo, mentoria e padronização. 2. **Agentes reduzem o custo de produzir código, mas isso não implica ganho proporcional de produtividade.** O professor modela o custo total como produção + responsabilidade futura do código + revisão. Se produção representar apenas um terço do custo total, por exemplo, reduzi-la em 90% reduziria o custo total em apenas 30%. Nesse cenário, revisão e outros processos passam a limitar os ganhos. 3. **O impacto dos agentes sobre a qualidade e o custo futuro do código ainda é incerto.** Os agentes podem aumentar retrabalho ao gerar código de menor qualidade (e quem não acredita em IA, tá apostando nisso!), mas também podem reduzir esse custo ao automatizar debugging e correções (minha aposta!). Testes, análise estática e revisão automatizada também ficam mais baratos, já que agentes conseguem também gerar eles mais rápido do que humanos, reduzindo potencialmente a necessidade de revisão humana. 4. **Mais código gerado por IA pode tornar a revisão humana menos eficaz.** O aumento do volume de código cria pressão para revisar rapidamente, favorecendo aprovações superficiais (bom, mas isso já acontecia antes também, quem que nunca deu um LGTM sem nem ler o PR direito?). Além disso, código gerado por agentes tende a parecer plausível, e pode ser mais difícil de ser revisado por um humano. 5. **A questão passa a ser quais funções humanas devem substituir o code review tradicional.** Se agentes assumirem produção e parte da revisão, precisaremos achar outras maneiras de garantir o aprendizado de júniores e espalhar conhecimento do sistema. Ninguém sabe muito bem ainda como o processo de code review nesse mundo da IA deve se parecer, mas com certeza o modelo atual não encaixa mais. ## Referências - [Link para o post](https://thelastsoftwareengineer.substack.com/p/the-end-of-code-review-or-an-opportunity) --- # Corrigir vulnerabilidades com IA ainda exige julgamento humano Data: 2026-10-12T14:24:20-03:00 URL: https://mauricioaniche.com/blog/corrigir-vulnerabilidades-com-ia-ainda-exige-julgamento-humano/ Idioma: pt-BR Recebi recentemente um estudo feito pelo time do 1password. Confesso que li apenas o abstract e não avaliei a metodologia científica (meus tempos de acadêmico ficaram pra trás). O estudo deles avaliou modelos de IA (Claude Opus 4.8 e GPT 5.5) na correção de seis vulnerabilidades reais, recentes e complexas. Três resultados chamam atenção: 1. **A taxa de correções realmente bem-sucedidas foi baixa.** Considerando diferentes cenários e estratégias de geração, os modelos raramente conseguiram eliminar todos os caminhos conhecidos de exploração, sem alterar incorretamente o comportamento da aplicação. 2. **Passar nos testes não significou corrigir a vulnerabilidade.** Em vários casos, os modelos corrigiram apenas parte dos caminhos vulneráveis ou adicionaram "guards" frágeis que satisfaziam os testes, mas não atacavam a causa raiz da vulnerabilidade. 3. **Automatizar completamente a remediação ainda traz riscos relevantes.** Nos experimentos deles, os modelos às vezes introduziram mudanças sutis de comportamento, novas vulnerabilidades ou mascararam vulnerabilidades existentes. O estudo nos mostra que ainda é difícil confiar cegamente nesses modelos para encontrar e corrigir problemas de segurança. E pior, eles podem até gerar problemas extras. Como eu interpreto isso? Encontrar problemas de segurança sempre foi uma arte. Mesmo ferramentas de análise estática que adoramos rodar conseguem enxergar apenas problemas simples e limitados. Eu acho razoável combinar as ferramentas existentes com agentes de código que leem o código o tempo inteiro buscando por problemas. E quando achar um e corrigir, um humano revisa. Qualquer bug de segurança encontrado pela máquina é uma vitória. Outro ponto interessante: isso me parece algo temporário. Os modelos estão melhorando cada vez mais rápidos, e imagino que esse problema vai ficar menor a cada dia que passa. ## Referências - [Link para o estudo](https://1password.com/files/resources/frontier-models-vulnerability-patches-flawed.pdf) --- # Como a Prosus reduziu seus custos de IA em 90% Data: 2026-10-09T10:37:25-03:00 URL: https://mauricioaniche.com/blog/como-a-prosus-reduziu-seus-custos-de-ia-em-90/ Idioma: pt-BR O Fabricio Bloisi postou sobre como eles cortaram 90% dos custos de IA dentro da Prosus, que é o grupo que tem o iFood. Dicas do post deles: * Nem todos os problemas precisam do melhor modelo. Conseguir selecionar o modelo certo, e mais barato, ajuda a diminuir custo sem perder precisão. * Metade da memória, o dobro da capacidade. Entender bem o que precisa ser enviado pro agente pode fazer a diferença no custo final. Em conversas mais longas, descartar informação que o modelo não precisa mais, e trazer o dado somente quando o modelo realmente precisa faz diferença. * GPUs que estão paradas também tem custo. Diminuir o "custo" de cada chamada dá mais fôlego aos requests dos usuários. Você também não precisa competir o trabalho do humano, que trabalha em horários específicos, com batch jobs que podem trabalhar de madrugada quando as GPUs estão livres. * Crie modelos especialistas. Modelos destilados, que focam em tarefas específicas, são menores e por consequência mais baratos de serem servidos. Em termos da redução de custo de cada uma dessas iniciativas, eles reportaram: * Encaminhamento de tarefas para o modelo adequado: 50% * Redução da carga de cada solicitação: 20% * Destilação de modelos especializados para tarefas repetitivas: 20% * Utilização de GPU e balanceamento de carga: 10% ## Referências - [Post da Prosus](https://www.linkedin.com/pulse/how-we-cut-our-ai-costs-90-while-growing-fabricio-bloisi-jvbte/) --- # Estratégia e tática: o que o xadrez ensina sobre liderança Data: 2026-10-08T09:15:07-03:00 URL: https://mauricioaniche.com/blog/estrategia-e-tatica-o-que-o-xadrez-ensina-sobre-lideranca/ Idioma: pt-BR Um dos meus maiores desafios como CTO é que eu preciso navegar entre detalhes táticos junto com meu time de engenharia e decisões estratégicas junto com outros diretores. As palavras "estratégia" e "tática" são muito comuns em um dos meus hobbies favoritos: o xadrez. Então senta que lá vem viagem. No xadrez, estratégia é o plano: como vou atacar o rei adversário? quero controlar o centro ou vou atacar pelos flancos? quero ir pra um final agora ou quero jogar mais o meio-jogo? Tática são os movimentos concretos que permitem executar esse plano. Vou avançar esse peão e dar um duplo ataque; vou colocar o cavalo aqui, pq ele vai ser obrigado a mover a dama dele, fragilizando aquela casa onde quero então plantar meu bispo. Como jogador de xadrez, você precisa decidir sua estratégia, e a estratégia é o que vai levar você a ganhar um jogo. Mas há um problema: se não existe nenhuma sequência de movimentos capaz de viabilizar seu plano, você realmente tem uma estratégia? Do que adianta minha estratégia ser dominar o centro, se todos os meus peões centrais já foram embora e o adversário tem um cavalo plantado entre dois peões ali? Acho que o mesmo vale para negócios. Podemos decidir que nossa estratégia é crescer por um determinado mercado, competir por preço ou apostar em um novo canal. Mas, se não conseguimos imaginar ações concretas e plausíveis para fazer isso acontecer, talvez ainda não tenhamos uma estratégia. Temos uma intenção. E de boas intenções, o mundo dos negócios está cheio. Isso não significa que precisamos ter o caminho das pedras bem claro antes de decidir a estratégia. Estratégia lida justamente com incerteza. Mas precisa existir pelo menos um caminho plausível entre “onde estamos” e “onde queremos chegar”. Assim como no xadrez, estratégia e tática podem ser conceitos diferentes, mas é difícil pensar bem em uma sem pensar na outra. PS: Se está procurando por um livro legal de xadrez, adorei o "Winning Chess Strategies" do Yasser Seirawan. --- # FinOps para IA: as lições da Databricks para reduzir custos Data: 2026-10-07T10:08:07-03:00 URL: https://mauricioaniche.com/blog/finops-para-ia-as-licoes-da-databricks-para-reduzir-custos/ Idioma: pt-BR Mais uma empresa compartilhando como está salvando custo de IA. Dessa vez, foi a Databricks: - **Modelos mais eficientes.** Modelos de inteligência máxima não são necessários para muitas das tarefas deles de código. Alternativas "boas o suficiente", inclusive open source como o GLM, estão ficando muito mais baratas, e eles estão fazendo uso. Economia estimada de ~50%. - **Roteamento inteligente.** Não adianta depender da pessoa escolher o modelo mais barato para aquela tarefa. Tem que ser automatizado. Eles agora selecionam dinamicamente o modelo de acordo com a tarefa. Economia: ~30%. - **Visibilidade e orçamento adaptativo.** Cada usuário / dev acompanha seus gastos, recebe dicas para controlá-los e pode até ser bloqueado se ultrapassar certos níveis de consumo. Economia: ~10%. - **Menos contexto desnecessário.** Eles pararam de mandar pra IA aquele monte de resposta de ferramenta que não agrega em nada, e melhoraram as configurações de cache. Economia: ~10%. É o finops pra IA dando resultado. Esses posts sempre me ganham. Eu conto até quantos copos de Coca Cola a gente toma na janta, quem dirá tokens... ## Referências - [Tweet original](https://x.com/pwendell/status/2085781227588714948) --- # Cinco estágios de adoção de agentes: da sessão à fábrica de software Data: 2026-10-06T10:31:21-03:00 URL: https://mauricioaniche.com/blog/cinco-estagios-de-adocao-de-agentes-da-sessao-a-fabrica-de-software/ Idioma: pt-BR Muito legal o texto do pessoal da Kiro, "Como criamos uma software factory com Kiro Crew para mergear 1000 PRs em uma semana". O post diz que existem estágios diferentes de adoção de IA em times de software: * Estágio 1: Uma sessão, na mão. É o primeiro passo, você dev controlando uma única sessão do seu Codex ou Claude. Legal, mas limitado ao que vc consegue fazer em uma sessão. * Estágio 2: Muitas sessões, na mão. Você aprendeu a usar o seu agente, deu o próximo passo e começou a abrir várias janelas e threads com o seu Claude ou Codex. Agora você lida com múltiplos contextos ao invés de um só, mas ainda assim limitado pelo quanto cabe na sua cabeça. * Estágio 3: Memória, dashboard, crons, e workflows. O próximo passo é começar a fazer uso de memória para não ficar repetindo informação pro agente, com um dashboard para te ajudar a controlar suas 10-20 sessões, tendo inclusive cron jobs que disparam agentes de maneira autônoma em diferentes momentos. * Estágio 4: O pipeline de agentes. Vc tem agora um pipeline que é disparado por algum evento, como alguém abrindo uma issue no seu github ou uma mensagem no Slack. O pipeline sabe quais agentes devem atuar e em qual ordem. * Estágio 5: Sessões sendo operadas de maneira agêntica. Até então, o humano era o limitador do processo. Aqui, agentes tomam conta dessas sessões e o humano só garante que os agentes estão focando no objetivo correto. Gosto muito da ideia de tentar explicar o momento que você está e quais os próximos passos pra você conseguir fazer ainda mais uso de agentes. Não sei se esses 5 estágios são os que "ficarão pra sempre", mas com certeza uma boa maneira de pensar! ## Referências - [Post do Kiro Crew](https://kiro.dev/blog/software-factory-1000-prs/) --- # Quando o agente para, vale a pena voltar a programar na mão? Data: 2026-10-05T14:02:16-03:00 URL: https://mauricioaniche.com/blog/quando-o-agente-para-vale-a-pena-voltar-a-programar-na-mao/ Idioma: pt-BR Um fenômeno interessante que tem acontecido comigo é que quando o Codex caiu (ou por instabilidade ou pq meus tokens acabaram) é que eu prefiro esperar a ferramenta voltar do que codar na mão. Mesmo se eu codasse na mão por 2 ou 3 horas, o Codex seria capaz de me alcançar em 10 minutos. Não faz sentido. Vou gastar meu tempo com outras tarefas. --- # Escrever também é pensar: por que preservo minha própria voz Data: 2026-10-02T13:58:15-03:00 URL: https://mauricioaniche.com/blog/escrever-tambem-e-pensar-por-que-preservo-minha-propria-voz/ Idioma: pt-BR Esses dias li o texto do Bret Stephens, no New York Times. Ele levanta uma discussão interessante sobre o uso de IA para escrever. O autor defende não usar IA nem mesmo para organizar notas ou produzir primeiros rascunhos. Três pontos que me chamaram atenção no texto: - Escrever não é apenas comunicar; é uma forma de pensar. O esforço de transformar uma ideia em palavras nos obriga a organizar argumentos, identificar inconsistências e decidir exatamente o que queremos dizer. Ao terceirizar a escrita para uma IA, podemos estar terceirizando parte do processo de pensar. - Até a escrita cotidiana funciona como treinamento. E-mails, relatórios e textos, aparentemente triviais e que poderiam ser delegados pra IA sem "dor na consciência", exercitam as mesmas capacidades usadas em tarefas intelectualmente mais complexas. O argumento do autor é que automatizar sistematicamente essas pequenas atividades pode reduzir a prática necessária para desenvolver e manter a capacidade de escrever e raciocinar. - O impacto pode ir além da qualidade dos textos gerados (que sabemos, é "meia boca"). Ele conecta escrita e leitura com a capacidade de formular e avaliar argumentos. A preocupação, portanto, não é simplesmente termos textos mais genéricos produzidos por IA, mas sim uma possível redução em habilidades relacionadas a pensamento crítico, criatividade e argumentação. É um tópico muito próximo do meu coração, em particular, pq tenho dedicado muito do meu tempo aqui no blog compartilhando minhas experiências. E tenho tido um sentimento parecido. Escrevi um texto 100% com IA apenas uma vez. Queria resumir todos os artigos publicados no MSR Mining Challenge e não conseguiria me dedicar horas lendo todos eles. A IA me ajudou demais, já que em alguns minutos eu consegui ter uma noção dos principais resultados desses papers. Mas o texto claramente não tem alma (veja a referência ao final). Desde então, optei por escrever tudo com meus próprios dedos. Todos artigos que comento aqui, eu os li na íntegra. Às vezes peço para a IA me ajudar a gerar um resumo curto e bacana para o artigo, mas raramente uso o que ela produziu "as is", sempre acabo reescrevendo para ficar com o meu tom. A mesma coisa com apresentações que dou. Crio todos os slides com minhas próprias mãos. Meus slides são muito mais feios do que o Codex geraria pra mim, mas uso o processo de criação para "afinar" minha talk. É muito mais sobre pensar do que fazer. Aliás, sempre coloco o disclaimer no final, "slides feitos por mim, sem IA", e as pessoas adoram. Tá todo mundo querendo um pouco de autenticidade de volta. ## Referências - [Link para a notícia original](https://www.nytimes.com/2026/08/04/opinion/artificial-intelligence-ai-writing.html) - [Link para meu post gerado por IA](https://mauricioaniche.com/blog/ai-agents-in-oss-msr-mining-challenge-2026/) --- # Revise o texto que você gerou com IA antes de pedir que alguém o leia Data: 2026-10-01T14:59:15-03:00 URL: https://mauricioaniche.com/blog/revise-o-texto-que-voce-gerou-com-ia-antes-de-pedir-que-alguem-o-leia/ Idioma: pt-BR Poucas coisas no mundo corporativo moderno são tão ofensivas quanto pedir para alguém ler um texto que você gerou por IA em 5 minutos e não se deu nem ao trabalho de revisar e adicionar seu tom de voz. --- # Disciplina de engenharia continua fazendo diferença com IA Data: 2026-09-30T11:01:10-03:00 URL: https://mauricioaniche.com/blog/disciplina-de-engenharia-continua-fazendo-diferenca-com-ia/ Idioma: pt-BR O Bob Martin escreveu uma frase muito boa: "Humanos disciplinados criam bons sistemas, independentemente de utilizarem agentes ou não. Aqueles que utilizam agentes são simplesmente mais produtivos." Faz todo sentido. Se tem uma coisa que já aprendemos, mesmo antes da IA, é que times mais disciplinados de software entregam software melhor e mais rápido. Aliás, o DORA é a evidência mais recente disso. A mesma coisa agora no mundo pós-IA. Os times mais disciplinados vão acelerar ainda mais com IA. A frase de maneira inversa fica mais interessante: se a IA não está funcionando pra você, a culpa é da IA ou da disciplina do seu time? ## Referências - [Tweet do Bob Martin](https://x.com/unclebobmartin/status/2093662611329933576) --- # Fábricas de software: redesenhar o processo para entregar mais com IA Data: 2026-09-29T14:29:24-03:00 URL: https://mauricioaniche.com/blog/fabricas-de-software-redesenhar-o-processo-para-entregar-mais-com-ia/ Idioma: pt-BR Texto muito legal da Chris Kelly, no LeadDev, chamado "O guia do engenheiro para criar uma fábrica de software". A ideia de software factories vem crescendo rapidamente entre líderes de tecnologia. A ideia é ir além de simplesmente "usar Codex ou Claude" mas sim desenhar uma fábrica onde diferentes agentes atuam em todas as partes do ciclo de desenvolvimento, entregando muito mais do que somente código, mas sim software funcionando. Meus highlights: **1. Coding agents aceleram a escrita de código, mas não necessariamente o sistema de entrega.** Segundo o autor, líderes esperavam ganhos de 2–3x, mas têm observado algo mais próximo de 20–30% no nível organizacional. O motivo é que o código é produzido mais rápido, mas continua passando pelas mesmas filas de review, planejamento e deploy. **2. O próximo passo seriam “software factories”: vários agentes especializados trabalhando em loops de ponta a ponta.** Em vez de um agente fazer tudo, agentes diferentes planejam, implementam, testam, revisam, verificam e decidem quando envolver humanos. Exemplos de loops: PR até merge (ou seja, agentes levam o PR até o merge com a main), ticket até PR (ou seja, desde o ticket aberto pelo usuário até o PR) e alerta até resolução (desde o alerta tocando em produção até a resolução do alerta). **3. O ganho maior vem de redesenhar o processo, não simplesmente de adotar um modelo melhor.** Para isso, precisamos de uma infraestrutura compartilhada de orquestração, ambientes isolados, acesso a contexto, memória, triggers, model routing, governança, e muitas outras coisas para que os agentes tenham tudo o que precisam para trabalhar de ponta-a-ponta. A ideia da software factory é que os ganhos reais da IA só vão aparecer quando todo o SDLC for reorganizado em torno dos agentes, e não quando eles são apenas adicionados ao workflow existente, que é o que fazemos hoje. ## Referências - [Texto original](https://leaddev.com/software-quality/the-engineers-guide-to-building-a-software-factory) --- # A plataforma de desenvolvimento com IA é o próximo desafio Data: 2026-09-28T14:15:26-03:00 URL: https://mauricioaniche.com/blog/a-plataforma-de-desenvolvimento-com-ia-e-o-proximo-desafio/ Idioma: pt-BR Muito dos problemas que vejo as pessoas reportando sobre código gerado por IA é falta de um "prompt melhor". Ah, mas eu não deveria ter que pedir pra IA não gerar um N+1 ou escrever uma query não-otimizada. O dev não deveria "perder tempo" focando nisso. Sem dúvida. Do mesmo jeito que o dev não deveria perder tempo pensando em configurar infraestrutura, deploy, monitoramento, ou pensar em como conectar no banco de dados, ou configurar cache. Abstrair todas essas coisas do dev para que ele possa focar no produto sempre foi a missão dos times de plataforma ("platform engineering"). IA é só mais uma caixinha que precisamos encaixar lá. Para que, quando o dev pedir uma funcionalidade, a plataforma de desenvolvimento IA explicitamente garante que o N+1 não acontece e todas as outras garantias que são importantes no seu desenvolvimento. As LLMs e os harnesses já estão lá. Nosso desafio agora é criar essa plataforma. Tem muito desafio, o não-determinismo não ajuda, existe pouco material na internet, e você ainda precisa de coragem pra sair reusando skills que estão na internet (engraçado pensar que reutilizamos projetos open-source sem nunca ter lido uma linha do que está lá, mas temos mais medo com skills). Mas quem acertar isso, vai sair na frente. --- # Os bugs da IA estão mudando: de lógica para arquitetura e contexto Data: 2026-09-28T10:26:24-03:00 URL: https://mauricioaniche.com/blog/os-bugs-da-ia-estao-mudando-de-logica-para-arquitetura-e-contexto/ Idioma: pt-BR O Boris Cherny (dev na Anthropic, criador do Claude) fez um tweet interessante sobre a qualidade do código gerada pelas LLMs. Segundo ele, os LLMs ainda produzem bugs, mas esses bugs são diferentes dos que costumavam ser. Não se trata mais dos off-by-one errors (aqueles erros onde você trocou um maior por um maior-ou-igual), mas sim de arquitetura, usabilidade da interface do usuário, e decisões erradas por falta de um contexto mais amplo. Sinto algo parecido. Do ponto de vista algorítmico e lógico, a velocidade com que os modelos melhoraram no último ano é absurdo. Lembro-me de usar o Haiku e ele já errar pouco, agora com Sol e Astra (aqui na Alura, usamos Codex), raramente vejo erro de lógica. O desafio agora é continuar adicionando guardrails para que as LLMs entendam mais do produto que queremos construir. ## Referências - [Tweet original](https://x.com/bcherny/status/2087284684103537011) --- # Quem usa IA continua responsável pela qualidade da entrega Data: 2026-09-25T15:47:17-03:00 URL: https://mauricioaniche.com/blog/quem-usa-ia-continua-responsavel-pela-qualidade-da-entrega/ Idioma: pt-BR O Tobi, CEO da Shopify e um grande proponente do uso de IA, disse que tarefas feitas de maneira desleixadas com IA estão gerando muito trabalho para a companhia. Ele disse que tem visto muitos emails que não foram revistos, e portanto, cheio de erros. "Você não lê o texto e, agora, ele precisa ser revisado pelos seus colegas, que dizem algo como: 'isso não parece certo' [...] Você está simplesmente deixando a IA fazer o trabalho por você." Precisamos colocar a responsabilidade da garantia a qualidade na pessoa que fez uso da IA. Vc usou IA, ótimo, mas você precisa garantir que o conteúdo faz sentido. Seja revisando manualmente ou, mais inteligente ainda, criando guardrails para garantir isso de maneira automatizada. Apertar um enter e passar a bucha pro próximo não vai te levar e levar o seu time muito longe. ## Referências - [Notícia citada](https://fortune.com/2026/09/17/shopify-tobias-lutke-ai-slop-grenades/) --- # Quanto código gerado por IA precisamos revisar? Data: 2026-09-25T14:43:18-03:00 URL: https://mauricioaniche.com/blog/quanto-codigo-gerado-por-ia-precisamos-revisar/ Idioma: pt-BR A quantidade de linhas de código que estamos produzindo é gigante comparado com dois anos atrás. É tanta que nem você, que está gerando esse código, consegue acompanhar e entender tudo que está sendo produzido. O Guillermo Rauch, CEO da Vercel, postou esses dias sobre ler código. A opinião **polêmica** dele foi: se você não está lendo código, um desses é verdade: - Você é iniciante - O software é descartável - Você está criando protótipos - Você não tem usuários/receita - Você está assumindo dívidas e riscos - Seus problemas são básicos Meus dois centavos: A IA é sim capaz de escrever código que funciona e resolve problemas complexos, mas precisa ser bem guiada. Mas a real é que não temos ainda os guardrails corretos para garantir isso. Hoje, a IA vai de vez em quando quebrar seu sistema, se você não tomar conta. Isso é um super problema, e em particular, em sistemas complexos onde o custo de uma falha é gigante. Cada time vai precisar entender o quanto de revisão de código, da própria pessoa, de uma pessoa externa, de um outro agente de IA, é necessária para garantir que o sistema funciona, ao mesmo tempo em que trabalha na sua fábrica e nos seus guardrails para que essas revisões sejam cada vez menos necessárias. ## Referências - [Post do Guillermo](https://www.linkedin.com/posts/rauchg_if-youre-not-reading-the-code-whether-explicitly-share-7492281174262890496-pSqq/) --- # Como ensinar computação quando escrever código já não é o maior desafio Data: 2026-09-24T10:38:07-03:00 URL: https://mauricioaniche.com/blog/como-ensinar-computacao-quando-escrever-codigo-ja-nao-e-o-maior-desafio/ Idioma: pt-BR O mundo todo está discutindo o que será da educação em engenharia de software. Saiu um texto legal na Communications of ACM, uma revista mais técnica da ACM, escrita por acadêmicos, com o título "Computing ed when writing code is no longer the challenge", em português, "Educação em computação quando escrever código não é mais o desafio". De acordo com os autores, a IA generativa exige uma mudança importante na forma como ensinamos computação. Três pontos me chamaram a atenção: 1. **Escrever código não é mais o principal desafio.** O foco começa a migrar para especificar problemas, projetar soluções e compreender, avaliar e validar o código produzido pela IA. 2. **Proibir IA não resolve.** Precisamos ensinar os alunos a utilizá-la de maneira efetiva, crítica e ética — e repensar objetivos de aprendizagem e avaliações para esse novo contexto. 3. **Com sistemas agênticos, o papel humano muda ainda mais.** Se a IA também consegue decompor problemas, planejar e implementar soluções, competências como supervisionar o agente, avaliar e auditar a sua produção, e definir restrições para que o agente opere cada vez mais de forma independente ganham força. Gosto muito de ler a opinião de professores de universidades sobre educação em computação, pois eles estão recebendo centenas de novos alunos todo semestre, e precisam não só acompanhar a evolução tecnológica mas também a mudança geracional. Já fui um e sei o quão intenso (e maravilhoso!) é. É um ótimo texto e vale a leitura. Aqui compartilho um resumo dos pontos que me chamaram a atenção. Meus dois centavos: tanto a indústria quanto a academia já entenderam que escrever código não é mais o desafio principal e o que o papel do dev vai mudar. Falo sobre isso quase que diariamente aqui. Do ponto de vista de educação, a pergunta ainda em aberto pra mim é sobre o quanto de IA o aluno deve usar enquanto aprende. Não usar IA não faz sentido, a IA veio pra ficar. Mas usar IA pra 100% também pode fazer com que ele não aprenda de verdade. Não tenho resposta, só dúvidas por enquanto. ## Referências - [Texto da CACM](https://cacm.acm.org/opinion/computing-education-when-writing-code-is-no-longer-the-challenge/) --- # Julgamento, priorização, proatividade e bom gosto na engenharia de software Data: 2026-09-23T14:10:05-03:00 URL: https://mauricioaniche.com/blog/julgamento-priorizacao-proatividade-e-bom-gosto-na-engenharia-de-software/ Idioma: pt-BR Um trecho muito interessante do Deep Dive do Gergely sobre a visão da OpenAI sobre o que diferencia um bom engenheiro de software hoje: * Julgamento: Essa abordagem é a correta? Tem alguma maneira melhor de fazer isso? Devemos entregar essa funcionalidade ou não? * Priorização: Qual a próxima coisa que devemos construir agora? O que não vale a pena gastar tempo agora? * Proatividade: Os melhores engenheiros estão sempre gerando ideias, entregando de maneira eficiente, resolvendo problemas de maneira autônoma * Bom gosto: Engenheiros que sabem o que significa algo realmente bem feito produzem tudo melhor, desde funcionalidades até código. O mais interessante é notar que essas características sempre foram diferenciais de um engenheiro de software, mesmo no mundo pré-IA. Pode perguntar pra qualquer líder: o dev proativo, com bom julgamento, com bom gosto, e que sabe o que é importante de ser feito, sempre valeu ouro. A IA só subiu a barra. ## Referências - [Newsletter do Gergely](https://newsletter.pragmaticengineer.com/p/openai-software-factory) --- # Revisão por exceção: repensando o code review na era dos agentes Data: 2026-09-23T10:28:18-03:00 URL: https://mauricioaniche.com/blog/revisao-por-excecao-repensando-o-code-review-na-era-dos-agentes/ Idioma: pt-BR A Rachel Laycock (CTO da Thoughtworks) escreveu um texto muito interesse sobre code review. Ela levanta um ponto que todos que já estão codando com IA perceberam: se agentes vão gerar muito mais código, continuar exigindo revisão humana de todo diff cria um gargalo. E talvez isso signifique que estávamos usando code review para resolver problemas que deveriam ser tratados antes. De acordo com ela, code review acumulou várias responsabilidades: encontrar bugs, transferir conhecimento, mentorar, garantir alinhamento arquitetural e funcionar como mecanismo de propriedade. Isso funcionou enquanto humanos geravam código a uma taxa limitada. Com IA, o volume cresce e o modelo “faça algo - abra PR - outra pessoa revisa” não escala mais. A proposta dela é sobre mover a avaliação do código para a esquerda. Não é muita novidade. Programação Extrema sempre preferiu programação pareada do que revisão de código. Dave Farley também fala muito sobre PP para você pegar o problema na medida que ele acontece ao invés de esperar por etapas mais pra frente. Ela também sugere a "revisão por exceção", e usar pessoas para revisar código quando o julgamento de uma pessoa externa realmente importa: mudanças fundamentais de arquitetura, alteração de segurança, áreas críticas pouco familiares, etc. Minha opinião: - Também acho que revisão de código, do jeito que é hoje, com humanos revisando 100% dos PRs está com seus dias contados. Não vai escalar para a quantidade de código que vamos gerar. - Se você analisar com bastante cuidado, muitas das revisões de código são apenas "LGTM", mas outras são realmente densas e rolam boas discussões. De maneira implícita, nós já decidíamos quais PRs realmente mereciam nossa atenção e quais não. Isso vai só ficar agora mais formal, e com técnicas mais claras para decidirmos o que revisar e o que não revisar. - No mundo agêntico, o trabalho agora é também sobre não só comentar o código do produto, mas entender o que você pode mudar na sua fábrica para que na próxima vez o agente gere o código que você quer. - Revisão de código como maneira de aprender e treinar juniores vai desaparecer. Vamos precisar encontrar outras maneiras de acompanhar o trabalho do junior e dar feedback. Programação pareada também me parece o caminho. ## Referências - [Texto da Rachel Laycock](https://martinfowler.com/rachels-ramblings/code-review.html) --- # O que aprendi sobre a fábrica de software agêntica da OpenAI Data: 2026-09-22T15:01:19-03:00 URL: https://mauricioaniche.com/blog/o-que-aprendi-sobre-a-fabrica-de-software-agentica-da-openai/ Idioma: pt-BR Acabei de ler o deep dive "Inside OpenAI’s agentic software factory" do The Pragmatic Engineer. Muitas coisas legais. Algumas delas: * A morte das IDEs e dos PRs. No começo do Codex, eles estavam na dúvida se uma ferramenta entre o CLI e a IDE teria sucesso. Mas o tempo mostrou que sim. Eles observaram uma queda gigante no uso de IDEs e a migração para o Codex. Faz todo sentido. Também acho que não precisamos de IDEs da mesma maneira que precisávamos quando escrevíamos software linha-a-linha. Minha expectativa é que vamos ler código cada vez menos. Não vai chegar a zero tão cedo, mas com certeza muito menos do que lemos hoje. * Code review precisa mudar. Revisar todos os PRs não escala mais. A software factory deles decide se o PR precisa de revisão humana. Mudanças simples são mergeadas direto; só mudanças mais complexas são ainda roteadas por humanos. Também acho que revisão de código vai mudar. Em poucas palavras, revisão de código também foi feito para quando pessoas escreviam código, na velocidade com que pessoas conseguiam escrever código. * Agentes criando seus próprios dashboards para monitorar o deploy. O agente não só tem acesso a métricas do Datadog, mas também opta por gerar seu próprio dashboard para acompanhar o lançamento daquela funcionalidade. Essa me surpreendeu. Aqui na Alura também usamos Codex para acompanhar o datadog, em especial, em situações de incidente. Agora, o agente decidir criar um dashboard próprio, achei demais. * Codex como principal agente em momentos de incidente. Eles tem um bot chamado SevBot que é disparado sempre que um incidente acontece. O bot olha pra tudo que pode e sugere mudanças. Ele não toma decisões, o humano toma. Se você nunca usou Codex para investigar problemas em produção, você ficaria surpreso! * Usando Astra pra migrar de Python pra Rust. Eles estão fazendo uma migração gigante de Python pra Rust, basicamente feita por 2 engenheiros e o Astra. Concluímos bem recentemente uma migração gigantesca de Spring Boot 2 para Spring Boot 4 aqui na Alura. Escrevemos também um relato dessa jornada. Mas é isso aí, migrações que antes pareciam impossíveis, agora são possíveis. Tem muito mais coisa na newsletter! Assinem a newsletter e leiam! ## Referências - [Link](https://newsletter.pragmaticengineer.com/p/openai-software-factory) --- # Fundamentos de computação continuam importantes para programar com IA Data: 2026-09-22T10:21:19-03:00 URL: https://mauricioaniche.com/blog/fundamentos-de-computacao-continuam-importantes-para-programar-com-ia/ Idioma: pt-BR Um experimento da ETH Zurich avaliou 100 desenvolvedores em um ambiente controlado de “vibe coding”. Isto é, construir software majoritariamente via IA, sem tocar diretamente em muito código. Principais achados: - A capacidade de comunicação escrita da pessoa faz diferença. Saber estruturar pensamento e articular intenções importa muito para o que a IA vai gerar. - Formação e conhecimento em CS foram o fator dominante. Mesmo controlando por variáveis como inteligência geral da pessoa, ter um background em ciência da computação foi a principal variável que separou as pessoas que realmente conseguiram criar algo que funcionasse daquelas que não conseguiram. De acordo com os autores, codar com IA exige muito da pessoa. O dia-a-dia é muito sobre diagnosticar o que não funciona, corrigir lógica fazendo o pedido certo pra IA. Usuários não técnicos tendem a confiar na interface aparente, não sabem explorar bem a aplicação para procurar por bugs, e não sabem quais perguntas fazer nem quais falhas arquiteturais identificar. Dito isso, enxergo algumas consequências práticas: - Investir em aprender fundamentos de engenharia de software ainda é um bom investimento. Para aqueles alunos e alunas, que nos mandam perguntas, aqui uma pequena evidência científica disso. - Os fundamentos de engenharia vão ficar ainda mais importantes quando conseguirmos realmente desenhar fábricas de software via IA. Manter a fábrica vai ser ainda mais trabalhoso do que escrever o código do produto. É aqui onde o grupo Alun como um todo pode te ajudar demais. A Alura tem milhares de cursos que vão desde o básico da engenharia de software até técnicas avançadas de programação com IA. E se vc tem tempo para fazer uma graduação, a FIAP também oferece graduações em CC e em engenharia de software. Bora virar dev, pessoal! ## Referências - [Tweet original](https://x.com/thesupermannx/status/2096168441338384609) --- # Human-in-the-loop: em qual loop o engenheiro deve estar? Data: 2026-09-21T10:13:19-03:00 URL: https://mauricioaniche.com/blog/human-in-the-loop-em-qual-loop-o-engenheiro-deve-estar/ Idioma: pt-BR Falamos muito de human-in-the-loop em engenharia de software agêntica. Eu também acho que o humano sempre estará no loop. A pergunta é: em qual loop? Pra mim, o humano estará sempre no loop da "fábrica de software", garantindo que a IA tem o que precisa pra escrever código que funciona, que tem o que precisa pra tomar decisões arquiteturais de maneira sólida, que sabe como operar o sistema, inclusive em momentos de caos. Quanto mais conseguirmos tirar o humano do loop da escrita do código do produto em si, pra focar na fábrica, mais software vamos entregar. Quem aí já começou a desenvolver a sua fábrica de software com IA? --- # IA no desenvolvimento: precisamos começar pela operação Data: 2026-09-18T10:09:12-03:00 URL: https://mauricioaniche.com/blog/ia-no-desenvolvimento-precisamos-comecar-pela-operacao/ Idioma: pt-BR Estamos colocando IA na engenharia de software da "esquerda pra direita". Já temos muito bons agentes pra fazer requisitos e escrita de código. Mas quando chega em revisão de código, mergear PR, muitos times, incluindo os nossos, ainda fazem de forma 100% manual. Mesma coisa pra deploy, monitoramento e operação. Mesmo pré-IA, quem trabalha em sistema de larga escala sempre soube que o desafio é o que está mais a direita do fluxo. Não é escrever o código o que sempre doeu, mas sim subir uma versão nova, garantir que ela funciona, monitorar, voltar pra trás se algo quebrou, seja via mudar feature flag ou em último caso, revert e push. Esse sempre foi e sempre será o mais difícil. Precisamos inverter a lógica, e começar a ir "da direita pra esquerda", e ter agentes olhando pra monitoramento, rollback automático, verificação automática da PR. --- # Profissionais de alto impacto: quando a IA amplia a atuação individual Data: 2026-08-31T15:02:19-03:00 URL: https://mauricioaniche.com/blog/profissionais-de-alto-impacto-quando-a-ia-amplia-a-atuacao-individual/ Idioma: pt-BR A IA pode transformar profissionais individuais em departamentos inteiros? Com novas ferramentas, especialistas conseguem ampliar sua capacidade de análise, criação e execução, conduzindo projetos complexos com mais autonomia e velocidade. Esse movimento impulsiona o surgimento dos High-Impact Individual Contributors (HI-C), profissionais capazes de conectar conhecimento técnico, visão de negócio e uso estratégico da tecnologia para gerar resultados. Para as empresas, o desafio passa a ser preparar esses talentos. A vantagem competitiva não está apenas no acesso às ferramentas de IA, mas na capacidade das pessoas de aplicá-las para resolver problemas relevantes. Sua empresa já está preparando profissionais para esse novo cenário? --- # O novo gargalo da engenharia de software é supervisão e decisão técnica Data: 2026-08-24T15:06:20-03:00 URL: https://mauricioaniche.com/blog/o-novo-gargalo-da-engenharia-de-software-e-supervisao-e-decisao-tecnica/ Idioma: pt-BR O gargalo da engenharia de software mudou e muitos times ainda não perceberam! Antes o desafio era capacidade de desenvolvimento. Com IA gerando código mais rápido do que os times conseguem revisar, o novo problema é supervisão e decisão técnica. Isso exige um upgrade real no perfil do dev, que precisa evoluir de executor de código para system thinker, de implementador para supervisory engineer, de revisor manual para engenheiro que decide onde o humano precisa atuar. E há um ponto que não muda: boa engenharia continua sendo a base. A IA não corrige arquitetura frágil nem substitui julgamento técnico. Nenhum modelo escolhe seus trade-offs. O time de engenharia da sua empresa já está sendo desenvolvido para essa nova realidade? Fale com o nosso time e conheça as nossas soluções! --- # Liderar a adoção de IA exige conversar com quem enfrenta os mesmos desafios Data: 2026-08-20T10:30:19-03:00 URL: https://mauricioaniche.com/blog/liderar-a-adocao-de-ia-exige-conversar-com-quem-enfrenta-os-mesmos-desafios/ Idioma: pt-BR Muita gente fala em "adotar IA". Poucos falam sobre como é liderar times enquanto isso ainda não tem manual. Não existe playbook pronto. O que mais ajuda nessas decisões vem de conversas com quem está travando no mesmo ponto que você, em outra empresa, com outro time, mas com o mesmo tipo de problema. Com qual frequência você se reune com líderes de tecnologia do mercado brasileiro e fala sobre IA? Por isso, decidimos promover esse tipo de conversa, no Alura Signals Experience, dias 10 e 11 de setembro em São Paulo. Eu, o Paulo Silveira, o Guilherme Silveira, o Sérgio Lopes e Guilherme Pereira, todos diretores do grupo Alun, Alura, e FIAP, estaremos lá debatendo as transformações que já estão impactando produtos, carreiras e decisões de negócio. Se seu time também está tentando resolver isso sozinho, talvez a saída não seja resolver sozinho. Garanta a sua vaga no Alura Signals Experience. Veja as referências ao final. ## Referências - [Inscreva-se já](https://carreira.alura.com.br/signals) --- # FinOps para IA: as lições da Coinbase sobre modelos, cache e contexto Data: 2026-08-19T11:04:17-03:00 URL: https://mauricioaniche.com/blog/finops-para-ia-as-licoes-da-coinbase-sobre-modelos-cache-e-contexto/ Idioma: pt-BR FinOps pra IA está só começando. Vi um post legal do Brian Armstrong, co-founder do Coinbase. - A escolha do modelo padrão importa. O dev deve ser capaz de mudar de modelo, mas o modelo padrão importa, pois é o que o povo realmente usa. Eles estão usando modelos mais baratos como padrão e percebem que os devs não estão mais batendo nos seus limites de uso pessoais mais. - Melhor roteamento. O sistema vê o prompt do usuário e roteia para o melhor modelo. Por exemplo, se for uma tarefa de planejamento, um modelo mais avançado é melhor; mas para uma tarefa simples do dia-a-dia, um super modelo é demais. - Cache é importante. Fazer bom uso do cache é importante para reduzir custos. - Mantenha o contexto enxuto. Comece novas sessões quando começar uma nova tarefa. Adicione só o que precisar, incluindo arquivos e ferramentas. O objetivo não deve ser menos tokens usados, mas sim menos tokens desperdiçados. - Mais visibilidade. O time pode usar quantos tokens quiser, mas quanto mais token você usar, maior o impacto esperado de você. Com tudo isso em prática, os custos deles caíram pela metade enquanto o uso de tokens subiu! Pra quem me acompanha aqui, sabe que eu sou fã (leia-se mão de vaca) da ideia de FinOps pra IA. Veja a referência ao final. ## Referências - [Tweet original](https://x.com/brian_armstrong/status/2070670644577280109?s=46&t=83Fo6IcQ9bNl-SS6uJZuMA) --- # Treinamento corporativo: medir atividade não basta para medir impacto Data: 2026-08-18T13:33:34-03:00 URL: https://mauricioaniche.com/blog/treinamento-corporativo-medir-atividade-nao-basta-para-medir-impacto/ Idioma: pt-BR Será que a sua estratégia de T&D ainda reproduz alguns dos principais mitos sobre treinamento corporativo? Durante muito tempo, medir horas treinadas, cursos concluídos e certificados pareceu suficiente. Esses indicadores continuam importantes, mas já não respondem sozinhos se a aprendizagem gerou impacto no dia a dia, contribuiu para a performance ou ajudou o negócio a avançar. Quando a estratégia continua presa a essas premissas, fica mais difícil aproximar desenvolvimento e resultado. Vale revisar essas premissas e perguntar se a aprendizagem do time está se traduzindo em resultados para o negócio. --- # Construir ou comprar software continua sendo uma decisão difícil Data: 2026-08-17T10:54:14-03:00 URL: https://mauricioaniche.com/blog/construir-ou-comprar-software-continua-sendo-uma-decisao-dificil/ Idioma: pt-BR Acho que o SaaS está longe de morrer... Vi um post do Roja Buck contando uma história onde eles criaram internamente um substituto do Monday. Os primeiros 80% saíram bem rápido, os 20% restantes é onde você trava, e o 5% final nunca fica pronto. Eles também observam que os times que decidiram criar suas próprias ferramentas gastam por volta de 15%-20% da sua capacidade mantendo esse ferramental. Capacidade essa que não estava no orçamento inicial do time. Como ele mesmo disse: "o demo foi brilhante; manter de pé tornou-se um fardo." Construir ou comprar, o famoso "build vs buy" nunca foi uma decisão fácil. A IA "bagunçou" a decisão porquê agora é fácil criar software. Mas, como todos nós já sabemos (e sabíamos antes da IA), criar a v1 é sempre a parte fácil. Precisa ser mesmo uma decisão bem pensada, pois ela sempre vai ter prós e contras. ## Referências - [Link pro post original](https://www.linkedin.com/posts/rojabuck_buildvsbuy-softwareengineering-technicaldebt-share-7475095555900297216-aZhy/) --- # Agentes de IA: simplicidade, determinismo e observabilidade Data: 2026-08-14T14:45:27-03:00 URL: https://mauricioaniche.com/blog/agentes-de-ia-simplicidade-determinismo-e-observabilidade/ Idioma: pt-BR O Bjorn, engenheiro de IA da Adyen, empresa que eu trabalhei e tenho muito carinho, apresentou no Agents and APIs Developer Meetup, um meetup lá no escritório da Adyen em Madrid. - O que dá pra ser determinístico, faça de maneira determinística. Não precisa deixar tudo pra LLM. (Aqui, lembro-me de ver uma palestra de um engenheiro da Anthropic falando a mesma coisa!) - Comece simples. Às vezes uma simples chamada para o LLM já o suficiente para a sua v1. Adicione complexidade, pense em agentes mais complexos, apenas quando realmente necessário. - Observabilidade. Você precisa ser capaz de analisar o comportamento do seu agente. Veja as referências ao final. ## Referências - [Link para o post original](https://www.linkedin.com/posts/bjorn-van-dijkman_spent-a-bit-more-time-on-stage-in-june-and-share-7480946995881291776-Os8J/) --- # Hora de descansar: os agentes também podem esperar Data: 2026-08-12T15:34:22-03:00 URL: https://mauricioaniche.com/blog/hora-de-descansar-os-agentes-tambem-podem-esperar/ Idioma: pt-BR Até umas semanas atrás, eu ia pra cama e ficava ansioso. Deixa eu botar mais um agente pra rodar, pra não perder a janela de noite. Assistia TV com a esposa e ficava de olho no celular pra ver se o agente terminou e se dava tempo de disparar mais um agentezinho antes de dormir. Percebi que isso não estava sendo saudável. Hora de parar de trabalhar é hora de parar de trabalhar. A mente precisa descansar também. --- # A fatura da IA chegou: como conectar custo e retorno Data: 2026-08-12T15:00:24-03:00 URL: https://mauricioaniche.com/blog/a-fatura-da-ia-chegou-como-conectar-custo-e-retorno/ Idioma: pt-BR A fatura da IA chegou e ela está maior do que muitas empresas esperavam! O motivo é simples: o modelo de cobrança mudou. Se antes as ferramentas de IA funcionavam como assinatura fixa, hoje o custo é por uso. Quanto mais a empresa usa, mais paga. Empresas como Uber, Coinbase e Salesforce já revisam seus investimentos, questionando o retorno real sobre o que foi gasto. A resposta passa por mapear onde a IA gera retorno de verdade, capacitar as pessoas para extrair mais resultado com menos custo e criar governança clara sobre quando e como usar a tecnologia. Na sua empresa, os gastos com IA já têm critérios claros de retorno? --- # Automação com IA: quais competências desenvolver na sua carreira? Data: 2026-08-10T14:54:24-03:00 URL: https://mauricioaniche.com/blog/automacao-com-ia-quais-competencias-desenvolver-na-sua-carreira/ Idioma: pt-BR Seu trabalho tem mais ou menos chances de ser automatizado pela IA? Algumas atividades têm maior potencial de automação, enquanto outras dependem de habilidades que continuam sendo essencialmente humanas, como pensamento crítico, criatividade e tomada de decisão. Entender onde sua carreira se encaixa nesse cenário ajuda a identificar quais competências desenvolver para acompanhar as mudanças. Para profissionais e empresas, o caminho passa pela evolução contínua ao combinar conhecimento em IA com habilidades humanas que ampliam a capacidade de gerar valor. Sua empresa já está preparando as pessoas para esse novo cenário? --- # Resolver o problema ou resolver uma classe de problemas? Data: 2026-08-10T10:32:27-03:00 URL: https://mauricioaniche.com/blog/resolver-o-problema-ou-resolver-uma-classe-de-problemas/ Idioma: pt-BR O Dax, um dos criadores do OpenCode, deu um conselho que gostei muito sobre como ser bom no seu trabalho: - Perceber que algo é, na verdade, composto por duas coisas distintas - Perceber que, em vez de resolver o problema imediato, você pode resolver um problema mais amplo - Em vez de implementar uma coisa, implementar outra que facilite a implementação da primeira Quebrar um problema grande em um problema menor, e entender quando você deve resolver a classe inteira do problema ao invés daquela instância específica, separam bem aqueles que ainda estão no começo de carreira para pessoas mais sêniores! ## Referências - [Post original](https://www.linkedin.com/posts/thdxr_how-to-be-good-at-your-job-realize-this-share-7468476500728496128-iDsL/) --- # Pensamento sistêmico e excelência: lições da liderança da Netflix Data: 2026-08-07T14:29:28-03:00 URL: https://mauricioaniche.com/blog/pensamento-sistemico-e-excelencia-licoes-da-lideranca-da-netflix/ Idioma: pt-BR O Lenny entrevistou a Elizabeth, CPTO do Netflix. Algumas das ideias que achei legal: - O pensamento sistêmico, conseguir olhar para o todo, é a habilidade mais importante nesse novo mundo da IA. E é possível aprender. Dê sempre um passo atrás, e tente entender melhor o problema que está resolvendo e como ele ajuda o negócio a ir pra frente. - A confusão em relação a cargos e carreiras é normal. Foque em qualidade, guardrails, e responsabilidade. - Excelência é fundamental. Em todos os sentidos. Pessoas boas, contexto e não controle, e um ambiente de confiança com responsabilidade são importantes. - Profissional em T é o profissional do futuro. Batemos muito nessa tecla na Alura. Veja as referências ao final. ## Referências - [Link para o post](https://www.linkedin.com/posts/lennyrachitsky_my-biggest-takeaways-from-netflixs-chief-share-7485043345195429889-5238/) --- # Deixe para os humanos as coisas que são humanas Data: 2026-08-05T10:21:23-03:00 URL: https://mauricioaniche.com/blog/deixe-para-os-humanos-as-coisas-que-sao-humanas/ Idioma: pt-BR Nas últimas duas semanas, vi dois CEOs famosos falando sobre os agentes de IA deles e o quanto eles têm "ajudado". Um deles comentou que o agente mandava parabéns aos seus familiares nas datas dos aniversários deles; o outro comentou que o agente gerava áudio para que os filhos ouvissem durante o trajeto do carro até a escola. Pessoal, deleguem para a IA aquelas coisas em que é perda de tempo nós, como humanos, fazermos; e deixem ainda para os humanos as coisas que são humanas. Deem parabéns aos seus familiares e conversem com seus filhos vocês mesmos :) --- # Memória dos agentes: quanto contexto realmente precisamos guardar? Data: 2026-08-03T11:00:12-03:00 URL: https://mauricioaniche.com/blog/memoria-dos-agentes-quanto-contexto-realmente-precisamos-guardar/ Idioma: pt-BR Lembro-me de quando tanto o Claude quanto Codex anunciaram uma sequência de melhorias em relação a memória do harness. Em particular, eles agora conseguem lembrar de coisas que aconteceram em sessões anteriores e reutilizar esse conhecimento. Você já deve ter sentido isso inclusive no ChatGPT. Ele lembra dos seus últimos projetos e tenta conectar as respostas com esse "conhecimento do além". Eu sempre vi essas funcionalidades de memória, onde informação vem de lugares que eu não faço ideia, de maneira bem cética. Me incomoda o fato fazer o agente ser ainda mais não-determinístico do que ele já é. Também lembro de quando as pessoas estavam pirando em guardar todo e qualquer planejamento de funcionalidade que o agente já fez em markdown, para que o modelo pudesse ter acesso a eles. Sempre achei que isso, no longo prazo, iria mais confundir o modelo do que ajudar. Vi um tweet do Jerry Liu e Dex Horty sobre o jantar que eles organizaram (veja o tweet nas referências ao final). E uma das ideias discutidas lá foi exatamente essa: "A quantidade mínima de contexto necessária para a IA pode ser apenas a base de código acompanhada de alguma documentação. Quaisquer arquivos de pesquisa ou planejamento destinam-se a tarefas pontuais e não precisam ser mantidos. Ter uma wiki auto-organizada é interessante, mas adiciona complexidade." Um bom AGENTS.md e o seu código são suficientes. ## Referências - [Link para o tweet](https://x.com/jerryjliu0/status/2082673383255216356) --- # Engenharia de software agêntica além do hype no TDC Rio Data: 2026-07-31T15:32:08-03:00 URL: https://mauricioaniche.com/blog/engenharia-de-software-agentica-alem-do-hype-no-tdc-rio/ Idioma: pt-BR Eu estarei no Rio Innovation Week, dentro do The Developers Conference (TDC), na semana que vem, dia 6/agosto, falando sobre "Engenharia de software agêntica além do hype". Veja as referências ao final. Nos vemos lá! ## Referências - [Link do evento](https://thedevconf.com/tdc/2026/stage/rio/) --- # As habilidades mais buscadas e o desafio de preparar os times Data: 2026-07-22T09:05:11-03:00 URL: https://mauricioaniche.com/blog/as-habilidades-mais-buscadas-e-o-desafio-de-preparar-os-times/ Idioma: pt-BR Essas são as habilidades mais buscadas no mercado brasileiro em 2026, segundo um estudo recente no LinkedIn: IA, engenharia de software, cibersegurança, marketing estratégico e gestão de projetos lideram a lista. Não por acaso: são exatamente as competências que sustentam a transformação digital em curso nas organizações. Mas o dado que mais chama atenção está nos bastidores: 1 em cada 5 profissionais no mundo afirma que a falta de qualificação dificulta a busca por emprego. Com o avanço da tecnologia ganhando velocidade, cresce também a necessidade de competências especializadas. Para as lideranças, a pergunta deixa de ser "quais habilidades o mercado vai exigir?" e passa a ser "o meu time está preparado para o que já está acontecendo?" --- # IA na liderança: da automação à qualidade das decisões Data: 2026-07-15T09:00:23-03:00 URL: https://mauricioaniche.com/blog/ia-na-lideranca-da-automacao-a-qualidade-das-decisoes/ Idioma: pt-BR A IA já começou a orientar decisões dentro das empresas! Por muito tempo, o foco estava na automação: ganhar velocidade, reduzir custos e otimizar processos. Esse papel ainda existe, mas algo mais profundo está em curso. Lideranças estão usando IA para estruturar dados, reduzir incertezas e elevar a qualidade das decisões. O impacto deixou de ser operacional e passou a ser estratégico. E os dados confirmam esse movimento: 62% dos executivos no Brasil já utilizam agentes de IA nas empresas que lideram, segundo estudo do National Research Group. O diferencial não está mais no acesso à IA, mas sim na capacidade de interpretar, conectar e decidir a partir dela. Na sua liderança, a IA já está sendo usada para tomar decisões melhores? --- # Da experimentação ao impacto: maturidade em engenharia de software com IA Data: 2026-07-09T08:59:18-03:00 URL: https://mauricioaniche.com/blog/da-experimentacao-ao-impacto-maturidade-em-engenharia-de-software-com-ia/ Idioma: pt-BR Entre o acesso à IA e o impacto real no negócio, existem gaps que a maioria das empresas ainda não fechou! Para Guilherme Pereira, Diretor de Inovação, Programas & Experiências da Alun Business, o problema não está na falta de ferramentas. Times experimentam muito, mas não conseguem conectar IA com estratégia e resultado concreto. Outros desafios são um ritmo de mudança maior do que a capacidade de atualização das pessoas e engenharia de software despreparada para a era da IA. Entre as soluções, o primeiro passo para mudar esse cenário é entender onde o time realmente está. E o Radar de Maturidade em Engenharia de Software com IA faz o diagnóstico em 5 minutos, com 8 níveis, 3 horizontes e passo a passo claro. A proposta é ajudar a identificar em qual nível de maturidade o time está e quais passos pode dar a seguir. --- # Precisamos mesmo de pull requests para toda mudança? Data: 2026-06-26T09:30:15-03:00 URL: https://mauricioaniche.com/blog/precisamos-mesmo-de-pull-requests-para-toda-mudanca/ Idioma: pt-BR O Andrea LaForgia escreveu um post bem provocativo sobre se precisamos mesmo de pull requests. O resumo do próprio autor: - As solicitações de pull request (Pull Requests) foram concebidas para contribuições de código aberto feitas por pessoas desconhecidas e sem qualquer vínculo de confiança. Aplicá-las a equipes confiáveis ​​é um erro de categoria. - Trabalhos científicos mostram que o principal valor da revisão de código é a transferência de conhecimento, não a detecção de bugs. Menos de 15% dos comentários de revisão se referem a bugs reais. - Fluxos de trabalho de Pull Requests assíncronos significam que seu código passa de 86% a 99% do seu tempo de desenvolvimento aguardando. Uma organização chegou a gastar 130.000 horas em um único ano esperando por Pull Requests que não receberam nenhum comentário. - Uma pesquisa da DORA com mais de 36.000 profissionais mostra que o desenvolvimento baseado em trunk está correlacionado a um desempenho de entrega de software dramaticamente superior, e revisões de código mais rápidas, por si só, melhoram o desempenho em 50%. Estamos tão acostumados com o fluxo de PRs, que nem paramos pra refletir se realmente faz sentido. Algumas provocações: - Será que todo PR precisa mesmo de um segundo olho humano? Até aquele micro-PR onde você só troca uma label no site? Por quê não só revisar aqueles PRs mais complicados, onde você realmente precisa de feedback? - Será mesmo que a melhor forma de passar conhecimento é ter alguém lendo cada linha de código que você escreveu? E será mesmo que todo mundo tem que estar ciente de todas linhas escritas? Tem maneiras melhores de treinar o seu dev júnior sem ser revisando cada vírgula que ele escreve em cada PR que ele abre? - Será que é a hora da "volta do pair programming"? Sinto que a popularidade de PP deu uma caída, mas será que a melhor hora dele voltar é agora, onde não conseguimos mais revisar tanto PR? Meu sentimento é de que realmente não precisamos de PRs como gate-keepers 100% do tempo para 100% do código escrito. Precisamos testar. Leiam o texto original, indicado nas referências ao final. ## Referências - [Link para o texto](https://a4al6a.substack.com/p/stop-using-pull-requests) --- # Mais código, mais fricção: escalar a entrega depois da adoção de IA Data: 2026-06-24T14:00:18-03:00 URL: https://mauricioaniche.com/blog/mais-codigo-mais-friccao-escalar-a-entrega-depois-da-adocao-de-ia/ Idioma: pt-BR "Escalar raramente falha drasticamente, ela apenas adiciona fricção em todo lugar", disse o Rob Zuber, CTO da CircleCI, uma das mais conhecidas infraestruturas de integração contínua. E é verdade. Se seu time está voando agora com a adoção de IA, 2-3x mais pull requests do que antes, é muito provável que você esteja sentindo agora a fricção em outro lugar. Será que seu CI ficou mais lento? Será que o tempo de code review aumentou? Como líder, você precisa ficar de olho nas consequências da adoção, e continuar otimizando o sistema como um todo. No caso do time tech da Alura, nós mudamos nossa regra de code review, diminuindo o número de reviewers necessários para uma PR e adicionando também um review via IA, e também trabalhamos para escalar nossa CI. ## Referências - [Link pro post original](https://www.linkedin.com/posts/robzuber_scaling-rarely-fails-dramatically-it-just-ugcPost-7467651871000915968-l8WD) --- # A adoção de IA pelos profissionais avança mais rápido que as organizações Data: 2026-06-24T10:04:29-03:00 URL: https://mauricioaniche.com/blog/a-adocao-de-ia-pelos-profissionais-avanca-mais-rapido-que-as-organizacoes/ Idioma: pt-BR O Brasil está entre os países mais avançados no uso de IA no trabalho, mas as empresas ainda não acompanham o mesmo ritmo! Segundo o Work Trend Index 2026 da Microsoft, 27% dos profissionais brasileiros que usam IA já atuam em nível avançado, acima da média global de 16%. São profissionais capazes de automatizar fluxos, criar sistemas multiagentes e reformular rotinas inteiras. O problema é que as organizações ainda não acompanham o mesmo ritmo. O gargalo deixou de ser habilidade técnica e passou a ser a capacidade das empresas de redesenhar o trabalho para incorporar a IA de forma estrutural. E na sua empresa, a estrutura já acompanha o ritmo dos profissionais? --- # FinOps para IA: use o modelo certo para cada tarefa Data: 2026-06-22T10:00:15-03:00 URL: https://mauricioaniche.com/blog/finops-para-ia-use-o-modelo-certo-para-cada-tarefa/ Idioma: pt-BR A IA acelerou demais a escrita do código. Mas ela tem um preço, e esse preço é alto. Se você usa os planos da Anthropic ou OpenAI que tem subsídio por trás, aqueles de 20 ou 100 dólares, você percebe que sua janela acaba rápido. Pra quem paga por token então... Não à toa você vê Uber, Microsoft, todas tentando fazer a conta de IA fechar. No longo prazo, minha expectativa é que o custo do token caia, mesmo para esses super modelos como Opus ou GPT 5.5, que hoje são caríssimos. Mas esse custo nunca vai ser zero. Vejo aqui um desafio análogo ao que tivemos no cloud. O cloud é barato, mas se você deixar a torneirinha aberta, vai pagar muito no fim do mês. Do mesmo jeito que criamos toda uma disciplina de finops para cloud, vamos criar pra IA. Será que você precisa mesmo do Opus para resolver TODAS as suas tarefas de código? Sabe aquela tarefa de mudar um label no seu HTML, adicionar um if a mais no seu código Java, tem certeza que precisa de um canhão como o Opus pra matar essa formiguinha? O Kimi, o GLM, ou até mesmo o Deepseek Flash, que custa 51x (CINQUENTA E UMA VEZES!) mais barato do que o Opus, podem dar conta. Por quê não "rotear" a sua requisição para modelos mais baratos, caso a tarefa seja mais simples? E deixa o Opus e o GPT 5.5 pras tarefas que realmente precisam de ultra inteligência? Já tenho visto exemplos na internet, e os números fecham muito melhor. Deixo um exemplo nas referências ao final. Aqui na Alura ainda não estamos roteando. Mas eu já sou bloqueado pelo meu Codex com mais frequência do que gostaria. Está na hora de experimentar. E você, já cogitou rotear pra modelo mais barato quando a tarefa é mais simples? Como você implementou isso em escala? ## Referências - [Post no twitter relacionado](https://x.com/0xdepressionn/status/2065044012793201001?s=46&t=83Fo6IcQ9bNl-SS6uJZuMA) --- # Transformar mudanças em rotina é uma competência de liderança Data: 2026-06-19T11:53:13-03:00 URL: https://mauricioaniche.com/blog/transformar-mudancas-em-rotina-e-uma-competencia-de-lideranca/ Idioma: pt-BR Lideranças precisam aprender a transformar mudanças em rotina! Esse foi um dos pontos abordados por Tavane Gurdos, CEO da Alun Business, no CBTD 2026. Entramos em uma era em que mudanças constantes, simultâneas e cada vez mais complexas passaram a ser a nova normalidade. Nesse cenário, liderar hoje é criar as condições para que a mudança aconteça todos os dias, ajudando as pessoas a desenvolverem os reflexos necessários para navegar nela. Quando a mudança é incorporada à rotina, a adaptação para de ser uma reação e se torna uma capacidade organizacional. --- # Guardrails de qualidade e estratégias de adoção de IA: meu novo curso Data: 2026-06-19T10:30:13-03:00 URL: https://mauricioaniche.com/blog/guardrails-de-qualidade-e-estrategias-de-adocao-de-ia-meu-novo-curso/ Idioma: pt-BR Meu mais novo curso de IA acabou de sair na Alura: "IA na engenharia de software: Guardrails de qualidade e estratégias de adoção". O que você vai aprender? - Identifique riscos e defina guardrails para o uso de IA no desenvolvimento de software. - Implemente práticas de verificação de qualidade, incluindo testes automatizados, revisão de código e análise estática. - Avalie o impacto da IA na produtividade do time e meça resultados relevantes evitando métricas de vaidade. - Equilibre velocidade e qualidade ao incorporar código gerado por IA em pipelines de entrega. - Integre requisitos de observabilidade e segurança em sistemas que usam IA para gerar código. - Planeje e conduza pilotos e iniciativas internas para promover adoção responsável da IA na equipe. Nos vemos lá! Veja as referências ao final. ## Referências - [Link para o curso](https://www.alura.com.br/curso-online-ia-engenharia-software-guardrails-qualidade-estrategias-adocao) --- # Enquanto a janela de uso dos agentes não volta Data: 2026-06-18T13:30:27-03:00 URL: https://mauricioaniche.com/blog/enquanto-a-janela-de-uso-dos-agentes-nao-volta/ Idioma: pt-BR Eu esperando a janela do Codex e do Kimi abrirem de novo... O que vocês fazem enquanto esperam a janela voltar? :) --- # Mais pull requests não significam mais deploys nem mais valor Data: 2026-06-15T10:30:22-03:00 URL: https://mauricioaniche.com/blog/mais-pull-requests-nao-significam-mais-deploys-nem-mais-valor/ Idioma: pt-BR Vejo pessoas desapontadas pelo fato de que, apesar do número de PRs ter crescido bastante (no caso da Alura, cresceram por volta de 3x), mas o número de deploys não cresceu na mesma proporção. Faz todo sentido que o número de deploys não cresça igual. Você tem um número enorme de engenheiros/as fazendo PRs, enquanto tem provavelmente uma esteira linear de deploy. Ainda assim, mesmo que a quantidade de deploys não mudou, a quantidade de código entrando em produção aumentou, pois você tem mais PRs entrando na branch principal e sendo deployado. "Ah, estamos entregando mais coisa, mas não vejo diferença no número de funcionalidades que mudam o ponteiro indo pro ar". Mas aí, meu amigo, isso não tem nada a ver com IA. Tem a ver com priorização. Saber o que entregar primeiro, saber o que traz mais valor. Priorizar sempre foi um desafio, com ou sem IA. --- # A taxa da orquestração: o custo de coordenar múltiplos agentes Data: 2026-06-12T10:40:22-03:00 URL: https://mauricioaniche.com/blog/a-taxa-da-orquestracao-o-custo-de-coordenar-multiplos-agentes/ Idioma: pt-BR O Addy Osmani escreveu um texto legal chamado "The Orchestration Tax", ou a taxa da orquestração. Veja as referências ao final. Resumo rápido: - A "orchestration tax" refere-se ao custo de gerenciar vários agentes de inteligência artificial, onde a capacidade cognitiva do indivíduo não se paraleliza, resultando em um processamento serial de decisões e análises. - A criação de múltiplos agentes pode dar uma falsa impressão de produtividade, mas o verdadeiro desafio está em gerenciar a revisão e a integração do trabalho feito por esses agentes, que depende da atenção e julgamento de uma única pessoa. - É crucial tratar a atenção como um recurso escasso; a carga de trabalho deve ser compatível com a capacidade de revisão, e o foco deve estar em tarefas que realmente exigem julgamento humano, evitando dispersão em tarefas complexas. Não tenho dúvidas de que, no curto prazo, estaremos todos coordenando o trabalho de múltiplos agentes ao mesmo tempo. Hoje a grande maioria de nós já está perto disso. Afinal, quem nunca disparou outro Codex ou Claude Code para trabalhar enquanto esperava o primeiro terminar? Só não podemos esquecer que disparar vários agentes pra rodar é a parte fácil. Revisar o trabalho de todos esses agentes e garantir que o que eles entregaram é realmente o que precisamos é a parte difícil. Qual é o limite máximo de PRs que conseguimos revisar, com qualidade, e ao mesmo tempo? Quanto melhor os guardrails automáticos, maior o número de PRs que você consegue revisar. Você vai simplesmente confiar no "verdinho" da sua integração contínua para muitos desses PRs. Tenho curiosidade de saber como o mundo ideal será: mesmo com guardrails perfeitos, será que vamos chegar em um mundo onde precisaremos de zero trabalho manual pra revisar esses PRs? Só o futuro dirá; hoje, não é o caso. ## Referências - [Link para o post do Addy](https://x.com/addyosmani/status/2059844244907696186) --- # O que aprendi criando três microaplicações com IA Data: 2026-06-10T13:30:19-03:00 URL: https://mauricioaniche.com/blog/o-que-aprendi-criando-tres-microaplicacoes-com-ia/ Idioma: pt-BR Nesse último ano, já criei três micro aplicações do começo ao fim. Cada um deles tem 1 usuário (!!!), mas meu objetivo sempre foi aprender sobre engenharia de software e IA. Lições que aprendi com cada um deles: A primeira é um gerenciador de projetos. Você cria projetos, listas de tarefas, e TODOs. Minha ideia era ver se conseguia criar um clone do Basecamp. E em poucas semanas, trabalhando só uma ou duas horas por dia, consegui. Ele é 100% funcional. Tenho um escritório de arquitetura usando. O que aprendi? Escrever código não é mais o desafio, mas sim criar uma experiência no produto que realmente agrade ao usuário final. Se você usar a minha ferramenta e o Basecamp, você vai ver que as funcionalidades são as mesmas, mas o Basecamp simplesmente te dá uma experiência com zero fricção. A segunda é um CRM que conecta ao Whatsapp. Seus agentes conseguem responder aos chamados de clientes e você consegue organizar cada lead em um kanban do começo ao fim. O sistema também tem relatórios, IA, orçamentos, e até visitas técnicas. Tenho uma empresa de limpeza usando. O que aprendi? Tomar decisões arquiteturais ainda é muito a nossa tarefa. A primeira versão do LeadZen se perdia na comunicação com o Whatsapp. Precisa implementar uma fila para paralelizar o processamento das várias mensagens que chegavam dos diferentes telefones, mas sequencializar as mensagens do mesmo usuário para evitar alterações concorrentes no estado do lead do mesmo usuário. Por fim, a terceira é uma ferramenta que me ajuda com agendar meus posts na minha rede social. O post original no LinkedIn, por exemplo, escrevi 15 dias antes, e foi publicado automaticamente pela minha ferramenta. O que aprendi? Esse foi o primeiro micro-SaaS que decidi pedir pra IA escrever testes do começo ao fim. Não dei muita instrução ao modelo. Depois da primeira versão, decidi revisar com atenção os testes escritos. Encontrei muito código de teste mal escrito e cenários cobrindo casos que eram menos relevantes. A IA realmente automatizou a escrita do código. Não preciso mais digitar letrinha por letrinha. Mas garantir a experiência do usuário, a arquitetura, e a qualidade como um todo, essa ainda é uma tarefa muito humana. --- # A adoção de IA precisa vir da liderança e do time Data: 2026-06-08T10:30:17-03:00 URL: https://mauricioaniche.com/blog/a-adocao-de-ia-precisa-vir-da-lideranca-e-do-time/ Idioma: pt-BR Gravamos recentemente um podcast do Hipsters.tech junto com o time da Alura, onde falamos da nossa própria adoção de IA dentro do time de tecnologia. O Paulo Silveira me perguntou se a abordagem foi top-down ou bottom-up. Minha resposta foi: A IA é uma mudança muito grande, e para a transformação acontecer, precisa vir tanto top-down (do chefe pra baixo) quanto bottom-up (do time pra cima). Do lado do líder, a visão de IA deve estar bem definida e passada de maneira clara para todo o time. A liderança também deve trabalhar para que as ferramentas, governanças, e todos os "checks and balances" estejam bem definidos e disponíveis para todos. No caso da Alura, trabalhamos por semanas na escolha das ferramentas, na integração dessas ferramentas na nossa base de código e dia-a-dia do dev, na mensagem de como enxergávamos o uso de IA no mundo do dev. Do lado do time, é abrir espaço para que as pessoas experimentem, levantem ideias, e engajem entre si. No caso da Alura, vários dos nossos devs se juntaram e organizaram um treinamento interno sobre como usar IA ao máximo no nosso contexto. Outros começaram a produzir skills específicas. Entre outras. Como que foi a adoção do seu lado? Foi mais top-down ou bottom-up? Onde você está nesse processo? ## Referências - [Link para o podcast](https://www.hipsters.tech/estudo-de-caso-engenharia-agentica-e-vibe-coding-na-alura-hipsters-ponto-tech-517/) --- # Testes gerados por IA também precisam de qualidade Data: 2026-06-05T09:30:22-03:00 URL: https://mauricioaniche.com/blog/testes-gerados-por-ia-tambem-precisam-de-qualidade/ Idioma: pt-BR Automatizar a escrita de testes com IA é uma das coisas mais legais desse novo mundo. Você consegue gastar zero energia com isso e, "de graça", ganha uma bateria de testes que garante que seu sistema funciona e que dá sinais claros pra IA quando ela quebra algo. Mas não podemos esquecer de pensar em duas coisas: - Na eficácia e confiabilidade da bateria de teste gerado. Ela testa mesmo o que precisa ser testado? Se os testes estão passando, posso deployar com confiança? - Na qualidade do código do teste. O código faz o melhor uso das tecnologias? A bateria de teste é fácil de evoluir junto com o código de produção? No meu micro-SaaS de agendamento de posts em redes sociais, optei por dar instruções bem simples pro modelo. Basicamente, sempre escreva testes, rode sempre os testes antes de dar a tarefa como pronta. Depois de 100+ testes, eu decidi revisar o código gerado bem a fundo. Percebi vários problemas. Cada classe de teste com uma abordagem diferente. É uma aplicação Spring Boot. Para alguns controllers, a IA decidiu testar o componente direto, para outros, ela decidiu usar MockMvc. Para algumas entidades, ela decidiu escrever testes de unidade, para outras, ela preferiu testar pelo Service. Para alguns fluxos, ela testou corner cases como possíveis entradas de valor com nulo, para outros, ela focou só no caminho feliz. Sem contar testes que soltavam exceção no log e a exceção era engolida pelo teste. Dado tudo que sabemos sobre código de teste, isso claramente não é o que eu gostaria de ter, mesmo em uma micro aplicação como essa. Decidi então investir em um guia bem extenso de como eu gostaria que esses testes fossem escritos. Usei o GPT para me ajudar a escrever todas as boas práticas que eu acredito. Depois, pedi para o Codex revisitar todos os testes e alinhar eles em relação a essas boas práticas. Desde então, os testes gerados são muito mais próximos do que eu gosto. Eu sei que é fácil ignorar o código de testes, ainda mais código gerado. Mas não esqueça de guiar bem a sua IA para que ela gere testes úteis e com código de qualidade! ## Referências - [O guia aqui, não é nada demais, mas ilustra o meu ponto](https://gist.github.com/mauricioaniche/c6f80e32f79b55ed6fec439a2280395a) --- # Idempotência e retentativas: a IA ainda precisa de visão do todo Data: 2026-06-03T14:00:26-03:00 URL: https://mauricioaniche.com/blog/idempotencia-e-retentativas-a-ia-ainda-precisa-de-visao-do-todo/ Idioma: pt-BR A IA pode ter automatizado a escrita do código, mas ainda não consegue "pensar no todo" por conta própria. Vou dar aqui dois exemplos recentes onde o "one-shot" da IA gerou código sem pensar no todo. - No meu novo micro SaaS de agendamento de posts em redes sociais, a IA não pensou em idempotência nos endpoints da principal entidade: Post. A consequência foi a criação de posts duplicados. Depois que pedi pra ela pensar em idempotência, ela resolveu. - No nosso portal de dev interno da Alura, mandamos um e-mail para líderes técnicos e diretores toda vez que um incidente acontece. Esses dias recebemos 10 cópias do mesmo e-mail. Quando fui olhar, percebi que o código mandava e-mail e depois mandava para nosso comunicador interno. A comunicação com o comunicador interno estava falhando, então o job como um todo falhava, e ele re-tentava depois de alguns minutos, causando o envio de múltiplos e-mails. Depois que expliquei o problema pra IA, ela corrigiu certinho. O trabalho do dev do futuro não é mais pensar nas linhas de código e nos ponto-e-vírgulas que estão faltando. É olhar para o todo, não deixando a IA pular decisões importantes, tanto de arquitetura quanto de negócio, e continuar alimentando ela com contextos e decisões cada vez mais precisas e assertivas para que você possa então focar no próximo "grande peixe" do negócio. --- # Como formar desenvolvedores seniores em um mundo de IA? Data: 2026-06-01T10:30:26-03:00 URL: https://mauricioaniche.com/blog/como-formar-desenvolvedores-seniores-em-um-mundo-de-ia/ Idioma: pt-BR Grande parte do nosso trabalho na Alura é estar por dentro e liderar o aprendizado de tecnologia no Brasil. E claro, a pergunta que não quer calar é: nesse novo mundo de IA, como treinamos as pessoas para que elas virem sêniores no futuro? De maneira bem simplista, o dev sênior é aquela pessoa que já escreveu muito código, e aprendeu muito com seus erros. Mas se o dev não "coda" mais, será que ele vai conseguir aprender tudo o que o sênior aprendeu? Eu ainda não tenho resposta pra isso, então vou soltar meus pensamentos atuais aleatórios. - Um resultado muito validado em ciência do aprendizado é que, pra aprender, precisa "doer". Você precisa fazer esforço pra aprender algo novo, e se você não está sentindo aquele desconforto, é porquê talvez não esteja aprendendo de verdade. Eu aprendi muito escrevendo código na unha, eu confesso, e em particular, detalhes como estruturas de dados ou rotinas de frameworks específicos. Mas os meus grandes aprendizados, aqueles que me fazem senior, aconteceram pq eu estava ali tomando parte de decisões complexas de arquitetura, de negócio, e de operação. Eu estava discutindo se precisávamos meter uma fila naquele processamento ou não; eu estava discutindo se essa modelagem de tabelas suportaria as consultas SQL que precisávamos ou não; eu estava olhando log do sistema e entendendo o que eu poderia fazer para que aquele problema não acontecesse mais. - Os fundamentos ainda são absurdamente importantes. Entender estruturas de dados, entender arquitetura de software, entender sistemas distribuídos, entender banco de dados será sempre necessário. E pra aprender esses, não tem como fugir, igual não tinha como fugir antes: você vai ter que sentar na cadeira e estudar essas coisas todas no detalhe. Você quer entender mais de estruturas de dados? Vai ter que se aprofundar em lista ligadas, pilhas e filas, e como a implementação delas funciona. Quer entender mais de sistemas distribuídos? Vai ter que sentar e estudar. Você não vai mais precisar saber cada vírgula que existe no Redis, mas vai ter que ter uma boa intuição de como o Redis funciona por dentro e por fora. - Nossos mecanismos de avaliação de educação vão precisar mudar. Eles sempre existiram pq precisávamos de uma maneira de separar quem entendeu de verdade e quem precisa ainda estudar mais. E projetos eram sempre uma ótima maneira de dar para o aluno um projeto desafiador e ao mesmo tempo medir se ele aprendeu. Projetos complexos de faculdade faziam com que alunos precisassem realmente parar pra aprender, senão não conseguiam entregar nada. Esses dias li o post da prof Crista Lopes, da UC Irvine, comentando que um certo aluno entregou um projeto lindo, mas que quando questionado, não sabia explicar nada. Ou seja, ele provavelmente não aprendeu muito com o projeto. Meu amigo Michael Hilton, da CMU, também publicou um texto, também discutindo a necessidade de repensarmos educação em CS. Como disse, pensamentos ainda crus, mas que queria abrir com vcs. O que acham? Faz sentido? ## Referências - [Post da Prof Crista Lopes](https://www.linkedin.com/posts/cristina-crista-lopes-5161b_i-just-had-a-student-come-to-our-meeting-share-7463328400632406016-sbuV) - [Texto do Prof Michael Hilton](https://www.theatlantic.com/technology/2026/05/computer-science-major-coding-ai/687279/) --- # Guardrails leves e pesados para código gerado por IA Data: 2026-05-29T10:00:17-03:00 URL: https://mauricioaniche.com/blog/guardrails-leves-e-pesados-para-codigo-gerado-por-ia/ Idioma: pt-BR Garantir que o código gerado pela IA funcione é um dos desafios que mais me interessam hoje. Eu e o Guilherme Silveira falamos muito sobre isso no nosso dia-a-dia, e recentemente vi um post do Prof Philipp Leitner formalizando a discussão, que gostei muito. Dá pra separar esses mecanismos, que nós e a comunidade tem chamado de 'guardrails', de duas formas: - Primeiro é o "guardrail leve" (ou soft em inglês). Esse é aquele guardrail onde você define para a LLM as suas estratégias para garantir qualidade. Por exemplo, você diz pra ela, no seu prompt, arquivo de contexto, skill, etc, que ela deve sempre fazer boundary testing (prática de teste de software), que ela deve sempre garantir que todo código trate possíveis null pointers, e que ela deve sempre rodar os testes antes de marcar a tarefa como pronta. Guardrails leves são fáceis de serem criados. A LLM vai dar o seu melhor, mas sabemos que ela é não-determinística e pode "sem querer" não seguir a sua instrução. - O segundo é o "guardrail pesado" (ou hard em ingles). Esse é aquele onde não é possível "pular". É a sua integração contínua garantindo que os testes rodem antes do merge. É a sua análise estática para garantir que realmente NPEs não acontecem. Esses geralmente são mais difíceis de serem implementados, especialmente se você precisa de customização. No mundo ideal, e acredito que chegaremos lá eventualmente, guardrails via AI seriam suficientes. Mas hoje eles sozinhos não são suficientes, e portanto precisamos encontrar o balanço entre esses dois tipos de guardrails, para que possamos entregar cada vez mais código. ## Referências - [Post do prof Philipp Leitner](https://www.linkedin.com/posts/philipp-leitner-aa5b52156_soft-vs-hard-guardrails-when-share-7464952600233385984-Bmy2/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAB178EB1aVeabLYbmWe02WqDTLNd30zK4k) --- # Quando uso IA para escrever e quando prefiro escrever à mão Data: 2026-05-28T10:30:18-03:00 URL: https://mauricioaniche.com/blog/quando-uso-ia-para-escrever-e-quando-prefiro-escrever-a-mao/ Idioma: pt-BR A quantidade de texto gerado por IA que andamos lendo cresceu demais. E é engraçado que por mais real que o texto possa se parecer, a IA deixa a "sua marca" de alguma forma, e nós conseguimos perceber. Sabe que o ChatGPT saiu e eu estava no meio da escrita do meu livro "Simple Object-Oriented Design" com a Manning. E claro, todos estavam curiosos se o ChatGPT poderia ajudar na escrita. Pra mim que tenho inglês apenas como segunda língua, fiquei curioso e resolvi experimentar. Eu basicamente passei o ChatGPT em tudo que havia escrito e pedi para ele reescrever. O inglês do texto ficou MUITO melhor do que o meu inglês. Mas havia algo naquele texto que eu sentia que ele simplesmente não era mais meu... Sempre que escrevo um livro, me imagino contando a ideia pro leitor, em uma conversa informal, e não estava sentindo isso nesse livro. No fim, dei rollback em todos os commits que havia feito com a IA, e o livro final ficou 100% escrito pelos meus dedinhos (e claro, com muita revisão de inglês da Manning). Mas isso não quer dizer que a IA não tem espaço na escrita de texto. Eu separo da seguinte forma: - O texto que eu quero mesmo me conectar com meu leitor, eu escrevo na mão. Posso pedir ideias para o ChatGPT, posso pedir para ele revisar, mas nunca para ele escrever por mim. Exemplos de texto que são assim: meus posts, meus livros, meus artigos técnicos, meus cursos, e-mails mais importantes para meu time. - O texto cujo objetivo é apenas passar uma mensagem, esse sim me sinto mais confortável em usar IA. Eu não quero me conectar com o leitor, quero apenas transmitir informação. Aqui, eu me coloco também na posição de revisor desse texto, para garantir que ele é enxuto e factual, pois também não quero desperdiçar o tempo dos leitores. Esse tipo de texto é muito comum em ambientes empresariais. Exemplo: um email detalhando números para meu time, um texto resumindo o conteúdo de 10 posts dos nossos concorrentes na internet, um RFC para discutir mudança de arquitetura, etc. Existe, aliás, um benefício quando se usa IA pra escrever documentos corporativos. Muitas pessoas não tiveram treino de escrita, escrever bem é difícil, e ao mesmo tempo é uma parte importante do trabalho. Quem escreve bem, passa melhor sua mensagem, tem mais impacto, e cresce mais rápido na carreira. A IA ajuda essa pessoa a conseguir se comunicar muito melhor enquanto ainda trabalha nessa habilidade. Como você tem usado IA para a escrita? Quais são suas boas e más práticas? Quando usar e quando não usar? --- # A nova forma de trabalhar com IA: uma conversa da Alura Data: 2026-05-26T16:30:28-03:00 URL: https://mauricioaniche.com/blog/a-nova-forma-de-trabalhar-com-ia-uma-conversa-da-alura/ Idioma: pt-BR O mundo do dev mudou... A Alura mudou também! Venha ouvir o que temos pra falar sobre essa nova forma de trabalhar com IA. HOJE, às 7pm! Veja as referências ao final. ## Referências - [Live da Alura](https://youtube.com/live/Vfd4uSOIl80?si=3xyQS9FvWWiMHO9y) --- # Criando o Ticka com IA: lições de um clone simplificado do Basecamp Data: 2026-05-25T10:30:31-03:00 URL: https://mauricioaniche.com/blog/criando-o-ticka-com-ia-licoes-de-um-clone-simplificado-do-basecamp/ Idioma: pt-BR Quando comecei a experimentar o Claude, no começo de 2025, decidi criar uma app do começo ao fim para entender o poder da engenharia agêntica. Sempre fui fã do Basecamp como ferramenta de gerenciamento de projeto, gosto muito da simplicidade do modelo de projetos, listas de tarefas, tarefas, nada mais do que isso. Então decidi criar meu próprio Basecamp. Em poucas semanas, trabalhando menos de 1 hora por dia, criei o Ticka, uma versão absurdamente simplificada do Basecamp. O que eu aprendi na época: - Naquele momento, percebi que o mundo de engenharia de software ia mudar. Ainda não tinha conseguido enxergar que IA agêntica ia entrar em tudo, mas ao menos, escrever código "estava resolvido". - Todo mundo diz que o mundo mudou depois do Opus. Eu concordo em partes; o mundo já tinha mudado ali. Os modelos já eram absurdamente capazes de escrever código. Com a instrução certa, eles produziam código perfeito em "one shot". O Opus é mais independente e consegue rodar sozinho por horas, mas pro dia-a-dia do dev, onde a maioria das tarefas é mais pontual, os modelos já eram bem capazes. - Pra ser honesto, até hoje uso os modelos mais novos do mesmo jeito que usava antes, com instruções bem específicas. Sei que os modelos novos são super capazes de se virar, encontrar coisas sozinhos, resolver ambiguidades, mas ainda acredito muito em dar instruções mais precisas pro modelo. Ainda aponto para classes onde sei que a mudança tem que acontecer, digo como quero o "design" das classes, etc. A IA coda pra mim, ela não pensa por mim. Gosto da frase "5 minutos a mais no prompt te economizam 10 minutos a mais na revisão de código". - Em situações que não sei bem o que fazer, e isso acontece especialmente em tecnologias que sei menos, como front-end, eu deixo ele "se virar" primeiro e aí dou uma lida. Mesmo sem entender da tecnologia, sou capaz de entender se foi uma boa mudança ou não. - Acabei não tentando pedir pro Claude fazer o bootstrap inicial da app. A v0 do front-end foi feita no Lovable, pois já conheci a sua capacidade de gerar um CRUD. Hoje, já vou direto no Claude ou Codex, eles conseguem gerar o bootstrap inicial sozinhos também. - Eu revisei muito de perto quase todos os commits no meu "sprint inicial". Tive que mudar muita coisa, em particular, coisas como o que o endpoint devolve, segurança, etc. Atualizei muito o AGENTS.md baseado nisso. Hoje, por ser uma aplicação com baixo risco (poucos amigos usam), eu reviso só passando o olho por cima da mudança. E ele raramente gera algo ruim. Deixei a ferramenta gratuita para quem quer usar de gerenciador de tarefas pessoal, igual eu uso! Faz 1 ano que uso e tem me servido muito bem. Veja as referências ao final. Se tiver qualquer dúvida sobre como foi o processo de criar esse micro SaaS, é só me avisar. Desde então já fiz outras 2 apps dessa, que escreverei sobre mais pra frente. Vcs gostariam de uma live, no estilo "me pergunte qualquer coisa" sobre o assunto? ## Referências - [Link pro Ticka](https://www.ticka.com.br) --- # Transformação com IA começa pelo aprendizado da liderança Data: 2026-05-22T15:00:00-03:00 URL: https://mauricioaniche.com/blog/transformacao-com-ia-comeca-pelo-aprendizado-da-lideranca/ Idioma: pt-BR O Diego Barreto, CEO do iFood, escreveu recentemente sobre como ele está liderando a revolução IA dentro do seu time de liderança; e pasmém, com o bom e velho treinamento! Aqui estão três pontos essenciais do artigo dele: - **Achar um tempo da liderança é difícil**: O Diego optou por marcar o treinamento no sábado e no domingo, que eram os dias em que todos líderes teriam livres. Fazer isso no fim de semana é um reflexo da prioridade que a empresa confere à transformação digital. - **Prática é mais importante que teoria**: Só saber falar de IA não é suficiente; os líderes precisam saber usar IA. No bootcamp que criaram, os "Super Humanos", a ideia é fazer com que os líderes saiam de lá com vários pequenos agentes criados. - **A Transformação IA como um diferencial**: A verdadeira vantagem competitiva não está na tecnologia em si, mas na capacidade de uma organização de evoluir e se adaptar. A cultura de aprendizado contínuo, aliada à IA, é o que irá moldar o futuro das equipes. Aqui eu tenho meu viés, mas nós aqui da Alura temos criado formações muito completas sobre IA para todos os níveis, para devs e não devs, para líderes, e para C-levels. Vem falar comigo se isso te interessa! ## Referências - [Link para o artigo](https://diegocbarreto.substack.com/p/por-que-pedir-a-lideranca-senior) --- # Como a OpenAI usa Codex no dia a dia da engenharia Data: 2026-05-22T10:30:00-03:00 URL: https://mauricioaniche.com/blog/como-a-openai-usa-codex-no-dia-a-dia-da-engenharia/ Idioma: pt-BR A OpenAI lançou recentemente um documento chamado "How OpenAI Uses Codex", ou seja, "Como a OpenAI usa Codex". O texto dá uma visão bem legal de como a OpenAI integra o Codex em suas operações diárias, melhorando a eficiência e a qualidade do trabalho em equipe. Alguns pontos principais de como o time de engenharia da OpenAI usa o Codex: - **Compreensão de Código**: O Codex auxilia eles na rápida familiarização com trechos desconhecidos de código, facilitando a resolução de incidentes e a documentação. - **Refatoração e Migrações**: Codex é usado para realizar mudanças em múltiplos arquivos, garantindo consistência e eficiência em grandes refatorações. - **Otimização de Performance**: Codex identifica gargalos de desempenho e sugere melhorias nas rotinas de código, contribuindo para a saúde do software a longo prazo. - **Aumento da Velocidade de Desenvolvimento**: Desde a criação de APIs até a triagem de bugs, Codex ajuda a acelerar todo o ciclo de desenvolvimento. Estamos usando o Codex aqui na Alura também. Ainda não usamos para grandes refatorações e migrações, mas está nos nossos planos. Afinal, quem não tem um legado? :) ## Referências - [PDF](https://cdn.openai.com/pdf/6a2631dc-783e-479b-b1a4-af0cfbd38630/how-openai-uses-codex.pdf) --- # Kimi e OpenCode: minhas experiências com uma alternativa de menor custo Data: 2026-05-21T09:00:35-03:00 URL: https://mauricioaniche.com/blog/kimi-e-opencode-minhas-experiencias-com-uma-alternativa-de-menor-custo/ Idioma: pt-BR Estou testando o Kimi, o modelo criado pela Moonshot AI, uma startup chinesa de inteligência artificial fundada em 2023 e apoiada por grandes gigantes da tecnologia, como o grupo Alibaba. E estou usando OpenCode como harness. Meus sentimentos até agora: - Para tarefas cotidianas do dev backend e front-end, ele se vira muito bem. Estou criando aqui meu terceiro micro-saas (mais um pra ninguém usar) com Spring Boot e NextJS, e ele tem gerado um ótimo código. Não perdeu nada aqui para os modelos de ponta. - Para tarefas mais complexas que saem do cotidiano do dev, o GPT ainda se dá melhor. Exemplo: criei uma integração via OAuth com o Twitter e Instagram. Em ambas integrações, o Kimi me sugeriu uma versão mais antiga da API. Pedi para o GPT arrumar, e ele arrumou em one-shot. - O harness do OpenCode também tem me surpreendido. Sabe a hora certa de chamar ferramentas, não cai em loops malucos, se vira bem pra rodar meus testes, sobe e desce ambas aplicações. - Assinei o OpenCode Go, que é o plano barato deles, e dá acesso a modelos como Kimi e GLM. Ele custa 10 dólares, 5 dólares no primeiro mês. O plano é realmente bem generoso. Devo ter codado sem parar por umas 16 horas seguidas (entre sábado e hoje), e bati na janela só agora. Infelizmente, é a janela semanal, então vou ficar uns dias sem usar ele novamente. Minhas conclusões pessoais: - Se você tem condições de pagar planos mais caros da Anthropic ou GPT, é a melhor escolha. São modelos melhores que vão te deixar na mão bem menos. - Nem todo mundo tem dinheiro infinito, então o OpenCode é uma ótima saída se o seu budget é mais apertado. - Se você, como muitos, está fazendo uso dos subsídios comprando o plano Teams e Business dos big labs, e bate na janela o tempo todo, ter o OpenCode como segunda opção é uma boa saída. O custo ainda fica controlado (10 USD a mais por dev por mês apenas) e você tem uma ferramenta pra usar enquanto a janela do outro está expirada. Ao mesmo tempo que o custo desses modelos tende a cair (mais competição, melhor tecnologia, etc), eu não acredito que esses modelos vão custar zero em pouco tempo. Vejo um modelo mais perto do cloud onde todos tem acesso, mas se você não estiver sempre olhando pra custo, vai acabar gastando mais do que deveria. Experimente o Kimi! Você vai se surpreender! Eu vou continuar usando! --- # Agentes de IA no código aberto: uma síntese do MSR 2026 Data: 2026-04-14T00:00:00-03:00 URL: https://mauricioaniche.com/blog/ai-agents-in-oss-msr-mining-challenge-2026/ Idioma: pt-BR ## Sumário executivo Esta síntese integra resultados de 62 artigos publicados no MSR Mining Challenge 2026, analisando as contribuições dos agentes de codificação de IA para software de código aberto. A pesquisa revela um cenário complexo onde os agentes de IA exibem capacidade significativa, mas introduzem desafios distintos em termos de qualidade de código, dinâmica de revisão e padrões de integração. Embora os agentes demonstrem mudanças de código estrutural comparáveis aos humanos em muitos contextos, surgem lacunas críticas no rigor da validação, na acumulação de dívida técnica e no desempenho específico de tarefas. **Importante:** Todo este texto foi criado por Claude Cowork e Codex. O procedimento foi o seguinte: * Enviei o prompt inicial ao Codex com GPT-5.4 e esforço de raciocínio alto. * Enviei o mesmo conteúdo ao Claude Opus com esforço de raciocínio alto. * Pedi ao Codex para revisar ambas as sínteses, verificar inconsistências e mesclar as descobertas. Fiz verificações aleatórias para garantir que as referências apontassem para os artigos corretos. No entanto, este texto pode conter erros ou informações factualmente incorretas. As descobertas correspondem aos meus sentimentos durante a conferência, depois de conversar com tantos autores. ## Resumo * Os agentes de codificação de IA já são um grande fenômeno OSS: o conjunto de dados AIDev captura 932.791 pull requests criadas por agentes em 116.211 repositórios e 72.189 desenvolvedores, portanto, essas descobertas refletem o uso no mundo real em escala. * Os PRs criados por agentes são geralmente mais propensos à rejeição do que os PRs humanos, mas a lacuna depende muito mais do tipo de tarefa, do tamanho do PR, das normas do repositório e do agente específico do que apenas da "autoria de IA". * Documentação, tarefas e pequenas correções de bugs são os pontos de entrada mais seguros para os agentes, enquanto recursos, refatoração, trabalho de desempenho e grandes mudanças de manutenção permanecem muito mais difíceis de serem implementados com sucesso. * A qualidade do código é a maior preocupação a longo prazo: mesmo os PRs de agentes integrados muitas vezes carregam problemas de código, redundância, crescimento de complexidade e manutenção que os revisores nem sempre detectam. * Os testes estão melhorando, mas continuam irregulares. Muitos PRs de agente incluem agora testes e podem alcançar uma cobertura decente, mas os PRs de cobertura zero ainda são comuns e as evidências de validação são muitas vezes mais fracas do que deveriam ser. * Os resultados de segurança são mistos, em vez de uniformemente piores: os agentes podem introduzir falhas graves, como segredos codificados ou injeção de comando, mas em soluções restritas e bem definidas, às vezes podem igualar ou superar os humanos. * A revisão humana ainda está fazendo o verdadeiro trabalho de integração. Os mantenedores muitas vezes precisam restringir o escopo, corrigir problemas de build ou testes e alinhar as mudanças com as expectativas do projeto, especialmente quando os PRs dos agentes são subexplicados. * Os agentes não são intercambiáveis. Codex, Claude Code, Cursor, Devin e Copilot mostram padrões de edição, estilos de comunicação e pontos fortes específicos de tarefas distintos, o que significa que as equipes devem escolher agentes com base no trabalho, em vez de assumir um perfil genérico de “agente de IA”. * A comunicação de pull requests é mais importante do que muitas equipes esperam: descrições fracas, pull requests silenciosas e inconsistência no código da mensagem reduzem substancialmente a probabilidade de mesclagem e retardam a revisão. * A taxa de mesclagem não é suficiente como métrica de sucesso. Para entender se o desenvolvimento de agentes está realmente funcionando, as equipes e os pesquisadores precisam rastrear reversões, referências downstream, correções após o merge e a carga de limpeza humana após a integração. ## Contexto do conjunto de dados O Desafio de Mineração MSR 2026 é baseado no conjunto de dados AIDev, que captura 932.791 pull requests criadas por agentes em 116.211 repositórios e 72.189 desenvolvedores. O conjunto de dados abrange cinco agentes de codificação amplamente estudados: OpenAI Codex, Devin, GitHub Copilot, Cursor e Claude Code [63]. ## Síntese Temática de Resultados ### 1. Padrões de aceitação e rejeição de pull requests PRs gerados por IA são frequentemente mais propensos à rejeição do que códigos de autoria humana, mas o tamanho da lacuna depende fortemente do tipo de tarefa, da dinâmica de revisão e do agente específico, e não apenas da autoria do agente [9, 11, 16]. Implementações incompletas, testes fracos, incompatibilidades de documentação e soluções inadequadas são recorrentes em estudos de rejeição como principais modos de falha para PRs criados por agentes [9, 13, 33]. O tipo de tarefa é um fator dominante de aceitação, com documentação e outras tarefas restritas integrando-se mais facilmente do que recursos, trabalho de desempenho ou grandes mudanças de manutenção, enquanto o tamanho do PR e a revisão antecipada sinalizam ainda mais os resultados [17, 20, 41, 49]. O contexto social e de processo ainda é importante: a reputação do criador, os padrões de engajamento de revisão e se a mesma conta envia e mescla um PR, todos influenciam os resultados, e uma classe restrita, mas importante, de PRs pequenos e focados ainda pode superar os limites de mesclagem automática em repositórios favoráveis [12, 8, 61]. ### 2. Qualidade do código e acumulação de dívida técnica O código gerado pelo agente apresenta preocupações de qualidade que muitas vezes persistem mesmo após a integração. Análises focadas em build mostram que a maioria das edições de build criadas por agentes são de qualidade neutra, mas problemas nas dependências e manutenção ainda aparecem em uma minoria significativa de casos [4]. PRs silenciosos podem aumentar a complexidade ciclomática e preservar ou aumentar questões de qualidade sem atrair muita discussão, o que sugere que alguma degradação passa despercebida pela revisão [15]. Análises após o merge de PRs de agentes integrados descobrem que os code smells dominam os problemas observados, enquanto os bugs funcionais são menos frequentes, mas mais graves, e estudos separados relatam mais redundância, métodos desnecessários e um ceticismo mais forte do revisor sobre a manutenibilidade no código de autoria do agente [55, 62, 32]. Estudos de dívida técnica e legibilidade sugerem ainda que as mudanças geradas podem trocar a manutenibilidade por conveniência, e reversões posteriores geralmente citam excesso de engenharia, incorreção funcional e problemas de gerenciamento de dependência como razões pelas quais o código do agente não funciona [29, 31, 28]. ### 3. Vulnerabilidades de segurança e perfis de risco Os resultados de segurança no código gerado pelo agente são mistos, em vez de uniformemente piores ou melhores. Análises focadas na segurança mostram que PRs criados por agentes apresentam fraquezas reais, incluindo credenciais codificadas e injeção de comando, mas o desempenho varia de acordo com tarefa, agente e escopo de mudança, com agentes às vezes superando humanos em pequenas e focadas correções de bugs [25]. Estudos sobre temas de revisão também mostram que as preocupações relacionadas à segurança são mais comuns em PRs rejeitados, e estudos de reversão indicam que as reversões relacionadas à segurança são raras, mas têm um impacto potencialmente alto quando ocorrem [7, 28]. Estudos de comunicação acrescentam que humanos, bots e agentes mencionam identificadores de vulnerabilidade de diferentes maneiras, com menções a agentes comparativamente raras e concentradas em descrições de pull requests, títulos e mensagens de commit, em vez de discussões de revisão mais ricas [56]. Em domínios sensíveis, como repositórios de blockchain, esse quadro misto reforça a necessidade de interpretar a atividade do agente juntamente com a maior consequência da falha [39, 25]. ### 4. Práticas de teste e dinâmica de cobertura Os testes continuam a ser centrais, mas desiguais em todo o desenvolvimento dos agentes. Estudos em larga escala descobrem que os testes são cada vez mais comuns em PRs criados por agentes, variam de acordo com o agente e o tipo de tarefa, e muitas vezes continuam a evoluir após o envio inicial, em vez de chegarem completos no primeiro patch [44, 57]. As análises de cobertura mostram que os PRs somente com IA podem alcançar uma cobertura diferencial mais alta do que os PRs humanos, ao mesmo tempo que mantêm a qualidade das afirmações amplamente comparável, mas os PRs com cobertura zero permanecem comuns em todos os grupos [58]. Estudos de geração de testes mostram ainda que os testes criados por agentes são frequentemente mais longos e densos nas asserções, mas as análises de falhas revelam que os erros de tempo de execução e de asserção dominam quando esses testes quebram, apontando para um desempenho sintático mais forte do que semântico [60, 46]. A mesma lacuna de validação aparece em trabalhos não funcionais, como a otimização, onde os PRs de desempenho de autoria do agente têm menos probabilidade do que os PRs humanos de incluir evidências de validação explícitas [5]. ### 5. Colaboração e dinâmica de revisão de IA humana A dinâmica de revisão difere materialmente entre PRs de autoria humana e de agente. Estudos de temas de revisão mostram que o feedback sobre o código de autoria do agente centra-se na correção e na lógica, mas as preocupações com documentação, refatoração, teste, reversão e segurança tornam-se mais proeminentes em PRs rejeitados [7]. Outras análises mostram que os mesmos sinais de revisão não operam de forma idêntica entre PRs humanos e de agentes: a discussão adicional do revisor pode se correlacionar com menores chances de mesclagem para PRs de agentes, e os envios de agentes são mais frequentemente mesclados pela mesma conta que os abriu [8]. A intervenção humana continua a ser importante mesmo quando não é onipresente; os mantenedores frequentemente intervêm para restringir o escopo, reparar testes ou criar problemas e alinhar as mudanças do agente com as expectativas do projeto, enquanto o feedback do revisor-bot parece muito menos decisivo e pode prolongar o tempo de resolução quando o volume de comentários aumenta [27, 40]. A prática de OSS, portanto, ainda reflete a formação de equipes entre humanos e IA, em vez de autonomia direta, com muitos PRs assistidos por IA chegando rapidamente e com pouco feedback explícito, especialmente de contribuidores sem propriedade prévia do código [14]. ### 6. Padrões comportamentais e impressões digitais específicos do agente Cada agente de IA exibe assinaturas comportamentais distintas que suportam identificação confiável e diferenciação significativa. A impressão digital comportamental pode identificar o agente remetente com 97,2% F1, mostrando que a estrutura do commit, o estilo do corpo do PR e as características do código variam sistematicamente entre as ferramentas [23]. Essas diferenças também são importantes operacionalmente: comparações estratificadas por tarefa e em nível de tarefa mostram que o Codex tem um desempenho consistentemente bom em muitas categorias, enquanto Claude Code, Cursor, Devin e Copilot mostram pontos fortes mais restritos ou compensações distintas em aceitação, volume de revisão e qualidade da mensagem [17, 42]. A análise de patches comportamentais reforça o mesmo ponto, com Claude Code inclinando-se para a reescrita, Devin para edições incrementais, Codex para edições mistas de remodelação e preservação e Copilot para repetição local mais forte [45]. Estudos de CI/CD e auto-merge sugerem ainda que os agentes variam em especialização e sucesso de integração, em vez de se comportarem como uma única classe homogênea [22, 61]. ### 7. Consistência do código da mensagem e qualidade da comunicação A qualidade da comunicação é um gargalo de integração recorrente para PRs agentes. A inconsistência no código da mensagem aparece em uma minoria pequena, mas consequente, de PRs de autoria do agente e está associada a menor aceitação e tempos de mesclagem muito mais longos, especialmente quando as descrições afirmam trabalho que o código na verdade não implementa [24]. Estudos comparativos também mostram que os agentes escrevem mensagens mais fortes no nível de commit do que resumos no nível de PR, enquanto a legibilidade e a integridade variam de acordo com o tipo de PR e com o estilo de comunicação dos diferentes agentes [6, 47, 34]. Ao mesmo tempo, tanto os PRs humanos quanto os agentes podem mostrar um alto alinhamento semântico entre descrições e diferenças, o que sugere que a dificuldade de revisão é motivada menos pela incompatibilidade de tópicos brutos do que pela fraca explicação e capacidade de revisão de alto nível [43]. Um problema relacionado é o trabalho subexplicado: PRs silenciosos e PRs fracamente fundamentados tornam a revisão mais difícil, e os arquivos de instruções melhoram os resultados apenas de forma inconsistente, a menos que sejam claros, estruturados e suficientemente específicos [15, 52]. ### 8. Integração CI/CD e confiabilidade do sistema de construção A CI/CD e as mudanças de construção continuam a ser uma área frágil para o desenvolvimento agente. Estudos de fluxo de trabalho mostram que PRs criados por agentes são bem-sucedidos em CI/CD na maioria das vezes, mas a confiabilidade varia de acordo com a tarefa e o idioma, sendo o trabalho de correção de bugs especialmente propenso a falhas [10]. Os agentes modificam as configurações de CI/CD e o YAML do fluxo de trabalho, mas essas alterações são relativamente incomuns e são revisadas com um pouco mais de cautela do que as alterações não CI/CD, mesmo que alguns agentes mostrem especialização de configuração [22]. Estudos de integração contínua acrescentam que os agentes podem resolver falhas muito mais rapidamente do que os humanos, mas também introduzem a maioria das falhas que mais tarde ajudam a corrigir, deixando os mantenedores humanos profundamente envolvidos na estabilização [26]. A análise do código de construção sugere que a maioria das edições de construção criadas por agentes são neutras, mas problemas de dependência e manutenção ainda surgem dentro dos arquivos de construção [4]. ### 9. Variação de desempenho específico do tipo de tarefa e do domínio A eficácia do agente varia drasticamente entre os tipos de tarefas, o que torna essencial a avaliação baseada no contexto. Estudos estratificados por tarefas mostram uma lacuna de aproximadamente 29 pontos percentuais entre as categorias de tarefas de maior e menor aceitação, com documentação, tarefas e alguns trabalhos de correção chegando mais facilmente do que recursos, testes ou alterações relacionadas ao desempenho [17, 42]. A sensibilidade ao tamanho também difere por tarefa: PRs de correção de bugs toleram mudanças substancialmente maiores do que PRs de recursos antes que a probabilidade de mesclagem caia drasticamente [41]. Estudos de domínio mostram que esses padrões não são uniformes entre os ecossistemas: os projetos Android aceitam PRs de agente com mais frequência do que o iOS, enquanto os repositórios de blockchain mostram aceitação semelhante entre grupos de agentes, mas forte sensibilidade no tempo de resolução para PRs maiores [37, 39]. As tarefas não funcionais sublinham ainda mais a variabilidade, uma vez que os PRs relacionados com o desempenho e a energia são mais difíceis de validar e muitas vezes mais difíceis de fundir do que o trabalho mais rotineiro [5, 35, 59]. ### 10. Experiência do desenvolvedor e atrito de integração A experiência do desenvolvedor e o contexto do repositório moldam materialmente o custo de trabalhar com agentes de codificação. Os codificadores de baixa experiência enviam PRs maiores que atraem muito mais comentários de revisão, permanecem abertos por muito mais tempo e são aceitos com menos frequência, sugerindo que a assistência da IA pode transferir a carga de verificação para os revisores, em vez de removê-la [38]. Em ambientes de OSS, os PRs assistidos por IA também vêm desproporcionalmente de contribuidores sem propriedade prévia do código e muitas vezes recebem feedback limitado mesmo quando mesclados, o que pode mascarar uma supervisão fraca [14]. A governança do repositório também é importante: o comportamento de mesclagem automática agrupa fortemente no nível do repositório, e repositórios menos maduros ou mais permissivos têm maior probabilidade de permitir que PRs pequenos e focados passem diretamente [61]. Os arquivos de instruções ajudam alguns projetos, mas não resolvem o atrito de integração de maneira confiável, a menos que sejam bem estruturados e mantidos ativamente [52]. ### 11. Refatoração de comportamento e estratégias de modificação de código Os agentes adotam estratégias de refatoração e modificação que diferem das abordagens humanas de maneiras reconhecíveis. Estudos de refatoração mostram que as refatorações Java criadas por agentes são dominadas por edições relacionadas a anotações, enquanto as refatorações humanas são muito mais diversificadas estruturalmente; apenas o Cursor mostra um aumento estatisticamente significativo nos problemas de refatoração em relação aos desenvolvedores [18]. Estudos de modificação em larga escala acrescentam que as principais diferenças entre PRs de agentes e humanos estão no empacotamento de commits, nos arquivos tocados e nas linhas excluídas, e não apenas no volume total de linhas adicionadas [43]. A análise comportamental de patches complementa isso, mostrando tendências estáveis específicas do agente para reescrita, edição incremental ou repetição local mais forte entre idiomas e tarefas [45]. ### 12. Interação do ecossistema de código e gerenciamento de dependências Os agentes demonstram um comportamento ecossistêmico relativamente conservador, mas ainda imperfeito. As importações de bibliotecas aparecem em muitos PRs criados por agentes, mas novas adições de dependência são raras, geralmente limitadas em número e muitas vezes fixadas explicitamente na versão, sugerindo que os agentes trabalham com mais frequência em ecossistemas de projetos existentes do que os expandem agressivamente [3]. Mesmo assim, os problemas de gerenciamento de dependências continuam sendo um modo de falha importante e contribuem materialmente para reversões posteriores [28]. Essa combinação aponta para um fluxo de trabalho onde os agentes geralmente evitam mudanças agressivas no ecossistema, mas ainda lutam com compatibilidade e integração quando tocam em dependências [3, 28]. ### 13. Padrões de clonagem de código e comportamento de reutilização Os padrões de reutilização de código mostram sobreposições e diferenças importantes entre as contribuições humanas e dos agentes. Em PRs criados por agentes, os clones Tipo III e Tipo I são as formas mais comuns de duplicação, e os clones que persistem em vários commits têm muito mais probabilidade de serem mesclados do que introduções de clones únicos [48]. Em projetos colaborativos, a maioria das genealogias de clones ainda são introduzidas por humanos, mas as linhagens originadas por agentes sobrevivem em taxas aproximadamente semelhantes, o que sugere que a principal diferença reside na manutenção a jusante, em vez da rejeição imediata [54]. Os desenvolvedores humanos frequentemente realizam o trabalho posterior de estabilização e normalização em clones criados por agentes, reforçando o padrão mais amplo de limpeza pós-geração e acompanhamento humano [48, 54]. ### 14. Padrões de adoção de agentes e efeitos de maturidade do repositório As características do repositório influenciam fortemente a forma como as contribuições dos agentes são integradas e aceitas. Os agentes de codificação produzem os maiores ganhos de rendimento quando introduzidos em repositórios sem ferramentas prévias de IA, enquanto os riscos de manutenção e o crescimento de alertas permanecem visíveis, independentemente da exposição anterior [30]. A maturidade do repositório também molda as normas de integração: o comportamento de mesclagem automática é altamente específico do repositório, com repositórios mais maduros menos propensos a mesclar tudo automaticamente e mais propensos a impor requisitos de revisão consistentes [61]. Os arquivos de instruções acrescentam outra camada de governança, mas os seus benefícios são heterogêneos; apenas uma minoria de projetos mostra fortes melhorias na taxa de merge após adicioná-los, e melhores resultados tendem a aparecer em projetos com instruções mais longas e estruturadas [52]. ### 15. Persistência após o merge e acompanhamento do ciclo de vida A mesclagem não é o ponto final do trabalho do agente. A análise de referência downstream mostra que apenas 4,2% dos PRs de autoria do agente são referenciados posteriormente, mas 95,62% dessas referências são iniciadas por humanos, que muitas vezes desenvolvem, adaptam ou corrigem o trabalho anterior do agente, em vez de simplesmente aceitá-lo como final [36]. Mesmo após a integração bem-sucedida, 2,66% dos PRs de agente atraem posteriormente a reversão de commits, e estudos após o merge de PRs de correção de bugs mesclados ainda encontram problemas comuns de manutenção, além de bloqueadores funcionais menos frequentes, mas mais graves [28, 55]. As evidências da genealogia dos clones reforçam o mesmo padrão: os humanos frequentemente estabilizam e normalizam os clones criados por agentes ao longo do tempo, o que significa que o valor a longo prazo depende da persistência e do esforço de manutenção posterior, em vez de apenas decisões iniciais de merge [54]. Juntos, esses estudos sugerem que a aceitação é uma métrica de sucesso incompleta e que a avaliação do agente deve rastrear reversões, referências subsequentes, sobrevivência do clone e carga de limpeza após o merge. ## Implicações para profissionais 1. **Implementar políticas de revisão consciente do tipo de tarefa**: As taxas de aceitação variam 29 pontos percentuais entre categorias de tarefas, sugerindo que fluxos de trabalho de revisão de tamanho único são ineficazes. Os profissionais devem adotar processos de revisão diferenciados, com um escrutínio mais leve para tarefas bem definidas (documentação, correções de bugs) e revisão intensiva para mudanças complexas (refatoração, otimização de desempenho, desenvolvimento de recursos). Na prática, isso significa introduzir agentes primeiro em trabalhos estreitos e com baixo raio de explosão e exigir um exame minucioso adicional para grandes manutenções, alterações sensíveis a alterações de ruptura ou críticas de segurança. Os limites de reconhecimento de tamanho devem variar de acordo com o agente e o tipo de tarefa, uma vez que PRs menores e focados demonstram uma probabilidade de mesclagem substancialmente maior em todos os agentes. 2. **Estabelecer barreiras de qualidade antes do merge**: A aceitação silenciosa sem discussão introduz dívida técnica em escala; 56,87% dos PRs silenciosos aumentam a complexidade ciclomática apesar da integração. Implementar verificações de qualidade obrigatórias para PRs de agentes, incluindo análise estática, validação de cobertura de teste (exigindo cobertura diferente de zero) e verificação de consistência de código de mensagem. A comunicação de pull requests também deve fazer parte do padrão de qualidade: as pull requests de autoria do agente devem fornecer um resumo preciso da mudança, a lógica por trás dela e evidências concretas de validação. A lacuna de aceitação de 51,7% e o atraso de mesclagem de 3,5x para PRs de alta inconsistência justificam o investimento em triagem automatizada. As restrições de tamanho devem ser aplicadas contextualmente, com os PRs do Copilot e do Cursor limitados de forma mais agressiva do que as contribuições do Codex devido a janelas terapêuticas distintas. 3. **Selecione agentes com base na especialização da tarefa**: Agentes individuais demonstram pontos fortes distintos (Codex em tarefas gerais, Copilot em documentação apesar da maior sobrecarga de revisão, Claude Code em alterações detalhadas de código). Os profissionais devem realizar pilotos em pequena escala para estabelecer métricas de desempenho de base para seus repositórios específicos antes da implantação generalizada. A variação de 29% entre agentes em tipos de tarefas idênticos justifica a seleção de agentes em vez de assumir a intercambialidade. 4. **Priorizar testes e validação de segurança**: 62,6% das falhas de testes são erros de tempo de execução que exigem compreensão semântica, e os agentes raramente mencionam identificadores de vulnerabilidade (90 menções versus 2.302 humanas), apesar de gerarem código com lacunas de segurança mensuráveis. Estabelecer a geração de testes suplementares e a verificação de segurança como portas obrigatórias. A taxa de MCI de 1,7% com impacto de aceitação de 51,7% sugere que a verificação da descrição do PR proporcionaria um alto ROI. Para domínios confidenciais (blockchain, código crítico de segurança), o padrão é diminuir os limites de aceitação e exigir validação humana. 5. **Investir em treinamento de desenvolvedores e maturidade de CI/CD**: Os codificadores do Vibe enfrentam tempos de resolução 5,16 vezes mais longos, apesar de contribuições 2,15 vezes maiores, indicando lacunas de treinamento. Fornece orientação estruturada sobre práticas de revisão de código, composição de PR e alinhamento com a infraestrutura do projeto. Mantenha um revisor humano responsável por cada alteração criada pelo agente, porque a revisão somente por bot e o feedback automatizado de baixo sinal não são substitutos fortes o suficiente para o julgamento humano quando a correção, a arquitetura ou o contexto de negócios são importantes. A taxa de falha de IC de 27,23% para PRs agentes versus taxa humana de 20,27% reflete oportunidades de ajuste; sistemas CI/CD maduros com ciclos de feedback claros aceleram a integração dos agentes. A maturidade dos repositórios e as estruturas de governança influenciam de forma mensurável a aceitação, sugerindo que os investimentos em infra-estruturas fundamentais geram retornos extraordinários. 6. **Monitorar dívida técnica silenciosa**: clones semânticos tipo 4 (1,87x mais altos no código do agente) e acúmulo de redundância ocorrem sem serem detectados quando os revisores se concentram na correção superficial. Implemente auditorias periódicas de qualidade de código visando especificamente padrões introduzidos por agentes e rastreie reversões, hotfixes e limpeza após o merge junto com métricas de dívida técnica em coortes de agentes. A deterioração de 65,1% na manutenibilidade em refatorações focadas na legibilidade sugere que as tentativas de otimização dos agentes muitas vezes saem pela culatra; restringir a autonomia de refatoração a mudanças bem definidas com validação explícita de melhoria de qualidade. 7. **Definir expectativas claras por meio de diretrizes e ciclos de feedback**: Apenas 27,7% dos projetos tiveram melhorias na taxa de mesclagem após adicionar arquivos de instrução, mas aqueles com arquivos maiores (976 palavras) bem estruturados apresentaram ganhos de 20%. Invista em diretrizes abrangentes e ricas em exemplos que descrevam padrões de código esperados, requisitos de teste, restrições de integração, convenções de repositório e prompts específicos de tarefas. Ciclos de feedback claros continuam críticos; a constatação de que 79,1% dos merges bem-sucedidos não apresentam feedback explícito sugere que diretrizes de alta qualidade podem compensar o trabalho de revisão, mas a qualidade da orientação é imensamente importante. As equipes devem, portanto, tratar os arquivos de instruções e orientações relacionadas como ativos de engenharia mantidos, em vez de artefatos únicos. ## Implicações para pesquisadores 1. **Desenvolver modelos preditivos para triagem de pull requests de agentes**: A previsão antecipada do esforço de revisão (alcançando AUC 0,96 com características estruturais) mostra uma promessa substancial para reduzir a carga do revisor. O trabalho futuro deve estender os modelos de mudanças incompatíveis para prever outras dimensões da complexidade da revisão, incluindo risco de segurança, adequação de testes e impacto na manutenção. Esses modelos devem permanecer atentos às tarefas, separando pequenas correções, documentação, refatoração, testes, CI/CD, manutenção sensível à segurança e trabalho de desempenho, em vez de agrupar tudo em sinais de aceitação agregados. Modelos de previsão multivariados que incorporam tipo de tarefa, identidade do agente, maturidade do repositório e estrutura de mudança poderiam permitir o roteamento automatizado para caminhos de revisão apropriados, reduzindo potencialmente os atrasos de resolução em 5,16x para contribuições complexas. 2. **Investigar as causas raízes da variação do tipo de tarefa**: A diferença de 29 pontos percentuais entre as categorias de tarefas com maior e menor aceitação excede enormemente a variação entre agentes, mas permanece pouco compreendida mecanisticamente. Conduza análises detalhadas sobre por que o desenvolvimento de recursos, a refatoração e a otimização de desempenho geram modos de falha distintos. Estudos baseados em hipóteses que comparem as trajetórias de raciocínio dos agentes entre os tipos de tarefas poderiam identificar oportunidades de reciclagem. A análise qualitativa do feedback dos revisores em todas as categorias de tarefas esclareceria se as lacunas de aceitação refletem diferenças genuínas de qualidade ou preconceitos dos revisores. 3. **Projetar estudos de intervenção sobre ferramentas de apoio ao revisor**: A lacuna de aceitação de 51,7% e o atraso de 3,5x para PRs com alto ICM sugerem uma oportunidade imediata de pesquisa de intervenção. Teste mecanismos de correção automatizados (sugerindo reescritas de descrição com base em diferenças de código), variações de engenharia de prompts e verificação de descrição post-hoc. Além da consistência do código da mensagem, crie ferramentas voltadas para o revisor que sinalizem a provável carga de revisão, destaquem padrões de mudança arriscados e descubram onde a escassa atenção humana é mais necessária. Experimentos controlados randomizados em repositórios reais estabeleceriam se a melhoria do suporte à revisão e da qualidade da descrição pode preencher lacunas de aceitação. Além disso, investigue se os agentes podem aprender a autoverificar a integridade de sua própria implementação antes do envio. 4. **Estabelecer o acompanhamento longitudinal das métricas da dívida técnica**: A análise atual revela padrões imediatos após o merge, mas a carga de manutenção a longo prazo permanece subexplorada. Acompanhe a progressão do code smell, taxas de refatoração, reversões, referências downstream e introdução de defeitos no código contribuído pelo agente durante períodos de 6 a 12 meses. Crie benchmarks e conjuntos de dados complementares para resultados não funcionais e de ciclo de vida, como segurança, alterações significativas, legibilidade, propagação de clones, qualidade de documentação e dívida de manutenção. Investigue se os clones Tipo 4 acumulados e a redundância criam clusters de defeitos duradouros ou se são absorvidos pelos padrões normais de manutenção. A extensão às comparações entre projetos esclareceria se os efeitos da dívida técnica variam de acordo com as características da base de código. 5. **Conduzir estudos de dinâmica de colaboração centrados no ser humano**: Pesquisas qualitativas sobre por que o envolvimento do revisor reduz a aceitação de PRs do agente (probabilidades 17,6 vezes menores) podem iluminar a dinâmica fundamental da confiança humana-IA. Estude como os desenvolvedores modelam mentalmente as capacidades dos agentes, quais padrões de feedback melhoram efetivamente as contribuições dos agentes e como as normas da equipe evoluem com a adoção dos agentes. Estudos etnográficos em organizações com diferentes níveis de maturidade de adoção de IA capturariam dinâmicas de transição e identificariam práticas que apoiam uma integração bem-sucedida. 6. **Desenvolver modelos de comportamento e contextualização do agente**: A impressão digital existente (pontuação F1 de 97,2% com recursos comportamentais) permite a detecção, mas carece de interpretabilidade. Trabalhos futuros devem criar ontologias de comportamento de agentes explicáveis, mapeando padrões de recursos para decisões de design subjacentes e modos de falha. Os pesquisadores também devem investigar formas mais ricas de fundamentação do projeto, como arquivos de instruções, memória de repositório, convenções de codificação e contexto arquitetônico, e testar quais estratégias de fundamentação melhoram mensuravelmente a capacidade de revisão, correção e manutenção a longo prazo. Essa base poderia permitir modelagem preditiva de comportamento e estruturas de comparação de agentes baseadas em princípios, independentes das taxas brutas de mesclagem. 7. **Projetar estruturas de avaliação para desempenho específico de domínio**: As métricas atuais se aplicam amplamente, mas ignoram as restrições de domínio; O desenvolvimento blockchain, móvel, crítico para a segurança e consciente da energia apresenta desafios distintos. Desenvolva rubricas de avaliação específicas de domínio, capturando critérios de aceitação técnicos e contextuais, e vincule essas rubricas a benchmarks mais amplos que medem o comportamento não funcional e do ciclo de vida, em vez de apenas a taxa de mesclagem. Pesquise se os agentes têm sucesso diferente em domínios especializados e se a solicitação ou o ajuste fino com reconhecimento de domínio melhoram os resultados. Estudos longitudinais em ecossistemas especializados (blockchain, estruturas de segurança) esclareceriam se os agentes de uso geral podem atender a requisitos específicos de domínio ou exigir especialização. ## Referências 1. From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests — Kowshik Chowdhury, Dipayan Banik, K M Ferdous, Shazibul Islam Shamim 2. When AI Teammates Meet Code Review: Collaboration Signals Shaping the Integration of Agent-Authored Pull Requests — Costain Nachuma, Minhaz F. Zibran 3. A Study of Library Usage in Agent-Authored Pull Requests — Lukas Twist, Jie M. Zhang 4. AI Builds, We Analyze: An Empirical Study of AI-Generated Build Code Quality — Anwar Ghammam, Mohamed Almukhtar 5. How Do Agents Perform Code Optimization? An Empirical Study — Huiyun Peng, Antonio Zhong Qiu, Ricardo Andrés Calvo Méndez, Kelechi G. Kalu, James C. Davis 6. Code Change Characteristics and Description Alignment: A Comparative Study of Agentic versus Human Pull Requests — Dung Pham, Taher A. Ghaleb 7. Understanding Dominant Themes in Reviewing Agentic AI-authored Code — Md. Asif Haider, Thomas Zimmermann 8. Let's Make Every Pull Request Meaningful: An Empirical Analysis of Developer and Agentic Pull Requests — Haruhiko Yoshioka, Takahiro Monno, Haruka Tokumasu, Taiki Wakamatsu, Yuki Ota, Nimmi Weeraddana, Kenichi Matsumoto 9. Do AI-Generated Pull Requests Get Rejected More? (Yes but Why?) — Yiru Wang, Zhou Yang 10. Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows — Syed Muhammad Ashhar Shah, Sehrish Habib, Muizz Hussain, Maryam Abdul Ghafoor, Abdul Ali Bangash 11. Bug-Fixing in the Age of AI: Human vs. Agentic Pull Requests — Renato Domingues, Fernando Castor, Fernanda Madeiral 12. Why and When Agentic Pull Requests are (not) Accepted: An Exploratory Study — Strauss Marius Christoph, Schulze Sandro 13. When Bots Get the Boot: Understanding PR Rejections in the Era of AI Coders — Karla Gonzalez, Mariam El Mezouar 14. On Autopilot? An Empirical Study of Human-AI Teaming and Review Practices in Open Source — Haoyu Gao, Peerachai Banyongrakkul, Hao Guan, Mansooreh Zahedi, Christoph Treude 15. The Quiet Contributions: Insights into AI-Generated Silent Pull Requests — S. M. Mahedy Hasan, Md Fazle Rabbi, Minhaz Zibran 16. Why Are Agentic Pull Requests Accepted or Rejected? An Empirical Study — Sien Reeve Peralta, Fumika Hoshi, Hironori Washizaki, Naoyasu Ubayashi, Inase Kondo, Yoshiki Higo, Hiroki Mukai, Norihiro Yoshida, Kazuki Kusama, Hidetake Tanaka, Youmei Fan 17. Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance — Giovanni Pinna, Jingzhi Gong, David Williams, Federica Sarro 18. How do Agents Refactor: An Empirical Study — Lukas Ottenhof, Daniel Penner, Abram Hindle, Thibaud Lutellier 19. Mining Type Constructs Using Patterns in AI-Generated Code — Imgyeong Lee, Tayyib Ul Hassan, Abram Hindle 20. Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub — Ramtin Ehsani, Sakshi Pathak, Shriya Rawal, Abdullah Al Mujahid, Mia Mohammad Imran, Preetha Chatterjee 21. When is Generated Code Difficult to Comprehend? Assessing AI Agent Python Code Proficiency in the Wild — Nanthit Temkulkiat, Chaiyong Ragkhitwetsagul, Morakot Choetkiertikul, Ruksit Rojpaisarnkit, Raula Gaikovina Kula 22. When AI Agents Touch CI/CD Configurations: Frequency and Success — Taher A. Ghaleb 23. Fingerprinting AI Coding Agents on GitHub — Taher A. Ghaleb 24. Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests — Jingzhi Gong, Giovanni Pinna, Yixin Bian, Jie M. Zhang 25. When AI Writes Code: Investigating Security Issues in Agentic Software Changes — Esteban Dectot-Le Monnier de Gouville, Mohammad Hamdaqa, Moataz Chouchen 26. On the Reliability of Agentic AI in Continuous Integration Pipelines — Jasem Khelifi, Mahi Begoug, Ali Ouni, Mohammed Sayagh, Mohamed Aymen Saied, Moataz Chouchen 27. Behind Agentic Pull Requests: An Empirical Study on Developer Interventions in AI Agent-Authored Pull Requests — Syrine Khelifi, Ali Ouni, Maha Khemaja 28. When AI Code Doesn’t Stick: An Empirical Study on Reverted Changes Introduced by AI Coding Agents — Issam Oukhay, Mahi Begoug, Moataz Chouchen, Ali Ouni 29. Characterizing Self-Admitted Technical Debt Generated by AI Coding Agents — Zaki Brahmi, Ali Ouni, Mohammed Sayagh, Mohamed Aymen Saied 30. AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development — Shyam Agarwal, Hao He, Bogdan Vasilescu 31. Do AI Agents Really Improve Code Readability? — Kyogo Horikawa, Kosei Horikawa, Yutaro Kashiwa, Hidetake Uwano, Hajimu Iida 32. What to Cut? Predicting Unnecessary Methods in Agentic Code Generation — Kan Watanabe, Tatsuya Shirai, Yutaro Kashiwa, Hajimu Iida 33. Understanding the Rejection of Fixes Generated by Agentic Pull Requests - Insights from the AIDev Dataset — Mahmoud Abujadallah, Ali Arabat, Mohammed Sayagh 34. How AI Coding Agents Communicate: A Study of Pull Request Characteristics and Human Review Responses — Kan Watanabe, Rikuto Tsuchida, Takahiro Monno, Bin Huang, Kazuma Yamasaki, Youmei Fan, Kazumasa Shimari, Kenichi Matsumoto 35. How Do Agentic AI Systems Deal With Software Energy Concerns? A Pull Request-Based Study — Tanjum Motin Mitul, Md. Masud Mazumder, Md Nahidul Islam Opu, Shaiful Chowdhury 36. Humans Integrate, Agents Fix: How Agent-Authored Pull Requests Are Referenced in Practice — Islem Khemissi, Moataz Chouchen, Dong Wang, Raula Gaikovina Kula 37. On the Adoption of AI Coding Agents in Open-source Android and iOS Development — Muhammad Ahmad Khan, Hasnain Ali, Muneeb Rana, Muhammad Saqib Ilyas, Abdul Ali Bangash 38. Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding — Syed Ammar Asdaque, Imran Haider, Muhammad Umar Malik, Maryam Abdul Ghafoor, Abdul Ali Bangash 39. Studying the Footprints of AI Coding Agents in Blockchain Repositories — Munim Iftikhar, Maaz Shahid, Shahreyar Ashraf, Muhammad Saqib Ilyas, Abdul Ali Bangash 40. On the Footprints of Reviewer Bots' Feedback on Agentic Pull Requests in OSS GitHub Repositories — Syeda Kaneez Fatima, Yousuf Abrar, Abdul Rehman Tahir, Amelia Nawaz, Shamsa Abid, Abdul Ali Bangash 41. The Dose Makes the Agent: Therapeutic Index Analysis of AI Coding Contributions — Giuseppe Destefanis, Ronnie de Souza Santos, Marco Ortu, Mairieli Wessel 42. A Task-Level Evaluation of AI Agents in Open-Source Projects — Shojibur Rahman, Md Fazle Rabbi, Minhaz Zibran 43. How AI Coding Agents Modify Code: A Large-Scale Study of GitHub Pull Requests — Daniel Ogenrwot, John Businge 44. An Empirical Study of Tests in Agentic Pull Requests — Sabrina Haque, Sarvesh Ingale, Christoph Csallner 45. Behavioral Analysis of AI Code Generation Agents: Edit, Rewrite, and Repetition — Mahdieh Abazar, Reyhaneh Farahmand, Gouri Ginde, Benjamin Tan, Lorenzo De Carli 46. An Empirical Analysis of Test Failures in AI-Generated Pull Requests — Alireza Hoseinpour, Sajjad Rezvani Boroujeni, Jashhvanth Tamilselvan Kunthavai, Kyle Cusimano, Abbas Heydarnoori 47. Readability of AI-Generated Pull Request Descriptions Across Pull Request Types — Aidan Tobar, Joseph Peterson, Abbas Heydarnoori 48. A Study on Code Clone Lifecycles in Pull Requests Created by AI Agents — Italo Uchoa 49. Early-Stage Prediction of Review Effort in AI-Generated Pull Requests — Duy Minh Dao Sy, Trung Kiet Huynh, Phu Quy Nguyen Lam, Phu Hoa Pham, Chi Nguyen Tran, Dinh Ha Duong Nguyen, Bao Tran Truong 50. Safer Builders, Risky Maintainers: A Comparative Study of Breaking Changes in Human vs Agentic PRs — K M Ferdous, Dipayan Banik, Kowshik Chowdhury, Shazibul Islam Shamim 51. Why Are AI Agent–Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study — Khairul Alam, Saikat Mondal, Banani Roy 52. Toward Instructions-as-Code: Understanding the Impact of Instruction Files on Agentic Pull Requests — Ali Arabat, Mohammed Sayagh 53. Who Writes the Docs in SE 3.0? Agent vs. Human Documentation Pull Requests — Kazuma Yamasaki, Joseph Ayobami Joshua, Tasha Settewong, Mahmoud Alfadel, Kazumasa Shimari, Kenichi Matsumoto 54. An Empirical Study of Code Clone Genealogies in Human–AI Collaborative Development — Denis Sousa, Italo Uchoa, Matheus Paixao, Chaiyong Ragkhitwetsagul, Thiago Lima 55. Beyond Bug Fixes: An Empirical Investigation of Post-Merge Code Quality Issues in Agent-Generated Pull Requests — Shamse Tasnim Cynthia, Al Muttakin, Banani Roy 56. Who Said CVE? How Vulnerability Identifiers Are Mentioned by Humans, Bots, and Agents in Pull Requests — Pien Rooijendijk, Christoph Treude, Mairieli Wessel 57. Human-Agent versus Human Pull Requests: A Testing-Focused Characterization and Comparison — Roberto Milanese, Francesco Salzano, Angelica Spina, Antonio Vitale, Remo Pareschi, Fausto Fasano, Mattia Fazzini 58. Test Coverage of Code Changes in AI-Generated Pull Requests — Tales Vinícius Alves da Cunha, Leopoldo Teixeira 59. How Do Agentic AI Systems Address Performance Optimizations? A BERTopic-Based Analysis of Pull Requests — Md Nahidul Islam Opu, Shahidul Islam, Muhammad Asaduzzaman, Shaiful Chowdhury 60. Testing with AI Agents: An Empirical Study of Test Generation — Suzuka Yoshimoto, Shun Fujita, Kosei Horikawa, Daniel Feitosa, Yutaro Kashiwa, Hajimu Iida 61. LGTM! Characteristics of Auto-Merged LLM-based Agentic PRs — Ruben Branco, Paulo Canelas, Catarina Gamboa, Alcides Fonseca 62. More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests — Haoming Huang, Pongchai Jaisri, Shota Shimizu, Lingfeng Chen, Sota Nakashima, Gema Rodríguez-Pérez 63. AIDev: Studying AI Coding Agents on GitHub — Hao Li, Haoxiang Zhang, Ahmed E. Hassan ## Prompt original (em inglês) Este foi o prompt inicial usado para gerar o relatório. Outras instruções foram usadas depois para verificar a validade do texto. ``` In this folder, we have all PDFs of the MSR mining challenge. This year's challenge was to understand code changes done by agentic AI coders. You can read more about it in the website https://2026.msrconf.org/track/msr-2026-mining-challenge?#Call-for-Mining-Challenge-Papers and in dataset.pdf. You will act as a senior software engineering researcher that will summarize and group the main findings of these papers by themes, similarly to performing a systematic literature review. Your first task is to go paper by paper, read each of them, and then write a summary about the paper. Each summary must have the following: the title and list of authors, a two paragraph summary of the paper (which you can use the introduction and the conclusions part of the paper), and then a bullet point list with 5 to 7 main findings of the paper (which you can get from the results, findings, and implications sections of the paper). Each paper summary should be stored in a markdown file with the same name of the PDF. Then, once all summaries are created, you will read all the summaries and analyze their main findings as a whole. You should group the main findings by themes. Each theme must have a bullet point list of the findings. Each finding must be accompanied by the paper that that finding comes from, and if it comes from multiple papers, list all the papers. The citation must be the name of the PDF. Then, let's write a section called "Implications for Practitioners" with 5-7 recommendations based on these findings. Think of industry developers rather than OSS developers here. Then, let's write a "Implications for Researchers", looking at all the findings. What type of work can they do to improve the current state of things. Finally, create a References section at the bottom where you list the name of the pdf and its title and author list. Get them one by one from the summary files. ``` --- # As vantagens de um doutorado em engenharia de software na indústria Data: 2023-09-07T00:00:00-03:00 URL: https://mauricioaniche.com/blog/advantages-phd-industry/ Idioma: pt-BR Uma pergunta que ouço com frequência de colegas que estão quase concluindo seu doutorado em engenharia de software e considerando uma transição para a indústria é: “Como posso aproveitar minhas habilidades de doutorado no mundo corporativo?” A jornada de doutorado é sem dúvida desafiadora, mas a boa notícia é que ela fornece um conjunto raro de habilidades que podem melhorar significativamente suas perspectivas de carreira na indústria. * **Enfrentando projetos complexos de forma independente.** Embora o caminho para um doutorado possa ser solitário, ele ensina a habilidade inestimável de dividir problemas complexos e vagamente definidos em componentes gerenciáveis. Na indústria, a demanda por indivíduos que possam navegar em projetos complexos com o mínimo de ajuda está sempre presente. * **Generalização de problemas.** Quem tem doutorado possuem uma habilidade de generalizar observações após apenas alguns casos. Esta habilidade para trabalhar em níveis mais elevados de abstração, aprimorada ao longo de anos de pesquisa, os prepara para enfrentar as causas profundas dos problemas, em vez de apenas abordar seus sintomas — um atributo muito procurado no mundo corporativo. * **Comunicação eficaz.** Grande parte do papel de um engenheiro envolve descrever e persuadir outras pessoas sobre suas ideias brilhantes. A qualidade da escrita desempenha um papel fundamental nesse sentido. Quem tem doutorado são excelentes em articular ideias de forma objetiva, apoiando-as com dados e apresentando prós e contras claros. Afinal, o processo de redação de artigos de pesquisa e de convencimento dos revisores gira em torno dessas habilidades. A indústria anseia por indivíduos que possam explicar com clareza as vantagens e desvantagens dos vários caminhos que enfrentam. * **Conhecimento do estado da arte.** Os engenheiros normalmente dependem de livros técnicos e cursos on-line para 99% de seu trabalho diário. No entanto, nesse período crítico de 1% do tempo, o conhecimento dos desenvolvimentos de ponta ainda confinados ao domínio acadêmico pode fazer uma enorme diferença. Os recém-formados com doutorado estão bem familiarizados com a trajetória futura de sua área, mesmo que essas ideias ainda não tenham permeado a indústria. Eles também são adeptos da leitura produtiva de artigos científicos, o que lhes permite ficar atualizados sobre os conceitos mais recentes. Não estou sugerindo que aqueles sem doutorado sejam desprovidos dessas habilidades ou incapazes de adquiri-las. Em vez disso, um programa de doutorado é talvez a única oferta social que aprimora explicitamente essas habilidades. Em geral, você não pratica essas habilidades explicitamente durante sua escolaridade, bacharelado, bootcamp ou treinamento interno. No entanto, aqui está a advertência: os programas de doutorado mergulham você profundamente em um nicho específico e restrito dentro de sua área. A intensidade do programa, aliada ao foco na contribuição para o estado da arte, deixa pouco espaço para o aprendizado das facetas práticas da engenharia de software. Esta é sem dúvida a desvantagem mais significativa do programa de doutorado em comparação com os engenheiros tradicionais. No entanto, acredito firmemente que é muito mais fácil ensinar a alguém as práticas, os princípios e as ferramentas atuais do setor do que incutir as habilidades que mencionei anteriormente. Portanto, se você está chegando ao fim de sua jornada de doutorado e deseja embarcar em uma carreira no setor, reserve algum tempo para se familiarizar com a engenharia de software prática. Boa sorte nessa jornada! (Escrito por mim, revisado pelo ChatGPT) --- # O que aprendi ao inverter minha sala de aula Data: 2021-02-03T00:00:00-03:00 URL: https://mauricioaniche.com/blog/what-did-i-learn-from-flipping-my-classroom/ Idioma: pt-BR Experimentei sala de aula invertida nas edições 2019-2020 e 2020-2021 de nosso Teste e Qualidade de Software (CSE1110). Esta foi a primeira e a segunda vez que experimentei "de verdade". Pedi aos alunos que [lessem o material](https://sttp.site), resolvessem alguns exercícios e fizessem perguntas no fórum online _antes_ da palestra; a palestra em si seria usada apenas para debate. No primeiro ano em que fiz isso, não tinha certeza se funcionaria. Meu pensamento honesto era que os alunos não fariam suas tarefas antes da aula. Tive medo de não ter perguntas para responder ou temas para debater; Até me certifiquei de ter os slides que usei nos anos anteriores como plano de backup caso isso não funcionasse. Eu não poderia estar mais errado! **Um grande número de alunos realmente lê as notas da aula _antes_ da aula**. Veja os números abaixo, referentes a 2020 e 2021, respectivamente. Note-se que a maioria dos alunos afirma ter lido as notas de aula antes de _todas_ as nossas 13 aulas em 2020 (obtive 329 respostas entre cerca de 500 alunos que frequentam o curso), e a maioria dos alunos também afirma ler as notas antes da aula em 2021 (número de respondentes na figura), embora de forma menos expressiva quando comparado com o ano anterior. Essa é, pelo menos para mim, a lição mais importante aprendida aqui. Claro que também existe um número não negligenciável de alunos que nunca lêem as notas de aula, mas prefiro ver isso pelo lado positivo. ![Leitura das notas antes das aulas em 2020](https://mauricioaniche.com/assets/blog/flipped-classroom/output_6_0.png) Leitura das notas antes das aulas em 2021 Por outro lado, **resolver os exercícios _antes_ da aula é definitivamente feito com menos frequência.** Você vê os dados brutos nas figuras abaixo. Ao refletir sobre o primeiro ano, diria que ofereci muitos exercícios e muitos deles envolviam codificação. Isso significa que os alunos não poderiam simplesmente “acordar uma hora antes da aula e ler”. Mudei isso no segundo ano: as questões antes da palestra eram, em sua maioria, questões curtas de múltipla escolha. Mesmo sendo muito mais rápidos nas respostas, os alunos ainda não parecem se envolver com elas. Curiosamente, como mostrarei mais tarde, a resolução de exercícios era muito popular quando se tratava de estudar para o exame. ![Exercícios antes das aulas em 2020](https://mauricioaniche.com/assets/blog/flipped-classroom/output_8_0.png) Resolução de exercícios antes das aulas em 2021 Eu também disse aos alunos na aula introdutória que não daria “nenhum material novo” per se nas aulas; em vez disso, serviriam para responder perguntas e debater temas mais avançados. Portanto, o lado negro dentro de mim esperava que os alunos não assistissem às palestras. Sem ter números concretos, tenho sim uma frequência maior no início do curso, com mais de 300 participantes me assistindo no Zoom, mas no final esse número caiu para uma média de 150. Isso aconteceu nos dois anos e se reflete nas respostas da pesquisa. Dito isto, não assistir às aulas faz parte da cultura dos nossos alunos, pois muitos deles preferem aproveitar esse tempo para estudar. No entanto, **não percebi uma grande queda na frequência em comparação com as palestras tradicionais** onde as pessoas tinham que estar presentes para ouvir a informação. Além disso, eu definitivamente reconheci muitos alunos que acompanharam todas as palestras (algo complicado de fazer no ambiente on-line, pois todos estavam com as webcams desligadas e interagiam principalmente por chat). Curiosamente, minha percepção foi que o **nível das perguntas que os alunos me fizeram durante a palestra foram definitivamente um nível mais alto do que nos anos em que não inverti a sala de aula**. Algumas questões eram tão mais avançadas que, muitas vezes, tive que improvisar novos exemplos para expressar meu ponto de vista. Minha conjectura aqui é que todos os alunos agora conhecem o básico antes de ingressar na minha palestra e, portanto, levam as perguntas para o próximo nível. O **número de perguntas no fórum também foi muito alto no primeiro ano**. No final do biénio 2019-2020, tivemos 201 perguntas e 443 respostas (nunca tive tantas perguntas no fórum online antes). Muitas perguntas aconteceram antes da palestra, embora eu não tenha números concretos para compartilhar. Fiz questão de responder a essas perguntas todas as manhãs antes do início da palestra e usei essas perguntas como pontos de discussão na palestra. Curiosamente, **o número de perguntas diminuiu na edição 2020-2021**. Não tenho números concretos em mãos, mas definitivamente houve menos perguntas. Vejo duas explicações para isso. Primeiro, adotamos o StackOverflow como um sistema de perguntas e respostas. Embora tenha notado um aumento na qualidade das respostas fornecidas pelos próprios alunos, talvez os alunos sintam um pouco mais de medo de postar uma pergunta que perdure por todas as próximas edições do curso. Em segundo lugar, os alunos estão agora mais habituados a estudar online. Quando perguntei na aula por que havia tão poucas perguntas, eles mencionaram que muitas delas realmente acontecem em seu canal privado do Discord. Parte do meu plano para o terceiro ano será convencê-los de que é realmente importante construir uma base de conhecimento. ![Participação e perguntas em 2020](https://mauricioaniche.com/assets/blog/flipped-classroom/output_10_0.png) Participação nas aulas em 2021 Outro ponto interessante, e provavelmente muito contextual ao nosso programa de ciência da computação, é que os alunos não trabalharam na tarefa laboratorial opcional que oferecemos. 2020 foi o primeiro ano que ofereci como opcional (ou seja, não faz parte da nota), seguindo nossos novos regulamentos que não permitem trabalhos de casa obrigatórios. Embora eu tenha dito aos alunos que o trabalho de laboratório lhes daria uma perspectiva mais prática sobre o tema e que os TAs estavam disponíveis para ajudá-los com qualquer dúvida, você pode ver na figura abaixo que **apenas alguns alunos realmente trabalharam em todas as três partes do projeto de trabalho de laboratório (opcional)**. No segundo ano, decidi abandonar completamente a tarefa e focar em “exercícios mais focados”. Isso pareceu funcionar, pois **a maioria dos alunos resolveu exercícios relacionados a todas as aulas**. Esse parece ser o caminho e pretendo melhorar ainda mais nosso conjunto de exercícios. ![Atividades de laboratório em 2020](https://mauricioaniche.com/assets/blog/flipped-classroom/output_12_0.png) Resolução de exercícios após as aulas em 2021 Talvez outra coisa que não surpreende é que **uma grande parte dos alunos não passa todas as horas que deveriam no curso**. CSE1110 é um curso de 5 ECTS, o que significa que os alunos devem dedicar cerca de 14 horas semanais ao curso, por exemplo, acompanhando aulas, lendo, resolvendo exercícios, estudando. Como você pode ver abaixo, apenas alguns alunos chegam às 14 horas. Meu pressentimento diz que o quarto trimestre (trimestre onde meu curso acontece) é movimentado para os alunos, já que eles têm dois cursos teóricos básicos de ciência da computação. Muitas vezes os vejo gastando muita energia nesses outros cursos (são bem difíceis!) enquanto entro no laboratório. Não tenho certeza se aumentar o número de atividades é uma boa ideia, dada a agenda bastante lotada. Talvez eu deva apenas aceitar que eles não passarão todas as horas que precisam. Observo também que alguns deles ultrapassam as 15 horas, o que também não é o ideal. Eu deveria entender por que esse é o caso. ![Horas dedicadas ao curso em 2020](https://mauricioaniche.com/assets/blog/flipped-classroom/output_14_0.png) Horas semanais dedicadas ao curso em 2021 Por fim, perguntei aos alunos como estudaram para o exame final. Embora não seja realmente uma surpresa, **resolver exercícios e reler as notas de aula eram práticas de estudo populares**. O interessante, porém, é que eles preferem não resolver as questões que coloco nas notas de aula (que são bastante variadas), mas questões que compartilho explicitamente como "essas questões são semelhantes às questões do exame", que são um pouco mais focadas nos tipos de perguntas que posso fazer durante os exames. Este é novamente outro regulamento que temos aqui: temos que oferecer alguns exames simulados, e os alunos aproveitam isso. Minha lição aprendida aqui é apenas oferecer mais “práticas de exame” com mais perguntas. Verdade seja dita, essas perguntas não são tão ruins, pois são principalmente trechos de código onde peço aos alunos que escrevam testes, e eles precisam aproveitar JUnit e/ou Mockito para testá-los. Em breve investirei em outros tipos de testes (por exemplo, testes de integração, testes Selenium, etc). Além disso, gostei que eles realmente **releram minhas notas de aula**, mostrando que todo o esforço que fiz para construí-las está valendo a pena. Finalmente, parece que os alunos preferem **reler as notas de aula em vez de assistir novamente aos vídeos**. Além das notas textuais, também compartilhei vários vídeos. Isso também é bom para mim, pois evoluir notas de aula textuais é muito mais fácil do que evoluir vídeos. ![Práticas de estudo em 2020](https://mauricioaniche.com/assets/blog/flipped-classroom/output_16_1.png) Práticas de estudo para a prova em 2021 O que eu tive que mudar no meu curso para invertê-lo? Três coisas: - Primeiro, **criar notas de aula**. Foi muito trabalho, para ser honesto. No entanto, sinto que o custo será compensado com o tempo, pois poderei reutilizá-los facilmente nos próximos anos. (Bem, dado o quanto meus alunos gostaram, decidi escrever um livro adequado sobre o assunto, o que dá muito trabalho novamente; então, siga-me para novidades em breve). Algumas novidades: estou trabalhando em um livro completo sobre testes de software que será publicado pela Manning em 2021. Manterei vocês informados. - Segundo, **confiar que os alunos farão a sua parte**. Foi muito difícil para mim ir às primeiras palestras sem um longo conjunto de slides. Eu estava com muito medo de ficarmos ali em silêncio durante toda a palestra. Porém, quanto mais o tempo passava, mais eu via que realmente podia confiar neles. Além disso, como as notas da aula estavam disponíveis no GitHub, orientei os alunos a enviar pull requests sempre que encontrassem algo não tão claro. Ao longo do trimestre, recebi mais de 100 PRs de alunos! Embora eu tenha dito que os alunos ganhariam pontos extras por isso, prefiro acreditar que alguns deles estavam realmente empenhados em simplesmente melhorar o material. Além disso, **certifique-se de não ter o cenário perfeito em mente**. Por exemplo, vimos que os alunos não fazem exercícios antes da aula. Talvez eu devesse apenas aceitar isso e focar em outras maneiras de eles exercitarem seus conhecimentos. - Terceiro, **reservar tempo para responder às perguntas**. Todo o tempo que não gastei preparando slides, tive que gastar respondendo perguntas no fórum. Eu queria proporcionar aos alunos uma experiência incrível, então li todas as perguntas que foram postadas e respondi a grande maioria delas (as outras foram respondidas por algum monitor). No entanto, responder às perguntas não demorou muito tempo. Acho que 30 minutos antes de cada palestra geralmente é suficiente. Também passo algum tempo elaborando alguns slides de última hora com os principais pontos que observei no fórum. Por fim, devo dizer que estou gostando muito da experiência da sala de aula invertida. Em ambos os anos, sinto que foi bom para mim e para os alunos. Não me senti entediado em nenhuma das palestras (um sentimento comum quando você está dando a mesma palestra pela enésima vez). **Agradecimentos:** Isso não seria possível sem a ajuda de tantas pessoas. Primeiro, Frank Mulder, meu parceiro neste curso. Além disso, devo agradecer a Wouter Polet e Sará Juhosová, meus monitores responsáveis (Wouter sendo meu monitor responsável pela terceira vez consecutiva). Além disso, a Marsha Ginsberg, pelas muitas melhorias gramaticais nas próprias notas de aula. Finalmente, a todos os alunos CSE1110 de 2019-2020 e 2020-2021 por serem tão gentis. --- # Testar é diferente de escrever testes Data: 2018-06-21T00:00:00-03:00 URL: https://mauricioaniche.com/blog/testing-vs-writing-tests/ Idioma: pt-BR _Testar é diferente de escrever testes. Desenvolvedores escrevem testes para ter espaço para pensar e confiança para refatorar. Testar tem como foco encontrar bugs. As duas práticas são necessárias._ Chegamos a um ponto em que os desenvolvedores *sabem* que precisam escrever testes automatizados. Afinal, ideias como [Extreme Programming](https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658) e [Test-Driven Development](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ref=pd_lpo_sbs_14_t_1?_encoding=UTF8&psc=1&refRID=WE962S6TKV1QRTYEN1WT), de Kent Beck, Michael Feathers sobre [sinergia entre teste e design](https://vimeo.com/15007792), Steve Freeman e Nat Pryce sobre [como desenvolver um software orientado a objetos guiado por testes](https://www.amazon.de/Growing-Object-Oriented-Software-Addison-Wesley-Signature/dp/0321503627), DHH e Ruby on Rails ao [garantir que um framework web venha com um framework de testes](http://guides.rubyonrails.org/testing.html), entre outras, se consolidaram. Essas ideias também ficaram comigo. Tenho tentado escrever o máximo possível de testes automatizados para os sistemas de software em que trabalho desde 2007 (posso contar a história de quão traumático foi meu projeto de 2006 em uma postagem posterior). Fiquei tão entusiasmado com o Desenvolvimento Orientado a Testes que até fiz dele o tópico da minha [tese de mestrado](https://journal-bcs.springeropen.com/articles/10.1186/s13173-015-0034-z). Em 2012, achei que tinha experiência suficiente com o tópico, então decidi escrever um [livro sobre como eu estava praticando TDD](https://www.casadocodigo.com.br/products/livro-tdd), bem como um [livro sobre os fundamentos de ferramentas como JUnit e Selenium](https://www.casadocodigo.com.br/products/livro-testes-de-software) (infelizmente, disponível apenas em português brasileiro). Depois de muitos anos de programação em pares, vejo desenvolvedores usando código de teste automatizado como uma espécie de *rede de suporte*. Os testes ajudam a pensar com clareza sobre o que implementar e dão suporte às inúmeras refatorações que acontecem durante o desenvolvimento. Na verdade, pesquisas mostraram algumas vezes que fazer TDD pode melhorar o design de sua classe (veja [Janzen](http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1039&context=csse_fac), [Janzen e Saiedian](http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1030&context=csse_fac), [George e Williams](https://www.semanticscholar.org/paper/An-Initial-Investigation-of-Test-Driven-Development-George-Williams/66869075d20858a2e9af144b2749a055c6b03177), [Langr](http://eisc.univalle.edu.co/materias/TPS/archivos/articulosPruebas/test_first_design.pdf), [Dogsa e Batic](https://link.springer.com/article/10.1007/s11219-011-9130-2), [Munir, Moyaaed e Petersen](https://pdfs.semanticscholar.org/16d4/2a1eaefb1f404f6da91b12d6c0e710dacb9d.pdf), [eu](https://journal-bcs.springeropen.com/articles/10.1186/s13173-015-0034-z), entre outros). Recentemente, [Fucci et al.](https://arxiv.org/pdf/1611.05994.pdf) argumentaram que a parte importante é escrever testes (e não importa se é antes ou depois). Essa também é a percepção dos profissionais, como mostra uma [postagem recente no blog de Feathers](http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html): *"Essa é a mágica, e é por isso que os testes unitários também funcionam. Quando você escreve testes unitários, no estilo TDD ou após o desenvolvimento, você examina, pensa e muitas vezes evita problemas sem sequer encontrar uma falha no teste."* Escrever testes automatizados é, portanto, algo a ser recomendado. Pragmaticamente falando, sinto que, ao usar código de teste como forma de fortalecer a confiança, *testes do caminho feliz são muitas vezes suficientes*. E, de fato, não há necessidade de muito conhecimento ou teorias para testar o caminho feliz: basta saber como tornar os testes possíveis (os desenvolvedores falam muito sobre projetar para testabilidade) e usar as melhores ferramentas disponíveis (e os desenvolvedores realmente dominam ferramentas como JUnit, Mockito e Selenium). O que defendo é que, após implementar o código de produção (com todo o suporte do código de teste de caminho feliz), o próximo passo deveria ser testá-lo adequadamente. **O teste de software consiste em encontrar muitos bugs**; trata-se de explorar como o seu sistema se comporta não apenas no caminho feliz, mas também em casos excepcionais e extremos. Recentemente perguntei aos meus alunos do primeiro ano de ciência da computação que tipos de erros eles cometeram em seus programas até agora, o que os ensinou que o teste é importante. Recebi uma lista enorme: * Programas que não funcionam quando um loop não itera (a condição do loop nunca foi avaliada como verdadeira e o programa travou). * Programas que não funcionam porque deixaram de executar a última iteração (o famoso erro off-by-one). * Programas que não funcionam quando as entradas são inválidas, como null, ou não estão de acordo com o esperado (por exemplo, uma string que representa o nome de um arquivo a ser aberto contendo um espaço extra no início). * Programas que não funcionam porque o valor está fora do intervalo esperado ou exatamente no seu limite. Por exemplo, se você tiver um if que espera que um número seja maior que 10, o que acontece se o número for menor que 10? Ou precisamente 10? * Dependências que não existem, por exemplo, seu programa lê um arquivo, mas o arquivo pode não estar lá. * Entre outros. Independentemente da sua experiência, tenho certeza de que você também já enfrentou alguns desses bugs antes. *Mas com que frequência os desenvolvedores realmente exploram e escrevem esses casos de teste?* Tenho a impressão de que isso acontece pouco. (Se você é um pesquisador empírico de engenharia de software, esta essa é uma boa pergunta para investigar). É claro que, quando se trata de teste de software, [pesquisadores e profissionais falam sobre diferentes tópicos.](https://ieeexplore.ieee.org/abstract/document/8048625/) Livros pragmáticos muito bons, como [Pragmatic Unit Testing in Java 8 with JUnit](https://pragprog.com/book/utj2/pragmatic-unit-testing-in-java-8-with-junit), têm um forte foco em como fazer automação de testes. Embora forneçam boas dicas sobre o que testar (os capítulos sobre [CORRECT e RIGHT-BICEP](https://media.pragprog.com/titles/utj2/bicep.pdf) no livro da PragProg são interessantes), eles geralmente não vão além disso. Por outro lado, livros de teste de software da academia, meu favorito é [Análise de Teste de Software](https://www.amazon.com/Software-Testing-Analysis-Principles-Techniques/dp/0471455938) de Young e Pezzè, têm um forte foco em teorias e técnicas sobre como projetar casos de teste que exploram o máximo possível do programa em teste. No entanto, com poucos exemplos oportunos sobre como aplicar essas ideias, o que é definitivamente um requisito para os profissionais. [Robert Binder em seu livro de 2000](https://www.amazon.de/Testing-Object-Oriented-Systems-Addison-wesley-Technology/dp/0201809389) (p.45) faz uma distinção entre testes “direcionados a falhas” e “direcionados à conformidade”: * Testes direcionados a defeitos: a intenção é revelar defeitos observando falhas. * Conformidade direcionada: intenção de demonstrar conformidade com os recursos exigidos (por exemplo, atende a uma história de usuário, concentra-se no comportamento do caminho feliz). Eu argumento que **um desenvolvedor forte deve testar de ambas as perspectivas**. Eles são complementares. Como desenvolvedor, se você quiser levar seus testes para o próximo nível, você definitivamente deve se familiarizar com o que os pesquisadores têm feito, pois eles têm conduzido um belo trabalho na área de testes de software, que acredito ser definitivamente aplicável na prática. Alguns exemplos (mas definitivamente não uma lista completa): * Detectar se algum conjunto de testes é capaz de detectar possíveis bugs. A ideia de [teste de mutação](https://ieeexplore.ieee.org/abstract/document/5487526/) está [sendo aplicada no Google](https://research.google.com/pubs/archive/46584.pdf). * Gerar testes automaticamente (o famoso exemplo é o [EvoSuite](https://pdfs.semanticscholar.org/216b/98bb3d9221d5f5d261864975612e4d0faaa6.pdf), que é capaz de gerar testes para classes Java) ou para [reproduzir travamentos automaticamente](https://pure.tudelft.nl/portal/en/publications/a-guided-genetic-algorithm-for-automated-crash-reproduction(3490acbb-240b-4ec2-8202-712a7d1bb64e).html). Eu mesmo trabalhei em [gerar testes para consultas SQL automaticamente](https://pure.tudelft.nl/portal/en/publications/searchbased-test-data-generation-for-sql-queries(90a6431f-f78f-4ac3-bf87-c052cd9cd5d4).html). * Derivação de [modelos dos logs do seu sistema de produção](https://pure.tudelft.nl/portal/en/publications/an-experience-report-on-applying-passive-learning-in-a-largescale-payment-company(b463c54a-d69f-4db4-9fcc-cbeb6e2ddf09).html) e construção de modelos que podem ser analisados por especialistas do domínio. * Fornecer [diferentes critérios de cobertura de código](http://laser.cs.umass.edu/courses/cs521-621/papers/ZhuHallMay.pdf) (você provavelmente tem alguma ferramenta de cobertura de código em seu CI) e entender os benefícios de cada um deles. * Várias ferramentas para testar aplicativos da web, como [explorar automaticamente o aplicativo da web em busca de falhas](http://search.proquest.com/openview/c7cf9aff7640da5036f7653ca6a9bfe1/1?pq-origsite=gscholar&cbl=21418&casa_token=Zr4Nz0ZAzfsAAAAA:UTguZ-3zSx1MHQUGirDsM_wejL2UtQRJd93oADSQ2TMCXdTSpAcQveL-YzvQrCtoHhBBn5ywyr0), bem como [encontrar falhas em APIs REST](https://github.com/EMResearch/EvoMaster/blob/master/docs/publications/2017_qrs.pdf). Mais informações podem ser encontradas nesta [revisão da literatura de testes da web](https://www.sciencedirect.com/science/article/pii/S0164121214000223). * Medir empiricamente [quanto os desenvolvedores testam](https://pure.tudelft.nl/portal/en/publications/developer-testing-in-the-ide-patterns-beliefs-and-behavior(a63e79e0-e0e4-48cd-81ed-87f163810538).html), se [os test smells são importantes](http://www.cs.loyola.edu/~binkley/papers/icsm-12-smells.pdf) ou se [eles são a causa de testes instáveis](https://pure.tudelft.nl/portal/en/publications/does-refactoring-of-test-smells-induce-fixing-flaky-tests(c68e527c-bf4a-41f4-827a-6fcab9582c71).html), [por que e como os mocks são usados em sistemas Java](https://pure.tudelft.nl/portal/en/publications/to-mock-or-not-to-mock(a0b02521-ad00-4f96-9d96-17a85dc23f99).html), e como [os desenvolvedores revisam o código de teste durante as revisões de código](https://pure.tudelft.nl/portal/en/publications/when-testing-meets-code-review-why-and-how-developers-review-tests(256e7d56-352f-44ae-919b-97fad0eafe69).html). * Os testes baseados em propriedades também estão chegando aos profissionais por meio de ferramentas como [ScalaCheck](https://www.scalacheck.org/) e [QuickTheories](https://github.com/ncredinburgh/QuickTheories). * Entre outras coisas. E se você quiser entrar nessa luta, leia este resumo de [Antonia Bertolino sobre os atuais desafios da pesquisa em testes](http://people.scs.carleton.ca/~jeanpier/sharedF14/Bertolino-state-of-artinSWTesting.pdf). **Escrever testes é diferente de testar**. Ambos fornecem aos desenvolvedores resultados diferentes. O primeiro dá confiança e apoio durante todo o desenvolvimento. Este último garante que o software foi avaliado também nos cenários que podem revelar defeitos. Embora ambos sejam importantes, é hora de ambas as comunidades se alinharem: * Os desenvolvedores devem se familiarizar mais com técnicas de teste de software mais avançadas (que os pesquisadores têm fornecido). Eles são definitivamente um bom complemento à rede de segurança dos testes e os ajudarão a testar melhor seus softwares. * Educadores devem ensinar ambas as perspectivas. Minha percepção é que as universidades ensinam técnicas de teste de forma abstrata (os desenvolvedores precisam aprender como usar as ferramentas!), enquanto os profissionais ensinam apenas como usar as ferramentas automatizadas (os desenvolvedores precisam aprender como testar corretamente!). * Pesquisadores devem entender melhor como os profissionais têm evoluído no campo de testes de software a partir de sua perspectiva, bem como para compartilhar melhor seus resultados, já que os desenvolvedores não leem artigos. [O jargão de pesquisa é para pesquisadores](https://twitter.com/mauricioaniche/status/997498070395949057). Atualização: Mariefred (da R/Programming) sugeriu este link relacionado: [Teste e verificação refinados](http://www.satisfice.com/blog/archives/856). *Agradecimentos: Agradeço a Alberto Souza (Caelum, São Paulo), Anderson Leite (RG/A, São Francisco) e Arie van Deursen (Delft University of Technology) pelos comentários nas versões anteriores deste post.* --- # O que sabemos (e o que não sabemos) sobre Domain-Driven Design? Data: 2017-12-05T00:00:00-02:00 URL: https://mauricioaniche.com/blog/what-do-we-not-know-about-ddd/ Idioma: pt-BR Em 2004, Evans escreveu o belo "Design orientado a domínio: combatendo complexidade no coração do software". Em poucas palavras, Evans mostra que a verdadeira complexidade do sistema (seu coração) muitas vezes depende do seu modelo de domínio. O livro apresenta então vários padrões para apoiar a modelagem de modelos de domínio. Eu mesmo considero este livro obrigatório para Engenheiros de Software. Influenciado pelo estilo de estampa de Christopher Alexander, o livro contém um total de 43 estampas divididas em quatro partes. O livro rapidamente atraiu a atenção dos profissionais: diferentes autores começaram a escrever seus próprios livros sobre DDD, Stack Overflow contém mais de 4.000 perguntas e 7.000 respostas relacionadas ao tema (em 27 de janeiro de 2017), os desenvolvedores trocaram 24.000 e-mails na mailing list oficial que está hospedada no Yahoo Groups!, e existem até conferências dedicadas ao tema, como DDDEurope. O elevado número de perguntas e discussões faz sentido. Afinal, se você já tentou implementar DDD, provavelmente enfrentou desafios, que vão desde “como modelar X” até “como implementar isso na prática ao usar o Hibernate”. ![Padrões no livro DDD](https://mauricioaniche.com/assets/blog/ddd/i1.png)*Padrões no livro DDD* Então, por que não investigar o que os desenvolvedores estão realmente perguntando sobre DDD em sites como Stack Overflow e Yahoo! Grupos? *Quais são os padrões DDD mais discutidos? Que tipo de perguntas os desenvolvedores fazem? Com que frequência uma discussão se torna técnica (ou seja, contém código-fonte)? Quais são as referências mais comumente citadas nessas discussões? Como os tópicos se correlacionam entre si?* No Stack Overflow (SO), extraímos todas as questões da tag #ddd. A amostra contém 4.076 questões, sendo a primeira postada em 24 de agosto de 2008 e a última postada em 27 de janeiro de 2017. Essas questões juntas receberam 7.799 respostas. O número de questões varia de 381 questões (em 2009) a 593 (em 2011). Vemos um aumento no número de questões após 2010 que permaneceu semelhante até 2015. Em 2016, observamos uma pequena queda. Da mesma forma, o número de respostas varia de 720 (em 2016) a 1.176 (em 2011). Cada pergunta recebe uma mediana de 2 respostas. Essas postagens foram feitas por 2.176 usuários diferentes. O número médio de postagens feitas por um usuário é 1 (máx. = 26). Nós raspamos o Yahoo! Página Grupos (YG), pois não há API para extrair as discussões. Se o título da mensagem não contivesse "RE:", marcamos como pergunta ou como resposta, caso contrário. Realizamos algumas limpezas de texto para remover assinaturas, corpos repetidos (os clientes de e-mail geralmente anexam o e-mail anterior abaixo do novo e-mail) e anúncios que o Yahoo! às vezes adiciona e-mails. A amostra contém 5.091 e-mails e 19.514 respostas. O primeiro e-mail foi postado em 6 de setembro de 2001. Cada e-mail recebe em média 5 respostas. Os e-mails foram enviados por 1.765 usuários diferentes. A lista teve pico de e-mails e respostas em 2009, com 1.689 e-mails e 5.693 respostas. O número de e-mails caiu drasticamente em 2014 (48), 2015 (33) e 2016 (18). ![Perguntas e respostas ao longo do tempo no StackOverflow (à esquerda) e no Yahoo! Grupos (à direita)](https://mauricioaniche.com/assets/blog/ddd/i2.png)*Perguntas e respostas ao longo do tempo no StackOverflow (à esquerda) e no Yahoo! Grupos (à direita)* **Quais são os padrões de design orientados a domínio mais discutidos?** * **Os padrões na Parte II são muito mais populares do que outras partes do livro.** Três desses padrões (*Entidade*, *Serviço* e*Repositório*) aparecem em mais de 1.000 perguntas no Stack Overflow e no YG. *Agregados* também são populares em ambos (1.041 perguntas no SO e 936 no YG). As *Entidades*, em particular, são as mais populares, aparecendo em 1.841 perguntas (45% de todas as perguntas) e 2.539 respostas (32% de todas as respostas) no SO, e em 1.351 perguntas (27%) e 3.934 (20%) na YG. Nenhuma outra parte do livro contém padrões tão populares. Por outro lado, a Parte IV é a menos popular, pois a maioria dos padrões contém zero ou menos de 10 questões. *Bounded Context *é uma exceção em ambos os conjuntos de dados, aparecendo em 231 perguntas e em 451 respostas no SO, e em 196 e-mails iniciais e 621 respostas no YG. * **Existem questões que não se concentram em nenhum padrão.** Embora, como esperado, a maioria das questões se concentre nos padrões definidos no livro, algumas delas não o fazem. No SO, 18% deles não mencionam nenhum deles. Esse número é maior na GJ: 41%. ![Número de perguntas e respostas mencionando padrões DDD. T=Total de perguntas/respostas, C=Perguntas/respostas com código-fonte, L=Perguntas/respostas com links.](https://mauricioaniche.com/assets/blog/ddd/i3.png)*Número de perguntas e respostas mencionando padrões DDD. T=Total de perguntas/respostas, C=Perguntas/respostas com código fonte, L=Perguntas/respostas com links.* ![Número de e-mails e respostas mencionando padrões DDD no Yahoo! Grupos. T=Total de perguntas/respostas, C=Perguntas/respostas com código fonte, L=Perguntas/respostas com links.](https://mauricioaniche.com/assets/blog/ddd/i4.png)*Número de e-mails e respostas mencionando padrões DDD no Yahoo! Grupos. T=Total de perguntas/respostas, C=Perguntas/respostas com código fonte, L=Perguntas/respostas com links.* **Que tipo de perguntas os desenvolvedores fazem?** Contamos o número de “o que”, “como” e “por que” que apareciam no título de todas as postagens. As perguntas no SO pareciam seguir melhor esta convenção do que as postagens no YG. * **"Como" é o tipo de pergunta mais popular.** No SO, observamos 1.064 perguntas *como*, 222 perguntas *o quê* e 50 perguntas *por que*. Na YG, contamos 329 perguntas do tipo *como*, 110 perguntas do tipo *o quê* e 15 perguntas do tipo *por que*. * **A entidade é de longe a que tem mais perguntas do tipo "como".** A *Entidade* recebeu 301 perguntas do tipo "como" no SO. É seguido por *Repositórios *(199), *Agregados* (187) e *Serviços* (185). Em outras partes do livro, *Bounded Context* (34) é o mais popular, embora longe dos mencionados acima. ![Tipos de perguntas (o quê, por que, como) em SO e YG](https://mauricioaniche.com/assets/blog/ddd/i5.png)*Tipos de perguntas (o quê, por que, como) em SO e YG* **Com que frequência uma discussão se torna técnica (ou seja, contém código-fonte)?** * **O número de perguntas e respostas com detalhes de implementação é significativo.** Um número significativo de perguntas e respostas contém trechos de código-fonte. Os padrões da Parte II são aqueles com mais código-fonte. Embora isso esteja relacionado ao fato de a Parte II ser a mais popular no SO, alguns padrões contêm uma alta frequência de detalhes de implementação em suas perguntas e respostas. O padrão *Especificação*, por exemplo, contém código-fonte em 65% de suas perguntas e em 51% de suas respostas. Números semelhantes acontecem em muitos outros padrões. * **Perguntas e respostas no SO têm maior probabilidade de ter código-fonte do que e-mails no YG.** No SO, observamos 1.985 e 2.091 questões com e sem código-fonte, respectivamente. Na YG, esses números caem para 546 e 4.545. Portanto, uma pergunta SO tem 8,76 vezes (intervalo de confiança de 95%: 7,8714 - 9,7683, Qui-Quadrado = <0,0001) mais probabilidade de conter um código-fonte do que um e-mail inicial em YG. Observamos uma probabilidade semelhante nas respostas: Embora SO contém 2.965 e 4.834 respostas com e sem código-fonte, YG contém 1.344 e 18.170. Isso significa que uma resposta em SO tem 8,29 vezes (intervalo de confiança de 95%: 7,7175 - 8,9099, Qui-Quadrado = <0,0001) mais probabilidade de conter um código-fonte do que uma resposta em YG. **Quais são as referências mais comuns nas discussões?** * **É comum encontrar links em perguntas e respostas.** Curiosamente, a presença de links é quase tão frequente quanto o código-fonte. Em alguns padrões, o número de links é ainda maior: *Bounded Context *contém links em 164 respostas SO (enquanto 113 com código fonte), *Mapa de Contexto *contém links em 13 respostas (e apenas 3 com código fonte), e *Linguagem Ubíqua* (109 contra 106). Observamos padrões semelhantes também no conjunto de dados YG. Curiosamente, isso acontece apenas nas respostas; o número de links nunca é maior que o número de códigos-fonte em questão. * **Os desenvolvedores referem um total de 1.770 links diferentes.** Os usuários do SO citaram um total de 956 links diferentes, enquanto o YG citou um total de 997. Há uma interseção de 183 links entre os dois conjuntos de dados. * **StackOverflow e o blog de Martin Fowler são as referências mais populares.** No SO, os usuários costumam consultar outros links do SO. Na YG, o wiki de Martin Fowler é a referência mais citada. O wiki de Fowler também é popular no SO, com um total de 432 citações. Outras referências comuns para ambos os conjuntos de dados são domaindrivendesign.org (o site oficial do DDD), Wikipedia e o blog pessoal de Udi Dahan. * **Perguntas e respostas no SO têm maior probabilidade de conter links do que e-mails no YG.** Existem 744 e 3.332 perguntas com e sem links no SO. Os mesmos números para YG são 721 e 4.370. Assim, as perguntas no SO têm 1,35 vezes (intervalo de confiança de 95%: 1,21 - 1,51, Qui-Quadrado = <0,0001) mais probabilidade de conter um link do que o YG. Além disso, o SO possui 2.679 e 5.120 respostas com e sem links. Os números YG são 2.321 e 17.193. Portanto, as respostas no SO têm 3,87 vezes (intervalo de confiança de 95%: 3,63 - 4,13) mais probabilidade de conter uma ligação do que uma resposta no YG. ![Referências comuns em postagens DDD.](https://mauricioaniche.com/assets/blog/ddd/i6.png)*Referências comuns em postagens DDD.* **Os tópicos estão correlacionados entre si?** Aplicamos o algoritmo *Apriori*, uma abordagem tradicional de mineração de regras de associação. Depois de decidir o suporte e a confiança mínimos, o algoritmo calcula o conjunto de todas as regras que estão acima desses limites. O algoritmo foi capaz de gerar 2.432 regras de associação. A seguir, listamos as 10 principais regras ordenadas por *lift*. ![10 principais regras de associação para Stack Overflow e Yahoo! Grupos.](https://mauricioaniche.com/assets/blog/ddd/i7.png)*As 10 principais regras de associação para Stack Overflow e Yahoo! Grupos.* * **Os padrões da Parte II estão fortemente conectados entre si.** O padrão *Entity* acontece frequentemente com *Value Object*, *Repository* e *Aggregate*. Além disso, *Factory* está associado a *Repository*. Por outro lado, alguns deles tendem a não aparecer juntos: *Objetos de valor*, *Agregados* e *Entidades* não são frequentemente encontrados juntos com *Serviços*. * **Os padrões de outras partes do livro estão desconectados da Parte II.** Padrões como *Linguagem Ubíqua*, *Bounded Context* e *Arquitetura em Camadas* não acontecem juntos com os padrões da Parte II. Na verdade, observamos muitas regras *A => !B*, sendo A esses padrões, sugerindo que eles tendem a acontecer sozinhos. Esperamos que estes dados esclareçam os aspectos importantes, mas ainda não claros, da prática. Algumas conclusões baseadas nos resultados: * Padrões DDD populares em perguntas Stack Overflow e as discussões no Yahoo! Groups podem ser uma indicação de quais padrões requerem mais atenção durante o treinamento e implementação, pois são provavelmente mais complicados de serem implementados na prática. Por outro lado, padrões menos populares podem indicar que ou não são comumente aplicados (e, portanto, os profissionais não têm dúvidas sobre eles) ou que a implementação de tais padrões não é simples e deveríamos dedicar mais tempo para esclarecê-los. * É interessante ver que a Parte II do livro é de longe a mais popular tanto no SO quanto no YG. Curiosamente, esta é a parte mais técnica (como no código-fonte) do livro. Talvez SO e YG não sejam bons meios para discutir outros tópicos? Ou os desenvolvedores pensam que DDD é apenas sobre Building Blocks e esquecem toda a discussão sobre design estratégico? Na palestra [“O que aprendi sobre DDD desde o livro”](http://dddcommunity.org/library/evans_2009_2/), Evans diz que os desenvolvedores dão muita atenção aos blocos de construção e menos atenção a outras partes. * Embora a análise do tipo pergunta tenha sido simplista (correspondência de palavras-chave no título do post), o número de perguntas “por que” é menor tanto no SO quanto no YG quando comparado às demais palavras-chave. Por outro lado, "Por que" são comuns em livros sobre o assunto, como os de Evans e Vernon. Novamente, uma explicação para tal fenômeno poderia ser 1) que SO e YG não são o melhor lugar para tais discussões, ou 2) porque os "porquês" já estão claros para os desenvolvedores, ou 3) os desenvolvedores estão trabalhando em um modelo de domínio existente e suas questões agora se concentram em como implementar as coisas, em vez de entender por que essas decisões foram tomadas. * Observamos diversas dúvidas sobre como aplicar padrões usando uma determinada tecnologia, por exemplo, *como fazer Aggregate Roots funcionar com NHibernate*. Talvez devêssemos gastar mais tempo documentando como aplicar DDD em diferentes tecnologias. O número de perguntas do tipo “como” também pode ser um bom indicador dessa necessidade. * Na palestra mencionada, Evans também fala sobre acréscimos que faria ao livro agora, como Eventos de Domínio. Podemos encontrar outras adições (ou mesmo remoções) importantes ao DDD em nosso conjunto de dados SO e YG? Este é um bom trabalho futuro. Você quer ajudar nisso? Um primeiro passo seria ler todas as questões do SO e classificar manualmente seu conteúdo. Talvez com o poder das pessoas, possamos fazer isso. Então, [vá para esta planilha](https://docs.google.com/spreadsheets/d/1fFaFO4o74QDzZvynpeWQPtwrQEQ9ogwyvEtfWjba-uw/edit?usp=sharing), escolha um post (ou dois), leia e escreva do que se trata na planilha! * Não é novidade que a página de Martin Fowler é uma referência popular para vincular as pessoas a artigos bem explicados sobre DDD. Curiosamente, o número de links Github/Gist também é alto, indicando que as pessoas comumente compartilham código-fonte e exemplos. Talvez seja hora de uma ligação melhor entre o livro + artigos de Fowler + exemplos de código? * O algoritmo *Apriori* identificou vários padrões que tendem a não acontecer com outros. Uma possível explicação para isso seria que é natural tentar isolar ao máximo a conversa ao fazer perguntas. No entanto, dois deles têm associações fortes: *Entidade* e *Objetos de Valor*, e *Fábrica* e *Repositórios*. Talvez mais material sobre os dois tópicos juntos ajudasse os desenvolvedores a entender seu relacionamento. *Agradeço a Christoph Treude (Universidade de Adelaide), Arie van Deursen (Delft University of Technology), Mario Amaral, Veranildo Veras, Pedro Pessoa e Mozair Carmo pelos seus insights.*