Will AI Coding Kill Low-Code?

AI coding will first displace the old low-code proposition of replacing hand-written code with drag-and-drop. If the next generation of low-code can become a machine-readable, verifiable, reversible foundation for enterprise applications, it will inherit a harder and more valuable job: making generation fast without making change uncontrollable.

Part I · When code becomes cheap

01Why the death of low-code sounds plausible

The classic low-code demo begins with a table dragged onto a canvas. A data source is attached, a form is configured, and a working management application appears within minutes. The result felt remarkable because the alternative was assumed to be slower: find developers, create a project, choose a stack, implement the interface and API, then wait for deployment. That comparison has changed.

A user can now ask an AI for a supplier onboarding application. Suppliers submit credentials; procurement performs the first review; legal checks the contract; finance verifies the bank account; high-risk suppliers receive an additional compliance review; every action must be traceable. A few minutes later, the pages, API, database, and sign-in flow may already exist. The result may not be reliable, but it can look remarkably complete.

In his talk “Software Is Changing (Again),” Andrej Karpathy describes large language models as a new kind of computer programmed through natural language. ^[1] Follow that argument into application development and drag-and-drop begins to look indirect. The user does not really want to say, “Place a dropdown in the second column.” The user wants to say, “High-risk suppliers require an additional compliance decision.” If natural language can carry the latter, the canvas loses much of its advantage as the primary interface.

This is not the first time a higher-level abstraction has challenged low-code. Code generators, fourth-generation languages, model-driven development, and cloud services have all removed implementation work. AI is different because it can work with incomplete intent, explain its interpretation, and revise the result without requiring the user to learn a precise formal language first. The low barrier once associated with low-code is no longer exclusive.

I therefore agree with the first half of the pessimistic case. If writing less code remains a platform’s main claim to value, its moat is disappearing. A fixed template is not necessarily more adaptable than generated code. A proprietary formula is not necessarily easier than natural language. A constrained component set may offer less freedom than a conventional codebase. AI does not need to replace the whole platform at once. It only has to invalidate the reason customers originally accepted its constraints.

02Zero to running has become genuinely cheap

The clearest effect of AI coding is that software work can begin with “let us make one and see” rather than a request ticket. Product managers can test an interaction themselves. Operations teams can create a temporary tool. A founder can compare several product directions in a day. Ideas that would never have reached an engineering backlog can now acquire an executable form.

Addy Osmani calls the resulting experience the “70% problem.” AI can take someone to a surprisingly complete first version, while the remaining distance to maintainable, production-worthy software still demands architecture, edge-case reasoning, and verification. ^[2] The percentage is best treated as a useful engineering metaphor, not a universal project measurement. The first stretch feels quick because it is easy to demonstrate. Much of the last stretch appears only under failure, growth, and change.

A complaint-management prototype may already include authentication, a list, a detail view, and a state transition. Before production, the questions change:

• How does the system identify and merge duplicate complaints from the same customer?
• Customer service agents may see only their product line, while quality leads see across lines. Is that rule enforced centrally or reimplemented in every page?
• Does “no response within 24 hours” use elapsed time or a business calendar? What happens on a holiday or while a case is paused?
• If a notification succeeds but the state update fails, can a retry escalate the case twice?
• When a complaint contains private customer information, what rules govern exports, search indexes, logs, and backups?
• When the workflow changes six months later, do in-flight cases remain on the old version or migrate to the new one?

These questions rarely appear in the first screenshot. They determine whether a company should trust the application with customer relationships and service obligations.

03A prototype can be most dangerous when it looks finished

A rough prototype invites skepticism. A polished interface with smooth transitions and a deployment URL does the opposite. Visual completeness becomes a proxy for engineering completeness, and “a few fixes before launch” begins to sound reasonable.

Enterprise qualities are rarely plugins fitted at the end. A data model’s treatment of history sets the limit for audit and migration. Whether permissions are enforced by the service or scattered through the frontend determines the exposure to unauthorized access. Transaction boundaries determine whether a partial failure can be recovered. Dependency choices determine whether growth can be accommodated or requires a rewrite. These decisions already exist in the first version, even when nobody has asked them to survive scrutiny.

AI increases the scale of this misjudgment. One agent creates pages, another adds APIs, a third changes the database, and a fourth edits deployment configuration. Every local answer may be plausible while no one understands the assembled system. Producing ten times more code does not create ten times more review capacity, test coverage, or architectural understanding. The bottleneck moves from “Who can write this?” to “Who can prove this?”

Part II · Enterprises buy controlled change

04Enterprise is a statement of responsibility, not size

“Enterprise-grade” is often confused with a larger feature set or a more elaborate stack. Microservices, containers, and Kubernetes become ceremonial markers of maturity. In practice, a three-screen approval tool may need enterprise safeguards if it carries real money, customer data, or regulatory obligations. A fifty-screen demonstration with no continuing dependency is still a prototype.

A more useful definition is a statement of responsibility: the organization is willing to entrust an ongoing business operation to this system and knows who must detect, explain, and recover it when something goes wrong.

That responsibility needs at least six kinds of certainty:

• Outcome certainty. The same business conditions produce the same result, and retries or concurrent actions do not silently create conflicting facts.
• Boundary certainty. Identity, role, tenant, and data permissions remain consistent at every entry point; security cannot depend on one page remembering to hide a button.
• Operational certainty. The system can isolate, degrade, or recover when a dependency times out, a network becomes unreliable, or traffic changes abruptly.
• Change certainty. The impact of a model, workflow, or interface change can be inspected; old data can be migrated; a failed release can be reversed.
• Evidence certainty. It is possible to reconstruct who acted, when, with which information, and under which rule.
• Ownership certainty. Business meaning, technical risk, and production release have accountable owners. AI is not one of them.

These properties are not proportional to the number of features. They determine whether software becomes an organizational asset rather than a disposable output.

05AI raises output; the engineering system decides what it amplifies

DORA’s 2025 research on AI-assisted software development offers a more useful conclusion than either “AI works” or “AI harms delivery.” AI acts as an amplifier of an organization’s existing strengths and weaknesses. The study associated AI adoption with higher delivery throughput while delivery stability remained under pressure. ^[3] That does not predict the outcome for an individual team. It does warn against treating local coding speed as end-to-end delivery performance.

In a team with clear boundaries, fast tests, short feedback loops, and dependable releases, AI can reproduce good practice more quickly. In a team where requirements change verbally, permission rules are scattered, tests are chronically deferred, and deployment depends on memory, AI can multiply inconsistency just as efficiently. Generation has no direction of its own. The surrounding engineering system determines whether it amplifies order or disorder.

This is where low-code may find a more defensible purpose. It does not have to beat AI at generating code. It can supply engineering facts that already exist: how identity is integrated, how workflow state is persisted, which components may access sensitive fields, how tasks are timed, how data is audited, and how applications are released and rolled back. AI need not reinvent those answers for every project.

06The valuable part of low-code lives below the canvas

A mature table component appears to offer columns, filters, pagination, and buttons. Its real accumulation sits underneath. How does it paginate large datasets? Do field permissions also constrain query and export? How are concurrent updates detected? What do locale and time zone do to sorting? How does the component behave on mobile or with assistive technology? What is retried after failure? Which actions produce audit evidence?

AI can certainly generate a table on demand. Generating a similar appearance does not reproduce every incident, correction, and trade-off learned over years of operation. The value of a mature component is not the number of lines it saves. It is a compressed history of failure turned into reusable default behavior.

The same accumulation exists in workflow, identity, files, messaging, scheduling, and integration. An approval engine is not merely a set of connected boxes. It must account for withdrawal, reassignment, additional reviewers, duplicate submission, old workflow versions, departed employees, time zones, and business calendars. A file service is not just an upload button. It includes malware scanning, access control, lifecycle rules, and retention.

None of this means that using a mature component guarantees a stable application. Components can be combined incorrectly, and platforms have defects. The defensible claim is narrower and more useful: reusing proven capabilities reduces the amount of foundational failure each project must rediscover, but it does not eliminate architecture or acceptance testing.

07From development tool to runtime contract

If the canvas is no longer central, what remains of low-code? I believe the answer is an application model that both people and machines can understand:

• the fields, uniqueness rules, states, and lifecycle of a business object;
• the nodes, transitions, conditions, validations, and compensation paths in a process;
• who may perform an action and which fields and records that person may see;
• the semantic components on a page and the business capabilities on which they depend;
• capacity, availability, audit, recovery, region, and retention requirements;
• the live instances affected by a change and the checks required before release.

When this information exists only as canvas coordinates and proprietary JSON, it remains configuration inside a closed tool. Once it has stable semantics, versions, interfaces, diffs, and validation rules, it becomes a runtime contract. AI can generate the contract, people can review it, the platform can execute it, and a delivery pipeline can verify it.

Writing on Martin Fowler’s site, Evan Bottcher describes a digital platform as self-service APIs, tools, services, knowledge, and support presented as a compelling internal product. A good platform offers a safe and compliant paved road rather than forcing every team down one mandated route. ^[4] The next generation of low-code should work the same way. It cannot become a larger shared-services queue, and it cannot use “governance” as an excuse for poor usability. Trusted defaults must be easier to consume than bypassing the platform and rebuilding them.

Part III · Natural language plus CLI, not a magic textbox

08Natural language should carry business intent

Drag-and-drop works well for a local layout adjustment. It is a poor medium for the complete meaning of a business process. When a user asks for supplier onboarding, the important material is the set of objects, roles, transitions, exceptions, and obligations, not the coordinates of controls.

A useful AI should not immediately create pages. It should first turn the request into a plan that people can challenge:

This step can look like a delay because no code has appeared. In reality, it prevents one of the most expensive mistakes: a fluent interface hiding the assumptions the AI made on the user’s behalf. Natural language should not leave ambiguity permanently ambiguous. Its value is helping a team turn ambiguity into confirmable structure earlier.

09A CLI bridges intent and engineered delivery

Why introduce a CLI when the user can already describe the outcome? Because a sentence is suitable for expressing a goal, not for serving as a production change record. Enterprise delivery must identify the target environment, current version, exact mutation, validation result, and recovery material. A CLI turns those actions into repeatable, composable, auditable commands. It also lets an AI operate through business semantics instead of screen coordinates or guessed internal JSON.

The current Spark CLI provides a concrete example. It establishes an authentication profile, application, editable version, and workflow context before exposing commands such as add a node, connect a transition, or attach a validation rule. High-impact writes require an explicit --yes. The result can be checked and exported as a package. The visual designer remains the place for graphical inspection and human governance; the CLI handles automation, batch work, structured output, and AI integration. ^[5]

The following is an illustrative scenario assembled from real command semantics. It assumes that the application, workflow, form, and reusable Step already exist. The names explain the method; they do not refer to a particular production environment.

# Prove the target context instead of inferring it from chat history
spark auth use spark-dev
spark-designer task app use customer-service
spark-designer task current
spark-designer task workflow use "Complaint Handling"
spark-designer task workflow current
spark-designer task workflow describe --json

# Read the rules registered by the target service, then prepare a change plan
spark-designer task workflow rule-types

# After a person approves the plan, add a quality review for major complaints
spark-designer task workflow add-node \
  --type status \
  --name "Quality Review" \
  --step "Quality Review" \
  --yes

spark-designer task workflow connect \
  "Product Review" \
  "Quality Review" \
  --name "Escalate Major Complaint" \
  --form qualityReview \
  --yes

# Read back the result, run checks, and preserve recovery material
spark-designer task workflow describe
spark-designer task check workflow-config --yes
spark-designer task package export \
  --output complaint-management-backup.json

This is less magical than the invented platform create command in the original outline, and more useful for that reason. AI can still translate a business request into these operations, but it must show the target context, actual capability catalog, and expected change. A person confirms before the write; the tool reads back afterwards; the designer and a suitable runtime environment remain part of validation. The CLI does more than save typing. It gives generation an evidence trail that can be questioned.

10A trusted build is a loop, not a prompt

Combining AI and low-code into a responsible delivery process requires roughly seven movements:

1. Express intent. A business owner states the outcome, roles, exceptions, and constraints that must not be violated.
2. Form a plan. AI decomposes objects, workflows, permissions, components, and open questions without immediately changing production data.
3. Prove context. Tools read the actual application, version, environment, and capability catalog so the wrong target is not modified.
4. Compose capabilities. The platform prefers mature identity, workflow, SLA, audit, notification, and data components.
5. Generate the difference. AI creates only the model, configuration, or extension code not covered by the platform, with an explicit impact surface.
6. Verify the result. Automated checks cover primary flows, permission matrices, retries, escalation, recovery, and performance baselines; people validate business meaning and high-risk decisions.
7. Operate and learn. Monitoring, audit, versioning, progressive delivery, and rollback produce evidence for the next change.

The third approach is not a mechanical sum of the first two. Its generation space is different. Open-ended AI coding may choose any framework, dependency, or design. A trusted platform prefers approved components, shared identity, and standard connectors. Sensitive actions must be audited, and releases must pass known gates. This reduces freedom, but it also reduces the cost of proving the same foundational properties for every new application.

Part IV · Low-code still needs a revolution of its own

11“Fast and good” is not automatic

AI and low-code can improve speed and quality together, but the mechanism matters.

Speed comes mostly from interpreting intent and automating boilerplate configuration, documentation, and differential implementation. Quality comes mostly from mature components and a shared runtime, not from AI becoming incapable of error. Stability comes from failure boundaries, observability, and recovery. Reliability comes from constraints, tests, audit, and release ownership. Maintainability comes from models, code, versions, and decision records existing together.

Remove any one of those pieces and the promise changes. Natural language without a stable platform creates a fast-growing code pile. A closed platform without a better intent interface leaves users trapped in laborious configuration. Both together, without validation and responsibility, send mistakes into production at greater speed.

The division of labor is therefore subtler than “AI supplies speed and low-code supplies stability.” AI can help with testing and governance; a poor platform can slow everything down. The effective pattern is to let probabilistic generation propose candidates, deterministic systems enforce constraints, and people remain responsible for judgments that cannot be outsourced.

12Seven changes the next platform must make

Years of component development do not guarantee that a low-code platform will survive this transition. If the accumulated knowledge remains locked inside browser clicks, private formats, and manual operations, AI cannot invoke it reliably and an enterprise cannot inspect it well.

Forrester analysts Diego Lo Giudice and John Bratincevic use the term AppGen for a related direction: an AI-native, business-aware full-stack platform with intermediate models between business intent and executable systems, plus domain knowledge and governance embedded in the platform. ^[6] Whether that label survives does not matter much, and their timeline for reshaping the software lifecycle remains a forecast. The more durable observation is that low-code and generative AI are converging, and the competitive unit is shifting from an editor to the entire application delivery chain.

Security cannot be established by a platform promise either. NIST’s Secure Software Development Framework places security requirements, provenance, design decisions, release integrity, and vulnerability response across the development lifecycle. ^[7] A platform that expects to carry core enterprise work must turn requirements like these into executable defaults and evidence, not check them once in a procurement questionnaire.

13A stronger platform needs clearer boundaries and an exit

Not all software belongs on a shared low-code runtime. Novel interaction models, extreme performance or real-time requirements, infrastructure systems, algorithmically distinctive products, and regulated scenarios the platform has not proven may require direct engineering control. Even an ordinary business application can contain a rule too specific to force into the wrong component.

AI can also deepen platform lock-in. In the past, a developer at least knew which configuration screens had been used. In the future, AI may continuously invoke proprietary platform semantics while the application portfolio expands faster than the team can map its dependencies. A responsible platform needs data export, open interfaces, versioned models, observable runtime behavior, and explicit extension boundaries. A good paved road has signs and exits. It does not turn its guardrails into walls.

False certainty remains another danger. Stable components can still be assembled into an unstable system. An automatically generated permission matrix may be internally complete while misunderstanding the organization. Every test may pass because the tests simply repeat the AI’s mistaken assumption. A platform can lower risk. It cannot define correctness on behalf of the business owner or accept production consequences on behalf of the technical owner.

14The destination is not No Code, but Trusted Build

AI coding will eliminate some low-code products. Platforms built mainly on templates, drag-and-drop, and the promise that non-programmers can make apps will struggle to justify their learning cost and lock-in. Natural language is more direct, conventional code is more open, and AI will keep improving the conversion between them.

Cheaper code does not make the whole cost of enterprise software cheap. If anything, more candidate implementations make proven components, explicit runtime contracts, automated governance, and recoverable delivery more scarce. Enterprises do not need a larger supply of code with unknown origins. They need controlled change at a lower cost.

The most competitive low-code platform may no longer begin with a canvas. A user states the business objective and AI produces a structured plan. The platform composes pages, data, workflow, and permissions from trusted capabilities. CLI and API calls make every mutation traceable. Tests, policy, and accountable approval decide whether to release. Operational evidence improves the next generation.

I call this Trusted Build, not to invent another market category, but to change the acceptance questions. We should ask more than whether the system can generate:

• Does it express the business intent and surface its unknown assumptions?
• Does it reuse proven capabilities instead of rebuilding infrastructure?
• Can it provide evidence about permissions, data, performance, and failure paths?
• Is the change explainable, reversible, and transferable to another owner?
• If the platform stops fitting, does the organization still own its data and business knowledge?

If those questions have credible answers, AI coding and low-code are not engaged in a simple replacement war. AI changes the application interface. Low-code contributes capabilities selected by time and failure. The engineering system constrains both into a delivery process for which someone can responsibly answer.

The contest is no longer about who can let a non-programmer make software. AI has already pushed that door open. The harder question comes next: when everyone can generate software, who can make it worthy of an enterprise’s long-term trust?