Everyone is writing more code than ever. Few are shipping proportionally more.

AI coding agents produce a lot of plausible-looking code. But two failure modes keep that code from reaching production: silent failures and slop. Silent failures are code that the agent says is "done" but that doesn't actually work; it's not reading real data, not making the right side effects, not doing what you asked. The agent passes in nonexistent data, observes an error, and considers the task complete. It claims success without verifying the output against real data. Slop is the gradual drift that accumulates when nobody checks: a thousand small inconsistencies that turn a clean codebase into a house of cards.

Both have the same root cause: AI that is unconstrained by anything deterministic. And the same fix. We call it Deterministic Boundary Programming. The principles work with any stack, but FRAGMENT is built for it. Here's how to apply it.

The mistake is using AI with nothing deterministic 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. The agent says "done." But when you test it against real data, the payment doesn't go through. The fields don't map to anything. The side effects never fired.

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. Nothing enforces schema validation. No type system catches the errors. No rigid checkpoint exists between sessions. LLMs are unreliable narrators; when they say they're "done," you need to check.

This is how code piles up without shipping: silent failures that look like progress, and drift no one notices until the codebase feels unreliable.

The model isn't broken. It's just unconstrained. And unconstrained AI optimizes for "make the prompt work," not "verify the program does what you think it does."

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 do the same thing: they define what's acceptable and 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. Pure rigidity fractures. Pure flexibility collapses. The alternation is the only stable structure.

This is Deterministic Boundary Programming: alternate deterministic checkpoints with creative freedom. Let AI generate freely in the loose layers. Force its output through rigid validation before it becomes real.

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; every debit must have a matching credit, every account path must resolve, every currency must be declared. You either conform to the schema or you don't.

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

The Dashboard's Schema Designer makes this checkpoint tangible. As you design your ledger structure, the designer validates every constraint in real-time.

When validation fails, the feedback is immediate and specific: "entry type 'card_purchase' does not balance—debits exceed credits by 500." The AI can see the issue and correct itself. The loop is tight: try, fail, fix, try again.

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

This is not documentation. This is the truth of your ledger, encoded in types. Your entry types become strongly-typed functions. Your parameters become typed arguments. Your account hierarchy becomes a type the compiler checks. If the schema says card_purchase takes a cardId and a merchantId, the SDK requires exactly those parameters, no more, no less.

The SDK is a contract. When AI writes code that uses FRAGMENT, it must go through this SDK. The types reject code that invents fields or omits parameters the schema requires. 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.

This is what separates deterministic boundaries from "just write more tests." The schema is an external source of truth that exists before any code is written. The SDK encodes that truth into types. When the AI writes a payment handler, it isn't being checked against its own output; it's being checked against your design. The model can draft the handler, but the types won't let it fabricate 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.

Here's the process in practice, from schema to production:

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 enforces every constraint in real-time. You can iterate freely, but 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 write your application logic: payment handlers, UI components, workflows. It has freedom to explore, but every FRAGMENT call goes through 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. Use it adversarially: open a fresh chat, give it only your requirements, and have it write tests that define correct behavior without ever seeing the implementation. The tests encode what "correct" means; the code must satisfy them. This is the opposite of asking the same AI to grade its own homework. 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:

A Postgres CHECK (amount >= 0) doesn't care whether a human or an agent wrote the insert; it rejects the row either way. Every rigid layer in the diagram works the same way: same input, same answer, every time. That's why this scales when AI is doing the typing.

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 validation to SDK generation to application code to tests. Rigid, loose, rigid, loose, rigid.

This is Deterministic Boundary Programming. Whatever stack you use, find your deterministic checkpoints (schemas, generated types, validators, tests) and make sure AI output passes through them before it ships. FRAGMENT gives you these boundaries out of the box: declarative schemas, real-time validation, and generated SDK contracts. Once you start working this way, letting AI ship code without deterministic checkpoints starts to feel reckless.