I'm skeptical of low-code

Original Article ↗ Hacker News Discussion ↗

Low‑code and no‑code platforms promise faster software delivery and fewer developers, but many engineers report that these tools break down as requirements become complex, leading to brittle systems, poor version control, and hard‑to‑untangle vendor lock‑in. Commenters distinguish between “end‑user programming” tools like Excel, which can be incredibly productive in narrow domains, and heavyweight visual platforms that end up recreating spaghetti code in proprietary GUIs and YAML instead of text. The emerging consensus is that low‑code can work well at the fringes—prototyping, simple CRUD apps, expert-rule configuration—when paired with real engineering practices and escape hatches to code, but is a poor fit for core business logic or long‑lived, mission‑critical systems.

What “low-code” means in the thread

  • Term is used loosely; posters distinguish:
    • Visual flow / GUI builders (PowerApps, Webflow, Retool, Node-RED, n8n, etc.).
    • Enterprise platforms (Salesforce, SharePoint, Oracle APEX, SAP-style tools).
    • “End‑user programming” like Excel, Access, Airtable.
    • “Less code” for developers: good frameworks, generators, headless CMS, auth/CMS services.
  • Some argue almost all higher‑level languages and frameworks are “low code” relative to assembly.

Where low-code works well

  • Simple CRUD apps, forms, workflows, marketing sites, internal dashboards.
  • Rapid prototyping / MVPs; later may or may not be rewritten.
  • “Last‑mile” automation in enterprises: connecting SaaS, wiring approvals, basic integrations.
  • Expert systems / policy engines: letting SMEs encode changing rules (tax, compliance).
  • Replacing email + spreadsheets + ad‑hoc macros; empowering “power users”.
  • Specific success stories: Excel, Access, Airtable setups, Lotus Notes, Node-RED, Retool, Power Automate, Unreal Blueprints (for some games).

Common problems and failure modes

  • Complexity ceiling: easy to get 80–90%, last 10–20% becomes painful or impossible.
  • Escape hatches (custom code) lead to proprietary, tangled logic that’s harder than normal code.
  • Weak or absent version control, testing, debugging, observability, and deployment workflows.
  • Vendor lock‑in: proprietary languages, runtimes, pricing (esp. per‑end‑user).
  • Breaking platform upgrades; opaque, messy underlying schemas and data governance issues.
  • Spaghetti diagrams / YAML / visual flows that are hard to diff, review, and maintain.
  • Security/compliance, auditing, and long‑term maintenance often neglected; IT must rescue.

Organizational and social dynamics

  • Tools are sold to managers as a way around “slow IT” and expensive engineers.
  • Often solve prioritization/communication problems socially misdiagnosed as “developer scarcity”.
  • Successful use requires clear scope: non‑core, non‑mission‑critical, and with IT involvement.
  • Some see low-code roles as career‑limiting for developers due to niche, non‑transferable skills.

Alternatives and future directions

  • Preference for “developer‑empowering” tools: Rails/Django generators, headless CMS, good libraries.
  • Calls for open‑source, self‑hostable platforms with real VCS support and non‑proprietary languages.
  • Several argue AI assistance plus conventional code will displace much of the “no‑code for non‑devs” promise, while still requiring skilled developers to handle complexity and edge cases.