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.