Vamos acompanhar uma interação real do início ao fim, porque o discurso abstrato — "um assistente que age, não só responde" — não diz nada até se ver acontecer. Alguém escreve "cria-me um rastreador de hábitos com sequências" no botão Ask-AI que flutua em todas as páginas deste site. Eis o que acontece na realidade entre essa frase e uma construção em execução, e onde optámos por devolver a decisão a uma mão humana.
A frase
Nove palavras, sem pontuação, sem navegação por menus, sem sequer saber em que página vive o construtor. Este é o input, e tem a mesma forma da maioria dos pedidos que este sistema recebe: não é um comando, é um desejo. Ninguém formula assim: "abre o construtor, dá ao projeto o nome Rastreador de Hábitos, preenche o campo de prompt com uma descrição do acompanhamento de sequências, e coloca o foco no botão de iniciar". Dizem simplesmente o que querem que exista. O espaço entre estas duas formulações — desejo versus instruções — é toda a funcionalidade.
A análise
Seja qual for a língua em que essa frase chega, é tratada nessa língua — suportamos vinte no produto, alinhado com a postura multilingue mais ampla da plataforma, e o assistente não está a correr uma camada de tradução sobre um guião fixo em inglês, está a raciocinar nativamente naquilo que escreveu. Para "rastreador de hábitos com sequências" especificamente, a análise tem de fazer três coisas ao mesmo tempo:
- Reconhecer que se trata de um pedido de construção, não de uma pergunta
- Extrair um nome de projeto
- Extrair especificações suficientes para que o campo de prompt não fique em branco
Se falhar em qualquer uma destas coisas, o utilizador chega a um construtor que não corresponde ao que pediu, o que é pior do que não agir de todo — agora tem de reparar na discrepância, depois corrigi-la, e recomeçar.
O ecrã pré-preparado
Esta é a parte que é fácil de subestimar numa demonstração e fácil de fazer mal na prática: não inicia a construção. Abre o construtor com o projeto já nomeado, o campo de prompt já preenchido, e a execução pronta a um clique de distância. Este é um ponto de paragem deliberado, não um atalho que ficou por concluir por falta de tempo. Abrir uma página e pré-preencher um formulário tem um custo baixo de estar errado — no pior dos casos, edita o texto ou fecha o separador. Por isso o assistente simplesmente fá-lo, sem caixa de confirmação, sem "tem a certeza de que quer navegar".
O clique que continuou a ser seu
Iniciar a construção é uma categoria diferente, porque iniciar a construção gasta créditos — reais, debitados da sua conta no momento em que a execução arranca. É aí que entra a regra proporcional:
| Tipo de ação | O que acontece |
|---|---|
| Fácil de anular — navegação, texto pré-preparado | Acontece automaticamente, sem confirmação |
| Gasta dinheiro ou capacidade de computação real — iniciar a construção | Aguarda um clique deliberado da sua parte |
Chegámos a este ponto depois de muito ir e vir sobre o assunto, e admito que nenhum dos extremos parecia obviamente certo. Confirmar tudo e reconstrói-se a velha experiência de clicar por três menus, agora com uma janela de chat colada por cima, o que é pior do que aquilo que substituiu. Não confirmar nada e, eventualmente, a análise adivinha mal um pedido ambíguo e dispara uma execução que ninguém pediu, à custa de outra pessoa. Para este exemplo em concreto, isso significa: o assistente leva-o ao construtor já carregado numa única ação, e o botão que realmente gasta algo continua a ser um clique humano, real e deliberado.
O trilho por baixo
Uma coisa que não conseguimos ver em lado nenhum deste fluxo, e é precisamente por isso que importa: cada parte dele — a navegação, o prompt preparado, a compilação final — acontece dentro do seu espaço de trabalho e de mais nenhum. O assistente não pode ser convencido a aceder a outros clientes, por mais que o pedido seja formulado, porque não é uma funcionalidade de chat especial fora do sistema de permissões — mecanicamente, é apenas mais um agente na plataforma, a funcionar sob a mesma fronteira por conta que todos os outros agentes seguem. Não existe uma questão separada sobre "será que o chatbot consegue ver isto", porque a resposta já tinha sido decidida pela infraestrutura antes mesmo de a funcionalidade de chat existir.
O que não acontece
Se seguir este mesmo exemplo mais um passo, chega ao limite do que o assistente fará sem intervenção sua, e vale a pena ser específico sobre onde esse limite se situa. Ele abre o construtor por si. Além disso:
- Não vai gastar além do que já aprovou
- Não vai publicar o projeto terminado em lado nenhum em seu nome
- Não vai realizar nenhuma ação que saia do sandbox do seu próprio espaço de trabalho e toque no mundo exterior
Essa categoria inteira não tem um caminho conduzido pelo assistente — nem uma confirmação mais rigorosa, nem qualquer caminho. Se quiser tornar um projeto público, isso continua a ser um botão que procura e prime você mesmo, tal como sempre foi.
Porque é que os pontos de paragem estão onde estão, e não algures mais seguro
Poderíamos ter feito com que cada um destes passos pedisse permissão e chamado a isso cautela. Não creio que isso fosse cautela — creio que seria uma versão mais lenta exatamente do trabalho repetitivo que a funcionalidade existe para eliminar. Um chatbot que apenas descreve onde está o botão de construir tem um raio de impacto pequeno quando erra: desperdiça trinta segundos, fica ligeiramente incomodado, nada é gasto. Um assistente que prepara uma compilação real erra de forma mais dispendiosa se as salvaguardas não estiverem certas, e é essa a verdadeira razão pela qual existe a linha de confirmar-antes-de-gastar — não como uma proteção que acrescentámos para parecer responsável, mas porque observámos onde o modo de falha iria cair e colocámos a paragem exatamente ali. Tudo antes dessa linha — ler a frase, preparar o ecrã, ficar a um clique de terminar — não precisava de qualquer permissão, porque nada disso o pode prejudicar.
