Vibe coding para quando a ferramenta não suporta a tarefa: o teste que não prova nada

Jhonatan afirma que a ferramenta não faz o que ele precisa e, logo em seguida, tenta fazer assim mesmo. O que separa a cena de pura teimosia é o critério que ele enuncia em voz alta antes de clicar: ali tudo é teste. O critério é defensável, e ainda assim aquela tentativa saiu cara, porque uma tentativa só paga quando você consegue dizer de antemão o que a falha vai provar.

O limite veio primeiro, afirmado como fato:

"o Codex não consegue gerar looping, mano. Eu preciso de fazer o looping nele."

O que ele chama de looping é aquilo que ele precisava gerar para seguir. A gravação não explica o que é, e eu não vou preencher esse buraco. O que interessa é a forma da frase, que é de fato consumado: não consegue. E logo depois ele foi tentar.

Tudo é teste, e por que essa posição costuma funcionar

"Deixa-me arriscar. Vamos arriscar, certo? Tudo é teste. Vamos deixar tudo teste."

Essa postura é comum em quem constrói em público, e ela se defende bem. Você troca certeza por velocidade, aceita gastar tentativas para descobrir o terreno andando nele, e no agregado costuma chegar mais longe que quem confirma cada passo antes de dar. Quem transmite ao vivo tem incentivo extra, porque pesquisar é tempo morto na tela e tentar é conteúdo.

O que decide se essa troca paga é a pergunta em que você a aplica.

Os 2 tipos de "isso não vai funcionar"

Uma tentativa rende quando você está diante de uma dúvida genuína. Você não sabe se aquele caminho aguenta, roda, e o resultado te entrega uma informação que você não tinha. Falhou, você aprendeu onde. Passou, você ganhou um caminho.

O outro caso é o limite conhecido. Você já sabe que a ferramenta não faz aquilo, roda mesmo assim, e o resultado devolve exatamente a informação com que você começou. O custo é o tempo, e o retorno é zero.

Jhonatan descreveu o segundo caso e agiu como quem está no primeiro.

Só que dizer "não consegue" em voz alta não prova que a pessoa foi verificar. Live é um lugar onde a gente fala com mais convicção do que tem, e é bem possível que a certeza dele fosse menor do que a frase deixa parecer. Se era menor, testar passa a ser a decisão certa, e o defeito muda de lugar: sai da tentativa e vai para a frase, que anunciou como fato uma coisa ainda em aberto.

A tentativa não subiu, e a gravação não diz por quê

A execução não iniciou, e ele perguntou 2 vezes:

"Por que é que ele não me está a deixar? Por que é que não me está a deixar startar, hã, velho?"

"Ele não está a deixar startar não, velho. Mas mesmo aqui também não."

Depois disso ele seguiu para outra coisa.

A gravação não liga a falha ao limite que ele nomeou. Pode ter sido o limite, pode ter sido permissão ou qualquer outra coisa que nem chegou a aparecer na tela. A tentativa não confirmou a hipótese dele e também não a desmentiu. Ela custou tempo e não produziu leitura.

Ele saiu dali com uma pergunta a mais, e não com uma resposta errada, o que pesa mais do que a dúvida original, porque agora existe um evento na mesa pedindo explicação.

O que o vibe coding barateou, e o que continuou caro

O preço de uma tentativa caiu tanto que "vamos arriscar" virou o caminho de menor esforço, mais barato até do que procurar a resposta. Isso inverte um hábito antigo: quem ia rodar algo demorado lia antes, porque errar custava a tarde.

O custo que não caiu é o de interpretar o que voltou. Ler um erro e isolar a causa continua exigindo o mesmo tempo de sempre. Quando dá para tentar 10 coisas por hora e ler 2, você acumula resultados que não sabe ler, e a sensação de estar testando ocupa o lugar da informação que o teste deveria entregar. Boa parte do tempo perdido no vibe coding mora nesse desencontro, e não na qualidade do código que sai. O mesmo problema apareceu em vibe coding para nao vender a ferramenta da sua vantagem.

O mesmo tipo de obstáculo, 2 posturas diante da incerteza

Vale comparar com outro builder diante do risco de api de terceiro no vibe coding, que também esbarra num limite que não controla. Lá o builder marca a dúvida em voz alta, com um "foi isso que eu entendi pelo menos", e a recomendação que sai dali é ir ler a documentação da plataforma antes de construir em cima. Aqui o limite é afirmado sem essa marca e resolvido na tentativa.

A diferença entre os 2 casos está no que cada um faz com a própria incerteza, não no tamanho do obstáculo. Um builder deixa a incerteza visível e vai buscar a resposta onde ela está escrita. O outro a resolve clicando.

Análise minha, não da live

Daqui para baixo é leitura minha, e cabem 3 ressalvas.

"Tudo é teste" só paga se o resultado for legível. Antes de arriscar, vale escrever em uma frase o que você vai concluir caso aquilo falhe. Se a frase não sair, a tentativa não vai responder nada, e foi o que aconteceu aqui.

Quando a pergunta é sobre limite estrutural da ferramenta, o caminho barato quase nunca é a tentativa, é a documentação. Ler leva minutos e devolve uma resposta que você consegue interpretar, enquanto uma execução que nem inicia devolve uma pergunta nova.

E há o crédito que a cena merece. Tentar ao vivo tem um valor que a tentativa privada não tem, porque a falha fica registrada junto com a decisão que levou até ela. Quem assiste acompanha o critério e o resultado no mesmo lugar, e aprende com o erro sem pagar por ele. Isso é boa parte do que construir em público entrega, e é por isso que vale assistir à live inteira em vez de só ler sobre ela.

Da próxima vez que você for dizer "deixa eu arriscar", escreva antes a frase do que a falha vai provar. Se ela não sair, procure a resposta em vez de tentar. E se for tentar mesmo assim, decida antes quanto tempo aquilo vale, porque tentativa sem limite de tempo é onde a tarde vai embora.