Soy escéptico de low-code

Artículo original ↗ Discusión en Hacker News ↗

Las plataformas low-code y no-code prometen entregar software más rápido y con menos desarrolladores, pero muchos ingenieros informan que estas herramientas se desmoronan a medida que los requisitos se vuelven complejos, lo que lleva a sistemas frágiles, mal control de versiones y un bloqueo con el proveedor difícil de desentrañar. Quienes comentan distinguen entre herramientas de “programación para usuario final” como Excel, que pueden ser increíblemente productivas en dominios estrechos, y plataformas visuales pesadas que terminan recreando código espagueti en GUI y YAML propietarios en lugar de texto. El consenso emergente es que low-code puede funcionar bien en los bordes —prototipado, apps CRUD simples, configuración de reglas expertas— cuando se combina con prácticas reales de ingeniería y vías de escape al código, pero es una mala opción para la lógica de negocio central o para sistemas de larga vida y críticos para la misión.

Qué significa “low-code” en el hilo

  • El término se usa de forma laxa; quienes comentan distinguen entre:
    • Constructores visuales de flujos / GUI (PowerApps, Webflow, Retool, Node-RED, n8n, etc.).
    • Plataformas empresariales (Salesforce, SharePoint, Oracle APEX, herramientas al estilo SAP).
    • “Programación para usuario final” como Excel, Access, Airtable.
    • “Menos código” para desarrolladores: buenos frameworks, generadores, headless CMS, servicios de auth/CMS.
  • Algunos sostienen que casi todos los lenguajes y frameworks de nivel superior son “low code” en relación con assembly.

Dónde funciona bien low-code

  • Apps CRUD simples, formularios, flujos de trabajo, sitios de marketing, paneles internos.
  • Prototipado rápido / MVP; más tarde puede reescribirse o no.
  • Automatización de “última milla” en empresas: conectar SaaS, cablear aprobaciones, integraciones básicas.
  • Sistemas expertos / motores de políticas: permitir que los SMEs codifiquen reglas cambiantes (impuestos, cumplimiento).
  • Sustituir correo electrónico + hojas de cálculo + macros ad hoc; dar poder a los “power users”.
  • Historias de éxito específicas: configuraciones de Excel, Access, Airtable, Lotus Notes, Node-RED, Retool, Power Automate, Unreal Blueprints (para algunos juegos).

Problemas comunes y modos de fallo

  • Límite de complejidad: es fácil llegar al 80–90%; el último 10–20% se vuelve doloroso o imposible.
  • Las vías de escape (código personalizado) llevan a lógica propietaria y enredada que es más difícil que el código normal.
  • Control de versiones, pruebas, depuración, observabilidad y flujos de despliegue débiles o inexistentes.
  • Bloqueo con el proveedor: lenguajes propietarios, runtimes, precios (especialmente por usuario final).
  • Actualizaciones de plataforma que rompen todo; esquemas subyacentes opacos y desordenados, y problemas de gobierno de datos.
  • Diagramas espagueti / YAML / flujos visuales difíciles de diffear, revisar y mantener.
  • Seguridad/cumplimiento, auditoría y mantenimiento a largo plazo a menudo se descuidan; TI tiene que rescatar.

Dinámicas organizativas y sociales

  • Las herramientas se venden a los gerentes como una forma de sortear la “TI lenta” y a los ingenieros caros.
  • A menudo resuelven socialmente problemas de priorización/comunicación mal diagnosticados como “escasez de desarrolladores”.
  • El uso exitoso requiere un alcance claro: no central, no crítico para la misión, y con participación de TI.
  • Algunos ven los roles low-code como limitantes para la carrera de los desarrolladores por tratarse de habilidades de nicho, poco transferibles.

Alternativas y direcciones futuras

  • Preferencia por herramientas que “empoderan al desarrollador”: generadores de Rails/Django, headless CMS, buenas bibliotecas.
  • Llamados a plataformas open source, autoalojables, con soporte real de VCS y lenguajes no propietarios.
  • Varios sostienen que la asistencia de IA más el código convencional desplazarán gran parte de la promesa de “no-code para no desarrolladores”, aunque seguirá requiriendo desarrolladores expertos para manejar la complejidad y los casos límite.