Uma equipa com quem trabalhamos queria lançar mais depressa. Ambição justa, e o instinto habitual é comprar algo que ajude os programadores a escrever código mais rapidamente.
Por isso, antes de mudar o que quer que fosse, mapeámos onde uma alteração passava realmente a vida, desde o primeiro commit até estar a correr em produção. A maior parte dessa vida era espera. Espera por um revisor com tempo, porque toda a gente com senioridade suficiente para rever estava ocupada com o seu próprio trabalho. Espera pelos testes, que tendiam a ser escritos depois da revisão e não antes. Espera pela próxima janela de release, porque lançar era suficientemente manual para ter de ser agendado.
Escrever nunca foi a parte lenta. A fila é que era.
O que mudámos
Assim que se vê isto como um problema de filas, a lista de compras escreve-se sozinha: pôr ajuda onde o trabalho espera e deixar o teclado em paz.
O GitHub Copilot no editor já lá estava e, honestamente, é a parte menos interessante desta história. Torna a escrita mais rápida, e a escrita já era rápida.
O Claude revê primeiro todos os pull requests. Esta é a mudança que pagou tudo o resto. No momento em que um pull request é aberto, o Claude Fable lê o diff e deixa comentários: o null não tratado, a exceção engolida, a função que foi copiada e editada só até meio. Não aprova nada. Quando um revisor humano abre o pull request, essa camada já foi tratada, e por isso pode começar onde o seu julgamento importa: no desenho. Rever passou de uma tarefa chata que as pessoas adiavam a um trabalho curto que encaixam entre outras coisas, e a fila à frente encolheu em conformidade.
Testes Playwright redigidos a partir do diff. A suite de testes era mais fina exatamente onde o produto mais mudava, que é como costuma acontecer. Agora, quando um pull request é aberto, o diff e as convenções de especificação da equipa vão para um modelo, que redige testes Playwright para os caminhos que mudaram. Muitos são editados antes do merge e alguns vão para o lixo. Não faz mal. Redigir era a parte que ninguém queria fazer, e agora não custa nada, por isso a cobertura cresce onde quer que o produto se mova. As regressões são apanhadas no CI e não num ticket de suporte.
Dependabot e CodeQL, ligados numa tarde. GitHub nativo, sem novo fornecedor, sem glamour. Um pipeline mais rápido também envia erros mais depressa, e estes dois apanham uma categoria inteira deles sem que alguém tenha de estar atento numa sexta-feira à tarde.
O GitHub Actions faz o release. As builds viviam no Azure DevOps e a equipa estava, de qualquer forma, a consolidar no GitHub. Com revisão, testes, análise e deployment no mesmo sítio, há um único rasto de auditoria. Esse rasto importa mais quando um modelo participa, porque quer conseguir responder com precisão ao que correu e a que pessoa aprovou.
Manter o merge humano
Aqui, um modelo pode escrever código, rever código e redigir testes. Não pode aprovar um pull request nem fazer deploy. Isso é imposto como permissão do repositório, por isso não depende da disciplina de ninguém numa semana atarefada.
Tudo o que vem antes do merge é um rascunho, e os rascunhos são baratos de errar. Tudo o que vem depois do merge é produção. Manter a fronteira aí significa que a velocidade cai onde os erros são recuperáveis, e cada release continua a remontar a um engenheiro com nome que disse que sim. Quando a segurança ou um auditor pergunta quem aprovou, há um nome.
O resultado
Os releases deixaram de ser acontecimentos. Passaram de uma ocasião agendada para algo que acontece várias vezes por semana, quando uma alteração está pronta e não quando o calendário o diz.
A qualidade seguiu na mesma direção, o que surpreendeu quem esperava uma troca. Mais regressões morrem no CI porque os testes agora existem, e os rollbacks tornaram-se raros.
E a mudança que ninguém previu: rever deixou de ser o trabalho que toda a gente guardava para o fim do dia. Trabalho mais curto e mais interessante é apanhado mais cedo. Uma boa parte do ganho de ritmo é provavelmente só isso.
Como começar
Meça onde uma alteração espera antes de comprar o que quer que seja. Se a latência da revisão é o seu estrangulamento, escrever mais depressa não lhe toca. Comece pela revisão com IA, porque é barata de experimentar, fácil de desligar, e uma pessoa lê o resultado de qualquer forma. Deixe um modelo redigir os seus testes e trate os rascunhos como rascunhos. E faça do merge uma permissão humana desde o primeiro dia, porque é essa fronteira que lhe permite dizer que sim a tudo o resto.
Não há uma abordagem única para a cloud. É por isso que partimos da realidade da sua organização.
