Ivan Zhao, Notion's CEO, recently described his co-founder as "a manager of infinite minds"—orchestrating multiple AI coding agents at once to become a 30-40× engineer. At FRAGMENT, we see the same thing. The productivity multiplier is real.

But managing infinite minds requires giving them structure. Two failures show up over and over: hallucinations and slop. Hallucinations invent things that don't exist. Slop is the gradual drift that turns a clean codebase into a house of cards.

This post describes how to prevent both. We call the technique Deterministic Boundary Programming. The principles work with any stack. But FRAGMENT is built for it; we give you the structure to do it right. Here's how.

The most common mistake isn't using AI to write code. It's using AI without anything deterministic for it to push against.

You prompt "build me a payments flow" and the model does whatever it takes to make something work. It invents types, infers constraints, and makes up field names that sound right. The code compiles, runs, and looks plausible.

Then you prompt again. And again. Each time, the model works from its own previous inventions, which it only half-remembers, plus whatever new constraints you've implied in your latest prompt. There's nothing external enforcing consistency. No schema must validate. Generated types won't fail to compile. No rigid checkpoint exists between sessions.

This is how a codebase turns to jelly. Not through one catastrophic failure, but through a thousand small drifts that nobody notices until the whole thing feels unreliable.

The model isn't broken. It's just unconstrained. And unconstrained AI optimizes for "make the prompt work," not "preserve architectural integrity."

You already know what rigid layers look like. You've been building them your whole career.

A test either passes or fails. It doesn't care who wrote the code it's testing. A type constraint either compiles or it doesn't. The compiler won't negotiate.

Your database has opinions too. Foreign keys reject orphaned references. Unique constraints block duplicates. NOT NULL means not null. The database doesn't care what your application intended to do.

Then there's everything your CI pipeline enforces. Linting rules that reject forbidden patterns. Bundle size limits that block bloated builds. Accessibility checks.

All of these share the same quality. They define what is acceptable, and they reject what isn't.

You can ask AI to help you build any of these. Prompt it to write tests, generate types, draft lint rules, define schemas. But the rigidity isn't in the artifact itself. It's in the relationship between the artifact and the code it governs. The test defines what success means. The code must satisfy it. That binding cannot be bypassed.

The AI helps you build the cage. Then the cage constrains the AI.

Think of buildings in earthquake zones: they alternate rigid slabs with flexible bearings. Your spine alternates vertebra and disc. Pure rigidity fractures. Pure flexibility collapses. The alternation is the only stable structure.

This is Deterministic Boundary Programming.

So far we've described a general principle. Now we'll show what happens when a platform provides the rigid layers for you.

FRAGMENT is a toolkit for building products that move and track money. When you build on FRAGMENT with AI, the rigid layers—schema validation, SDK generation, type enforcement—are already there. You don't build them. You use them.

FRAGMENT schemas are declarative and deterministic. They define accounts, entry types, and conditions with absolute clarity. You either conform to the schema or you don't.

You can let AI draft these schemas. But every schema must pass FRAGMENT's validator. If it doesn't validate, it does not exist.

The Dashboard includes a Schema Designer that makes this checkpoint tangible. As you design your ledger structure, the designer validates in real-time. Entry types must balance according to the accounting equation.

When validation fails, the feedback is immediate. If the AI drafts an entry type that doesn't balance, the error appears instantly. Often the AI can see the issue and correct itself; sometimes you step in. Either way, the loop is tight: try, fail, fix, try again.

Once you store your schema, you can generate a type-safe SDK customized to your design.

This is not documentation. This is the truth of your ledger, encoded in types. Entry types become strongly-typed functions. Parameters become typed arguments. Constraints become things TypeScript enforces.

The SDK is a contract. When AI writes code that uses FRAGMENT, it must use this SDK. The types won't compile if it tries to access fields that don't exist. There is no gap between what you designed and what gets built.

Now the AI can write application logic. It can move quickly and creatively. But the SDK contract cannot be breached. Fields that don't exist cannot be invented. Entry types cannot be misused. The boundaries hold.

The model can draft a payment handler, but the types won't let it hallucinate fields. The SDK enforces posting correctness. Schema redesigns are constrained to only those that validate.

AI moves fast in the loose layers. The rigid layers keep it honest.

The process starts with Fragment's API as your foundation. This rigid platform provides the ledger infrastructure. Everything else builds on top.

Here's how the process works when building an application with AI and FRAGMENT:

1. Draft your schema (loose layer). You design a ledger schema for your use case. Most users work in the Schema Designer; power users can have AI draft schema JSON and validate via CLI.

I'm building a prepaid card program. Design a ledger schema to track
card balances, loads, and purchases. Output valid Fragment schema JSON.
Run `fragment validate-schema` and fix any errors before responding.

2. Schema Designer (rigid layer you control). Whether you designed in the browser or drafted with AI, you validate here. The designer checks in real-time—entry types must balance according to the accounting equation, conditions must be satisfiable, account paths must be valid. You can iterate freely, but the designer enforces structure. Nothing invalid can be stored.

3. SDK generation (rigid layer). When you store your schema, FRAGMENT validates it. You then generate a type-safe SDK customized to your design using the CLI. Invalid schemas are rejected—the AI can iterate and refine, but it cannot proceed until the schema validates. This custom SDK becomes a contract: it ensures that all application code you write actually matches your schema design.

4. AI writes application code (loose layer). With your custom SDK in place, the AI can now write your application logic. Payment handlers get created. UI components get built. Workflows get designed. Business logic gets implemented. It has freedom to explore and iterate, but when it accesses FRAGMENT functionality, it must use your schema-specific SDK, which enforces type safety and correct usage.

Write a function that processes a card purchase using my Fragment SDK.
Debit the card balance and credit the merchant. If the balance is
insufficient, return an error—don't modify the ledger.

5. Tests (rigid checkpoint). You write tests that define your business requirements—what should happen, what shouldn't, and what must always be true. AI can write these too. Once written, the tests constrain all future changes—AI or human.

Write tests for processCardPurchase. Verify that:
1. A valid purchase debits the card and credits the merchant
2. Insufficient balance returns an error without modifying the ledger
3. The same idempotency key produces the same result
4. The ledger stays balanced after every operation

The result is a layered architecture where rigid checkpoints prevent drift:

Each enforcement point binds code to a contract it must honor. Each loose layer gives room to explore. The alternation prevents drift while preserving freedom.

The rule we eventually wrote down is the one we now teach: Never let AI output become real without passing through a deterministic checkpoint.

Give it freedom to create. Make it prove correctness before anything lands. Alternate the two as your system grows. Schema draft to Schema Designer to SDK to AI code to tests. Rigid to loose to rigid to loose to rigid.

This is Deterministic Boundary Programming. FRAGMENT's architecture allows you to take full advantage of this technique. The declarative schemas, validation checkpoints, and generated SDK contracts provide the boundaries that prevent drift. Once you start working this way, it's difficult to imagine trusting AI in a fintech codebase any other way.