Low-code needed engineers. AI agents make them affordable
Low-code made the first version of an app cheap and did little for every version after it. Agentic engineering changes that, and changes when you should build on a platform at all.
By Gary Kellett6 min read
For technology leaders, heads of digital and low-code centre of excellence leads.
Get the whitepaper (17 pages)Low-code won the argument it set out to win. Microsoft reported 56 million monthly active Power Platform users in April 2025, up 27% in a year, and Gartner expects 60% of software development organisations to use an enterprise low-code platform as their main internal developer platform by 2028. The business got the power to build, and the business used it.
Then it met scale. Tens of thousands of apps that nobody owns, tests or documents. Critical apps that nobody dares change because the maker who built them has moved on. And complex, high-volume work done through generic forms, one click-through at a time. Our new whitepaper argues that none of this is a governance problem. It is an engineering problem, and agentic engineering has finally made the engineering affordable.
Low-code automated building, not changing
Dragging a form onto a screen and binding it to a table is the easy part. The hard part is everything after version one: knowing what an app does, proving a change has not broken it, releasing it safely and keeping it current as the platform moves on. Benchmarking body ISBSG puts maintenance and support at an estimated 65-85% of software's total cost of ownership.
In a professional engineering team, version control, automated tests and release pipelines carry that cost. In most low-code programmes nobody had the time or skills for them, so the cost turned into risk. Security vendor Zenity estimated in 2024 that the average large enterprise was approaching 80,000 apps and copilots built outside the normal software lifecycle, with 62% carrying a security vulnerability. It sells security for these platforms, so treat the numbers as indicative, but anyone who has run a busy tenant will recognise the pattern.
Low-code has become code
Two changes make the fix practical. First, the platforms now expose apps as source. Microsoft made Dataverse Git integration generally available in April 2025, and code apps, written in frameworks such as React but running under Power Platform's own security, followed in February 2026. Second, coding agents can now work on those files directly: in April 2026 Microsoft released Dataverse skills that teach agents to create tables, relationships, forms, views and solutions.
That turns a low-code app into something an agent can read, explain, change, test and raise for review. It does not make agents infallible. METR's 2025 trial found experienced developers 19% slower with early-2025 tools, and Google's DORA research finds AI amplifies whatever engineering practice it meets. Agents pay off on well-specified work with strong automated checks, which is why the pattern we recommend starts with a specification.
Specify, generate, simplify
People write the specification: the data model, the business rules and who can see and do what. Agents generate the platform layer from it, as source with tests: tables, forms, views, security roles and server-side rules. The platform then supplies what a ground-up build would have to create and maintain, including row and field security, audit history, admin screens and connectors. Where work is complex and high-volume, agents add one task-focused screen over the same secured data.
We used this approach on a recent compliance hub for a regulated distribution group. From a written specification, agents generated and provisioned 38 tables, about 400 columns, 40 main forms, 64 views and 7 security roles, with plug-ins for the order checks, in days rather than months. The hardest area then got a single data-entry screen in place of a series of hops between standard forms.
56%
lower yearly cost to look after 40 low-code apps with two engineers and agents, in our worked example
So why not just code everything?
If agents make code this cheap, the obvious question is why use a low-code platform at all. Our answer: because much of the cost of a business application sits in things the platform already provides, and in regulated settings rebuilding them means re-proving controls the platform already evidences. Where the data model is known and security has to be applied, the platform layer should be the default.
Ground-up code still wins where there is no stable data model, or where the platform's data and security features add nothing: public consumer apps, high-volume customer portals, websites and real-time engines. The whitepaper maps typical applications onto those two questions, from lead management and work scheduling to customer records and reference data.
What the whitepaper adds
The paper has the full worked cost comparison and its assumptions, three lanes for deciding how much engineering each app deserves, the risks and where the approach does not fit, seven steps to put it to work, an app triage template and a readiness checklist for agentic low-code delivery.
Questions directors ask
Is agentic engineering a replacement for low-code?
No. Where the data model is known and security has to be applied, we recommend starting on a low-code platform and letting agents generate and maintain it. Ground-up code is for apps where the platform's data and security features add little.
Do makers still have a role?
Yes. Simple personal and team tools should stay with makers. Shared and business-critical apps get a small fusion team: a business product owner, one to three senior engineers and AI agents doing the volume work.
Is the 56% saving a forecast?
No. It is a worked example on UK contract rates, and it assumes two senior engineers with agents keep up with a team of six. That assumption is the one to test in a pilot.