← todos os posts
Mentoria 5 min de leitura

"\"Eu não sei programar; na hora do código de verdade eu travo\": a objeção 4"

"Você travou sozinho, com tutorial de dev e sem ponto de retorno. A mentoria não ensina a programar, e o primeiro passo você dá hoje: ler um diff."

"Ela conserta uma coisa e quebra outra. Você não entende o que está acontecendo porque não sabe ler o código. É como dirigir um carro sem saber abrir o capô."

Quem escreveu foi um programador brasileiro no TabNews, um fórum brasileiro de tecnologia, em fevereiro de 2026, descrevendo onde trava quem não é da área. É a frase por trás da quarta objeção que eu espero ouvir sobre a mentoria: "eu não sei programar. No Lovable deu, mas na hora de mexer em código de verdade eu vou travar, como travei antes."

A primeira turma ainda não aconteceu, então ninguém me disse isso ainda. Prefiro responder antes.

Você não travou por falta de talento

Olha as condições em que você travou da outra vez. Sozinho. Com tutorial escrito por dev, pra dev, que pula as etapas que o autor acha óbvias. Sem ponto de retorno, então cada erro podia ser definitivo. E sem ninguém pra perguntar "isso aqui é normal?".

Quatro condições. Qualquer pessoa trava nelas, inclusive gente que programa, só que quem programa já passou por aquele erro antes e não lembra que um dia travou nele.

Pensa na primeira aula de direção. Com instrutor do lado e pedal duplo no chão, morrer o carro no cruzamento é uma correção de dez segundos. Pegando o carro emprestado sozinho num domingo, o mesmo carro morrendo no mesmo cruzamento vira a certeza de que "eu não nasci pra dirigir". O carro é igual. A conclusão é que saiu errada.

A mentoria não ensina a programar

Isso eu digo com todas as letras, e está na lista de pra quem ela não é: quem quer virar programador vai se frustrar. O que se ensina é ser dono, e ser dono cabe em três habilidades:

  1. Voltar pra ontem quando a IA quebra o que funcionava. Já está escrito aqui, com quatro comandos.
  2. Pedir prova em vez de aceitar o "consertei". Também está escrito.
  3. Ler o que a IA mudou, que tem nome técnico: diff, a comparação entre o antes e o depois do código.

A terceira é a que dá medo, porque parece exigir ler código. Não exige. Você vai fazer hoje.

O que fazer hoje: ler um diff sem saber programar

Pré-requisito: o código do app num repositório seu no GitHub, o site onde se guarda o código com o histórico de cada mudança. Se ainda não está lá, o passo a passo de dez minutos está aqui. No Lovable, cada mudança que a IA faz vai parar no GitHub sozinha.

  1. Abra o repositório em github.com e clique no número ao lado do ícone de relógio, perto do topo, escrito algo como "128 Commits". Commit é cada ponto salvo da história do app.
  2. Clique no mais recente, o primeiro da lista. Abre uma página com a lista dos arquivos que mudaram e, embaixo de cada um, linhas coloridas: verde, com um "+" na frente, é o que entrou. Vermelho, com "−", é o que saiu.
  3. Não leia as linhas. Faça três perguntas a elas:

Quantos arquivos mudaram? Está escrito no alto da página. Você pediu pra trocar o texto de um botão e mudaram sete arquivos? Alguma coisa foi mexida sem você pedir. Quem programa faz essa mesma pergunta antes de ler qualquer linha: o tamanho errado aparece antes do erro.

Os nomes batem com o assunto? Arquivo tem nome, e o nome costuma dizer do que ele cuida. Pediu uma mudança na tela de agendamento e aparece um arquivo com auth no nome (de authentication, o login) ou payment (pagamento)? Anote. Não é prova de erro, é a pergunta certa pra próxima mensagem.

Tem vermelho que você não mandou tirar? Linha verde é coisa nova, e coisa nova você vai testar de qualquer jeito. Linha vermelha é coisa que existia e sumiu. Um bloco grande de vermelho num pedido pequeno é o lugar mais provável de onde saiu a quebra que você só vai ver amanhã.

Se alguma das três respostas incomodou, não precisa entender a linha. Copie o endereço daquela página e mande pra IA:

"Neste commit, explique em português, arquivo por arquivo, o que mudou e por quê. Diga se alguma mudança não era necessária pro que eu pedi, que foi: [seu pedido]."

Você não leu código. Você leu o tamanho, os nomes e a cor, e fez a pergunta que um dev faria. Isso é ler um diff no nível que um dono precisa.

O que esse passo não resolve

Ler o diff te diz que algo está estranho. Não te diz o que fazer quando o estranho é um erro que você nunca viu, às onze da noite, num app que o cliente usa. É nesse ponto que alguém sozinho perde dois fins de semana.

É pra esse ponto que existe a sessão individual: cinquenta minutos, só o seu projeto na tela. O erro que te seguraria dois fins de semana costuma ser coisa de minutos com alguém do lado, não porque você é lento, mas porque eu já vi aquele erro muitas vezes em quinze anos. Esse é o pedal duplo.

E ler o diff é um pedaço de uma parede maior. Na fase Construa, o portão pede código na sua máquina, banco no seu nome, ambiente de teste separado do de produção e ponto de retorno. Depois vem Estruture, depois Opere. Cada fase tem um lugar onde as pessoas travam, e a ordem existe justamente pra você não encontrar os quatro de uma vez, sozinho.

A objeção diz "eu travo". A frase honesta é outra: "eu travei quando estava sozinho, sem pedal duplo e com o tutorial errado". Hoje você leu um diff. Troque uma das quatro condições e veja o que sobra da previsão.

Fontes