Nunca deixe a IA dar push no GitHub:a lição

Nunca deixe a IA dar push no GitHub sem a sua revisão. Deixe-o revisar suas alterações, escrever suas mensagens de commit e preparar seus pull requests — mas o push continua humano. Aprendi essa regra do jeito caro: um único push sem revisão publicou a chave mestra do meu banco de dados na internet aberta, e a limpeza consumiu quatro horas que eu nunca vou recuperar.

Aqui está exatamente o que aconteceu, o que a IA deve e não deve poder fazer com o histórico do seu código, e o fluxo de trabalho que te mantém rápido sem o pânico de segurança.

Nunca deixe a IA dar push no GitHub: o dia da chave secreta

Eu estava construindo o FIKR Space, minha plataforma SaaS. Indo rápido. A IA estava ajudando em tudo.

Um dia eu disse a ela: "Faça commit dessas alterações e dê push na main."

Ela fez. Sem perguntar. Sem me mostrar o que estava commitando.

Acontece que eu tinha incluído sem querer minha service key do Supabase — a chave mestra que abre o meu banco de dados inteiro — num arquivo de configuração. Agora ela estava no histórico do git. No GitHub. Pública.

Tive que trocar todas as chaves imediatamente, dar um force-push para apagar o commit do histórico, verificar cada serviço conectado em busca de violações de segurança e passar quatro horas consertando o que uma revisão de trinta segundos teria evitado.

A lição: nunca confie cegamente na IA com o git. Mas a história tem uma segunda metade que importa tanto quanto a primeira — a IA é incrível com git quando você a usa do jeito certo. Se o próprio git ainda é um conceito nebuloso, comece por git explicado para fundadores não técnicos e depois volte; este post é sobre onde a IA se encaixa nele.

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

Revisar cada alteração antes do commit. Antes de cada commit, eu rodo um comando de revisão salvo. A IA lê exatamente o que mudou, verifica cada arquivo modificado em busca de bugs, restos de saída de depuração e problemas de segurança — segredos fixos no código, chaves expostas — e sugere melhorias. Um exemplo real: eu estava prestes a commitar alterações no código de processamento de pagamentos. A revisão pegou uma chave de API de teste que eu tinha deixado fixa no código, falta de tratamento de erros para pagamentos recusados, atalhos de tipagem malfeitos e um arquivo de teste que eu tinha esquecido de atualizar. Tudo pego antes do commit.

Escrever suas mensagens de commit. Boas mensagens de commit são difíceis, e a IA as torna fáceis. Depois de revisar as alterações, ela rascunha uma mensagem clara e descritiva listando o que foi adicionado e por quê. Eu posso editar se precisar, mas normalmente ela acerta de primeira.

Preparar seus pull requests. Quando uma branch de funcionalidade está pronta, a IA revisa cada commit dela, escreve o título e a descrição, monta um checklist do que mudou e acrescenta notas de teste. Profissional, completo, e me economiza trinta minutos de escrita por funcionalidade.

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

As seis coisas que a IA nunca deve fazer

1. Dar push na sua branch main sem confirmação. A main é o que seus usuários veem. Sempre confirme. Sempre.
2. Dar force-push sem permissão explícita. Um force-push reescreve o histórico e pode destruí-lo. Só quando você sabe exatamente por quê.
3. Apagar branches sem perguntar. Branches são baratas. Não deixe a IA fazer limpeza automática delas.
4. Commitar sem revisão. Essa é a regra que teria salvado minha chave. Revise as alterações antes de cada commit.
5. Pular suas verificações de segurança. Verificações automáticas de pré-commit existem por um motivo. Nunca deixe a IA contorná-las.
6. Reescrever commits que ela não criou. Emendar commits de outra pessoa reescreve um histórico compartilhado — perigoso a partir do momento em que mais alguém mexe no projeto.

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

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

A recompensa: de 30 minutos por funcionalidade para 4

O motivo para configurar isso direito não é só segurança — é velocidade. Veja quanto as tarefas de git em torno de uma única funcionalidade me custavam, antes e depois:

Eu faço de cinco a dez commits por dia. São de 130 a 260 minutos economizados por dia. Ao longo dos onze meses que passei construindo o FIKR Space, são centenas de horas — recuperadas por um assistente que ainda pega bugs que eu teria colocado no ar.

O fluxo seguro, passo a passo

1. Faça suas alterações.
2. Rode seu comando de revisão com IA em tudo o que mudou.
3. Corrija o que ela apontar.
4. Deixe a IA rascunhar a mensagem de commit; aprove ou edite.
5. A IA cria o commit.
6. Você dá o push — ou confirma explicitamente antes de a IA dar.

E as regras por baixo disso: sempre revise as diferenças antes de commitar, nunca coloque segredos no código (eles pertencem às variáveis de ambiente), sempre confirme pushes na main, deixe a IA rascunhar enquanto você aprova e, na dúvida, faça à mão.

Um push sem revisão é a forma mais barulhenta de a IA te prejudicar, mas é o mesmo tipo de falha da forma silenciosa — aceitar um resultado que você nunca inspecionou até o estrago se acumular. A versão mais lenta desta história é como a IA sabota o seu código.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

Perguntas frequentes

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

Um commit é uma foto local na sua máquina — um erro ali é privado e fácil de desfazer. Um push publica essas fotos no GitHub, onde podem ser vistas, clonadas e raspadas. Minha chave vazada só virou uma emergência de quatro horas no momento em que foi para o push. É por isso que o push é a etapa que sempre precisa de um humano.

O que fazer se um segredo chegar ao GitHub?

Considere-o comprometido no instante em que ele chega, mesmo que você apague segundos depois — robôs automáticos vigiam repositórios públicos. Troque a chave imediatamente, apague o commit do histórico e verifique cada serviço a que essa chave dava acesso em busca de atividade suspeita. Depois conserte a origem: segredos vivem em variáveis de ambiente, nunca em arquivos que o git rastreia.

Posso deixar a IA dar push alguma vez?

Sim — depois que ela te mostrar exatamente o que vai enviar e você confirmar explicitamente. A regra não é "a IA nunca encosta no git"; a IA toca a maior parte do meu fluxo de git. A regra é que nada irreversível ou público acontece sem os seus olhos em cima antes.

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

É o contrário, porque a própria IA faz o trabalho pesado da revisão. Meu fluxo revisado leva 4 minutos por funcionalidade, contra 30 à mão — e pega chaves fixas no código, falta de tratamento de erros e testes esquecidos antes de irem para o ar. As quatro horas que passei limpando a chave vazada foram o custo de pular uma revisão de dois minutos uma única vez.