A proprietary framework becomes
a cage with no exit.

Lock-in is the state in which migration cost is high enough that nothing moves.

The previous chapter showed that the disappearance of the SIer commission model is inevitable. Even so, customers do not move at once. The reason they cannot move is lock-in. This chapter decomposes the three layers of lock-in and reads Palantir's FDE model as the archetype. It then shows why AI-native development is structurally bad at producing lock-in in the first place.

Lock-in is built out of three layers

What makes the SIer commission model anchor a customer is three layers stacked on top of each other.

The first layer is proprietary frameworks. These are the SIer's in-house standard frameworks, its custom packages, its custom operational stacks. A system running on them can only be maintained by the SIer itself. Switching vendors means rewriting the framework along with everything else.

The second layer is proprietary abstractions and Ontology. The customer's business concepts get expressed in vendor-specific models. Customer master, product master, business flow — once these are encoded in the vendor's own abstractions, another system cannot reproduce the same meanings. Semantic compatibility is lost.

The third layer is human dependency. Implicit specifications live only inside the heads of the engineers who have maintained the system for years. When the SIer's team leaves, the knowledge leaves with them. Documentation is stale, code is hard to read, and a new joiner cannot find a way in.

One layer on its own can sometimes be undone by switching vendors. When all three are active, migration becomes practically impossible. The high price an SIer commands rides on top of these three layers.

Palantir's FDE model maximizes all three layers

The form that maximizes all three layers of lock-in is Palantir's FDE (Forward Deployed Engineer) model. In the world of software commissioning, it is known as the most polished form of customer attachment. It is also the most binding.

How the FDE model works:

• Palantir's engineers (FDEs) are embedded for long periods inside the customer's organization.
• The customer's operations run on Foundry / Gotham, Palantir's proprietary platforms.
• Business concepts are translated into Ontology, Palantir's proprietary semantic model.
• Contracts span years, and the engagements are large.

All three layers of lock-in are active.

• Proprietary frameworks — Foundry and Gotham only run on Palantir.
• Proprietary abstractions — Ontology is Palantir-specific. There is no practical semantic migration path to another system.
• Human dependency — FDEs physically sit inside the customer and absorb operational knowledge. Pull the FDEs out and the knowledge goes with them.

The result is that what customers pay Palantir is far above the commodity price of software development. The price is not set by competition. It is set by the premium that the lock-in structure sustains.

Read this as the fully refined form of the SIer commission model. The Japanese SIers use, at different scales, the same three layers to anchor their customers. Palantir has taken that mechanic and optimized it globally for military, intelligence, and large-enterprise customers.

AI-native development produces standard code

From here, look at why AI-native development is structurally bad at producing lock-in. The largest reason is that AI tends to write standard code.

• In Python: the standard library plus major OSS packages (Polars, SQLAlchemy, FastAPI, Pydantic, and so on)
• Data: standard formats (JSON, CSV, Parquet, SQLite, PostgreSQL)
• Configuration: YAML / TOML
• Documentation: Markdown
• Diagrams: Mermaid

Why does AI choose standard? AI was trained on a large body of public code. The majority of that training data is standard libraries and standard formats. AI outputs the form that is statistically easiest to write. As a result, its output lands biased toward standard libraries and standard formats.

There are three side effects.

• Proprietary frameworks do not grow easily — the same problem gets solved with the same standard.
• Proprietary abstractions do not grow easily — AI prefers standard abstractions over custom ones.
• Code is easier to read — anyone with general knowledge of the standard libraries can read it.

In other words, simply doing AI-native development produces, naturally, a structure that does not generate lock-in. The avoidance is not deliberate. The standard is what you reach for because it is faster.

Another AI, another builder can take it over

Look more concretely at how lock-in dissolves. An AI-native code base has these properties.

• Standard libraries at the center — another builder sees code built out of libraries they already know.
• The design lives in Markdown — structure is recorded in a form shared between humans and AI (1-04).
• AI regenerates tests and documentation — knowledge is not pinned outside the code base (1-02).
• Data formats are standard — JSON, Parquet, SQLite, readable by other systems too.

What this means is that another AI or another builder can pick up the work at minimal cost.

• Switch to another vendor's AI model and the code keeps running.
• The original builder leaves, and the successor reads the code with AI and understands it.
• The customer decides to go in-house, takes over the code, and keeps building.
• The customer wants a different service vendor for maintenance, and that works too.

None of these options is structurally available in the SIer / FDE model. The absence of lock-in is the structural strength of AI-native development.

Where lock-in stays, and where it dissolves

Sort engagements by whether lock-in keeps holding or whether AI-native development can dissolve it.

Lock-in stays in these cases.

• Core business systems still running on legacy Palantir or SIer proprietary frameworks — migration cost is hard to see.
• Engagements in regulated industries where "track-record SIer maintenance" is a regulatory requirement — migration needs the regulator's consent.
• Long-term maintenance contracts mid-flight — the customer cannot move while the contract runs.

Lock-in dissolves, or never forms, in these cases.

• New projects started AI-native — no lock-in is generated.
• AI-native extensions added on top of existing systems — the core stays as it is, and the new part is AI-native. Lock-in dissolves on the extension side first.
• Expiry of an SIer maintenance contract — at the next renewal window, the customer can evaluate AI-native replacement.

The ordering is that new projects and extensions move first. Core business systems move only when contract expiry, regulatory clearance, and migration cost assessment all line up. Even with a large price gap, not every engagement moves at the same speed.

The overall pace of the industry shift — Japan's multi-tier subcontracting, labor mobility, the transitional contract forms — is treated in 3-07.

Vendor AI and backward compatibility are a second lock-in

Everything so far has been about the development lock-in of the SIer-commissioned model. Separate from it is the lock-in of vendor AI (Copilot and the like) itself. It is a form in which the intelligence running underneath can be swapped for a cheaper in-house model without the user's consent. In June 2026, Microsoft's AI chief Suleyman said openly that the company's goal is to "ultimately eliminate" what it pays Anthropic. Even when development lock-in dissolves into standard code, entrusting your workflow to one vendor's AI creates a different dependence. The principle of keeping judgment and tools on your own side applies here too (→ Building a Microsoft 365 equivalent yourself).

And Microsoft's deepest lock-in is backward compatibility itself. By carrying old APIs and old behaviors without cutting any of them, it keeps customers from switching. But that same backward compatibility breeds a complexity no one grasps whole, and holes hidden in old code. In fact the Entra ID authentication flaw CVE-2025-55241 (CVSS 10.0) let an attacker impersonate a global administrator in nearly every tenant in the world, because a legacy API left in place for backward compatibility failed to validate the token's issuing tenant. The M365 Copilot zero-click leaks (EchoLeak and others) share the same root. Since attack and verification are the same power to understand deeply (1-01), in the age of an AI that can attack, such old holes get exposed faster and more surely than before. Yet Microsoft cannot abandon backward compatibility. Abandon it and the company becomes healthy, but it loses the power to bind customers. Becoming healthy and losing dominance are one and the same act. So it keeps the cage, and keeps having its holes made visible (→ blog When Fable 5 Returns, Do This First).

The counter-axis to all of this is open source. Once, open source's "the source is published" meant something only to specialists. It was also held to be inferior to proprietary software on being polished and ready to use. But with AI beside you, you can handle installation, operation, and extension yourself. The value of open source and proprietary software reverses. Being open becomes a practical benefit for the first time, and you stand on the side where lock-in does not bite.

Summary

Lock-in is the state in which migration cost is high enough that nothing moves.

• Three layers — proprietary frameworks, proprietary abstractions and Ontology, human dependency
• Palantir's FDE — the end-state form of SIer commissioning, maximizing all three
• AI-native development — biased toward standard libraries and standard formats, so none of the three layers grows
• Handover — another AI, another builder, or the customer themselves can continue the work
• Ordering — new projects and extensions move first, core business systems last
• A second lock-in — vendor AI, and Microsoft's backward compatibility

Wherever lock-in dissolves, customers will need builders. Whether the builder is in-house or external, the customer is bringing in management that makes business decisions — the CIO. The capacity to see lock-in coming and to design a way out of it is the capacity to read the vendor's pitch against itself, to verbalize your own organization's interests, and to define the criteria for an alternative. All of these fall inside the liberal arts (1-04).

The next chapter takes up the era in which companies hire builders — how builders get positioned, how they are paid, and how they function.

Related articles

• 1-03: AI Now Does the Software Engineer's Work
• 1-04: The Builder Role
• 3-06: Companies Hire Builders
• 3-07: Japan's SIer Industry Transition and Labor Mobility
• Structural analysis 08: Subtracting the enterprise-IT tax
• Structural analysis 12: AI and the sole proprietor
• Can You Build a Microsoft 365 (Standard + Copilot) Equivalent Yourself?