Voltar para o Blog
IA na Prática28 / 50
  1. 01Bem-vindo: o que você vai conseguir fazer no fim desta série
  2. 02O que é uma IA que conversa, em português claro
  3. 03O que dá e o que não dá pra fazer com IA hoje
  4. 04Claude, ChatGPT, Gemini: qual a diferença e por que vamos usar o Claude
  5. 05Os três jeitos de falar com a IA: site, app e terminal
  6. 06A mentalidade certa: você é o maestro, a IA é o instrumento
  7. 07Criando sua conta e instalando o app do Claude
  8. 08Sua primeira conversa: como pedir bem (o prompt)
  9. 09Anexando arquivos, imagens e PDFs
  10. 10Projetos no Claude: guardando contexto que não se perde
  11. 11Artifacts: quando o Claude monta um documento ou um mini-app pra você
  12. 12Memória, instruções e estilo: ensinando o Claude do seu jeito
  13. 13Planos, limites e custo: o que é grátis e quando vale pagar
  14. 14O que é o "terminal" e por que ele não dá medo
  15. 15Abrindo o terminal no Mac e no Windows (e no Linux)
  16. 16Cinco comandos de sobrevivência: pwd, ls, cd, mkdir, cat
  17. 17Como o computador organiza tudo: pastas, arquivos e caminhos
  18. 18Instalando o Node.js (e o que é isso, afinal)
  19. 19npm: a "loja de peças" gratuita do mundo dev
  20. 20Instalando o VS Code: seu editor de código (e por que precisa de um)
  21. 21O que é o Git e por que todo projeto sério usa
  22. 22Criando sua conta no GitHub (a nuvem do seu código)
  23. 23O que é o Claude Code e por que ele é diferente do app
  24. 24Instalando o Claude Code
  25. 25Primeiro login e sua primeira sessão
  26. 26Como o Claude Code "enxerga" suas pastas (e por que isso importa)
  27. 27Sua primeira tarefa real: peça pra ele criar um arquivo
  28. 28Permissões: quando ele pergunta antes de mexer
  29. 29O arquivo CLAUDE.md: ensinando o robô sobre o seu projeto
  30. 30Modo plano e revisão: deixe ele pensar antes de fazer
  31. 31Errou? Desfazendo e recomeçando sem medo
  32. 32Escolhendo um primeiro projeto pequeno e real
  33. 33Descrevendo o que você quer: o briefing
  34. 34Deixe o Claude montar o esqueleto do projeto
  35. 35Rodando o projeto na sua máquina pela primeira vez
  36. 36Mudando textos, cores e imagens só conversando
  37. 37Quando algo quebra: lendo um erro sem entrar em pânico
  38. 38Pedindo pro Claude consertar o erro (copiar, colar, descrever)
  39. 39Adicionando uma página ou funcionalidade nova
  40. 40Salvando seu progresso com Git (commits, sem decoreba)
  41. 41Subindo seu projeto pro GitHub
  42. 42Colocando seu projeto no ar de graça (deploy)
  43. 43A anatomia de um bom pedido (revisão turbinada)
  44. 44Dividir pra conquistar: por que tarefas pequenas vencem
  45. 45Revisar o que a IA fez: a responsabilidade é sua
  46. 46Segurança básica: senhas, chaves e o que NUNCA colar
  47. 47Quando a IA "alucina" e como perceber
  48. 48Aprendendo a aprender com a IA: ela é sua professora particular
  49. 49Cinco ideias de próximos projetos pra praticar
  50. 50Seu novo superpoder: pra onde ir a partir daqui (fecho)
IA na PráticaParte 28 de 50

Permissões: quando ele pergunta antes de mexer

4 min de leitura
Compartilhar
IA na Prática

No post anterior, quando você pediu pra criar o arquivo, apareceu uma telinha pedindo sua confirmação antes de qualquer coisa acontecer. Talvez você tenha aprovado no automático, só pra seguir em frente. Hoje vamos olhar pra ela com calma, porque essa telinha é uma das melhores coisas do Claude Code.

Ela existe pra uma razão simples: você está no controle, sempre.

A ideia: ninguém mexe na sua casa sem pedir

Pense num bom prestador de serviço. Antes de furar a parede, ele te chama: "Posso furar aqui?". Ele não sai furando tudo sozinho. Você vê o que vai ser feito, decide, e só então ele age.

O Claude Code faz igual. Toda vez que ele vai fazer algo que muda alguma coisa — criar um arquivo, editar um arquivo, rodar um comando — ele para e pede licença. Ele nunca altera nada nas suas costas.

Isso é diferente de só conversar. Ler e responder ele faz livremente. Mas agir no seu computador exige seu "sim".

Como é a tela de aprovação

Quando o Claude Code quer fazer uma ação, ele mostra:

  • O que ele pretende fazer, em palavras claras. Por exemplo: "Criar o arquivo notas.md" ou "Editar o arquivo lista.md".
  • O conteúdo ou o comando exato. Se for editar, ele te mostra o "antes e depois". Se for rodar um comando, ele mostra o comando inteiro.
  • As opções de resposta, que costumam ser três:
    • Aceitar uma vez (Yes): ele faz só esta ação agora. Na próxima, pergunta de novo.
    • Aceitar sempre (Yes, and don't ask again): ele faz esta e libera ações parecidas pelo resto da sessão sem perguntar toda hora.
    • Recusar (No): ele não faz. Você pode explicar o que prefere em vez disso.

Você escolhe geralmente com as setas do teclado e Enter, ou digitando a letra/número indicado na tela. Não tem mistério.

Aprovar com consciência

A tentação é apertar "sim" sem ler, igual a gente aceita termos de uso. Resista — pelo menos no começo. O hábito mais valioso que você pode construir aqui é: dê uma olhada no que ele vai fazer antes de aprovar.

Você não precisa entender cada detalhe técnico. Só precisa responder a perguntas simples na sua cabeça:

  • É no arquivo que eu esperava? Se eu pedi pra mexer em notas.md e ele quer editar outro arquivo, pare.
  • A ação faz sentido com o que pedi? Pedi pra adicionar uma meta e ele quer apagar o arquivo inteiro? Pare.
  • É na minha pasta de projeto? Se aparecer um caminho estranho, fora do seu cômodo, desconfie.

Na imensa maioria das vezes vai estar tudo certo e você aprova tranquilo. Mas esse meio segundo de leitura é o que te mantém dono da situação.

Sobre o "aceitar sempre"

O "aceitar sempre" é cômodo: você para de ser interrompido a cada passo. É ótimo quando você já confia na tarefa e quer fluidez — por exemplo, num projeto pequeno e sem risco onde ele vai criar vários arquivos parecidos.

Mas use com cabeça. No começo, enquanto você está aprendendo a ler o que ele propõe, prefira o "aceitar uma vez". Você troca um pouquinho de velocidade por muito aprendizado e controle. Conforme ganha confiança, libera mais.

Quando recusar

Recusar não é "dar errado" — é parte normal do trabalho. Recuse quando:

  • A ação não bate com o que você pediu.
  • Ele vai mexer num arquivo que você não quer que ele toque.
  • Você simplesmente mudou de ideia.
  • Apareceu um comando que você não reconhece e prefere perguntar antes.

Ao recusar, aproveite pra explicar: "Não, não apague o arquivo. Em vez disso, só acrescente uma linha no final." Ele se ajusta e propõe de novo. Recusar é conversar, não brigar.

Por que isso é tão bom

A grande vantagem: você nunca é pego de surpresa. Nada acontece no seu computador sem você ver e autorizar. Isso te dá liberdade pra experimentar sem medo. Pode pedir coisas ousadas, porque você sabe que vai haver um portão de aprovação antes de qualquer mudança real. O robô propõe; você decide.

Se algo der errado

  • Aprovei "sempre" e agora ele faz tudo sem perguntar. Sem pânico — isso vale só para a sessão atual. Feche o Claude Code (digite exit) e abra de novo: ele volta a pedir confirmação. Nada foi quebrado de forma permanente.
  • Recusei e não sei como continuar. É só escrever o que você quer em palavras. A recusa não trava nada; a conversa segue normalmente.
  • A tela some rápido demais pra eu ler. Você não é obrigado a responder rápido. Leia com calma; ele espera o tempo que precisar antes de você escolher.

No próximo post, vamos dar um superpoder ao seu projeto: o arquivo CLAUDE.md, onde você escreve as "regras da casa" que o Claude Code lê sozinho toda vez. É como deixar um manual pronto pro seu ajudante.

Curtiu como a gente pensa?

É assim que trabalhamos todo dia.

Se esse jeito de pensar é o seu, vem construir com a gente — dá uma olhada nas vagas abertas.

Ver vagas