Existe uma ferramenta open-source chamada Pake que faz algo enganosamente simples: pega qualquer URL e a transforma em uma aplicação desktop independente. Não um atalho de navegador disfarçado de app — uma janela nativa real, com seu próprio ícone, perfil e pegada de memória. Construída em Rust e Tauri, ela usa a WebView nativa do sistema operacional em vez de empacotar uma instância inteira do Chromium. O resultado pesa uma fração de um app Electron.

É engenharia limpa. Mas o interessante não é a ferramenta em si. É o que ela revela sobre uma lacuna no cenário atual de IA — uma lacuna que está prestes a fechar.

A pergunta sobre formato que ninguém está fazendo

Hoje, o modelo de interação dominante com IA é conversacional. Você digita, o modelo responde. Às vezes ele escreve código. Às vezes gera uma imagem. Ocasionalmente chama uma ferramenta ou executa um script. Mas a saída é quase sempre texto fluindo por uma interface de chat, ou no máximo um arquivo depositado em um diretório.

Considere o que o Pake faz por outro ângulo. Ele resolve um problema de formato. O conteúdo — uma aplicação web — já existe. O que falta é o contêiner certo: uma janela desktop em vez de uma aba de navegador. A inteligência necessária é mínima; o valor criado é real. Qualquer pessoa que já se afogou em trinta abas abertas tentando usar três ferramentas web simultaneamente entende isso instantaneamente.

Agora imagine um agente de IA que raciocina não apenas sobre o que produzir, mas sobre como empacotar. Um agente que, dada uma tarefa, consegue decidir se a resposta deveria ser um utilitário de linha de comando, um widget de desktop, uma extensão de navegador, um daemon de notificações, uma API local, um relatório em PDF ou uma aplicação interativa completa — e então construir a opção apropriada.

Isso é auto-instrumentação. E é a capacidade mais subdesenvolvida na geração atual de agentes de IA.

Software como variável, não como categoria

Passamos décadas tratando tipos de aplicação como categorias fixas. Você constrói um web app ou um app mobile ou uma ferramenta CLI. Cada um exige frameworks diferentes, modelos de distribuição diferentes, expertise diferente. A categoria é decidida cedo e raramente questionada.

Mas as categorias são artificiais. São artefatos de restrições de distribuição e economia de desenvolvimento, não de necessidades do usuário. Um painel de clima não precisa ser um web app — ele precisa mostrar a previsão. Se isso acontece em uma aba do navegador, um widget na barra de menu, um comando no terminal ou um briefing matinal no seu e-mail é uma decisão de empacotamento, não arquitetural.

Quando você dá a um agente a capacidade de raciocinar sobre formato — de tratar o tipo de aplicação como uma variável em vez de uma constante — o espaço de design explode. A mesma lógica subjacente (buscar dados climáticos, aplicar preferências do usuário, formatar saída) pode se materializar como software inteiramente diferente dependendo do contexto, dispositivo e fluxo de trabalho individual.

Isso não é hipotético. Cada componente já existe. LLMs geram código funcional em qualquer linguagem mainstream. Frameworks como Tauri, Electron e toolkits nativos de plataforma são bem documentados o suficiente para serem alvos de geração de código. APIs de extensões de navegador, utilitários de bandeja do sistema, frameworks CLI — tudo ao alcance de um modelo capaz. A peça faltante é a camada de raciocínio que conecta a necessidade real do usuário ao formato de saída correto.

Personalização em uma resolução que não existia

A implicação vai além de conveniência. Ela muda a unidade de distribuição de software.

Software tradicional serve milhões de usuários com uma interface. Customização existe, mas dentro dos limites que o desenvolvedor antecipou. Você pode trocar temas, alternar funcionalidades, reorganizar painéis. Você não pode alterar fundamentalmente o que a aplicação é.

Agentes de auto-instrumentação dissolvem essa restrição. A aplicação é gerada, não distribuída. Pode ser moldada ao fluxo de trabalho, preferências e contexto de um único usuário — não como uma camada de configuração sobre um produto genérico, mas como um artefato distinto construído do zero. Dois usuários com a mesma necessidade subjacente podem receber aplicações inteiramente diferentes: um recebe uma ferramenta CLI dirigida por teclado porque vive no terminal; outro recebe um dashboard visual porque pensa espacialmente. Nenhuma é uma versão degradada de algum app canônico. Cada uma é a ferramenta certa para seu usuário.

Isso é personalização em uma resolução que nunca foi economicamente viável. Construir software sob medida para usuários individuais exigia ou orçamentos enormes ou aceitar as limitações de plataformas no-code. Agentes que raciocinam sobre formato e geram ferramentas sob medida tornam isso viável a custo marginal.

Os agentes ainda não chegaram lá — mas a trajetória é clara

Assistentes de código com IA atuais são impressionantes, mas cegos para formato. Eles escrevem qualquer código que você pedir, em qualquer framework que especificar. A escolha de o que construir — web app, script, extensão, widget — permanece inteiramente com o usuário. O agente preenche a implementação; o humano decide a forma.

O próximo passo são agentes que participam dessa decisão. Diante de "preciso monitorar três preços de ações durante meu dia de trabalho", um agente de auto-instrumentação avaliaria a plataforma do usuário, padrões de fluxo de trabalho e preferências de notificação — e então produziria um widget de barra de menu, ou um monitor de terminal, ou um e-mail agendado, dependendo de qual formato realmente se encaixa. O formato se torna parte da solução, não um pré-requisito para fazer a pergunta.

Várias tendências convergentes aceleram isso. Frameworks multiplataforma estão amadurecendo — o Tauri 2.0, por exemplo, constrói desktop e mobile a partir de uma única base de código com performance nativa. WebAssembly permite execução quase nativa em qualquer ambiente. Function calling e tool use de LLMs fornecem a infraestrutura para agentes interagirem com sistemas de build, gerenciadores de pacotes e alvos de deploy. E os próprios modelos continuam melhorando em geração sustentada de código multi-arquivo.

O problema mais difícil é bom gosto. Escolher o formato certo exige entender não apenas a tarefa, mas o usuário — seus hábitos, seu ambiente, sua tolerância para complexidade. É onde a auto-instrumentação se cruza com o desafio mais amplo de personalização de agentes: o sistema precisa modelar o usuário, não apenas o problema.

O que isso significa

O Pake é uma chave inglesa bem feita. Resolve uma tradução de formato específica — web para desktop — e faz isso com elegância. Mas o padrão que ele representa é muito mais geral. A capacidade de remodelar software em torno de necessidades individuais, de tratar o formato da aplicação como uma decisão de design feita em tempo de execução e não na concepção do projeto — é uma capacidade que agentes estão posicionados de forma única para entregar.

Ainda não chegamos lá. Mas os componentes estão no lugar, a economia é favorável e a necessidade do usuário é óbvia para qualquer pessoa que já desejou que suas ferramentas se adaptassem ao seu fluxo de trabalho, e não o contrário.

A era do software tamanho-único tem sido longa. Ela está terminando não por causa de um novo framework ou plataforma, mas porque o construtor está se tornando algo que entende para quem está construindo.

Marcelo Kanhan escreve sobre tecnologia, IA e o futuro do trabalho. marcelo@collecto.com.br