Entender antes de aprovar: o que faz, por que, é seguro
No texto anterior eu contei como o site foi construído no Antigravity: plano primeiro, 12 etapas, um commit por etapa. Esta parte é outra. Agora o assunto é o clique: o que eu leio antes de dizer sim.
O que eu queria resolver
Trabalho durante o dia e, à noite e aos domingos, construo com agentes de IA. Nunca programei profissionalmente. Um editor com inteligência artificial pede aprovação o tempo todo. Instalar um programa. Copiar um arquivo. Apagar uma pasta. O botão é rápido. O estrago também.
Durante a construção do site eu criei uma regra para o agente do Antigravity. Antes de cada comando que precisa da minha aprovação, explicar em uma ou duas frases três coisas: o que o comando faz, por que é necessário, e se é seguro. Só então eu aprovo.
Junto veio a outra trava. Não usar senha de administrador. Tudo instalado na pasta do usuário.
Eu não queria virar a pessoa que aperta sim no automático.
Resumo rápido
- Antes de cada comando que pede aprovação, o agente explica em uma ou duas frases: o que faz, por que precisa, se é seguro.
- Sem senha de administrador. O trabalho fica na pasta do usuário.
- Aprovar sem entender é o jeito mais comum de um agente fazer estrago.
- Cada aprovação vira uma aula curta. A regra dá para copiar.
Primeiro: o que é um comando (e o que é aprovar)
Comando, neste texto, é um pedido que o computador executa. Instalar. Copiar. Apagar. Gerar as páginas do site.
Aprovação é o momento em que o editor para e espera o humano. No Antigravity isso aparece na tela. Eu opero. O agente não clica por mim.
O Antigravity é o editor de código com inteligência artificial da Google. Eu descrevo o que quero. O modelo sugere arquivos e comandos. Eu leio e decido.
Dá para imaginar alguém na porta com uma caixa. Antes de entrar, diz o que traz, por que precisa entrar, e se aquilo mexe só na caixa ou na casa inteira. Você ouve, olha, e só então abre.
Por dentro é mais seco. O modelo monta o pedido. O editor mostra o pedido e espera. Se eu digo sim, o sistema roda. A analogia da porta para de valer num ponto: a pessoa na porta tem cara. O comando é uma linha. Se você treina o hábito de aprovar sem ler, a linha seguinte pode ser a errada, com a mesma cara de confiança.
Por isso a explicação tem teto: uma ou duas frases. Texto longo a gente pula quando está cansado. Frase curta obriga o agente a escolher o que importa. Se não dá para dizer o essencial nesse espaço, o pedido ainda está confuso. Aí eu não aprovo.
Primeiro: senha de administrador e pasta do usuário
Administrador, no computador, é a conta com permissão para mexer no sistema inteiro. Instalar coisa no miolo da máquina. Mudar configuração que vale para todo mundo que usa aquele computador. Apagar o que não está na sua pasta.
Senha de administrador é a chave dessa conta. Quando um programa pede essa senha, ele está pedindo para sair do seu quarto e entrar no resto da casa.
Pasta do usuário é o cantinho da sua conta no computador. Seus documentos, seus projetos, o que o sistema trata como seu. Um programa instalado ali costuma valer para você, não para o sistema inteiro.
Dá para imaginar a gaveta da mesa, não o quadro de energia do prédio. Você mexe no que é seu.
Por dentro, o sistema de arquivos separa o que é da sua conta do que é do sistema. A analogia da casa ajuda porque o alcance muda: pasta do usuário é o seu espaço; administrador é o prédio. Ela falha num ponto: mesmo no quarto, dá para jogar fora o único caderno. A trava da senha não impede todo erro. Impede o erro de abrir uma porta que o site pessoal não precisava.
A gaveta de papel também não executa nada sozinha. Um comando na pasta do usuário ainda copia, apaga e instala. Por isso as três frases continuam necessárias mesmo sem a senha.
Eu pedi o trabalho sem essa senha. Tudo na pasta do usuário.
O que as três perguntas seguram
A primeira pergunta é o quê. Sem ela, eu aprovo um verbo vazio. “Atualizar” pode ser trocar uma letra ou apagar uma pasta.
A segunda é o porquê. Sem ela, o agente pode estar resolvendo um problema que eu não tenho. Necessário para o pedido que eu fiz, não necessário “porque ficou mais elegante”.
A terceira é se é seguro. Aqui eu leio com desconto. “É seguro” dito pelo próprio agente é a opinião dele, não um laudo. Eu quero o risco em palavras simples: mexe só neste arquivo? pede senha de administrador? apaga alguma coisa? Se a resposta não aponta o risco, eu peço de novo.
Um exemplo do dia a dia: se o pedido for copiar um arquivo do projeto, a explicação precisa dizer de onde, para onde, e que o original permanece. Se não disser, eu recuso.
O que eu usei
Usei o Google Antigravity, comigo no teclado. Usei o agente dali, com a regra escrita: três perguntas, uma ou duas frases. Usei a pasta do usuário, sem senha de administrador.
Não estou colando comando neste texto. O hábito é o ponto, não a linha.
Eu uso a ferramenta. Não estou vendendo o editor. Estou contando a regra que eu impus naquela construção.
Como foi
Se você quiser copiar a regra, o caminho é este:
- Escreva no agente: antes de cada comando que precisa de aprovação, explique o que faz, por que é necessário e se é seguro, em uma ou duas frases.
- Leia as três respostas. Se uma delas for vaga, recuse e peça de novo.
- Confira se o pedido mexe só na pasta do usuário. Se pedir senha de administrador, a resposta é não.
- Aprove um comando de cada vez. Só clique quando você souber repetir, em uma frase, o que vai acontecer.
- Se recusar, diga o motivo. A próxima explicação precisa ser mais clara, não mais longa.
Quando dá certo, eu sei repetir o que vai rodar. Aí eu aprovo. Se não sei, não aprovo.
O que eu aprendi
Não tenho uma história de pasta apagada. Tenho a regra que eu pus para essa história não acontecer.
A lição para quem está começando: cada aprovação vira uma aula curta. Copie a regra das três perguntas para os seus agentes.
Se o agente responde as três perguntas com jargão, eu não aprovo. Sem o risco dito, sobra um “é seguro” que não me serve.
A regra não substitui julgamento. Um comando pode vir com clareza e ainda ser uma má ideia. As três frases me dão material. A decisão continua minha.
Nenhuma dessas ferramentas substitui julgamento. Elas encurtam o caminho entre “eu sei o que quero” e “está no ar”.
O que eu faria diferente: colar a regra no agente no começo do trabalho, não no meio. Ela nasceu durante a construção. Funcionou. Ainda assim, regra de casa fica melhor se existir antes da pressa.
Custos e limites
Nesta parte não há um valor em dinheiro para reportar. A regra não cobra extra. O custo é tempo: ler uma ou duas frases a cada pedido. É pouco perto de desfazer um comando errado.
O que a regra faz bem: obrigar uma pausa. Manter a instalação na pasta do usuário. Transformar cada sim numa aula de uma linha.
O que ela não faz: transformar um comando perigoso em seguro só porque veio com parágrafo. Também não faz o agente merecer senha de administrador. Essa senha, neste jeito de trabalhar, não entra.
Isto é o que eu fiz na construção do site, não um estudo. A frase “aprovar sem entender é o jeito mais comum de um agente fazer estrago” é o critério da escolha. Não é pesquisa publicada.
Para quem serve e para quem não serve
Serve se você usa um editor com IA que pede aprovação e ainda não é programador profissional. Serve se você já apertou sim cansado.
Não serve se você quer mandar um parágrafo e deixar o agente clicar sozinho em tudo. Esse jeito eu recuso.
Também não serve para quem quer a explicação como enfeite. Se você não vai ler, a regra só atrasa o estrago.
Fechamento
Eu queria parar de aprovar no escuro. A regra cabe num recado: o que faz, por que, se é seguro. Sem senha de administrador. Tudo na pasta do usuário.
Não aprove o que você não sabe repetir em uma frase.
No próximo texto eu conto como o trabalho ficou guardado: backup do site e registros no Google Drive.
Se quiser acompanhar a jornada, estou no X: @RodrigoesPorto.
Fontes e links
- Google Antigravity: https://antigravity.google/
- Este site: https://rodrigoesporto.com/