Repensando o fluxo de desenvolvimento de software com o aumento da codificação assistida por IA

A adoção de ferramentas de inteligência artificial no desenvolvimento de software está reduzindo consideravelmente o tempo necessário para implementar muitas tarefas. Atividades que anteriormente exigiam várias horas de investigação, escrita de código e criação de testes podem ser realizadas em períodos menores quando o desenvolvedor utiliza agentes capazes de analisar a base de código, propor implementações e executar parte do trabalho necessário.

Esse ganho é relevante, mas também começa a produzir algumas mudanças no fluxo de desenvolvimento que merecem atenção. Se um desenvolvedor consegue concluir mais tarefas no mesmo período, a consequência natural é um aumento na quantidade de alterações que precisam passar pelas etapas seguintes do processo, especialmente testes, revisão de código e integração.

A capacidade de produzir código, portanto, pode crescer mais rapidamente do que a capacidade do time de revisar esse código.

Na prática, isso pode resultar em um aumento do WIP (Work in Progress), com mais pull requests aguardando revisão e desenvolvedores precisando alternar com maior frequência entre implementação e análise de mudanças produzidas por outras pessoas.

O problema não está necessariamente no uso da IA ou no aumento da produtividade individual. O que talvez precise ser revisto é o processo ao redor dessas ferramentas. Se conseguimos aumentar significativamente a velocidade de uma etapa do desenvolvimento, precisamos entender como as demais etapas podem acompanhar essa mudança sem reduzir a qualidade das entregas ou simplesmente transferir o gargalo para outro ponto do fluxo.

Small batches como forma de reduzir o custo da revisão

Uma prática que pode ajudar nesse cenário é o desenvolvimento em small batches, discutido pelo DORA como uma das capacidades associadas à entrega contínua de software.

A ideia consiste em organizar o trabalho em mudanças menores, independentes e passíveis de validação individual. Em vez de concentrar toda a implementação de uma tarefa em uma alteração extensa, procura-se identificar incrementos menores que possam ser implementados, testados e revisados separadamente.

Em um primeiro momento, essa abordagem pode parecer contraditória para um time que já está lidando com um volume elevado de pull requests. Dividir uma implementação pode efetivamente aumentar o número absoluto de PRs e, se observarmos apenas essa métrica, o processo poderia parecer ainda mais sobrecarregado.

Entretanto, quantidade de pull requests e esforço necessário para revisá-los não são necessariamente proporcionais.

Um PR pequeno, com objetivo bem definido e poucas responsabilidades, tende a exigir menos contexto do reviewer. Também é mais simples compreender o impacto da alteração, identificar possíveis regressões e avaliar se a implementação corresponde ao que foi solicitado.

Essa característica se torna especialmente importante quando parte significativa do código é produzida com auxílio de IA. Um agente pode modificar muitos arquivos e implementar diferentes aspectos de uma funcionalidade em poucos minutos, mas a velocidade com que essas alterações são produzidas não reduz automaticamente o esforço necessário para que outra pessoa compreenda as decisões tomadas.

Por isso, talvez seja útil considerar o tamanho da unidade de revisão como uma restrição independente da capacidade de geração de código.

Ao dividir uma implementação em mudanças menores, também passamos a receber feedback mais cedo. Uma decisão arquitetural questionada no primeiro batch pode ser corrigida antes que ela seja reproduzida nos próximos. Da mesma forma, um problema identificado em uma primeira implementação pode modificar as instruções fornecidas ao agente nas etapas seguintes.

Nesse contexto, small batches não seriam apenas uma forma de facilitar o code review, mas também uma maneira de criar ciclos mais frequentes de aprendizado durante a implementação.

Utilizar automação antes de consumir atenção humana

Outro aspecto que merece ser discutido é o momento em que uma alteração passa a consumir tempo de outro desenvolvedor.

No fluxo tradicional, é comum que o autor conclua uma implementação, abra um pull request e solicite imediatamente uma revisão humana. Durante essa revisão, entretanto, podem surgir problemas relativamente mecânicos, como testes ausentes, inconsistências com padrões conhecidos do projeto, problemas simples de segurança, código duplicado ou situações que poderiam ter sido identificadas por ferramentas automatizadas.

Com ferramentas modernas de análise e code review assistido por IA, parte dessas verificações pode acontecer antes que o pull request seja considerado pronto para revisão humana.

A documentação do GitHub sobre o uso do Copilot Code Review ao longo do ciclo de vida de um pull request apresenta um fluxo semelhante. O PR pode permanecer inicialmente como draft, receber revisões automatizadas e passar por ciclos de correção antes de ser disponibilizado para os demais desenvolvedores.

Isso permite pensar em um fluxo no qual a implementação passa progressivamente por diferentes níveis de validação:

implementação → testes → análise estática → verificações de segurança → revisão por IA → correções → revisão humana.

Essa organização não pressupõe que a revisão automatizada substitua o code review realizado por desenvolvedores. O objetivo seria reduzir a quantidade de problemas que chegam até essa etapa, permitindo que o reviewer dedique mais atenção às questões que dependem de conhecimento do produto, experiência arquitetural e compreensão do contexto da mudança.

Em vez de utilizar parte significativa do tempo apontando problemas que poderiam ser detectados automaticamente, a revisão humana poderia se concentrar em aspectos como adequação da solução ao problema, impacto sobre outras áreas do sistema, complexidade introduzida, decisões arquiteturais e facilidade de manutenção futura.

Transformar padrões de desenvolvimento em critérios explícitos

Para que esse processo funcione de maneira consistente, existe uma questão adicional: as ferramentas automatizadas precisam conhecer os padrões que esperamos das implementações.

Muitas equipes possuem um conjunto considerável de regras que nunca foram formalizadas completamente. Desenvolvedores mais experientes conhecem determinadas convenções porque trabalham no projeto há bastante tempo, participaram de decisões anteriores ou aprenderam esses padrões durante revisões de código.

Quando passamos a delegar uma parcela maior da implementação para agentes de IA, depender exclusivamente desse conhecimento implícito se torna mais problemático.

Uma alternativa seria documentar critérios de engenharia de maneira estruturada e, sempre que possível, utilizá-los também como entrada para ferramentas de desenvolvimento e revisão.

Alguns desses critérios poderiam ser gerais e aplicáveis a praticamente qualquer alteração, como segurança, cobertura adequada de testes, tratamento de erros, compatibilidade com comportamentos existentes, observabilidade quando necessária e aderência aos padrões arquiteturais do projeto.

Outros critérios poderiam ser ativados dependendo do tipo de alteração realizada.

Alterações envolvendo APIs

Uma implementação que cria ou modifica uma API poderia ser analisada considerando, entre outros aspectos:

autenticação e autorização;
validação e sanitização dos dados recebidos;
padronização das estruturas de resposta;
utilização adequada dos códigos HTTP;
escolha dos métodos HTTP;
tratamento consistente de erros;
idempotência quando aplicável;
rate limiting quando necessário;
compatibilidade com consumidores existentes;
testes dos cenários de sucesso, erro e autorização.

Alterações envolvendo interfaces

Para mudanças relacionadas à interface, os critérios poderiam considerar:

consistência com os componentes e padrões visuais existentes;
responsividade;
acessibilidade;
comportamento durante carregamento;
estados vazios e situações de erro;
compatibilidade entre temas, quando aplicável;
experiência de uso;
SEO para páginas em que isso seja relevante;
compatibilidade com os navegadores suportados;
cobertura dos principais fluxos por testes.

Alterações envolvendo persistência de dados

Mudanças relacionadas ao banco de dados poderiam possuir outro conjunto de critérios:

impacto sobre dados existentes;
estratégia de migration e rollback;
índices necessários;
integridade dos dados;
privacidade e exposição de informações;
impacto de performance;
compatibilidade durante o processo de deploy;
comportamento durante atualizações graduais da aplicação.

A mesma lógica poderia ser aplicada a integrações externas, autenticação, processamento assíncrono, infraestrutura, billing e outras áreas relevantes para cada projeto.

Naturalmente, nem todos esses critérios deveriam se transformar em regras rígidas. Alguns podem ser verificados objetivamente por testes ou ferramentas de análise, enquanto outros funcionam melhor como perguntas que orientam a revisão.

O ponto importante é reduzir a dependência de conhecimento exclusivamente tácito e criar uma referência comum para desenvolvedores, agentes de implementação e ferramentas de revisão.

Um possível fluxo de desenvolvimento assistido por IA

Combinando essas práticas, poderíamos experimentar um processo no qual uma tarefa passa pelas seguintes etapas:

entendimento do problema e definição do escopo;
identificação de batches pequenos e independentes;
implementação de um batch;
execução dos testes automatizados;
execução de linters, análise estática e verificações de segurança;
revisão do código por IA utilizando os padrões definidos pelo projeto;
correção ou avaliação dos apontamentos encontrados;
disponibilização do pull request para revisão humana;
revisão, aprovação e merge;
observação do comportamento após a entrega.

Esse fluxo também cria uma separação mais clara entre o que esperamos da automação e o que esperamos das pessoas envolvidas no processo.

Ferramentas automatizadas são particularmente adequadas para verificações repetitivas, comparação com padrões conhecidos e análise sistemática de grandes quantidades de código. Desenvolvedores, por outro lado, continuam sendo fundamentais para avaliar decisões que dependem de contexto, experiência, conhecimento do produto e compreensão das consequências de longo prazo de uma implementação.

Small batches sem controle de WIP não resolvem o problema

Existe uma ressalva importante nessa proposta.

Dividir uma tarefa em cinco pull requests menores não necessariamente melhora o fluxo se os cinco forem produzidos imediatamente e colocados simultaneamente na fila de revisão. Nesse cenário, apenas substituímos uma alteração grande por várias alterações menores acumuladas no mesmo ponto do processo.

Por esse motivo, acredito que a discussão sobre small batches precisa estar associada ao controle de WIP.

Se o desenvolvimento assistido por IA permite produzir código mais rapidamente do que conseguimos revisar, talvez não seja desejável utilizar toda essa capacidade simplesmente para iniciar mais trabalho.

Uma alternativa seria utilizar parte desse ganho de produtividade para concluir completamente uma quantidade menor de mudanças antes de iniciar outras.

Isso pode significar que um desenvolvedor, enquanto aguarda uma revisão, dedique tempo à melhoria de testes, investigação de outros aspectos da mesma tarefa, documentação ou revisão de PRs de outros membros do time, em vez de iniciar imediatamente diversas novas implementações.

Nesse modelo, o objetivo não seria maximizar a utilização individual de cada desenvolvedor, mas melhorar o fluxo do trabalho através do sistema como um todo.

Como validar se essa abordagem realmente funciona

Apesar de essas práticas possuírem fundamentos conhecidos na engenharia de software, acredito que seria precipitado assumir que essa combinação necessariamente funcionará para qualquer equipe ou projeto.

O impacto da codificação assistida por IA ainda está sendo compreendido, e diferentes times possuem características bastante distintas em relação a tamanho, arquitetura, processo de revisão e frequência de deploy.

Por isso, talvez a melhor forma de avaliar essa proposta seja tratá-la como um experimento.

Durante algumas semanas, uma equipe poderia estabelecer algumas regras simples: limitar o tamanho das mudanças, controlar a quantidade de trabalho simultaneamente em revisão, manter pull requests inicialmente como draft e executar as verificações automatizadas e revisões por IA antes de solicitar uma revisão humana.

A partir daí, poderíamos observar algumas métricas, como tempo entre abertura do PR e primeira revisão, tempo total até o merge, tamanho médio das alterações, quantidade de ciclos de revisão, número de problemas encontrados antes da revisão humana, quantidade de problemas encontrados depois do merge e tempo dedicado pelos desenvolvedores a code review.

Também seria importante coletar informações qualitativas. Um processo pode apresentar métricas melhores e, ainda assim, aumentar a frustração dos desenvolvedores ou criar burocracia desnecessária. Perguntas simples sobre a facilidade de compreender os PRs, qualidade dos comentários automatizados e percepção de carga de revisão ajudariam a complementar os números.

O que estamos tentando otimizar?

Talvez uma das discussões mais importantes trazidas pela adoção de IA seja justamente a definição do que entendemos como produtividade no desenvolvimento de software.

Se avaliarmos produtividade principalmente pela quantidade de código produzido ou pelo número de tarefas implementadas, ferramentas de IA provavelmente apresentarão ganhos expressivos. Entretanto, essas métricas representam apenas uma parte do processo necessário para transformar uma necessidade de produto em software funcionando de maneira confiável em produção.

Uma tarefa implementada, mas aguardando revisão durante vários dias, ainda representa trabalho em andamento. Da mesma forma, uma grande quantidade de código produzida rapidamente não representa necessariamente uma melhoria se aumentar o custo de revisão, introduzir regressões ou exigir diversas rodadas de correção posteriormente.

Talvez seja mais útil observar o tempo necessário para que uma mudança percorra todo o fluxo, desde o início da implementação até sua integração e disponibilização, considerando também a qualidade obtida nesse processo.

Nesse cenário, a principal oportunidade oferecida pela IA não estaria apenas em escrever código mais rapidamente. Ela também pode ser utilizada para antecipar verificações, documentar decisões, aumentar a cobertura de testes e reduzir o trabalho repetitivo realizado durante revisões.

Considerações finais

O desenvolvimento assistido por IA está aumentando a capacidade de implementação das equipes, mas esse aumento não necessariamente ocorre na mesma proporção em todas as etapas do processo de engenharia. Revisão, validação, compreensão do impacto das mudanças e tomada de decisões continuam exigindo atenção e contexto.

Por isso, acredito que existe espaço para experimentar processos que combinem desenvolvimento em pequenos batches, controle de WIP, automação das verificações objetivas e revisão assistida por IA antes da revisão humana.

A intenção não é criar mais etapas burocráticas nem estabelecer que toda alteração precise passar pelo mesmo conjunto de verificações. Pelo contrário, um bom processo deveria ser capaz de selecionar os critérios relevantes de acordo com o tipo e o risco da mudança.

O resultado que buscamos também não deveria ser simplesmente produzir mais pull requests ou aumentar a quantidade de código entregue por desenvolvedor. O objetivo seria reduzir o tempo e o esforço necessários para que uma alteração percorra o processo de desenvolvimento com um nível adequado de confiança.

Essa é a hipótese que considero mais interessante para discussão: se a IA está aumentando significativamente nossa capacidade de produzir software, como devemos adaptar o restante do processo de engenharia para que esse ganho seja convertido em entregas melhores, e não apenas em mais trabalho aguardando revisão?

A resposta provavelmente dependerá de cada equipe. Justamente por isso, acredito que vale experimentar, medir os resultados e compartilhar o que funcionar — e também o que não funcionar.