Low code for AI: what it does well and where you still need engineers

Two bad arguments about low code

Two arguments about low code come up in almost every company that considers it, and both are wrong.

The first says a visual builder means you no longer need engineers. Business users will drag a few blocks onto a canvas, connect them to a model and ship an AI assistant by Friday. This is the version in the marketing material, and it produces a lot of half finished prototypes.

The second says low code is a toy. Anything serious must be written in code by a proper engineering team, and a visual builder only creates technical debt that someone will have to rewrite later. This is the version you hear from experienced developers who have been burnt by drag and drop tools before.

A good low code builder moves a large share of the work in an AI application to the people who understand the process, and leaves a smaller, harder share to engineers. Getting the split right is most of the skill.

Why AI applications suit low code better than most software

Traditional business software is mostly deterministic logic: if the invoice amount exceeds the purchase order by more than two percent, flag it. That logic is precise, testable and usually best written by a developer.

AI applications have a different shape. A large part of the work is describing what you want in language, choosing what information the model should see, deciding what a good answer looks like and setting limits on what the system may do. That work depends on knowing the business. The person who knows that a Rajkot distributor's largest supplier always sends invoices with the transport charge on a separate line is the person who should be shaping how the agent reads those invoices.

In a typical AI application, a surprising amount of the "logic" is really:

• a prompt that explains the task in the way an experienced team member would explain it to a new hire
• a set of documents the agent may consult, such as a leave policy, a rate card or a product catalogue
• a few decision points: is this a refund request or a delivery query, is this patient discharge routine or does it need a doctor's review
• rules about output format and tone
• a review step where a person approves or corrects

All of these can be built and changed visually. When the HR team at a mid sized manufacturer wants the leave policy assistant to stop answering questions about salary advances, they should be able to make that change themselves, test it on a few sample questions and publish it, without raising a ticket.

What a visual builder does well

Shaping prompts and flows

Prompt chaining, where the output of one step feeds the next, is easy to reason about when you can see it. Read the email, classify the request, look up the order, draft a reply, check the draft against tone rules. On a canvas, a business analyst can see the chain, run it on a sample, and spot exactly which step went wrong.

Connecting to knowledge

Pointing an agent at a folder of policy documents, a product catalogue or a set of past contracts is configuration work, as long as the documents are reasonably organised. The work is deciding which sources the agent may use for which questions, and keeping them current.

Decisions and routing

Decision trees and task routing are natural in a visual tool. A school group's admissions office might route enquiries by campus, by grade and by language, sending Gujarati enquiries about Class 1 at the Vadodara campus to the right counsellor. Building that as a flow is quick, and the admissions head can read it.

Forms, dashboards and review screens

Much of the value of an AI application lies in the screen where a person reviews its work. Smart forms, tables with filters and simple dashboards are well suited to a UI designer. The accounts executive needs a list of unmatched invoices, the reason each did not match and two buttons. That does not need a front end engineer.

Testing as you build

Real time testing changes how teams work. The old way was to write a specification, wait for a build and then discover the agent misreads half the inputs. Now the team runs real examples while they build. This shortens the loop from weeks to minutes, and it is where most of the practical gain from low code comes from.

Where you still need engineers

Integrations with older or unusual systems

Connecting to a modern CRM with a documented API is usually configuration. Connecting to a ten year old on premise ERP customised by three different vendors, or to a hospital information system with no API at all, is engineering. Someone has to understand the database, write a safe adapter, handle authentication, deal with rate limits and make sure the agent cannot write anything it should not. Tally deserves a special mention: it is everywhere in Indian businesses, and integrating with it properly, especially for writing vouchers back, needs care and testing.

Data preparation

If the purchase order data has supplier codes that do not match the vendor master, or the collections data for an NBFC lives in three systems that disagree about the outstanding amount, no amount of prompt design will fix it. Data cleaning, mapping and the pipelines that keep data current are engineering work, and they often take longer than building the agent itself.

Performance and cost at scale

A flow that works for twenty test cases can behave very differently at twenty thousand a day. Engineers look at token usage, caching, which model handles which step, how to batch work and what happens when a provider is slow. A D2C brand's WhatsApp support agent during a festive sale needs this kind of attention. A leave policy assistant used by 200 staff probably does not.

Security and access control

The builder should provide guardrails: who can see what, which data an agent may use, which actions it may take and a log of what it did. But mapping your actual access model onto those guardrails, especially in a bank, an NBFC or a hospital, needs someone who understands both the platform and your security requirements. Single sign on, network rules for a private cloud or on premise deployment and the review of what data leaves your environment are engineering and security tasks.

Custom components

Sometimes the business needs something the builder does not offer: a particular document parser for a regional language form, a specialised calculation, a custom approval workflow tied to a government portal. A good platform lets engineers write these as components that business users can then use in their flows. A poor one forces you to rebuild the whole application outside the platform.

Evaluation

Deciding whether an agent is good enough is harder than it looks. Engineers and analysts build test sets from real data, track how output quality changes when prompts or models change and catch regressions before users do. A business user can and should contribute examples, but someone has to own the discipline of measuring.

A practical split of responsibilities

On projects that work well, the business team owns the process description, the prompts, the knowledge sources, the decision rules, the review screens and the day to day changes. They test continuously and decide what goes live.

Engineers own integrations, data pipelines, access and security setup, custom components, performance work and the evaluation framework. They also set the boundaries within which the business team works, so a change to a prompt cannot accidentally give an agent access to payroll data.

A small number of people sit between the two. They understand the process well enough to talk to the accounts team and the technology well enough to talk to engineers. This is the role that forward deployed engineers and strategists play, and it is often the difference between a project that moves and one that waits.

The trade offs

Low code is faster to start and slower to customise at the edges. If 90 percent of what you need fits the builder, it will save a great deal of time. If only half fits, you may be better off with a mostly coded approach.

A visual builder makes it easy for many people to change things. That is good for speed and bad for control unless versioning, testing and publishing rules are in place. Workspace governance is not optional.

Low code platforms carry a degree of lock in. Your flows, prompts and configurations live in the platform's format. Ask how you would export them, and whether integrations and custom components can be reused elsewhere. Choosing a platform that supports private cloud or on premise deployment reduces some of this risk, though not all of it.

Finally, low code does not remove the need for clear thinking about the process. A badly understood process built quickly in a visual tool is still a badly understood process. It fails faster, which can itself be useful.

How to start

Pick one process. Let the team that runs it build the first version in the builder, with an engineer available for integrations and data. Note every point where the builder could not do what was needed. That list tells you, better than any vendor comparison, how much of your future work will be low code and how much will need engineers.

To see how the builder handles flows, components and testing in practice, read about the AksharAI app builder.