Parece que a IA não vai tornar seus processos mais rápidos
(frederickvanbrabant.com)- Há uma disseminação de expectativas irreais sobre IA dentro do fluxo de otimização de processos, mas simplesmente adotar IA não melhora, por si só, a velocidade de execução
- A verdadeira razão de o desenvolvimento de software demorar não é a velocidade de codificação, e sim o processo de transformar requisitos ambíguos em uma definição clara do problema
- A geração de código por IA enfrenta o mesmo problema a montante, e um envolvimento profundo de especialistas de domínio e de produto é indispensável para obter resultados corretos
- O processo de handholding que costuma ser omitido em casos comparativos de uso de IA é o que realmente cria a diferença de produtividade; desenvolvedores humanos também teriam um salto enorme de produtividade se recebessem a mesma documentação detalhada
- Para realmente acelerar um processo, a prioridade deve ser, como ensina The Goal, "fornecer ao gargalo entradas previsíveis e de alta qualidade"
Otimização de processos e expectativas sobre IA em meio à retração do mercado
- Quando o mercado desacelera, a maioria das organizações tende a se concentrar, ao menos em parte, na otimização de processos; recentemente, somou-se a isso o fator IA e expectativas irreais
- The Toyota Way e The Goal lembram que é fácil entender errado onde muitas otimizações de processo deveriam focar
- Uma etapa que leva muito tempo pode ser um sinal de onde começar a melhorar, mas não se pode concluir que é ali que o problema de fato surge
- Se a expectativa for simplesmente colocar mais gente ou achar que a IA vai aumentar muito a velocidade, você deixa de enxergar por que o trabalho está atrasando
- Para acelerar um processo, primeiro é preciso verificar se quem executa o trabalho realmente tem os insumos e as condições para começar e terminar a tarefa
O gargalo visual
- Por meio de um exemplo com gráfico de Gantt, é possível ver visualmente que a etapa mais demorada é o desenvolvimento de software
- O normal seria usar BPMN, mas, para facilitar a explicação, foi apresentado um gráfico de Gantt
- Se o objetivo é melhorar o throughput do projeto, faz sentido começar olhando para a etapa mais longa
- O problema é a forma como as pessoas tentam resolver isso
- Jogar mais pessoas no problema
- Assumir que a IA vai tornar tudo muito mais rápido
- O que não se investiga é "por que essa etapa demora tanto"; mais importante ainda, o fato de uma etapa levar muito tempo não significa que a causa do problema esteja nela
Resolver o problema a montante
- O texto usa desenvolvimento de software como exemplo, mas isso vale igualmente para qualquer processo que esteja demorando mais do que o desejado
- O desenvolvimento de software não fica mais rápido apenas aumentando a velocidade de digitação; se fosse assim, todo mundo estaria fazendo aula de datilografia
- A essência do desenvolvimento de software é traduzir um problema em uma solução que o computador possa resolver automaticamente, de preferência de forma segura e escalável
- Para isso, é necessário um entendimento completo do problema
- Em uma abordagem mais próxima de waterfall, são necessários documentos de funcionalidade ou de escopo
- Em uma abordagem ágil, são necessárias iterações contínuas com especialistas de domínio
- O que realmente torna o desenvolvimento lento é o processo de descobrir o que significa um pedido vago de feature com apenas um título
- "Enviar e-mail ao usuário quando a venda for concluída (send mail to user once sale is completed)" também não é um requisito que dê para implementar imediatamente
- É possível enviar um e-mail, mas o que deve constar nele?
- Se houve um problema no processo de venda, deve-se enviar um e-mail de erro?
- Em que momento a venda é considerada "concluída"?
A ideia de simplesmente deixar tudo com a IA
- Um argumento frequente é que a geração de código por IA permitiria pular a etapa de desenvolvimento, deixando o desenvolvedor de software apenas no papel de gerente de projeto
- Muita gente espera que o longo trecho tradicional de desenvolvimento de software seja substituído por cerca de 3 dias de desenvolvimento com IA
- Existe uma imagem do resultado que as pessoas esperam do desenvolvimento com IA, mas, na prática, não funciona assim; ele encara exatamente os mesmos problemas a montante
- É verdade que a IA pode gerar código rapidamente — se isso é bom ou não já é outra discussão —, mas gerar rápido não é o mesmo que gerar o código correto
- O que sempre é ignorado nas comparações entre desenvolvimento humano e IA é o processo de handholding necessário para fazer a IA funcionar direito
- Esse método pode até ser mais rápido do que o modo tradicional, mas não é uma comparação justa
- Para o desenvolvimento com IA funcionar, é necessário um envolvimento muito mais profundo de especialistas de domínio e de produto
- Cada funcionalidade precisa ser descrita até os menores detalhes
- Cada correção de bug também precisa detalhar claramente qual é o resultado desejado
- Isso é exatamente o que desenvolvedores de software vêm pedindo desde o início da profissão: uma visão detalhada do problema e do resultado final esperado
- Se desenvolvedores humanos recebessem a mesma quantidade de documentação de feature/escopo, a produtividade deles também aumentaria drasticamente
Como realmente aumentar a velocidade do processo
- Para aumentar a velocidade de um processo, é preciso garantir que as pessoas responsáveis pelo trabalho tenham de fato todos os meios para realizá-lo
- Se o processo de aprovação jurídica é lento, primeiro é preciso olhar para o que é necessário para iniciar esse processo de aprovação
- Se é preciso correr atrás de cinco pessoas por causa de documentação incompleta, colocar mais advogados no departamento não vai acelerar nada
- Uma das grandes lições de The Goal é que os gargalos devem receber entradas previsíveis e de alta qualidade
- "bottlenecks should receive predictable, high-quality inputs"
- O primeiro ponto de partida da automação de processos não deve ser o próprio gargalo, e sim aumentar a qualidade das entradas que ele recebe e sua previsibilidade
1 comentários
Comentários no Hacker News
Existe a ideia de que o que o desenvolvimento de software sempre quis desde o início era “receber uma descrição detalhada do problema e do resultado desejado”, mas isso por si só já é engenharia de software
Mesmo em 2026, é preciso abandonar a noção de que, com requisitos e especificações suficientemente detalhados, dá para criar a solução perfeita de uma vez só
Pela minha experiência, graças à IA ficou muito mais rápido iterar funcionalidades e ideias, e agora o atrito surge principalmente no alinhamento e na coordenação com outras equipes
Se quisermos acelerar o processo, é preciso reduzir o custo de coordenação e dar mais autonomia para indivíduos e equipes decidirem e executarem
Nem a Anthropic conseguiu fazer algo tão simples quanto um compilador C funcional, mesmo tendo especificação perfeita, implementação de referência e milhares de testes escritos por humanos ao longo de anos
Os modelos atuais não são bons o bastante para criar software de produção minimamente não trivial sem supervisão cuidadosa de uma pessoa, mesmo com especificação perfeita e testes perfeitos
Sem uma especificação perfeita e um conjunto perfeito de testes escritos por humanos, isso fica ainda mais difícil, embora talvez seja possível por volta de 2027
Muitas vezes recebo à tarde uma tarefa que o responsável pelo produto pensou na hora, e eles só consideram o caminho feliz, às vezes só parte dele
Como somos uma empresa global, precisamos cumprir normas e leis de cada país, então implementamos a funcionalidade e depois ouvimos: “na verdade, em 90% dos mercados em que atuamos isso não pode ser feito legalmente”, e aí temos de colocar de novo uma opção para desativar
Depois disso, voltam com “em alguns desses mercados dá para fazer se passarmos por um processo regulatório, então implementem assim”
Como o prazo já está estourando, no fim temos de remendar a solução na gambiarra
Isso não é engenharia de software, e nem tem a ver com software em si
O trabalho do engenheiro de software é receber uma lista de requisitos e descobrir como atendê-los, e levantamento de requisitos não é um problema de engenharia de software
Software é implementação, produto é comportamento, e o comportamento do que vai ser construído precisa ser conhecido antes de começar a construir para valer
Se alguém tivesse adiado uma semana e feito a devida diligência, teria sido possível projetar uma estrutura escalável, fácil de expandir, fácil de manter e que deixaria o futuro mais confortável
Faz mais de 40 anos que escrevi meu primeiro programa, mas nunca vi um caso em que primeiro se concluiu a especificação, depois se escreveu o software, e no fim tudo deu certo
A parte mais difícil em qualquer engenharia não trivial é entender o problema, e as primeiras versões do software são justamente a forma de chegar a esse entendimento
Por isso acho que uma “fábrica de software” baseada em IA nunca vai funcionar bem
No fim, isso vira de novo desenvolvimento em cascata, com arquiteto fazendo diagrama UML e repassando para uma equipe de programadores um trabalho de implementação essencialmente simples, mas que acaba implementando a coisa errada
A IA é muito boa para sair rápido da primeira versão errada para uma segunda versão menos errada
Só não podemos esquecer que a missão principal é entender o problema que se quer resolver
Se eu só recebesse especificações detalhadas, seria apenas um robô de codificação, e esse tipo de trabalho eu deixo para júnior
Como antes, meu trabalho é ler esses requisitos, entendê-los e validá-los à luz da realidade que eu conheço
Com código é a mesma coisa
Há pelo menos 20 anos o cerne da engenharia de software é não confiar em ninguém, e isso não mudou; ainda exige muito tempo e esforço
Quando os LLMs surgiram, parecia que as pessoas achavam que bastava dizer algo como “faça um clone do Facebook”
Agora estão percebendo que é preciso escrever requisitos com mais precisão e defini-los melhor
Esse sempre foi o gargalo do software
Em trabalhos anteriores, eu realmente recebia requisitos do tipo “pegue os dados e entregue ao usuário”
Não havia definição de que dados eram, onde estavam armazenados nem em que formato deveriam ser retornados, então eu precisava passar muito tempo com o responsável pelo produto para descobrir o que ele realmente queria
Para obter bons resultados com LLMs, é preciso fazer algo parecido, e requisitos ambíguos produzem resultados ambíguos
Eles preenchem modelos explicando que problema existe e por quê, por exemplo dizendo que no backend existe o campo X mas no frontend não, além de onde e como buscar os dados e quais são os critérios de aceitação
É o tipo de coisa que antes eles não faziam por preguiça ou por pensarem “o desenvolvedor se vira”
Depois, o desenvolvedor pode copiar e colar esse ticket do Jira no agente LLM que preferir, ou deixar que o LLM leia automaticamente via Atlassian MCP
Isso ajudou muito os desenvolvedores e deixou os requisitos bem claros
Sinceramente, só olhando para essa primeira etapa, parece que os PMs já chegaram à metade da implementação da funcionalidade, então talvez no futuro os PMs façam tudo diretamente e alguns desenvolvedores acabem ficando mais como SDET do que como implementadores completos
Ali ele descreve com precisão as características centrais do vibe coding e a experiência que estamos vivendo agora
A ideia é que, após sucessos iniciais em alguns domínios escolhidos com cuidado, ao expandir para fora deles surgem ganhos de produtividade razoáveis, mas não revolucionários
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
Nunca usei um prompt próximo de “faça um clone do Facebook”; em vez disso, eu explico como quero que funcione
Por exemplo, pedi um script em Python que lesse
/etc/hosts, encontrasse valores de host específicos definidos em.conf, desse nome a cada configuração, detectasse o ambiente atual, criasse um ícone no canto superior direito do GNOME padrão do Ubuntu 22 e, ao clicar, listasse os nomes das configurações e, ao selecionar uma delas, fizesse backup de/etc/hostse alterasse apenas as linhas com determinados nomes de hostCom isso saiu quase de primeira um alternador de ambiente simples para indicador de app do GNOME, e com alguns ajustes em poucas linhas quase tudo funcionou
Se você der ao LLM uma especificação decente, ele faz bem, e até entende sozinho se você inventar uma DSL falsa para explicar o que quer
O motivo de o processo anterior não funcionar era que quem escrevia os requisitos não entendia a intenção do negócio ou era descuidado e entregava requisitos ambíguos ou ruins
O LLM só faz esses mesmos requisitos ambíguos ou ruins parecerem plausíveis; quando se aprofunda, o problema aparece
Surgem perguntas como “o que exatamente significa ‘buscar os dados’?”
O LLM simplesmente responde “claro! aqui está o código completo para buscar os dados e entregá-los ao usuário” e segue em frente
Este texto assume que a IA afeta apenas a etapa de desenvolvimento, mas isso claramente não é verdade
Ela pode acelerar todas as etapas, incluindo ideação, jurídico, documentação, desenvolvimento e implantação
Na ideação, dá para trocar ideias, contrastá-las com a base de conhecimento e criar documentos de design; na documentação, dá para gerar grandes partes da documentação
No desenvolvimento, isso é óbvio; e na implantação, é possível gerar manifestos de deploy, ferramentas de teste e conhecimento sobre plataformas de nuvem
Todas as etapas podem ficar melhores e mais rápidas com IA; não tudo, mas muita coisa
O mesmo vale para o desenvolvimento: existe a parte de entender melhor o problema e criar a solução, mas também existe a parte que é puro trabalho mecânico
Se você já sabe que um botão tem de fazer X, então projetar esse botão, posicioná-lo, pensar nas exceções de hover e press e ligá-lo ao backend é trabalho braçal que pode ser pulado, e o mesmo princípio se aplica a quase todas as etapas
Quando tentamos adicionar uma nova funcionalidade importante, normalmente passamos dias, semanas ou meses em reuniões com as áreas de negócio para entender como o trabalho flui entre os sistemas X, Y e Z e quais são as exceções importantes
Por exemplo, o subconjunto A é tratado assim, o B de outro jeito, mas na última etapa os dois grupos se unem, exceto o C, que exige o processo especial 97
A partir desse entendimento vem o desenho da solução de sistema em vários sistemas, misturando sistemas internos e de fornecedores, e o grau de customização possível em cada um empurra o formato da solução final em várias direções
Aumentar a velocidade de codificação tem valor, sem dúvida, mas é só uma peça do quebra-cabeça, e os LLMs atuais não ajudam a coletar conhecimento de domínio nem a definir a solução
Há mais um ponto: agora pessoas de mais funções conseguem criar ferramentas de software para resolver problemas que antes eram empurrados na marra com procedimentos físicos
Somos um pequeno fabricante, então não se trata de grandes projetos corporativos que exigem experiência profunda em engenharia de software, mas ferramentas simples de software estão melhorando processos e produtividade por toda parte
Quando o responsável pela expedição consegue resolver com uma ferramenta sob medida um problema que antes consumia muitas horas de trabalho, coisas realmente impressionantes acontecem
Usamos muita IA no desenvolvimento de software, mas não estamos lançando mais rápido; às vezes até parece que estamos mais lentos, por razões parecidas ou outras
Fica uma sensação estranha de esperar a utopia chegar, mas ela não chega, e nem é fácil apontar exatamente onde está o problema
Pelo contrário, esse tipo de desacordo e desconfiança cria oportunidades e pontos de entrada no mercado
Se a média de QI dos participantes de um projeto for 140, uma IA com QI 150 pode replicar cada indivíduo do pipeline
Quem diz que a IA não consegue fazer isso ou aquilo precisa aceitar que essa diferença de QI está aumentando de forma monotônica
Por um lado, este é um texto limpo que descreve com precisão o que muita gente que trabalha com tecnologia em grandes organizações pensa e vê no dia a dia
Concordo 110% com o autor e queria que outras pessoas também entendessem o conteúdo deste texto
Por outro lado, tanto no HN quanto no trabalho de verdade, sinto que já tive essa conversa dezenas de vezes ultimamente
Os líderes têm incentivos sociais e financeiros para fingir que a IA realmente vai acelerar tudo, então não serão convencidos por um post de blog
Então agora só me resta esperar que os projetos de IA deles fracassem ou andem tão devagar quanto os projetos antigos, e torcer para que aprendam alguma coisa
Até fico receoso de compartilhar textos assim na empresa, porque parece que conteúdo que não combina com o status quo não é bem recebido
Materiais visuais e gráficos de Gantt são exatamente o tipo de linguagem de PM que PMs entendem
Enquanto C-level e investidores continuarem sinalizando inovação, isso não vai se resolver já, mas esse tipo de coisa também não dura para sempre
Ultimamente tenho passado meu tempo fazendo jardinagem e me obcecando com projetos pessoais de programação usando ferramentas agentivas
Coisas como criar do zero um banco de dados OLTP de alto desempenho, um novo ambiente lógico-relacional de programação persistente e sintetizadores baseados em matemática estranha com soft processors em FPGA
Coisas normais que pessoas normais fazem
Então eu sei o que essas ferramentas conseguem fazer quando estão nas mãos de uma única pessoa, e é realmente impressionante
Mas quando ouço de amigos que trabalham em empresas histórias sobre definir cotas mínimas de tokens, criar placares de “codificadores IA estrela” e dizer “não faça code review” ou “não programe manualmente”, só balanço a cabeça
Fiz um pouco de trabalho por contrato no inverno e foi ok, mas, enquanto o fundador fazia vibe coding de projetos inteiros novos todo fim de semana, o code review regrediu para um duelo entre LLMs
Essas ferramentas não são grande coisa para trabalho em equipe nem para engenharia de software de equipe de verdade
Vou só me afastar e observar até a indústria se reorganizar
Os lugares bons para trabalhar provavelmente serão apenas aqueles que saibam dizer “vai com calma!” e que tenham gente mais velha e sábia capaz de sustentar isso
Enquanto isso, estou vendendo maços de ruibarbo por 5 dólares na região de Hamilton, Ontário
Também tenho aspargos, bastante
Há uma dualidade interessante
Nas coisas que eu já faço bem, LLMs têm relativamente pouco impacto; mas nas coisas em que eu sou ruim, são uma mudança de jogo enorme
Grandes empresas conseguem contratar a maioria dos papéis necessários para um projeto, então o efeito total tende a ser relativamente pequeno
Na melhor das hipóteses, uma pessoa passa a fazer mais ou menos o trabalho de cinco, reduzindo custo de mão de obra, e em troca se obtém um produto pior
É óbvio como vai terminar essa combinação de ganho de curto prazo com custo de longo prazo
Mas para pequenos estúdios ou desenvolvedores independentes, LLMs mudam muito o jogo
Conseguir fazer mais ou menos o trabalho de cinco pessoas é um salto muito maior do que sobreviver sem essas funções, depender de assets de terceiros ou de outro conteúdo, ou pior, improvisar algo horrível na marra
Basta olhar a interface de quase qualquer programa claramente montada por um programador sem designer
Ou então casos em que tentam copiar algo do Dribbble, mas sem habilidade suficiente
Com IA, de repente dá para copiar de forma plausível tudo e todos, e na verdade é assim que quase toda a IA funciona
Soa como a definição de manual
No meu caso é exatamente o contrário
LLMs só me ajudam quando eu já sei exatamente o que estou fazendo
As pessoas não entendem bem que desenvolvimento de software não trivial não é nem 50% programação
A etapa de codificação costuma ser uma das mais fáceis e é delegada a desenvolvedores júnior
Em grandes organizações, a maioria das mudanças de produto atravessa vários sistemas e as operações de várias pessoas
Sêniores e plenos passam muito tempo realinhando prioridades locais em novos arranjos dentro de um ente cibernético já existente e obtendo concordância de outras equipes, cada uma com suas próprias prioridades, em relação a essa nova visão
Isso naturalmente envolve muitos trade-offs e política
Engenheiros sêniores lutam bastante para evitar adicionar mais “peso” aos sistemas pelos quais respondem e para impedir aumento de escopo ou desvios da direção pretendida
Por isso é preciso compromisso ou escalonamento para a gestão na hora de decidir prioridades
Talvez a IA também consiga resolver isso, mas é um problema muito mais difícil
Agora ele é um chamador de ferramentas, então agentes de código conseguem rodar lint, checagem de tipos e testes, corrigir esses erros, mergulhar em plataformas de observabilidade como Sentry para encontrar a causa raiz, executar benchmarks para achar código lento ou hot paths, e ler e aplicar documentação de migração para novas versões major das bibliotecas usadas, mantendo o sistema atualizado
Se essas coisas não estiverem configuradas para gerar pressão contrária no agente e fazê-lo entender melhor o sistema, ele continuará sendo apenas um escritor de código burro com LLM
Mas, com modelos e harnesses melhorando rápido, claramente isso pode ir muito além
Este texto acerta em grande parte e dá pistas sobre onde focar para que a IA realmente acelere o processo
Por exemplo, um gerente de produto disse que imagina um futuro em que, se ao fim de uma reunião com stakeholders não houver um protótipo interativo, isso será considerado fracasso, e sinto que a direção é essa mesmo
Outra coisa que prevejo é vibe coding virar o “Excel 2.0”
Ele vai permitir criar apps conversacionais de forma bastante self-service, e a TI entrará numa guerra constante para transformar isso em algo com melhores garantias de segurança, controle de acesso e logging adequados, escalabilidade, gestão de mudanças etc.
Num olhar histórico mais amplo, toda mudança revolucionária no começo produz um “cavalo a vapor”
Quando a máquina a vapor foi inventada, as pessoas imaginavam que o futuro do transporte seria um objeto em forma de cavalo movido a vapor puxando carroças já existentes
Só depois aprendemos a separar a função do transporte da forma
Na verdade comecei a falar em cavalo a vapor quando se discutia MOOC, porque MOOC era uma ideia típica de cavalo a vapor
Não é preciso código para fazer protótipos
É como dizer que para capturar uma cena você precisa necessariamente de atores e câmera, quando alguns esboços já bastam
O Gantt apresentado é um exemplo de modelo em cascata ou de outra metodologia que pressupõe que software tenha um destino final
99,999% do software de hoje não é construído assim
No desenvolvimento moderno de software não existe destino final
A cada duas semanas o negócio muda o que o software precisa fazer
Surgem novas funcionalidades, novas integrações, funcionalidades alteradas, componentes atualizados ou substituídos, escala maior, hospedagem diferente
Depois de alguns anos, o software fica fundamentalmente transformado, e qualidade e testes vão pela janela
Não é só um trabalho constante de lidar com mudanças por meio de improvisos, mas também uma batalha permanente contra a entropia
O software vira um ser vivo que se machuca, muda de estilo de vida e envelhece
A empresa se torna a cuidadora de um monstro, como um tratador de zoológico tentando manter vivo um animal deprimido
Como seres humanos são criaturas de hábito, todos esses mesmos problemas continuarão existindo com IA
Só que tudo ficará um pouco mais rápido, e code review talvez melhore um pouco o código
Ao mesmo tempo, a falta de bons testes e o desejo de implantar mais rápido deixarão tudo um pouco pior
O resultado desse cabo de guerra será uma qualidade de software quase igual, mas com tudo andando um pouco mais rápido
No fim, haverá de fato um processo mais rápido, mas o resto continuará penoso, então quase ninguém vai sentir grande diferença
Provavelmente todos só vão se esgotar mais rápido
Complexidade existe por um motivo, e sem remover esse motivo não dá para remover a complexidade
Ferramentas não resolvem problemas de negócio
Sobre a frase “a IA pode gerar código rapidamente, mas isso não significa que gere o código correto”, na prática o código quase sempre está certo
O que me incomoda normalmente é a forma como esse código é adicionado
Se você conhece bem o codebase, existem certos rituais: onde adicionar, como nomear, quanto comentar e em que lugar
Quando o agente erra isso, pessoas como eu ficam irritadas, e parece que nem escrever em AGENTS.md resolve
A afirmação de que “se um desenvolvedor humano recebesse a mesma quantidade de documentação de funcionalidades e escopo, sua produtividade dispararia” eu simplesmente não consigo acreditar, mesmo depois de quase 20 anos em TI
Mesmo que aconteça, deve ser tão raro que não vale a pena discutir
Basta comparar o esforço de replicar um sistema já escrito com o esforço de construir esse sistema do zero
Especialmente quando a entrada é um bug ou um problema de desempenho, ele frequentemente alucina e diagnostica errado se você não ficar guiando
Ainda assim, se você acompanhar o que está fazendo e o empurrar na direção certa, ele vai bem em análise de causa raiz e análise em geral, além de aumentar a eficiência
Acho que existe um teto para esse ganho de produtividade porque seres humanos têm limites de velocidade para absorver e analisar informação em comparação com máquinas
A IA não precisa contornar o processo, mas ainda assim pode acelerá-lo
Ela pode ajudar em refatoração, escrita de boilerplate, descoberta de erros nunca vistos antes e coisas que o linter não pega
Muitos comentários parecem partir do fato de que não usam processos padrão amplamente conhecidos, ou assumem que ao usar IA não é mais preciso seguir esses padrões
Dá para entregar mais código e mais funcionalidades? Claro que sim, se houver bons requisitos e testes suficientes
Todo código escrito por IA precisa passar por revisão e testes, e deve ser dividido em commits e pull requests separados
Quem abre PRs com milhares de linhas é um sinal de alerta
Você não faria isso sem IA, então por que faria com IA?
A única exceção conhecida são grandes reescritas ou refatorações, mas mesmo nesses casos acho melhor haver commits individuais que possam ser alternados para que seja possível ver o processo da mudança e julgar melhor
Se me mostrarem um commit ou PR gigante feito de uma vez só, eu vou rejeitar
É preciso dividir em pedaços que um desenvolvedor comum consiga auditar