Sou cético em relação ao low-code
Plataformas low-code e no-code prometem entregar software mais rápido e com menos desenvolvedores, mas muitos engenheiros relatam que essas ferramentas entram em colapso quando os requisitos ficam complexos, gerando sistemas frágeis, controle de versão ruim e lock-in com fornecedor difícil de desfazer. Os comentaristas distinguem entre ferramentas de “programação para usuário final” como o Excel, que podem ser incrivelmente produtivas em domínios restritos, e plataformas visuais pesadas que acabam recriando código espaguete em GUIs proprietárias e YAML em vez de texto. O consenso emergente é que o low-code pode funcionar bem nas bordas — prototipação, apps CRUD simples, configuração de regras especializadas — quando combinado com práticas reais de engenharia e saídas de emergência para código, mas é uma má escolha para lógica central de negócio ou sistemas duradouros e críticos para a missão.
O que “low-code” significa no thread
- O termo é usado de forma ampla; os participantes distinguem:
- Construtores visuais de fluxos / GUI (PowerApps, Webflow, Retool, Node-RED, n8n, etc.).
- Plataformas corporativas (Salesforce, SharePoint, Oracle APEX, ferramentas ao estilo SAP).
- “Programação para usuário final” como Excel, Access, Airtable.
- “Menos código” para desenvolvedores: bons frameworks, geradores, headless CMS, serviços de auth/CMS.
- Alguns argumentam que quase todas as linguagens e frameworks de alto nível são “low code” em relação à assembly.
Onde o low-code funciona bem
- Apps CRUD simples, formulários, fluxos de trabalho, sites de marketing, dashboards internos.
- Prototipação rápida / MVPs; depois, pode ou não ser reescrito.
- Automação de “última milha” em empresas: conectar SaaS, orquestrar aprovações, integrações básicas.
- Sistemas especialistas / mecanismos de políticas: permitir que SMEs codifiquem regras em mudança (impostos, conformidade).
- Substituir email + planilhas + macros improvisadas; capacitar “power users”.
- Histórias específicas de sucesso: configurações de Excel, Access, Airtable, Lotus Notes, Node-RED, Retool, Power Automate, Unreal Blueprints (para alguns jogos).
Problemas comuns e modos de falha
- Teto de complexidade: é fácil chegar a 80–90%; os últimos 10–20% ficam dolorosos ou impossíveis.
- Saídas de emergência (código customizado) levam a lógica proprietária e emaranhada, mais difícil que código normal.
- Controle de versão fraco ou inexistente, além de testes, depuração, observabilidade e fluxos de implantação.
- Lock-in com fornecedor: linguagens proprietárias, runtimes, precificação (especialmente por usuário final).
- Quebras em upgrades da plataforma; esquemas subjacentes opacos e bagunçados, e problemas de governança de dados.
- Diagramas espaguete / YAML / fluxos visuais difíceis de diff, revisar e manter.
- Segurança/compliance, auditoria e manutenção de longo prazo frequentemente negligenciados; o TI precisa “salvar” o projeto.
Dinâmicas organizacionais e sociais
- As ferramentas são vendidas a gestores como uma forma de contornar o “TI lento” e engenheiros caros.
- Muitas vezes resolvem problemas de priorização/comunicação, socialmente diagnosticados de forma errada como “escassez de desenvolvedores”.
- O uso bem-sucedido requer escopo claro: não central, não crítico para a missão, e com envolvimento do TI.
- Alguns veem funções em low-code como limitantes para a carreira de desenvolvedores devido a habilidades de nicho e pouco transferíveis.
Alternativas e direções futuras
- Preferência por ferramentas que “empoderem desenvolvedores”: geradores Rails/Django, headless CMS, boas bibliotecas.
- Pedidos por plataformas open source, auto-hospedáveis, com suporte real a VCS e linguagens não proprietárias.
- Vários argumentam que a assistência de IA junto com código convencional vai deslocar grande parte da promessa de “no-code para não desenvolvedores”, ainda exigindo desenvolvedores qualificados para lidar com complexidade e casos extremos.