Vibecoding
Como descobrir o que uma parte do código faz sem o autor
O autor saiu, ou o autor era a IA e ninguém guardou o raciocínio. Existe um método de investigação que funciona melhor que ficar encarando a tela.
Você abre um trecho e não faz ideia do que ele faz.
Quem escreveu não está mais na empresa. Ou pior, quem escreveu foi a IA e você aprovou seis meses atrás sem guardar o raciocínio.
O reflexo é encarar a tela e ler do começo ao fim. É o método mais lento que existe.
Comece pelas bordas, não pelo meio
Antes de olhar o que o trecho faz por dentro, descubra o papel dele.
Quem chama isso? Busca por referências. Se é chamado pela tela de pagamento, você já sabe muito. Se é chamado por um processo que roda de madrugada, sabe outra coisa.
O que ele devolve? Olha o retorno e o que quem chamou faz com ele.
O que acontece se falhar? Quem trata o erro, e como.
Com essas três respostas você já sabe o papel da peça. Ler o interior fica muito mais fácil quando você sabe o que procurar.
Segue o dado, não o fluxo
Ler de cima pra baixo é seguir o fluxo, e você se perde na terceira condicional aninhada.
Melhor: escolhe uma informação e acompanha ela.
De onde vem esse valor. Como ele é transformado. Onde ele para.
Funciona melhor porque a lógica existe pra transformar dado. Seguindo o dado você reconstrói a intenção; seguindo o fluxo você só percorre a estrutura.
Olha o histórico
A fonte mais subestimada.
Cada alteração naquele arquivo teve um motivo, e às vezes o motivo está escrito na mensagem da alteração.
Duas coisas pra procurar:
Quando aquele trecho estranho apareceu. Se ele foi adicionado numa alteração com mensagem "corrige erro no fechamento do mês", você acabou de descobrir por que ele existe.
Se aquilo já foi simples. Trecho complicado costuma ter nascido simples e ganhado remendos. Ver a versão original mostra a intenção antes das exceções.
Sem o autor, o histórico é o que sobra de mais próximo da intenção original.
Usa a IA pra mecânica, não pra intenção
Aqui ela rende muito, com um limite claro.
Pede pra ela explicar o que o trecho faz, em português, passo a passo. Ela é precisa nisso e economiza tempo real.
Pede os casos de borda: o que acontece com valor vazio, negativo, nulo. Ela enxerga isso rápido.
Pede um resumo do papel da função no arquivo.
O que ela não vai te dar é a intenção de negócio. Ela não sabe que aquela exceção existe por causa de um contrato de 2024. Ela vê o código, não a empresa.
Então: explicação dela é ponto de partida da investigação. Nunca é a conclusão. É o mesmo limite de não delegar arquitetura.
Testa a hipótese antes de confiar
Depois de formar uma teoria, confirma.
Muda um valor de entrada e vê se a saída muda como você previu.
Coloca uma marcação temporária e roda pra ver se aquele caminho é mesmo executado.
Quebra de propósito, num ambiente de teste, e vê o que deixa de funcionar. É a forma mais rápida de descobrir quem depende daquilo.
Teoria não confirmada é chute com aparência de conhecimento, e é o que faz gente mexer com confiança e quebrar.
Escreve o que descobriu
O passo final, e o mais pulado.
Você gastou uma hora entendendo. Se não registrar, daqui a seis meses gasta de novo, e provavelmente é você mesmo.
Três linhas no lugar certo: o que aquilo faz, por que existe, e o que descobriu que é armadilha. É o comentário que ajuda, no melhor momento possível pra ser escrito.
Entender código não é ler. É investigar.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Por onde começar a entender um trecho desconhecido?
Pelas bordas, não pelo meio. Descubra quem chama aquilo e o que ele devolve, porque isso define o papel do trecho no sistema antes de você olhar a implementação.
+Por que seguir o dado funciona melhor que ler o fluxo?
Porque a lógica costuma existir para transformar dado. Acompanhar a informação da entrada até a saída revela a intenção mais rápido que percorrer condicionais em ordem.
+O histórico de alterações ajuda mesmo?
Muito, porque cada mudança costuma ter um motivo e às vezes uma mensagem explicando. É a fonte mais próxima da intenção original que sobra quando o autor não está.
+A IA consegue explicar código que ela não escreveu?
Consegue explicar a mecânica com precisão, o que já resolve boa parte. O que ela não sabe é a intenção de negócio, então a explicação dela é ponto de partida e não conclusão.
Continue lendo
Como documentar um sistema que a IA escreveu
Documentação longa ninguém escreve e ninguém lê. Existe uma versão curta que cabe em uma página e resolve 90% do problema, principalmente quando quem escreveu o código foi a IA.
VibecodingComo subir pra produção numa sexta sem medo
A regra de não subir na sexta existe porque o processo é ruim, não porque sexta é perigosa. Com quatro coisas no lugar, o dia da semana para de importar.
VibecodingO agente de código entrou no canal do time. Ver não é revisar
O Slack lançou canais onde agentes de IA programam na frente de todo mundo, com Claude, Copilot, Devin, ChatGPT e Vercel. É a melhor notícia de governança do ano e a maior armadilha de teatro de revisão.