Nunca deixes a IA fazer push para o GitHub:a lição

Nunca deixes a IA fazer push para o GitHub sem a tua revisão. Deixa-o rever as tuas alterações, escrever as mensagens de commit e preparar os pull requests — mas o push fica nas mãos de um humano. Aprendi esta regra da forma mais cara: um push não revisto publicou na internet a chave mestra da minha base de dados, e a limpeza comeu quatro horas que nunca vou recuperar.

Eis exatamente o que aconteceu, o que a IA deve e não deve poder fazer com o histórico do teu código e o fluxo de trabalho que te mantém a avançar depressa sem sustos de segurança.

Nunca deixes a IA fazer push para o GitHub: o dia da chave secreta

Estava a construir o FIKR Space, a minha plataforma SaaS. A avançar depressa. A IA ajudava em tudo.

Um dia disse-lhe: "Faz commit destas alterações e push para a main."

Ela fez. Sem perguntar. Sem me mostrar o que estava a incluir no commit.

Afinal eu tinha incluído sem querer a minha service key do Supabase — a chave mestra que desbloqueia toda a minha base de dados — num ficheiro de configuração. Estava agora no histórico do git. No GitHub. Pública.

Tive de rodar imediatamente todas as chaves, fazer force-push para apagar o commit do histórico, verificar todos os serviços ligados à procura de falhas de segurança e passar quatro horas a corrigir o que uma revisão de trinta segundos teria evitado.

A lição: nunca confies às cegas na IA com o git. Mas a história tem uma segunda metade que importa tanto quanto a primeira — a IA é incrível com o git quando a usas corretamente. Se o próprio git ainda é um conceito nebuloso, começa por git explicado a fundadores não técnicos e depois volta; este artigo é sobre o lugar da IA nisso.

O que a IA deve fazer com o histórico do teu código

Rever cada alteração antes de fazeres commit. Antes de cada commit corro um comando de revisão guardado. A IA lê exatamente o que mudou, verifica cada ficheiro modificado à procura de bugs, restos de output de depuração e problemas de segurança — segredos escritos no código, chaves expostas — e sugere melhorias. Um exemplo real: estava prestes a fazer commit de alterações ao meu código de processamento de pagamentos. A revisão apanhou uma chave de API de teste que tinha deixado escrita no código, falta de tratamento de erros para pagamentos falhados, atalhos de tipagem desleixados e um ficheiro de testes que me tinha esquecido de atualizar. Tudo apanhado antes do commit.

Escrever as tuas mensagens de commit. Boas mensagens de commit são difíceis, e a IA torna-as fáceis. Depois de rever as alterações, redige uma mensagem clara e descritiva que lista o que foi acrescentado e porquê. Posso editá-la se for preciso, mas normalmente está certa à primeira.

Preparar os teus pull requests. Quando um ramo de funcionalidade está pronto, a IA revê todos os commits desse ramo, escreve o título e a descrição, monta uma lista do que mudou e acrescenta notas de teste. Profissional, completo, e poupa-me trinta minutos de escrita por funcionalidade.

Desembaraçar conflitos de merge. Quando duas versões de um ficheiro colidem, a IA lê as duas versões, percebe a intenção de cada alteração, sugere uma resolução que mantém as duas melhorias e explica porque a escolheu. Muito mais rápido do que comparar versões à mão.

As seis coisas que a IA nunca deve fazer

1. Fazer push para o ramo principal sem confirmação. A main é o que os teus utilizadores veem. Confirma sempre. Sempre.
2. Fazer force-push sem autorização explícita. Um force-push reescreve o histórico e pode destruí-lo. Só quando sabes exatamente porquê.
3. Apagar ramos sem perguntar. Os ramos são baratos. Não deixes a IA limpá-los automaticamente.
4. Fazer commit sem revisão. Esta é a regra que teria salvado a minha chave. Revê as alterações antes de cada commit.
5. Saltar as tuas verificações de segurança. As verificações automáticas antes do commit existem por uma razão. Nunca deixes a IA contorná-las.
6. Reescrever commits que não criou. Alterar os commits de outra pessoa reescreve o histórico partilhado — perigoso a partir do momento em que mais alguém toca no projeto.

Repara no padrão: tudo nesta lista é irreversível ou público. A IA pode redigir qualquer coisa; não confirma nada.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

A recompensa: de 30 minutos por funcionalidade para 4

A razão para montar isto como deve ser não é só a segurança — é a velocidade. Eis quanto me custavam as tarefas de git à volta de uma única funcionalidade, antes e depois:

Faço commit cinco a dez vezes por dia. São 130–260 minutos poupados por dia. Ao longo dos onze meses que já levo a construir o FIKR Space, são centenas de horas — recuperadas por um assistente que ainda apanha bugs que eu teria posto no ar.

O fluxo de trabalho seguro, passo a passo

1. Faz as tuas alterações.
2. Corre o teu comando de revisão com IA sobre tudo o que mudou.
3. Corrige o que ele assinalar.
4. Deixa a IA redigir a mensagem de commit; aprova-a ou edita-a.
5. A IA cria o commit.
6. Tu fazes o push — ou confirmas explicitamente antes de a IA o fazer.

E as regras por baixo disto: revê sempre as diferenças antes de fazer commit, nunca ponhas segredos no código (pertencem às variáveis de ambiente), confirma sempre os pushes para a main, deixa a IA redigir enquanto tu aprovas e, na dúvida, fá-lo à mão.

Um push não revisto é a forma mais ruidosa de a IA te prejudicar, mas é o mesmo modo de falha que a versão silenciosa — aceitar resultados que nunca inspecionaste até os danos se acumularem. A versão mais lenta desta história é como a IA sabota o teu código.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Perguntas frequentes

Porque é que o push é mais arriscado do que o commit?

Um commit é um instantâneo local na tua máquina — um erro aí é privado e fácil de desfazer. Um push publica esses instantâneos no GitHub, onde podem ser vistos, clonados e recolhidos por robôs. A minha chave exposta só se tornou uma emergência de quatro horas no momento em que foi feito o push. É por isso que o push é o passo que precisa sempre de um humano.

O que devo fazer se um segredo chegar ao GitHub?

Trata-o como comprometido no momento em que lá chega, mesmo que o apagues segundos depois — há robôs automáticos a vigiar os repositórios públicos. Roda a chave imediatamente, apaga o commit do histórico e verifica todos os serviços a que essa chave dava acesso à procura de atividade suspeita. Depois corrige a origem: os segredos vivem em variáveis de ambiente, nunca em ficheiros que o git acompanha.

Posso alguma vez deixar a IA fazer push?

Sim — depois de ela te mostrar exatamente o que vai enviar e de tu confirmares explicitamente. A regra não é "a IA nunca toca no git"; a IA trata da maior parte do meu fluxo de trabalho de git. A regra é que nada de irreversível ou público acontece sem passar primeiro pelos teus olhos.

Rever cada alteração não é lento?

É o contrário, porque é a IA que faz o trabalho pesado da própria revisão. O meu fluxo com revisão leva 4 minutos por funcionalidade, contra 30 à mão — e apanha chaves escritas no código, falta de tratamento de erros e testes esquecidos antes de irem para o ar. As quatro horas que passei a limpar a chave exposta foram o preço de saltar uma revisão de dois minutos uma única vez.