Vibe coding para dar permissão pontual ao agente sem virar regra

Uma permissão que vale "só agora" só é pontual se alguma coisa expirar sozinha. Quando a chave que você entrega ao agente continua valendo depois que a tarefa acabou, o "só agora" existe apenas na cabeça de quem falou.

Thiago encostou nessa fronteira ao vivo. O trabalho travou numa etapa que exigia publicar a versão nova, e ele perguntou, com alguma irritação, se o agente não podia fazer aquilo por ele em vez de sobrar tudo na mão dele. A resposta do agente foi melhor que um "não consigo":

"Precisa de duas coisas suas[:] credencial [...] e o login [...] nesta máquina. Frase explícita. Pode fazer push [e] deploy. Regra do rep[o] [é] não [fazer] sozinho. Sem isso, o caminho [na] unha é o único que resta. Não por preguiça, por falta de chave, autorização."

Um bloqueio bem nomeado devolve a decisão para você

O valor dessa resposta está em separar incapacidade de falta de autorização. A capacidade existe, e o que falta é uma chave e uma frase explícita de quem manda. O agente ainda citou uma regra do próprio projeto que o proíbe de publicar sozinho ali, ou seja, o freio não era técnico, era combinado.

Isso muda o que o humano faz no minuto seguinte. Com um "não consigo" na tela, você procura outro caminho ou vai na unha, sem saber direito o que está no meio do caminho. Saber que falta chave e falta autorização coloca uma decisão na sua mão: liberar ou não liberar.

Autorizar a ação e recusar o precedente na mesma frase

"Pode fazer push [e] deploy só agora. Não precisa virar regra, eu permito nesse momento apenas"

Ele liberou a ação e recusou o precedente sem precisar de 2 conversas para isso. Boa parte de quem faz vibe coding libera e depois esquece que liberou. Distinguir "eu topo isso agora" de "isso passa a ser assim" é o que impede uma exceção de virar mudança silenciosa no padrão do projeto.

O que o "só agora" não alcança no vibe coding

Permissão pontual é uma promessa sobre intenção. Credencial não tem intenção. Se o "só agora" é concedido entregando uma credencial de longa duração, o acesso continua valendo semanas depois, quando ninguém mais lembra da conversa. A intenção durou o tempo da tarefa, e o poder dura até alguém revogar.

Para a concessão ser pontual de verdade, alguma coisa precisa expirar. Ou a credencial é de curta duração e morre sozinha pouco depois da tarefa, ou ela é revogada assim que a tarefa termina, e revogar vira parte do fim da tarefa em vez de uma boa intenção para depois. Sem uma dessas 2 coisas, você combinou uma exceção e configurou uma regra. Isso aparece também em vibe coding para separar tela de aprovar e tela de publicar. O mesmo cuidado reaparece em contextos técnicos, como em vibe coding para agente que diz que salvou mas não salvou no lugar certo: quando o lugar onde o dado mora não está documentado, cada agente adivinha, e você acaba com 2 armazenamentos para a mesma coisa. E em contextos de orçamento, como em vibe coding para restringir modelo e conta de ia para o squad: quando ninguém define qual família de modelo ou qual conta, o agente escolhe, e o custo sai de onde você não vê. O mesmo problema apareceu em vibe coding para monitorar memoria ao rodar varios workers em paralelo.

Escopo primeiro, duração depois

Antes de perguntar por quanto tempo, pergunte quanto poder. Uma credencial que resolve exatamente aquela tarefa e nada além causa menos estrago em uma semana do que uma credencial ampla causa em uma hora. O critério é o poder mínimo que destrava o problema, sem margem guardada para o caso de precisar depois. Vale ver como isso funciona em vibe coding para separar formato visual da estrutura do conteudo. Vale ver como isso terminou em vibe coding para ver previa da legenda sem renderizar tudo.

Escopo mínimo tem menos a ver com desconfiar do agente e mais com entender como ele se comporta. Em outro caso do acervo, um builder mostra por que vale ter um agente que implementa separado do agente que valida: um agente com missão de implementar faz de tudo para cumprir a missão, inclusive apagar o que atrapalha. Agente com missão e credencial na mão usa a credencial. Esse é o argumento a favor do escopo mínimo, e ele pesa mais ainda quando a permissão saiu às pressas para destravar um trabalho parado.

Exceção que ninguém anota vira precedente

O último pedaço é o que ninguém lembra na hora: escrever a exceção. Uma exceção que não fica registrada em lugar nenhum não some, ela só perde a explicação. Meses depois, alguém abre a configuração do projeto, encontra um acesso ligado e não faz ideia se aquilo ainda precisa estar ligado. Sem saber por que foi liberado, ninguém se sente autorizado a desligar, e o acesso fica.

Anotar custa uma linha: o que foi liberado, para qual tarefa, quando expira ou quem revoga. É a mesma disciplina que faz o vibe coding render fora do improviso, escrever a decisão enquanto ela ainda faz sentido para você. O agente fez a parte dele quando citou a regra do repositório em voz alta; o registro é o equivalente humano disso. O mesmo padrão reaparece em vibe coding para usar ia como rascunho de contador e advogado, onde decisões provisórias precisam de data de revisão escrita.

O que fazer na próxima vez que o agente pedir permissão

Quando um agente travar por falta de autorização e avisar com essa clareza, decida o escopo antes de qualquer outra coisa: o menor poder que resolve aquela tarefa. Depois, defina como a permissão acaba, com uma credencial de curta duração ou com um compromisso de revogar que fica marcado junto com a tarefa, fora da sua memória. E deixe escrito o que você liberou e por quê, porque a pergunta difícil daqui a alguns meses vai ser exatamente essa.

Quem quiser ver a cena inteira pode assistir à live. A decisão do Thiago de delimitar já é melhor que a média do vibe coding feito às pressas. Falta a parte que nenhuma frase resolve sozinha: fazer o acesso acabar quando a intenção acabou.