Back to Blog

The Builder Bridge

AI Leadership Platform Engineering Governance

I used Claude (Anthropic) to help research and write this piece. The analysis and perspective are mine, but Claude did the heavy lifting on synthesizing industry data and making my draft readable.

A portfolio manager at a large asset manager opens Claude Code on a Tuesday morning. By lunch, she has a working application that pulls position data, runs a scenario analysis, and emails the result to her team every morning at 7 AM. She didn’t file a ticket. She didn’t talk to engineering. She just built it.

She is not a developer. She has never been a developer. But the tools no longer care, and neither does the work.

This scene is playing out in every large financial services firm right now. Product managers ship working prototypes in twenty minutes. Designers launch apps with no coding experience. Business analysts construct dashboards that once required engineering support. The democratization of building is no longer a forecast. It is a daily occurrence inside firms whose security, compliance, and operational risk frameworks were not designed for it.

The question every leader is now asking is what to do about it. Lock it down and you forfeit the productivity transformation everyone has been promising the board for two years. Open it up and you turn every department into a shadow IT incubator with a corporate logo on it.

There is a third path. It is a bridge, and your developers are the ones who build it. During a narrow window of twelve to twenty-four months, the work of accelerated developers shifts. Not toward shipping faster, but toward encoding the security, compliance, and operational guardrails directly into the platform itself. As those guardrails take hold, building can open safely to everyone else, not in one move but category by category, as fast as the platform earns it. The bridge is never quite finished; the point is to stay ahead of the blast radius, not to declare it built and wave everyone across. Without the guardrails, it does not open at all.

The builder bridge: three phases. Today building is done by developers only, with rigor enforced by human review. Over the next 12 months developers build the guardrails into the platform. Twelve to twenty-four months out, building opens safely to non-developers because the platform enforces the rigor.
The builder bridge: developers spend the window encoding the guardrails so that building can open safely to everyone else.

1. The Wrong Question

The state of the conversation has settled into three camps.

The first camp says democratize now. Gartner predicted years ago that by 2024, eighty percent of technology products and services would be built by people outside traditional IT roles, a threshold now behind us. LinkedIn has scrapped its Associate Product Manager program and replaced it with an Associate Product Builder track that teaches coding, design, and product skills together. Vendors like Lovable, Bolt, Replit, n8n, and Lindy are positioning their tools as the infrastructure of this shift. The productivity gains they promise are real and the bottleneck of waiting in the IT queue is real. Business teams report sixty to seventy percent reductions in time to deployment when they can build directly.

The second camp says don’t let anyone outside engineering build at all. The empirical case is sobering. A scan by Escape.tech of roughly 1,400 vibe-coded production applications (software built by describing what you want in plain language and letting AI write the code) reported more than two thousand critical vulnerabilities, hundreds of exposed credentials including API keys, and 175 instances of personally identifiable information including medical records and payment data. A controlled study by Tenzai built fifteen identical web applications using five major AI coding agents. Every one introduced server-side request forgery (a flaw that lets an attacker trick an application into reaching internal systems it should never touch), and none of the fifteen set basic defenses against common web attacks. The “big explosions” that David Mytton of Arcjet predicted for 2026 are already starting.

Both camps are missing what Simon Willison, in March 2025, identified as the actual variable. His framing has hardened into the cleanest principle in the field: vibe coding for yourself, where the only person who gets hurt if it has bugs is you, is fine. Vibe coding for others is dangerous. The line is not who is doing the building. The line is the blast radius of what gets built.

This is where the conversation gets uncomfortable for large financial services firms. In a bank, in an asset manager, in an insurer, there is almost no such thing as a personal project. A portfolio manager’s morning report tool reads regulated position data. A product manager’s quick prototype touches customer information. A business analyst’s dashboard feeds an executive decision on flows measured in the billions. The “for yourself, go wild” exemption does not apply, because there is no yourself. The blast radius is always the firm.

So the question is not whether non-developers should be allowed to build. They already are, and the trend is irreversible. The question is what the platform enforces when they do.

2. The Four Pillars, and Who Builds Them

In January 2026, Asif Awan, co-founder of Stackgen, published a forecast on the Cloud Native Computing Foundation blog that has not received the attention it deserves outside platform engineering circles. The CNCF is the open-source foundation that houses Kubernetes and the infrastructure software most modern enterprises run on. When it publishes a forecast, it represents the practitioners who actually operate this layer at scale.

Awan’s framing was deceptively simple. A generic guardrail approach to governing AI agents in production is insufficient, he argued. Success depends on a clear taxonomy of controls. He proposed four pillars: golden paths, guardrails, safety nets, and manual review workflows.

Golden paths are the curated, pre-approved blueprints that make the secure and compliant choice the easiest choice for the builder. Standardized infrastructure modules. Self-service portals. Service templates with security, monitoring, and cost controls already baked in. In the 2026 evolution Awan describes, golden paths become “intent-to-infrastructure” experiences. A builder describes what they need in natural language. An agent composes, validates, and provisions the compliant infrastructure along the path automatically. The builder never thinks about compliance, because the path itself is compliant.

Guardrails are the hard, non-negotiable stops that prevent actions which would compromise security or stability, like blocking a public storage bucket. In a financial firm, the guardrails that matter most govern what data an application can read and where its output can flow. That is where the blast radius lives, not in a missing security header. The direction Awan forecasts turns these from reactive scanners into proactive enforcers: policy-as-code agents translate the mechanizable parts of compliance into executable rules, auditor agents assemble evidence trails, drift remediation agents flag unauthorized changes.

Safety nets are the reactive controls (monitoring, automated rollbacks, backups) that catch failures and speed recovery, and the forecast pushes them toward predicting outages before users ever feel them.

Manual review workflows are the human-in-the-loop checkpoints reserved for the highest-blast-radius decisions (the consequential few, not the routine many), where AI does the prep, handing the reviewer a risk score and a recommendation so the gate is a fast, informed call rather than a bottleneck.

The line in Awan’s piece that should be on every CTO’s whiteboard is this: the goal is for AI to ensure that developers rarely, if ever, encounter a guardrail by guiding them through the golden path. Extend that principle one step further and you have the answer to the democratization question. The goal is for anyone, developer or not, to never encounter a guardrail, because the path itself is safe by default.

This is the work of the bridge. It is also, almost entirely, what your developers should be doing right now.

3. The Leadership Decision

There are two ways to get this wrong.

The first failure mode is letting non-developers build without guardrails in place. A KPMG survey of European companies found that fewer than a third of low-code users had governance rules in place (low-code being the tools that let non-engineers assemble software with little hand-written code). The vibe coding vulnerability data tells you what happens at scale when this becomes the default. The damage compounds because every shadow application built today will need to be either remediated or replaced when the platform eventually arrives, and the cost of remediation always exceeds the cost of building it right the first time.

The second failure mode is more subtle. It is using accelerated developers to ship the same features faster, missing the once-in-a-decade opportunity to redirect engineering capacity toward platform work that compounds. Every guardrail your developers encode, every golden path they curate, every safety net they wire up reduces the rigor burden on every future builder, indefinitely. Velocity on feature delivery does not compound. Platform infrastructure does.

Three things should be on every leader’s agenda right now.

The first is to redirect a meaningful portion of developer capacity toward platform work. Not all of it. Feature delivery still matters. But the question every engineering leader should be answering for their CEO is: what fraction of our accelerated capacity is going into the four pillars, and what fraction is going into running faster on yesterday’s roadmap? In most firms the answer is honest only if it is uncomfortable. Goldman did not ship Devin, an AI software-engineering agent, just to write the same code three times faster. The bet worth copying isn’t speed. It’s pointing that capability at the platform itself, at the agents that will, over time, carry more of the compliance and operational load. And they carry it under human accountability no regulator is going to relax in this window. Capacity pointed at the platform, not the backlog. That is the playbook.

The second is to make your firm’s golden paths explicit. Every organization has implicit paths today: the way things tend to get built, encoded in tribal knowledge and senior engineers’ heads. In an agentic world (one where AI agents take actions on their own, not just answer questions), implicit paths break. They cannot be enforced by an AI agent, they cannot be discovered by a non-developer using a natural language prompt, and they cannot scale. For the top ten things that get built in your firm (a new data pipeline, a new dashboard, a new client-facing integration, a new internal tool, a new analytical workflow), what is the compliant, secure, cost-managed default path? Until that is documented, instrumented, and AI-enforced, opening building to non-developers is reckless. Documenting it is engineering work, and it should be on a roadmap.

The third is to sequence the democratization deliberately. The mistake is treating the dev-or-not question as binary. It is not. Different categories of building have different blast radii, and the four pillars will mature at different rates for each. Internal productivity tools drawing on already-governed data are probably ready first. Customer-facing applications, regulated reporting workflows, and anything touching trading or risk systems are last. Pick the first category where the four pillars are mature enough to make non-developer building safe. Open that door. Measure what happens. Use the learning to sequence the next opening. This is an organizational design exercise, not a policy decision.

The portfolio manager who built her morning report tool on a Tuesday is not the problem. She is a signal. She is showing you exactly what your firm is going to look like in twenty-four months, and asking, implicitly, whether you have built the bridge to get there safely or whether she is the first person to step off the edge.

The rigor has to go somewhere, as Martin Fowler’s retreat concluded earlier this year. It is now clearer where. It goes into the platform. It goes into the four pillars. It goes into the agents your developers build during this window, while they still have the window. The firms that use the window to build the bridge will look back on this period as the moment they made democratized building safe. The firms that use the window to ship features ten percent faster will look back on it as the moment they let the shadow IT problem they had been managing for twenty years become the systemic risk they could no longer contain.

The bridge does not build itself. The window will not stay open.

References

Share this article