Pegue uma interação real e acompanhe do começo ao fim, porque o discurso abstrato — "um assistente que age, não só responde" — não diz nada até você ver acontecer. Alguém digita "cria um rastreador de hábitos com sequências" no botão Ask-AI que flutua em todas as páginas deste site. Aqui está o que de fato acontece entre essa frase e um build em execução, e onde escolhemos devolver o controle às mãos de uma pessoa.
A frase
Nove palavras, sem pontuação, sem navegação por menus, sem ideia nem de em qual página o builder está. Essa é a entrada, e tem o mesmo formato da maioria dos pedidos que essa ferramenta recebe: não é um comando, é um desejo. Ninguém formula assim: "abra o builder, nomeie o projeto Rastreador de Hábitos, preencha o campo de prompt com uma descrição de rastreamento de sequências e coloque o foco no botão de início". As pessoas simplesmente dizem o que querem que exista. A diferença entre essas duas formulações — desejo versus instruções — é toda a funcionalidade.
A interpretação
Seja qual for o idioma em que essa frase chega, ela é tratada nesse mesmo idioma — oferecemos suporte a vinte idiomas em todo o produto, alinhado com a postura multilíngue mais ampla da plataforma, e o assistente não está rodando uma camada de tradução sobre um roteiro fixo em inglês, ele raciocina nativamente em qualquer idioma que você digitar. Especificamente para "rastreador de hábitos com sequências", a interpretação precisa fazer três coisas ao mesmo tempo:
- Reconhecer que isso é um pedido de build, não uma pergunta
- Extrair um nome de projeto
- Extrair especificações suficientes para que o campo de prompt não fique em branco
Errar qualquer um desses pontos faz o usuário cair em um builder que não corresponde ao que ele pediu, o que é pior do que não fazer nada — agora ele precisa perceber a divergência, corrigi-la e recomeçar.
A tela pré-preparada
Essa é a parte fácil de subestimar em uma demonstração e fácil de errar na prática: ela não inicia o build. Ela abre o builder com o projeto nomeado, o campo de prompt já preenchido e a execução pronta a um clique de distância. Esse é um ponto de parada deliberado, não um atalho que deixamos incompleto por falta de tempo. Abrir uma página e pré-preencher um formulário tem baixo custo de erro — na pior das hipóteses, você edita o texto ou fecha a aba. Então o assistente simplesmente faz isso, sem diálogo de confirmação, sem "tem certeza que quer navegar".
O clique que ainda era seu
Iniciar o build é uma categoria diferente, porque iniciar o build gasta créditos — créditos reais, debitados da sua conta no momento em que a execução começa. É aí que entra a regra da proporcionalidade:
| Tipo de ação | O que acontece |
|---|---|
| Baixo custo de reverter — navegação, texto pré-preparado | Acontece automaticamente, sem confirmação |
| Gasta dinheiro ou processamento real — iniciar o build | Espera um clique deliberado seu |
Chegamos a esse ponto depois de ir e voltar bastante na decisão, e admito que nenhum dos extremos parecia obviamente certo. Confirmar tudo e você recriou a antiga experiência de clicar em três menus, só que com uma janela de chat acoplada por cima, o que é pior do que aquilo que substituiu. Não confirmar nada e, eventualmente, a interpretação erra em um pedido ambíguo e dispara uma execução que ninguém pediu, com o dinheiro de outra pessoa. Para este exemplo específico, isso significa: o assistente te leva ao builder já carregado em uma única etapa, e o botão que de fato gasta algo continua sendo um clique real, deliberado e humano.
A infraestrutura por trás
Uma coisa que você não vê em nenhum ponto desse fluxo, e é exatamente por isso que importa: cada parte dele — a navegação, o prompt pré-preparado, o build eventual — acontece dentro do seu workspace e de mais nenhum outro. O assistente não pode ser convencido a acessar dados de outros tenants, não importa como o pedido seja formulado, porque ele não é um recurso especial de chat que funciona fora do sistema de permissões — mecanicamente, ele é só mais um agente na plataforma, rodando sob o mesmo limite por conta que todo outro agente respeita. Não existe uma pergunta separada do tipo "o chatbot consegue ver isso", porque a resposta já foi decidida pela infraestrutura antes mesmo da funcionalidade de chat existir.
O que não acontece
Levando esse mesmo exemplo um passo adiante, você chega ao limite do que o assistente fará sem ser solicitado, e vale a pena ser específico sobre onde esse limite está. Ele vai abrir o builder para você. Além disso:
- Ele não vai gastar além do que você já aprovou
- Ele não vai publicar o projeto finalizado em nenhum lugar em seu nome
- Ele não vai realizar nenhuma ação que saia do sandbox do seu próprio workspace e toque o mundo exterior
Toda essa categoria não tem um caminho conduzido pelo assistente — não é uma confirmação mais rigorosa, não é um caminho, ponto final. Se você quer tornar um projeto público, esse continua sendo um botão que você mesmo precisa encontrar e clicar, como sempre foi.
Por que os pontos de parada estão onde estão, e não em algum lugar mais "seguro"
Poderíamos ter feito com que cada uma dessas etapas pedisse permissão e chamado isso de cautela. Não acho que isso seria cautela — acho que seria uma versão mais lenta exatamente do trabalho manual que essa funcionalidade existe para eliminar. Um chatbot que só descreve onde fica o botão de build tem um raio de impacto pequeno quando erra: desperdiça trinta segundos, você fica levemente irritado, nada foi gasto. Um assistente que prepara um build real erra de forma mais custosa se as proteções não estiverem corretas, e essa é a razão real pela qual existe a linha de confirmar-antes-de-gastar — não como uma salvaguarda que adicionamos para parecer responsável, mas porque observamos onde o modo de falha aterrissaria e colocamos a parada exatamente ali. Tudo antes dessa linha — ler a frase, preparar a tela, deixar você a um clique de terminar — não precisava de permissão nenhuma, porque nada disso pode te prejudicar.
