
O último obstáculo da codificação assistida por IA é um formulário de cadastro
A IA tornou a maior parte do meu desenvolvimento solo de duas a três vezes mais rápido. Agora, eu passo meu tempo em decisões de produto, não em boilerplate — o agente escreve a integração, a migração, o teste. Mas há uma parte do ciclo que ele continuava me devolvendo, e isso quebrava meu fluxo toda vez.
Você conhece o momento. Você pede um e-mail, ou notificações push, ou um banco de dados. O agente escreve a integração em trinta segundos e então para:
Adicione sua RESEND_API_KEY ao .env.
Então eu alterno para fora do editor, encontro o painel, me inscrevo, clico no onboarding, verifico um e-mail, crio uma chave de API, copio, colo em um .env — e agora há um segredo ativo em texto simples que eu tenho que lembrar de não cometer, e que o agente esquece e me pergunta novamente na próxima sessão. Todo serviço. Todo projeto. É o último gargalo manual na codificação assistida por IA, e por um tempo foi a única barreira que o agente não conseguia ultrapassar para mim.
Eu tentei as ferramentas óbvias primeiro — Operator da OpenAI, uso de navegador, algumas outras. Elas podem controlar um navegador, mas foram construídas como bots autônomos de propósito geral, e essa não é a forma do problema. Eu não quero assistir a um agente se inscrevendo para o Resend. E na prática, elas travariam em fluxos de inscrição reais de qualquer maneira. A percepção que eventualmente cheguei: o agente de codificação que eu já tenho (Claude Code, Codex, seja o que for) é um planejador perfeitamente bom. O que falta é um driver — um navegador escopado e um lugar seguro para colocar o que ele encontra.
Então eu construí esse driver. Isso se transformou em dois problemas de engenharia genuinamente difíceis, e o segundo é o que eu realmente me importo.
Problema 1: passando pela porta
O SaaS moderno não quer um bot preenchendo seu formulário de inscrição. Cloudflare Turnstile, Stytch, Clerk, DataDome — as páginas de inscrição agora são algumas das superfícies mais agressivamente protegidas contra bots na web. Isso se tornou um buraco de coelho de várias semanas, e a coisa mais útil que posso compartilhar é o quão errado eu estava, repetidamente.
Toda vez que uma inscrição foi bloqueada, eu tinha uma teoria confiante:
"É a reputação do IP." IP de datacenter, obviamente sinalizado. Falsificado: um IP residencial novo falhou da mesma forma.
"É a impressão digital / sem GPU." Headless Chromium não tem GPU real, diz em todo lugar. Falsificado: um laptop real com uma GPU real e um display real falhou da mesma forma.
"São os sinais de automação de nível CDP." navigator.webdriver, Runtime.enable, isolamento do mainWorld. Este foi real, mas não suficiente — eu mudei para patchright, um fork do Playwright que fecha os sinais CDP que os plugins stealth não conseguem, e melhorou as coisas, mas ainda não limpou o Turnstile.
Eu continuei re-derivando "é o ambiente" e continuava sendo provado errado por experimentos. A disciplina que eventualmente me salvou foi escrever cada hipótese falsificada em um STATE.md — formular uma hipótese, nomear o experimento que a falsificaria, executá-lo, registrar o resultado. Lê-se como um cemitério, e isso me impediu de repetir as mesmas três respostas erradas repetidamente.
A verdadeira causa da barreira do Turnstile, quando finalmente executei uma matriz controlada, era quase estúpida: launchPersistentContext do Playwright. Não era o IP, não era a GPU, não era a impressão digital. A forma como o Playwright inicia e se conecta a um perfil de navegador persistente é um sinal detectável. A solução foi iniciar um processo normal do Chrome e se conectar via CDP (connectOverCDP) em vez de deixar o Playwright iniciá-lo. Mesmo IP, mesma máquina, mesma impressão digital — token emitido.
O restante da camada anti-bot é menos surpreendente, mas merece seu lugar: simulação de comportamento para desafios invisíveis/classificados (caminhos de mouse em curva bezier, velocidade de digitação variável com pausas de pensamento, permanência pós-carregamento), clique-e-espera para desafios de checkbox visíveis, e — porque o headless Chromium é bloqueado à vista — rodando em modo visível contra um display virtual sob demanda (Xvfb) para que haja uma superfície real para renderizar, que o usuário nunca vê.
Nada disso é uma "barreira." Cada bloqueio que eu chamei de barreira acabou sendo um sinal específico e corrigível. Essa mentalidade — um bloqueio é um problema de diagnóstico, não um terreno — é a maior parte do trabalho.
Problema 2: mantendo a chave uma vez que você a tem
Esta é a parte para a qual eu realmente construí a coisa. Obter a chave é um meio; a questão interessante é onde ela vai.
A resposta padrão — um arquivo .env — é genuinamente ruim, e todos que estão lendo isso já sentiram isso. Arquivos .env são comprometidos no GitHub. Eles se perdem. Eles são colados em três serviços e rotacionados em nenhum deles. E na era da codificação assistida por IA, há um novo pior cenário: a chave da API acaba na janela de contexto do agente, que é o único lugar menos contido que um segredo pode estar.
Então, o princípio de design é: o segredo bruto nunca é devolvido ao agente, e nunca vai parar no seu repositório. Concretamente —
O cofre é somente para gravação. Quando o driver extrai uma chave do painel, ela vai diretamente para um armazenamento criptografado. O agente não pode lê-la de volta. Não há deliberadamente uma API de "me traga o texto simples" — se você quiser o valor para um .env, você o lê do cofre da web você mesmo.
Quando seu código precisa da chave, ele não obtém o valor — ele faz a chamada através de um proxy. Você escreve ${SECRET} na solicitação; o proxy injeta a chave real no lado do servidor na fronteira de saída e retorna apenas a resposta upstream. O segredo atravessa a rede para o provedor, nunca para você.
Para um aplicativo implantado (ou um loop de agente CLI), você cria uma concessão de saída: um token escopado, limitado por taxa e instantaneamente revogável. O aplicativo chama o provedor segurando isso, não a chave real. Assim, o cofre deixa de ser uma pasta de texto simples e se torna um plano de controle — rotacione uma chave uma vez e cada concessão a pega; algo vaza e você revoga a concessão, a próxima chamada falha, sem correria de re-rotações.
A parte da qual estou mais silenciosamente orgulhoso é a configuração de múltiplos consoles — coisas como conectar o Google OAuth, onde você cria um cliente no console GCP e depois cola seu segredo em um console diferente. O driver captura o segredo no console A, o sela na sessão (um identificador, não o valor) e o digita no console B — e o segredo nunca se materializa no contexto do agente ou na transcrição do chat em nenhum momento. Essa transferência selada na sessão é o que faz a afirmação "o modelo nunca vê isso" realmente se sustentar em um fluxo real de múltiplos passos, em vez de ser verdadeira apenas para o trivial caso de uma única página.
A parte que se acumula
Mais uma coisa que acabou se mostrando mais importante do que eu esperava: a primeira inscrição bem-sucedida para um determinado serviço é destilada em uma receita reexecutável e publicada em um registro compartilhado. Na próxima vez que alguém provisionar esse serviço, ele reproduz a receita em cerca de trinta segundos, em vez de o agente reconfigurar o fluxo do zero (que é mais como seis minutos de controle de navegador). Fica mais rápido quanto mais é usado, o que é uma propriedade agradável para algo cujo trabalho é remover uma tarefa.
O que ainda é difícil (porque é)
Eu preferiria te contar as bordas do que você as encontrar:
Funciona melhor com inscrições OAuth (Google/GitHub), que é a maior parte do SaaS moderno que eu busco, mas não todo ele.
Alguns serviços ainda ganham — os mais pesados conjuntos de captcha, portões de verificação de número de telefone, os painéis anti-bot mais agressivos. Quando a inscrição manual é realmente a chamada realista, eu tento dizer isso em vez de fingir.
Links mágicos de uso único são uma corrida — o link pode expirar entre a chegada e o clique, e isso é parcialmente a semântica do provedor, não algo que eu posso cobrir totalmente.
A invalidação de sessão de IP de datacenter é uma realidade operacional contínua.
Está em beta, e gratuito durante a beta.
A forma disso
A depuração anti-bot foi a coisa mais instrutiva que fiz em um tempo, e o cofre somente para gravação + proxy de injeção + modelo selado na sessão parece a forma certa para segredos em um mundo de agentes.
Trusty Squire
Empresas brasileiras que utilizam IA para desenvolvimento de software podem enfrentar desafios com cadastros em serviços. A solução apresentada pode otimizar o fluxo de trabalho e aumentar a segurança no manuseio de chaves de API, essencial para a proteção de dados.


