No final, o que importa não é a stack — é a entrega. Entendo a ideia, mas tem... · user1

No final, o que importa não é a stack — é a entrega.

Entendo a ideia, mas tem algumas coisas importantes que muita gente que divulga no-code não dá ênfase, por exemplo: manutenibilidade e continuidade/evolução.

Eu já comentei aqui no TN algumas vezes sobre uma boa quantidade de projetos que os clientes me procuraram pois criaram uma solução no-code que funcionou a princípio e que eram simplesmente terríveis de dar manutenção para adicionar novas funcionalidades (muito por conta dos serviços e componentes utilizados simplesmente não existiam mais ou não permitiam customizações). Tanto que as próprias empresas que criaram essas soluções abandonaram esses clientes que vieram nos procurar.

Eu brinco que ganhei muito dinheiro com no-code mesmo sem desenvolver nada com no-code, apenas refazendo esses projetos de maneira tradicional e aplicando uma arquitetura que permita evolução do software.

Acho que no-code no estado que está hoje, serve para pequenos projetos e projetos de validação, mas os envolvidos devem estar cientes que provavelmente o projeto é descartável. Mas não é o que os evangelistas do no-code vendem.

E já começou chegar aqui pra mim projetos que foram feitos com IA, mas nem a própria IA que fez consegue evoluir o projeto do jeito que o mantenedor queria.

Você trouxe um ponto muito válido — e que, na verdade, reforça o que o próprio post propõe: não é sobre a stack em si, mas sobre a forma como ela é usada.

O que acontece com muitos projetos no-code (e também com high-code, vamos ser honestos) é que são mal estruturados desde o início, sem visão de médio/longo prazo, sem arquitetura pensada, e com decisões técnicas tomadas apenas com foco em "entregar algo que funcione agora".

O resultado? Código (ou fluxos visuais) difíceis de manter, cheios de gambiarras, com dependências frágeis e baixa flexibilidade para evolução. Isso não é culpa do no-code em si, mas de como ele foi aplicado.

No meu post, inclusive, ressaltei que em projetos mais complexos — com regras dinâmicas, algoritmos pesados ou lógica customizada — pode sim fazer sentido migrar ou complementar com high-code. E essa migração se torna muito mais natural quando o projeto no-code já nasce pensando em integração com backend externo (como Supabase, n8n, APIs próprias).

Ou seja: dá pra escalar com no-code, se for bem pensado, com arquitetura clara e responsabilidade técnica desde o início. Do contrário, vira algo descartável — como você mesmo disse.

E isso vale também pro código tradicional. Já vi sistemas 100% codados que ninguém conseguia mais dar manutenção porque o dev original sumiu, não deixou documentação e criou um monstro técnico.

No fim, tanto o no-code quanto o high-code precisam de visão, arquitetura e boas decisões. É aí que mora a diferença entre uma solução descartável e uma solução escalável.

Obrigado por trazer essa visão. A discussão só cresce com contrapontos assim! 👊