Five Software Development Trends, and What They Actually Change

Every list of software development trends is accurate and slightly useless. The trends are real. What is missing is the part that decides whether adopting one helps you: what it actually changes about how a project runs, and where it quietly creates new work.

Here are the five that come up most in client conversations, and our honest read on each.

AI-assisted developmentReal leverage on scaffolding and tests. Review capacity becomes the bottleneck.

Low-code and no-codeFastest route to a working product. Data model and permissions still decide whether it scales.

Cloud and DevOpsAssumed rather than argued. The open questions are cost and operational maturity.

Progressive web appsRemoves the install step. Worth it when reach matters more than deep device access.

MicroservicesPowerful at the right size. Premature adoption buys distributed-systems problems early.

What does not changeData modelling, permissions, and knowing what to build. Every trend above sits on top of these.

How we weigh each of these on client work.

1. AI-assisted development

Gartner expects 75% of enterprise software engineers to be using AI code assistants by 2028, up from around 10% in 2023. That trajectory is not in doubt, and the productivity gain on certain work is obvious — scaffolding, boilerplate, test generation, unfamiliar API surfaces.

What the adoption numbers do not tell you is where the constraint moves. When generating code gets cheap, review becomes the bottleneck, and the failure mode is not rejection — it is approval with less attention. Teams that get real leverage change their review practice deliberately: smaller changes, tests treated as the contract, and a written list of what always needs human eyes (auth, payments, migrations, anything touching personal data).

Two engineers working through a problem at a workstation — The constraint moved from writing code to deciding what should be written, and checking what came back.

2. Low-code and no-code

Forecasts have put low-code behind the majority of new business applications, and on delivery speed the claim holds up — dramatically so for the first working version. We build production systems on these platforms every week, so this is not a sceptic’s take.

The caution is about what the platform does not decide for you. A visual builder handles the screens. It does not tell you whether your data model will survive year two, who should be able to see which record, or which workflows belong in the background rather than tied to a user session. Those are the decisions that determine whether a fast build becomes a durable product, and they are engineering decisions regardless of how the interface is assembled.

A development team reviewing work together — Low-code shifts who can build, not whether engineering judgement is needed. The review still has to happen.

3. Cloud and distributed teams

This one has finished arriving. Cloud is not pitched any more; it is assumed. The interesting questions have moved from whether to adopt it to how to operate it: cost visibility, environment parity, and whether your team can actually run what you have deployed.

The trap we see most often is a modern deployment target with no operational discipline behind it — no cost monitoring, no tested recovery path, no clear owner for upgrades. The platform is not the achievement. What you can do reliably on it is.

4. Progressive web apps

PWAs remove the install step, work offline, send push notifications, and run from one codebase across devices. For a business whose users will not download an app for a service they use twice a year, that is a genuinely better answer than a native build nobody installs.

They are not a universal substitute. Deep hardware access, background processing, and certain platform integrations still favour native. The decision comes down to whether reach or device capability matters more for what you are building — and that is a product question, not a technical one.

5. Microservices

Independent services, deployed and scaled separately, communicating over APIs. At the right size the benefits are real: smaller blast radius, independent scaling, teams able to move without coordinating every release.

At the wrong size it is a tax. A small team splitting an application into a dozen services before there is traffic to justify it has bought distributed-systems problems — network failure between components, data consistency across boundaries, tracing a request through five hops — without the scale that makes those trade-offs worth accepting. A well-structured monolith you can split later is usually the better starting point.

Every trend on this list is a genuine improvement in the right context. Adopting one because it is current, rather than because it solves a problem you actually have, is how technical debt gets built on purpose.

What has not changed

Underneath all five, the same things still determine whether a piece of software works: a data model that reflects the domain, permissions decided at design time rather than audited before launch, and clarity about what is being built and why.

The tools have improved enormously. What they have not done is remove the need for judgement about how to use them. That is the part we get paid for, and it is the part that stays constant while the trend list turns over.

Sources & further reading

← All articles