Vibe coding para confirmar deploy sem esperar verificação completa

A verificação que confirmaria o deploy era justamente a que estava quebrada. Isso acontece mais do que parece: o build sobe, a conferência que diria se ele está de pé retorna erro por conta própria, e você continua com informação na tela, só que não a informação que queria. Decidir com o que sobrou é a tarefa.

Na segunda parte da live de Martin construindo o Fumava, essa cena passa em poucos segundos e deixa uma frase que faz o trabalho todo: um sinal pode dar o veredito e o limite do veredito ao mesmo tempo, e é o limite que impede o sinal de virar promessa.

Veredito e limite na mesma linha

A pergunta que abre o problema aparece assim na transcrição:

"Como saber se funcionou sem esperar pela verificação que falhou [...]"

E o critério que responde:

"Se passar dela, nível de confiança elevado, não certo."

A frase faz 2 coisas de uma vez. Ela autoriza seguir, com "nível de confiança elevado", e recusa o crédito que essa autorização normalmente arrasta atrás de si, com "não certo". As 2 metades cabem em uma linha, e a segunda é a que raramente é escrita.

A maioria dos sinais que você usa no dia a dia chega só com a primeira metade. O teste passou, a página abriu. Os 2 são verdadeiros, e nenhum deles vem acompanhado do que não cobre, então quem lê completa sozinho, e completa para cima, porque a leitura otimista é a que deixa você seguir trabalhando.

O que dá para ver e o que a legenda corta

O material aqui é pequeno, e isso muda o que dá para afirmar. É uma passagem curta, de poucas linhas, lida depressa no meio de uma transmissão cheia de problema de conexão. Não tem demonstração nem desfecho, e ninguém volta ao assunto depois. Este post se sustenta em uma frase e no raciocínio em cima dela.

Dá para ver que existe uma janela curta no começo do processo:

"roda nos primeiros 35 segundos. Depois o build sai da fila."

O que exatamente roda nesse intervalo eu não sei dizer. A legenda quebra bem aí, no ponto em que o mecanismo seria explicado, e preencher esse buraco seria inventar. Também não dá para saber de quem é a passagem: o estilo é telegráfico, do tipo que aparece quando alguém lê em voz alta a saída do assistente, mas a transcrição não marca quem fala e não houve confirmação. Então ela fica sem atribuição, e o valor dela não depende disso.

O que um sinal antecipado precisa ter para valer

Daqui para frente é leitura minha, não da live.

Um sinal antecipado presta quando é barato de obter, chega bem antes da conferência completa e correlaciona com o resultado que interessa. As 2 primeiras qualidades são fáceis de conseguir e por isso enganam: qualquer coisa rápida parece útil. A terceira separa um proxy de uma coincidência confortável, e ela pede que você saiba por que aquele sinal antecipa aquele resultado, não só que os 2 costumam aparecer juntos.

Falta ainda a condição que quase ninguém escreve: alguém precisa dizer o que aquele sinal não cobre. Um proxy é legítimo quando a conferência completa está quebrada ou lenta demais para o ciclo em que você trabalha, e quando existe uma frase registrada dizendo até onde ele vale. Sem essa frase o sinal não é proxy, é torcida com aparência de método.

Por que o vibe coding vive perto dessa tentação

O ciclo aqui é curto. Você pede, o agente devolve em segundos, você olha e pede de novo. Esperar a verificação completa quebra exatamente o ritmo que faz o vibe coding render, então a pressão para aceitar um sinal mais rápido é permanente, não é o deslize de um dia ruim. Foi o mesmo caminho de macbook air m1 para programar.

Some a isso que o agente relata sucesso usando o sinal que ele tem à mão, e o relato chega até você sem dizer qual sinal foi usado. Você lê que o deploy está de pé e não tem como saber se isso veio da conferência completa ou do primeiro indício que apareceu na janela do começo.

O mesmo builder, e um verde que mentiu

Outra cena do próprio Martin mostra o avesso disso, em testar retomada matando o app de verdade. Lá o teste devolvia verde e o verde mentia, porque ele tinha reiniciado a camada errada. O sinal era real e o resultado era falso, porque ninguém tinha escrito o que aquele verde provava.

Aqui acontece o contrário. O sinal é parcial e mesmo assim é honesto, porque a etiqueta vem colada nele. A diferença entre um proxy e um falso positivo costuma não estar na qualidade do sinal, está em alguém ter escrito o que aquele sinal prova.

3 ressalvas minhas antes de você copiar isso

Proxy sobe de posto sozinho. Hoje é confiança elevada; em 2 semanas alguém lê o log, vê que o deploy passou no critério e trata como verificado, porque o rótulo ficou na conversa e o sinal ficou no log. O rótulo precisa morar junto do sinal, no mesmo lugar em que ele vai ser lido por outra pessoa.

O proxy também só vale enquanto a falha que ele prevê continuar sendo a mesma. Na passagem aparece "conhecendo a mesma divergência de antes", ou seja, o problema já era velho conhecido. Um sinal calibrado para uma falha conhecida não diz nada sobre uma falha nova, e ele não avisa quando saiu de validade.

E aceitar o sinal antecipado é uma decisão sobre risco, que depende do que o deploy toca. O mesmo proxy serve para trocar o texto de um botão e não serve para uma migração de dados. Essa distinção não está no sinal, está em você.

Escreva o rótulo no lugar onde o sinal mora

Quando aceitar um sinal antecipado, escreva 3 coisas no mesmo lugar em que ele aparece, seja o log, o comentário do commit ou o canal onde o deploy é anunciado: o que ele prova, o que ele não prova, e quando a conferência completa ainda vai rodar. A terceira é a que costuma ficar em branco. Se ela não tiver resposta, você não adiou a verificação, cancelou. Num dia de vibe coding esse registro custa uma linha, e é a única parte do processo que continua funcionando quando você não estiver por perto para explicar o critério.

Dá para assistir à live e ver a passagem no meio de tudo que estava quebrando naquele dia.