nokode - Se o LLM consegue fazer tudo, por que escrever código? (experimento com web app)

• Um experimento que construiu um servidor web sem nenhuma lógica de aplicação, deixando o LLM processar todas as requisições
  • O servidor apenas recebe a requisição HTTP e pergunta ao LLM “o que deve ser feito?”, e o LLM faz todo o resto
• O servidor executa funções de CRUD usando apenas três ferramentas: database, webResponse e updateMemory
• O LLM faz sozinho o design do schema SQL, a geração de HTML e JSON e a incorporação de feedback, implementando um app básico de gerenciamento de contatos
• O tempo de resposta é de 30 a 60 segundos, o custo é 100 a 1000 vezes maior que o de um web app tradicional, e há problemas de consistência da UI e de memória
• Mesmo assim, mostra a possibilidade de implementar um app CRUD completo funcionando sem código, sugerindo que o próprio código pode ser um conceito transitório

---

Contexto

• Tudo começou com uma ideia meio fantasiosa (Shower Thought): “um dia não vamos mais precisar escrever código”
  • No futuro, os LLMs poderiam processar entradas em tempo real e gerar vídeo a 120fps, tornando possível uma computação puramente baseada em intenção, sem apps nem código
• Na prática, isso ainda está mais para ficção científica, mas durante um fim de semana o autor decidiu testar por conta própria até onde a tecnologia atual consegue chegar
• A hipótese do experimento já partia da expectativa de fracasso
  • Enquanto a maior parte da IA está focada em gerar código (como Claude Code, Cursor, Copilot etc.),
    o projeto foi criado para validar outra perspectiva: “e se a geração de código fosse completamente eliminada?”
• O resultado foi um servidor HTTP sem rotas, controladores nem lógica de negócio, que funciona perguntando ao LLM, para cada requisição, “o que deve ser feito?”
• O objetivo do experimento é provar o quão distante esse futuro realmente está

Visão geral do projeto

• nokode é um experimento que testa uma arquitetura em que todas as requisições são processadas por um LLM, por meio de um “servidor web sem lógica de aplicação”
  • O servidor apenas recebe a requisição HTTP e pergunta ao LLM “o que deve ser feito?”, e o LLM faz todo o resto
• O objetivo é verificar se um LLM consegue executar diretamente a lógica da aplicação sem gerar código
• O alvo do experimento foi um app de gerenciamento de contatos (contact manager), com funções básicas de CRUD (criar, consultar, editar e excluir)

Estrutura do sistema

• O backend é composto por apenas 3 ferramentas
  • database: executa SQL no SQLite, com o próprio LLM desenhando o schema
  • webResponse: gera respostas no formato adequado, como HTML, JavaScript e JSON
  • updateMemory: salva feedback do usuário em Markdown para referência nas próximas requisições
• Por exemplo, em uma requisição para /contacts, ele gera uma página HTML; em /api/contacts, retorna uma resposta JSON
• Cada página inclui um widget de feedback, refletindo imediatamente pedidos como “deixa o botão maior” ou “muda para tema escuro”

Resultados do experimento

• Funcionalmente, deu certo
  • Envio de formulários, armazenamento de dados, exibição da UI e respostas de API funcionaram normalmente
  • Mesmo sem exemplos, o LLM gerou um schema de banco de dados adequado, SQL seguro, API em estilo REST, layout responsivo, validação de formulários e tratamento de erros
• Problemas de desempenho
  • Cada requisição leva de 30 a 60 segundos, ou seja, 300 a 6000 vezes mais lenta que um web app comum (10~100ms)
  • O custo por requisição fica entre US$ 0,01 e US$ 0,05, tornando-o 100 a 1000 vezes mais caro
  • Há inconsistências de cor e layout na UI, incapacidade de lembrar o estado anterior e erros imediatos quando SQL incorreto é gerado
  • Tentativas de otimizar o prompt com frases como “⚡ THINK QUICKLY” pioraram ainda mais a velocidade

Conclusão e implicações

• Os LLMs têm capacidade de executar diretamente a lógica de aplicação
• O problema está nas limitações de desempenho, como velocidade, custo, consistência e confiabilidade
• No entanto, essas limitações parecem estar mais no campo de melhorias quantitativas do que de barreiras qualitativas
  • A velocidade de inferência melhora cerca de 10 vezes por ano
  • Os custos estão em queda
  • O aumento do contexto pode melhorar a memória
  • A taxa de erro está diminuindo
• No fim, a era em que “a IA executa diretamente” pode estar mais próxima do que a era em que “a IA escreve código”
• O que sobra hoje são apenas trechos de código em nível de infraestrutura, como configuração de HTTP, definição de ferramentas e conexão com o banco de dados;
  no longo prazo, isso sugere a possibilidade de uma transição para uma “computação em que só existem intenção e execução”

Como executar

• Após npm install, configure o provedor de LLM e a chave de API no arquivo .env
• Execute npm start e acesse http://localhost:3001 (a primeira requisição leva de 30 a 60 segundos)
• É possível modificar prompt.md para mudar o tipo de app ou suas funcionalidades
  • Dá para testar rotas variadas, como /game, /dashboard e /api/stats
  • Feedbacks como “make this purple” ou “add a search box” são refletidos imediatamente
• O custo por requisição varia entre US$ 0,001 e US$ 0,05, dependendo do modelo
• Publicado sob a licença MIT

[aer0700]

A questão é até que ponto a computação vai ficar mais rápida e mais barata.
Se no futuro um servidor médio ficar 100 mil vezes mais rápido do que hoje, e mesmo assim os custos de operação e de instalação continuarem os mesmos, isso também parece um caminho válido.
Assim como, à medida que a computação ficou mais barata, passamos de linguagem de máquina para C, e de C para Node.js ou Python, talvez no futuro a mudança seja para LLMs.
Muita coisa vai mudar, e deve ser interessante à sua maneira. Também vão surgir várias oportunidades.

[GN⁺]

Opiniões no Hacker News

• Eu também vinha pensando em algo parecido

  1. Se a geração de código for totalmente automatizada e toda busca no Google passar a criar páginas personalizadas em tempo real, não deixaria de ser necessário que humanos construíssem sites? Nesse ponto, o “desenvolvimento web” ficaria mais próximo de modelagem de intenção (intent-shaping) do que de programação
  2. Também não concordo com a ideia de que chat seja a forma ideal de interface do usuário. Linguagem natural é flexível, mas lenta, ambígua e exige muita carga cognitiva. Provavelmente sistemas baseados em LLM vão precisar de um novo modelo de UI que combine conversa e interação estruturada

• Pensei nisso pela primeira vez quando o ChatGPT 3.5 apareceu
  Talvez um dia a IA consiga substituir completamente programas, mas o ponto realmente central é encontrar a abstração certa
  Por exemplo, assim como a transição de CVS para Git abriu a era dos microsserviços, boas abstrações têm o poder de mudar o problema na raiz
  Para que LLMs descubram esse tipo de abstração por conta própria, elas precisariam aprender interagindo com o mundo real por muito tempo

• Se adicionarmos ferramentas para que a LLM edite arquivos de código diretamente, a velocidade de resposta e a consistência devem melhorar bastante
  O código passaria a funcionar como uma espécie de memória (memory)
  Enviar requisições HTTP direto para a LLM seria algo parecido com um cache miss, e também daria para manter um mecanismo de feedback que dispara atualizações no código

  • Isso foi só um experimento simples, e a intenção era mostrar que ainda existem muitos gargalos
    Há muito espaço para otimização, mas na prática o jeito tradicional de programar ainda deve continuar sendo mais eficiente
  • Essa estrutura é como plantar uma semente (seed), definindo a direção de crescimento e os limites
  • Seria legal construir isso na prática

• Isso soa como perguntar: “se comportamento não determinístico (non-deterministic) é possível, por que insistir que tudo seja determinístico?”
  Mas a maioria das pessoas provavelmente não vai querer um webapp que funcione de um jeito diferente a cada vez

  • Na verdade, as pessoas não querem exatamente um “webapp”, e sim uma solução (solution) para o problema
    Código determinístico tem limites quando precisa lidar com problemas complexos, e uma abordagem mais flexível, parecida com a humana, pode ser mais adequada
  • Os LLMs de hoje ainda estão basicamente limitados a saída em texto e quase não têm memória de longo prazo
    Mas no futuro eles devem ganhar capacidades mais ricas de saída e armazenamento
    Por exemplo, um LLM poderia gerar links diretamente e, ao clicar neles, fazer novas consultas internamente, ou operar gerenciando um banco de dados temporário
  • Minha intenção não é dizer que comportamento não determinístico é melhor, e sim mostrar a lacuna entre o presente e uma era pós-código (post-code)
  • Na prática, o software de hoje também não é totalmente determinístico
    Atualizações automáticas, testes A/B e mudanças de UX alteram a experiência do usuário o tempo todo
  • Se você definir a temperatura como 0 e fizer a LLM salvar suas configurações em arquivos locais, também dá para criar um app determinístico

• Curiosamente, essa abordagem funciona até só com a janela de contexto, sem ferramentas separadas
  Em julho de 2025, montei um POC

• Este experimento mostra bem como o conceito de código boilerplate pode mudar
  Se você rodar várias instâncias ao mesmo tempo em sandboxes e entregar o resultado com melhor desempenho segundo uma avaliação interna, isso vira uma espécie de meta reinforcement learning
  O problema é que traduzir a intenção do usuário em uma saída determinística é difícil, enquanto apps tradicionais, por outro lado, não têm muita flexibilidade
  No fim, a questão principal é como implementar de forma estável a avaliação de intenção (intent evaluation)

  • Mas existe o risco de o modelo sofrer overfitting ao método de avaliação interna
    Criar um bom método de avaliação já é, por si só, quase tão complexo quanto criar um modelo de IA

• Processar requisições do jeito tradicional é muito mais custo-efetivo do que usar LLM diretamente
  Em termos aproximados, gerar 10 tokens com um modelo de 7 bilhões de parâmetros exige mais de 100 GFLOPs
  O desperdício de energia é grande

  • Mas acho que também deveríamos incluir no cálculo o custo energético do trabalho humano
    Quando você trabalha com TI corporativa, percebe que a ineficiência humana também não é pouca
  • A direção que a indústria toma nem sempre coincide com otimização
    Até a ineficiência vira tendência na prática
  • Ainda assim, usar LLM para criar rapidamente um protótipo (V1), validar o product-market fit e só depois otimizar com código tradicional é uma abordagem válida

• Talvez baste colocar uma LLM na porta 443 e dizer: “você é um servidor HTTPS e também um app server” ;)

• Será que realmente precisamos de webapps? Não daria para simplesmente conversar por voz com o computador?
  “Mostra as fotos das férias do ano passado, apaga as nuvens e manda para meu amigo”
  “Configura um timer de treino, mas tira jumping jacks”
  “Cria um beat techno estilo Detroit”
  “Encontra alguém para eu sair hoje à noite, prefiro cabelo preto”
  Fico imaginando um mundo em que tudo seria resolvido na fala, desse jeito

  • Mas esse tipo de automação pode enfraquecer a autonomia (agency) humana
    No fim, a humanidade talvez se divida entre os que aceitam isso e os que rejeitam
    Já dá para ver sinais disso em fenômenos como o renascimento dos discos de vinil
  • Interface por voz não é a resposta para toda comunicação
    Até entre humanos muitas vezes se prefere texto
  • Eu mesmo, nesta semana, fiz um app pessoal de gestão do conhecimento que usa WebSpeech para receber voz e ler/editar arquivos do org-mode e do logseq
    Dá para gerenciar tarefas, lista de compras e agenda, tudo totalmente customizado para as minhas necessidades
  • Esse tipo de futuro já apareceu bastante na ficção científica
    Tarefas complexas podem ser bem expressas por voz, mas para tarefas simples e repetitivas a UI é mais eficiente
    Por exemplo, se você disser “compra uma calça” e tiver que escolher uma entre 30 opções, no fim vai precisar de uma interface visual

• Eu também publiquei um PoC parecido no GitHub
  No começo, uso um “modelo de design” mais lento para criar o tema do app e o esquema do banco de dados, e depois um modelo mais rápido para processar as respostas
  Tentei usar PostREST para colocar a lógica no banco de dados, mas eram frequentes as falhas na geração do schema e consultas incorretas
  Usei uma biblioteca CSS para manter a consistência da UI e fiz o sistema lembrar da página anterior
  Acho que essa abordagem poderia servir como um App Bench para avaliar se uma LLM consegue criar um app completo de ponta a ponta de uma vez só