The Low-Code Paradox: AI Has Made Low-Code Editors More Cumbersome Than the CLI. APEX Has the Answer.

Low-code platforms were built on a simple idea: clicking is easier than typing. Drag a component onto a canvas, set some properties, wire up a data source, and ship it. For twenty years, that held up. Salesforce Lightning, Power Apps, Oracle APEX, Mendix, OutSystems all made the same bet that visual interfaces lower the barrier to entry and you do not need a developer to build an app.

Then AI coding assistants showed up and changed the way we work. Everyone now has an expert coder for $20 a month.

The problem with visual

AI is good at text, and code happens to be text. So are config files, CLI commands, and infrastructure definitions. You can hand an LLM a 2,000-line React component and it will understand the structure, find the bug, and write the fix.

But hand it a screenshot of your Power Apps canvas and it has nothing to work with. The layout lives as pixels on your screen and state in a proprietary runtime, so there is nothing for the AI to read, parse, or modify. The tools that were supposed to make development accessible turned out to be the ones AI cannot touch.

The flip

Meanwhile, the difficult tech tools got easy fast.

I can describe a full-stack Next.js app in plain English and have working code in minutes. I can tell an AI what Terraform infrastructure I need and get the HCL files back. If I describe a complex SQL migration with enough detail, Claude Code can one shot the joins, type conversions, and many of the edge cases.

Someone with zero React experience can build a working application today by iterating with an AI assistant in a terminal. Someone trying to do the same thing in a visual builder is still clicking through property panels one field at a time, or spending a fortune in tokens having Cowork build out the UI.

I live in both worlds

I have been building apps with AI coding assistants and I am genuinely amazed at what they can do. I can hand Claude Code a legacy spreadsheet with 40 tabs and it will create the required database tables in minutes -- correct data types, constraints, the works. But I am equally frustrated that it takes Cowork an hour to figure out how to click a specific button in a visual builder to start putting the UI together. The backend work that used to be "hard" is now trivially fast, and the UI work that was supposed to be "easy" is where all the time goes because the AI is fighting a point-and-click interface instead of reading and writing text.

APEXLang changes this

This is where Oracle did something smart. APEX 26.1 introduced APEXLang -- a human-readable application export format. Instead of exporting your app as a SQL script, you get structured text that describes every page, region, item, and process:

page:
  id: 15
  name: Supplier Migration
  mode: Normal

regions:
  - id: 1001
    name: Migration Batches
    type: Interactive Report
    source:
      type: SQL Query
      sql: |
        SELECT batch_id, batch_name, status, record_count
        FROM dmt_batches_v
        WHERE created_by = :APP_USER
    position:
      sequence: 10
      parent_region: Body

  - id: 1002
    name: Batch Actions
    type: Static Content
    items:
      - id: P15_BATCH_ID
        type: Hidden
      - id: P15_ACTION
        type: Select List
        lov:
          values:
            - display: Run Validation
              return: VALIDATE
            - display: Generate FBDI
              return: GENERATE
            - display: Submit to Fusion
              return: SUBMIT

processes:
  - id: 2001
    name: Execute Batch Action
    type: PL/SQL Code
    source: |
      dmt_pipeline_pkg.execute_action(
        p_batch_id => :P15_BATCH_ID,
        p_action   => :P15_ACTION
      );

Every item, region, process, and dynamic action is structured as text that an AI can read and modify. I can hand my AI assistant the full structure of an APEX page and say "add a chart region that shows migration status counts after the Interactive Report," and it produces the text that I import back into the app. The visual builder and the AI can finally work on the same application -- this is vibe coding for low-code.

Adapt or get left behind

Think about what happens when a company needs a new internal tool and two teams pitch different approaches. One team picks Next.js and Claude Code -- they have a working prototype in a week because the AI can read and write every file in the project. The other team picks Power Apps and spends that same week dragging fields onto canvases by hand because their AI assistant cannot interact with the visual editor in any meaningful way. That decision gets made once, and the losing platform does not get a second chance.

This is not hypothetical. It is already happening. Developers are choosing tools based on how well they work with AI, and visual-only platforms are losing that comparison badly.

APEXLang is not perfect -- it is new and the tooling is still catching up. But Oracle recognized the problem and shipped an answer. They kept the visual builder for people who want it and added a text representation that AI can work with. The two live side by side, and developers get to use whichever approach fits the task.

The platforms that follow APEX's lead and add a parallel text layer will keep their users. The ones that keep shipping visual-only editors will watch those users leave for tools they can use in conjunction with AI, and it will not take long.