> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2026/w16-nocode-rapid-iteration-and-new-engineering-constraints.md).

# W16-nocode, iteração rápida e novas restrições de engenharia

Na semana passada, o RH lançou uma atividade de vlogs sobre os dez anos da área de serviços financeiros. O projeto inteiro foi feito com nocode por um de nossos estagiários, Luo Huayu. Examinei o código e encontrei algumas coisas interessantes.

Primeiro, não me surpreenderia se no-code multiplicasse a produtividade desse tipo de projeto por várias vezes ou até dezenas de vezes. O que me surpreendeu foi o projeto ter gerado 268 versões ao longo do processo. Todos sabemos que a IA continuará acelerando a entrega de software e que os sistemas de produção provavelmente terão um ritmo várias vezes maior que o atual. Mas o que acontece depois que a velocidade aumenta? Acho que esse projeto é um ótimo exemplo.

Anos atrás, uma atividade de sorteio parecida costumava ter um desenvolvedor de frontend, outro de backend e pouco mais de meio mês de prazo. Depois de mais de uma semana de trabalho intenso, entregávamos um MVP. O cliente via, fazia sugestões, e os desenvolvedores voltavam a iterar. Dois dias depois, apresentavam de novo. Muitas vezes, ele ainda não gostava, e vinha outra rodada. No fim, o tempo acabava, e o cliente dizia: “Vamos deixar assim por enquanto.” Durante todo o processo, talvez visse apenas três ou quatro versões. A margem para iteração se esgotava rapidamente.

O nocode reduziu muito a distância entre o requisito e a implementação. O cliente recebe feedback mais rápido e também tem ideias mais rápido. No mesmo meio mês, o projeto percorreu mais de duzentas versões. Iterações que antes nem chegariam a acontecer se tornaram viáveis. Esse é um ponto importante: mais produtividade não significa necessariamente uma queda clara no tempo e nos recursos gastos. O resultado pode se aproximar mais do paradoxo de Jevons. Quando implementar fica mais fácil, surgem mais ideias e mais iterações; a demanda pode se aproximar do infinito. Não é necessariamente o volume de trabalho que desaparece. O que acontece é a liberação de iterações antes inviáveis.

Segundo, ao ler o código, tive uma sensação forte de que uma pessoa raramente escreveria algo assim por iniciativa própria. Esse serviço Web completo não tem um servidor independente: o frontend acessa diretamente o banco, com dezesseis procedimentos armazenados. É uma arquitetura típica de Frontend-only + BaaS. O frontend usa React + Vite para construir uma SPA, sem serviço de backend separado. Todas as operações de dados chamam diretamente, no navegador, a instalação privada do Supabase da Meituan via supabase-js. O banco subjacente é PostgreSQL.

A lógica de negócio foi dividida em duas partes. Validações simples e limites de frequência ficam no arquivo worksApi.js do frontend. A lógica central que exige segurança na concorrência e consistência de dados, como votar, curtir e excluir, é encapsulada em funções armazenadas do PostgreSQL, acionadas por supabase.rpc(). O controle de acesso depende principalmente das políticas RLS na camada de banco. A solução permite desenvolver rápido e elimina o custo de manter um servidor independente, mas os problemas também são claros. A lógica de negócio fica espalhada entre JavaScript no frontend e PL/pgSQL no banco, com manutenibilidade apenas razoável. Algumas informações sensíveis, como a lista de administradores, acabam codificadas diretamente no cliente.

O valor do projeto vai além de mostrar que nocode cria uma página de campanha mais rápido. Ele mostra concretamente uma nova normalidade da entrega de software na era da IA. Haverá mais versões, feedback mais rápido e arquiteturas que tendem cada vez mais a seguir primeiro o caminho mais curto de implementação. Para a equipe, isso traz oportunidades reais de produtividade e novas restrições de engenharia. O recurso escasso no futuro talvez não seja conseguir fazer a funcionalidade, mas preservar os limites da arquitetura, a manutenibilidade e a capacidade de evolução de longo prazo em meio a iterações extremamente rápidas.