Vibe coding para nunca silenciar aviso do lint: o aviso calado derrubou a tela

Desligar um aviso de lint é informação sobre quem está escrevendo o código, quase nunca sobre o lint. Quem formulou essa frase numa live do build de Martin foi o agente que trabalhava com ele, num relatório sobre o próprio erro: tinha calado um aviso e derrubado a tela do app.

A live é a construção ao vivo de um aplicativo para ajudar quem quer parar de fumar. Perto do fim da sessão, com o teste de retomada do onboarding já passando, o agente listou o que tinha quebrado no caminho:

"Dois bugs meus no caminho. Tela branca, [...] fewer hooks than expected. Esse foi mais feio. Eu tinha escrito um hook que semeava o campo dentro de use effect com uma função vinda do parâmetro e silenciei o aviso do lint que apontava. Tá. A lição que fica, quando eu desligo um aviso de lint sinal que eu estou fazendo algo errado. Não de que o lint está errado. Foi o aviso que eu calei que derrubou a tela."

O aviso some da tela, o defeito continua no código

O lint é uma ferramenta externa que lê o código e devolve um sinal sobre ele. Silenciar o sinal não mexe em nada do que estava sendo medido: some o aviso amarelo no editor, fica o mesmo código que o produziu. O hook semeava o campo dentro de um useEffect com uma função vinda do parâmetro, o lint apontou para isso, o apontamento foi calado, e o código seguiu inteiro do jeito que estava.

Quando o aviso aparece, a leitura mais confortável é que a ferramenta está sendo chata com um caso que ela não entende. Às vezes está mesmo. Só que a chance de o lint estar errado sobre uma regra que ele carrega há anos é pequena perto da chance de quem acabou de escrever o código ter feito algo torto, e o agente aplicou essa ordem de probabilidade a si mesmo antes de aplicar à ferramenta.

A conta chega deslocada, e por isso ninguém liga as pontas

Esse tipo de erro fica caro por causa da distância entre as 2 aparições. O aviso estava numa regra de hook, dentro de um arquivo específico. O estrago apareceu como tela branca no emulador, com uma mensagem sobre contagem de hooks, depois de o trabalho já ter seguido para outras telas. Nesse ponto, o arquivo silenciado não é o primeiro lugar onde alguém vai procurar. Isso aparece também em vibe coding para lista unica de telas em vez de tela apontando pra proxima, onde a ordem das telas do mesmo onboarding deixou de morar espalhada e virou lista única.

Essa defasagem faz o hábito de silenciar parecer barato. No instante da decisão o benefício é imediato, o editor para de reclamar e o trabalho continua, enquanto a cobrança vem depois, em outro arquivo, sem nenhuma marca que a ligue à escolha que a causou. Quando ela chega, a escolha já saiu da cabeça de quem a fez.

Vale ver também como vibe coding para deixar usuario corrigir escolha do onboarding trata o mesmo padrão: uma decisão tomada no começo aparece como problema depois. E vibe coding para separar o que falta de codigo do que falta de configuracao mostra que separar os tipos de trabalho que dependem de si mesmo daqueles que não dependem muda a ordem de tudo.

Em vibe coding, calar o aviso é a saída mais curta

Em vibe coding esse atalho fica ainda mais tentador, porque o objetivo imediato é quase sempre ver a tela funcionando. O aviso do lint entra nessa cena como obstáculo entre o estado atual e a tela pronta, e desligá-lo resolve o obstáculo em 1 linha. Um agente com missão de entregar tem todo incentivo para tomar esse caminho, e quem está acompanhando, querendo ver a tela subir, raramente tem motivo para barrar.

Outro builder do vibe coding descreveu o mesmo mecanismo por outro caminho, ao defender um agente que implementa separado do agente que valida: quem recebe a missão de implementar faz o que for preciso para implementar, inclusive apagar o código que atrapalha, e por isso quem julga precisa ser ferramenta externa. Silenciar o aviso do lint é esse padrão em escala pequena. O obstáculo foi removido em vez de resolvido, e quem removeu foi o mesmo que precisava dele para não errar. Vale ver como isso terminou em vibe coding para testar retomada matando o app de verdade.

O mesmo princípio de separar quem constrói de quem valida aparece em camadas de seguranca.

O que salva esse episódio é que o agente relatou. Ele podia ter consertado a tela branca e chamado aquilo de problema do emulador, explicação que estava à mão e teria passado. Em vez disso escreveu que os 2 bugs eram dele, apontou a decisão que causou o pior deles e formulou a regra contra si mesmo, que é o comportamento que se quer de quem entrega relatório. Ainda assim, relato próprio tem limite: quem conta é o mesmo que escreveu o código e sabe o que foi combinado no caminho. Quando o que está em jogo não é 1 bug e sim o estado do projeto inteiro, o jeito de escapar disso é pedir uma segunda opinião de IA sobre o projeto numa sessão que não tem histórico nenhum da conversa.

Vale também adiar decisões que dependem do produto existir. Vibe coding para decidir paywall sem trial gratuito mostra a vantagem de travá-las até a tela estar pronta.

O que faz a diferença no pedido ao agente é a clareza sobre a hipótese e o papel: vibe coding para saber pedir para o agente mostra que pedir sem essas 2 coisas é deixar o agente errar mais caro.

E para que o pedido seja bem executado, escreva a ordem antes: vibe coding para prompt de corrigir bug com plano antes de executar mostra como anexar as 4 exigências de processo no mesmo pedido.

Antes de tudo isso, porém, o projeto já precisa estar documentado: vibe coding para documentar projeto antes de codar lembra que o passo a passo precisa estar escrito para o agente não esquecer.

O que fazer quando o aviso aparece

Se você precisa desligar um aviso para continuar, pare antes de desligar e entenda o que ele está apontando. Na maior parte das vezes o entendimento já resolve o problema, porque o aviso estava descrevendo o defeito que você ia arrastar adiante.

Se depois de entender a decisão for mesmo desligar, deixe escrito o porquê ao lado da linha desligada. Isso muda o que a próxima pessoa encontra ali: em lugar de um silêncio sem autor, uma escolha assinada, com o motivo do lado, que ela consegue julgar. O comentário é também o que permite ligar as pontas quando a tela quebrar longe dali, que é como esse defeito costuma se apresentar.

A frase do agente vale carregar inteira, do jeito que ele disse: o aviso que você cala é candidato a ser o que derruba a tela. A cena completa está na live do dia 11 do build.