The paved road

Everyone has the same ambition for AI now: not just engineers, but every person in the business able to build the thing they need. It's the right ambition. Most attempts at it will fail — and they'll fail for a reason we've watched play out before.

The bottleneck was never the building

We have run this experiment. For twenty years it was called low-code, then no-code, then citizen development. The analysts predicted armies of business users building their own software and outnumbering professional engineers. It didn't happen — not because the tools were too clumsy (they got good) but because building was never the hard part. Integration was. Security was. Ownership, lifecycle, the unglamorous business of keeping a thing alive and compliant after launch — that was the bottleneck, and low-code never touched it.

LLMs are genuinely different in one respect: they demolish the authoring barrier in a way drag-and-drop builders never did. Describe it in English, get working code. But authoring was the part that was never the constraint. Everything that actually sank citizen development — integration, security, ownership — is exactly as hard as it ever was, and now there is far more of it.

Three responses, two of them lose

Faced with this, organisations reach for one of three responses.

Banning it forfeits the upside and drives the demand underground — the shadow-IT lesson, re-run at higher speed. APRA saw this one coming too: its April 2026 letter flagged "the use of enterprise AI tools by staff outside approved control frameworks" as a specific concern. Say no, and people route around you, and now you can't even see it. Letting everyone build is the sprawl from the last post: thousands of unowned tools, each a latent finding. The third response is the only one that works, and it is the oldest idea in platform engineering.

Pave the road

Netflix called it the paved road; Spotify calls it the golden path. A supported, opinionated way to build that teams take not because they're forced to, but because it's the path of least resistance. You make the compliant way the easy way: identity, secrets management, dependency provenance, logging, and an owner assigned at the moment of creation — all baked into the road, so that staying on it is less work than leaving it, and any tool built on it inherits its controls for free.

This is what APRA was actually asking for when it criticised "relying primarily on policy direction ... rather than enforceable technical restrictions". A paved road is enforcement that doesn't feel like enforcement. The control isn't a policy you're asked to read; it's the default you'd have to work to escape.

The engineer's job changes

Here's the part that matters if you build software for a living. If the goal is to put AI in 8,000 hands — or 50,000 — the highest-leverage thing an engineer can build is no longer the tool. It's the road every non-engineer's tool is forced to drive on. The work shifts from writing applications to encoding judgement — the organisation's standards, its controls, its hard-won lessons — into defaults that hold by construction.

Team Topologies has the language for it: a platform team whose product is the paved road, and an enabling team that helps others onto it. The deliverable isn't features. It's leverage — the guardrails that let a lot of people move fast without the organisation losing the plot.

Democratisation and control look like opposites. They aren't. Without a road, democratisation is just the sprawl. The road is how you get the upside of one without the downside of the other — and building it well is, I think, the most valuable engineering work going right now.

My own opinion, not the Group's.