Vibe coding para separar bug bloqueante de polimento visual

Quando um defeito visual aparece no meio de uma sessão de execução, ele tem 2 saídas: virar pedido para o agente agora, ou virar item de lista para depois. Escolher a segunda só funciona se você disser em voz alta que escolheu. Thiago fez isso no fim de uma sessão longa, diante de uma tela de formatos que tinha ficado feia, e o que resolveu a cena foi a frase com que ele encerrou a tentativa.

O primeiro tempo é tentar, o segundo é desistir com motivo

O agente entregou os formatos em grade. Ele olhou e não gostou:

"Esse negócio aqui vai ficar muito estranho, velho. Gostei assim não."

Pediu melhora no design, descreveu o que queria no lugar, um formato por linha, um carrossel com anterior e próximo. Voltou pior do que ele esperava. Em vez de abrir a terceira tentativa, parou e disse o motivo:

"Vou ter que ficar perdendo meu tempo isso aqui agora. Não vai dar."

O motivo é de agenda. Aquele layout não estava no caminho do que a sessão tinha ido fazer, e ele chega a comentar que acabamento daquele tipo seria trabalho de outra ferramenta, de outro tipo de sessão. Às vezes o item adiado não é só "depois", é "em outro lugar".

O terceiro tempo é nomear, e é ele que fecha a porta

A melhor fala da cena vem em seguida, dirigida ao agente:

"Você fez o que pôde, deixa assim por enquanto. Encerramos essa parte aqui."

E logo atrás: "Depois eu melhoro [...] o design dessa página."

Parece cortesia com a máquina, e o que ela faz é fechar a conta daquele item. Um defeito que você viu e não nomeou continua na sua cabeça, encostado ali, puxando sua atenção toda vez que a tela reaparece. Dentro de uma sessão com agente, cada puxada dessas custa caro, porque atenção puxada vira pedido e pedido vira ciclo do agente gasto naquilo. Dizer que fica para depois muda o defeito de estado, de coisa pendurada na sua cabeça para linha escrita numa lista.

A prova de que funcionou aparece pouco depois. Quando ele pede ao agente o que ficou em aberto, o agente devolve, no meio da lista: "Design dessa tela fica para você melhorar depois." O item saiu da cabeça dele e entrou no inventário da sessão, que é bem diferente de esquecer.

O que o vibe coding cobra quando você poli no meio da execução

Consertar polimento no meio de uma sessão de execução não custa só o seu tempo. Custa o agente queimando ciclo e contexto numa coisa que não destrava nada, dentro de uma janela que tinha objetivo. Você entrou para fechar o pipeline de trabalho e passou os minutos seguintes discutindo grade de cards. O agente não protesta, ele obedece, e é por obedecer que ele te leva junto.

A cena acontece no fim de um dia comprido, e ele diz por quê:

"Faz 7 horas que eu tô mexendo aqui nas coisas."

7 horas dentro é o ponto em que a triagem para de acontecer sozinha. Cansado, você aceita qualquer coisa que a tela sugerir, porque pedir dá menos trabalho do que decidir se aquilo vale. Aí o critério escrito salva a sessão, e não a disposição do momento.

Bloqueante é o que impede a próxima etapa, e só você sabe qual é

A triagem entre bug bloqueante e polimento visual é do humano, e precisa ser dita. O agente não descobre sozinho o que trava o seu negócio hoje, porque bloqueio é uma propriedade do seu calendário e não do código. A mesma tela torta é irrelevante na semana em que você está fechando o fluxo e é inaceitável na véspera de mostrar o produto para um cliente. O código é idêntico nos 2 casos; o que muda é a sua semana, e o agente não enxerga a sua semana.

O critério prático cabe numa linha. Bloqueante é o que impede a próxima etapa de acontecer. Polimento é o que só ofende quem está olhando. Tela feia com fluxo funcionando não impede ninguém de continuar, e por isso ela espera. Num dia de vibe coding, esse critério é a única coisa que o agente não tem e você tem, então ele precisa sair da sua boca em forma de frase, do jeito que saiu ali. Vale ver como isso terminou em vibe coding para separar tela de aprovar e tela de publicar. Foi o mesmo caminho de vibe coding para separar formato visual da estrutura do conteudo.

Ele repete o movimento até o fim da live. Olha a home e diz: "Tá meio zoada, hein? Não precisa arrumar isso aqui." Adiante, vendo outra seção, comenta que precisa melhorar o layout. Mais adiante ainda, que as letras estão muito pequenas. Continua vendo defeito e continua não consertando, dizendo em voz alta a cada vez. Ver e adiar em voz alta é uma habilidade só, praticada várias vezes na mesma hora.

Existe uma versão preventiva dessa mesma fronteira. Em guardrails no vibe coding, outro builder escreve antes o que o agente não pode fazer na primeira entrega, proibindo enfeite de saída desde o começo; aqui a fronteira é desenhada no meio da execução, sobre o enfeite que já apareceu na tela. Um previne, o outro tria.

Na prática, quando um defeito visual aparecer na sua próxima sessão, faça a pergunta antes do pedido: isso impede a próxima etapa de acontecer? Se impedir, é bug, conserte agora. Se não impedir, diga em voz alta que fica para depois, registre onde ficou e volte para o que você tinha ido fazer. Dizer é a parte que as pessoas pulam, e é a que garante que o item volte na hora dele em vez de voltar na próxima tela que você abrir. É assim que o vibe coding rende num dia longo, e dá para assistir à live inteira e ver a decisão sendo tomada em tempo real.