Low-Code in 2026: What It Changes for Developers

Low-code has become a normal part of business application delivery. It has not made professional developers obsolete, and there is no reliable basis for saying that a fixed percentage of all application development now belongs to low-code.

The useful question is simpler: which parts of your application can a low-code platform handle well, and which parts still need software engineering?

First, retire the 75% headline

Historical claim: The previous version of this article said that 75% of new application development would use low-code by 2026. It attributed the figure to Gartner but did not link to the original research.

We could not verify that exact claim from an accessible primary source, so it should not be treated as a measured result. Forecasts are also not adoption data. Even a correctly cited prediction would tell us what an analyst expected, not what organisations actually built.

Current evidence: Gartner's February 2026 research summary says strategic low-code adoption can accelerate delivery, while rushed adoption often creates waste. That is a more useful starting point than a market-share slogan.

What low-code actually changes

Low-code moves some work from writing infrastructure and interface code towards configuring components, data and rules.

In Microsoft Power Platform, a maker can assemble a Power Apps interface, connect approved data sources and automate parts of a process. Microsoft describes Power Fx as a strongly typed, declarative language with spreadsheet-like formulas. That is more approachable than many general-purpose languages, but it is still logic that must be designed, tested and maintained.

Microsoft's own Power Platform role guidance includes makers, professional developers, architects, administrators, security specialists and data stewards. That is a strong clue about the real operating model: low-code broadens the delivery team rather than removing the technical roles.

Work that often fits low-code

departmental forms and approval workflows
mobile apps for structured field work
replacements for shared spreadsheets and email-based processes
internal apps that use supported connectors and clear permission rules
prototypes used to test a workflow before a larger investment

Work that deserves more engineering scrutiny

safety-critical or highly regulated systems
complex transactional workloads
products with demanding latency or offline requirements
unusual integrations, custom protocols or heavy data processing
systems that need deep automated testing, portability or precise control of runtime behaviour

This is not a permanent boundary. Platforms change, and the decision depends on the actual requirements. Treat it as an initial filter, not a verdict.

The developer's role is shifting, not disappearing

Evidence: Microsoft's application lifecycle management guidance treats governance, architecture, testing, deployment, monitoring and maintenance as part of the application lifecycle. Its guidance covers traditional developers and app makers rather than presenting them as competing groups.

Inference: As routine construction becomes easier, more value moves into work that a visual designer cannot decide for you:

translating a messy business process into clear requirements
choosing the right data model and security boundary
deciding when a connector is safe and supportable
reviewing formulas, custom code and generated output
designing test cases and failure handling
managing environments, releases and ownership
knowing when low-code is the wrong tool

AI-assisted building strengthens this pattern. A prompt can produce a plausible screen or formula quickly. It cannot accept accountability for incorrect permissions, lost records or an unsupported production app.

Citizen development needs an operating model

Giving more people the ability to build can remove a queue at the IT department. It can also create orphaned apps, duplicated data and unclear support obligations.

Microsoft recommends role clarity and governance as Power Platform adoption grows. Its citizen-development ALM scenario recommends discussing environment strategy, access and security with the organisation, then moving shared apps and flows into solutions and a managed lifecycle.

A sensible minimum is:

Name an owner for the business process and an owner for the application.
Classify the data before connecting it.
Build outside production.
Use solutions and separate development, test and production environments when the app matters to the business.
Record dependencies, service accounts and recovery steps.
Test permissions, failure paths and handover, not only the happy path.
Review whether the app should be rebuilt, retired or moved to another platform as it grows.

What can we forecast responsibly?

Forecast: Low-code is likely to remain an important option for workflow-centred business apps because major vendors continue to invest in it and organisations still need more software than specialist teams can build alone.

That does not prove that low-code will dominate a set percentage of development, reduce total cost in every case or replace professional developers. Licensing, governance, integration, maintenance and vendor dependency can change the economics.

The better career bet is not to choose between “real code” and low-code as if one must win. Learn to frame the problem, select the least complicated suitable tool and deliver something another person can safely operate.

If Power Apps is part of that decision, join the Power Apps Builders Space to work through practical build and governance questions with other practitioners.