AI is now table stakes. The differentiator is the control layer around it.
In 2026, “AI coding” no longer means autocomplete. It means agents writing, testing, reviewing code end to end. Anthropic’s 2026 trends report tracks the same shift.
Here is the catch: your competitors use the same LLMs and the same coding agents you do. On the model side, LLMs like Claude, GPT, and Gemini are all commercially available. On the agent side, coding agents like Claude Code, Codex, and Cursor lead a fast-moving field. If your AI strategy is “we use Claude”, you have a vendor — not a strategy.
What separates firms that win with AI is not the AI. It is the control layer around it. AI is the engine. You still have to steer.
Four principles follow.
1. Control Your Architecture and Information
If you surrender your architecture to AI, the system quickly becomes AI slop — a tangle of generated code no one understands, where every change makes the next one harder, until eventually the team can no longer proceed. Architecture is what prevents that outcome.
When AI gets things wrong, the blast radius is a function of how tightly your architecture contains the impact. That is within your control.
Your software architecture directly determines your AI success. Bounded contexts. Clear contracts. Stability at the bottom, iteration at the top.
The insureMO architecture is built exactly this way:
- Project Zone (yours): Web UI, Agent UI, Business APIs.
- insureMO Platform (the foundation): 2,000–3,000 atomic insurance APIs, documented, versioned, battle-tested over a decade.
2. Scope Small — Tasks and Codebases
AI performs best with small, well-bounded work. The corollary: AI fails best under the same conditions.
A 500,000-line monolith with tangled dependencies is hostile to agents — context overflows, edits ripple, verification is slow. A 500-line business API or a 1,000-line UI page with clean purpose and interface are the opposite: the agent holds the whole context, changes are localized, and rollbacks are cheap.
The standard monolith vs. microservices debate treats the microservice as the smallest unit of independent deployment. insureMO pushes that boundary one layer finer. In iComposer, each API is independently developed and deployed, even though those APIs ultimately run inside a single Java Spring service. In UIC, each UI page is its own unit — built, iterated, and shipped without impacting any other page. The blast radius of any change drops from a whole service to a single API or a single page.
insureMO bakes this in three ways:
- UI Connector (UIC) — typically a few hundred to a few thousand lines per page. Auth and base infrastructure are predefined by the platform. Even a fully vibe-coded page is one rollback away from clean.
- iComposer — a simplified scripting style that shrinks business-logic code by ~10x. A typical API is just a few hundred lines. Less code, less to break.
- Atomic APIs — agents compose pre-built services instead of reinventing insurance from scratch.
3. Lower the Skills Bar with the Right Infrastructure
The bottleneck on AI adoption is not the AI. It is not even a senior vs. junior question. It is about who has tools. When the right infrastructure is in place, people closer to the business — analysts, product managers, operations staff — can prototype ideas and build small functions for their own use cases, not just wait on engineering.
This is not the “one-person company” extreme. It is the same philosophy at the team level: simplify the communication overhead by giving the same tools to more people, and productivity with AI compounds. The opposite is the traditional model, where even a small UI change required a professional UI developer — every request a ticket, every iteration a sprint.
Crucially, you can only do this comfortably because principles 1 and 2 are already in place. Handing more people AI tools is reckless without architectural boundaries that contain the blast radius, and without small scoped units of work that an agent can complete safely. Lowering the skills bar rests on first controlling the architecture and scoping small.
Good governance amplifies this rather than throttling it. The FSB’s twelve sound practices makes the same point: clear ownership and well-defined risk boundaries are what make it safe to give more people more powerful tools.
4. Be LLM- and Agent-Agnostic
Models and coding agents change every quarter. Anything hard-coded to one model or one agent becomes technical debt within a year.
- Be model- and agent-agnostic — swap LLMs and coding agents based on cost, latency, or capability. Never lock yourself to one provider on either side.
- Document your process as standalone markdown — practices, runbooks, and conventions live as plain markdown files any agent can read, not as config inside one agent’s proprietary format.
- Build a portable harness — testing, log-checking, and deployment tools should be CLI commands or skills any coding agent can invoke, not scripts wired into one agent’s plugin system.
LLMs and coding agents are tools, not competencies. Treat them like a database or a message queue: pick a good one, but never build on the assumption that only one will ever exist.
The Unspoken Fifth Principle: Domain Depth
None of the above is generic to insurance for free. Insurance carries its own data models, regulatory regimes, product structures, and rate / claim / reinsurance logic. A vertical platform that has spent a decade encoding those rules into atomic, documented services gives the AI a head start no general-purpose tool can match.
That is the Vertical PaaS thesis — and it is why a bet on insurance-specific AI-friendliness is the substrate that makes the four principles above actionable.
2026 Is the Defining Year
2026 is when AI governance in insurance moves from ambiguity to definition. The firms that come out ahead will be the ones who treated AI not as a tool to adopt but as an engineering discipline to own.
Own your architecture. Scope small. Lower the bar. Own your tools.
AI is the engine. You still have to steer.