FDE + Loop Engineering: define the loop, not the code

How to build AI that does real work without doing real damage — written so anyone (engineer, VP, controller, or domain expert) can follow it and apply it to their own problem. For a running, worked example of everything below, see the FDE in Action build.

The shift: stop writing the solution, start defining the loop

Here’s what’s changed. You used to build software by writing it, line by line. Going forward, you mostly won’t. Your job moves up a level: you define the system — the loop it runs, the rules it follows, the walls it can’t cross, and the tests that prove it works — and the AI builds it and runs it for you.

Your leverage is now in the definition, not the keystrokes. A good, complete definition of a loop is worth more than a thousand lines of hand-written code, because the AI can produce those lines (and re-produce them, and change them) from a clear enough description.

The FDE in Action build is the proof. A person described a system in a single brief; an AI wrote every line of it and deployed it live — twice. Nobody hand-coded it.

Two things keep this powerful instead of reckless:

1. Code doesn’t vanish — it moves. The exact, boring, safety-critical parts (the matching, the math, the limits, the guardrails, the tests) still exist as code. You just don’t type them anymore; the AI generates them. “Define a loop and let the AI handle it” is only safe because your definition includes those walls. Leave them out and you get the disaster version — an AI doing arithmetic and paying bills on a hunch.
2. Defining the walls is now the human’s real work. The hard, valuable thinking isn’t “how do I write this function.” It’s “what is the loop, who does each step, what must be impossible, and how will I know it’s right.” That’s this whole field guide.

So read the rest of this as the things you now define, in order.

The one idea to remember

Use the cheapest thing that is reliably correct.

An AI model is powerful, expensive, and occasionally wrong. Plain code is cheap and exactly right at the boring stuff (matching numbers, checking totals, comparing to a limit). A human is slow and precious, so you spend them only on the decisions that actually need a person. Good systems put each kind of work where it belongs — and make that choice visible so everyone can see why.

Everything below is just this idea, applied carefully.

Two layers

• Layer 1 — the engagement loop. How you approach the problem, from understanding it to shipping it. You don’t start by coding, you start by understanding.
• Layer 2 — the three pillars. How you build the agent so it’s safe: give it a workplace, keep its actions on a leash, and measure everything.

You need both. Layer 1 without Layer 2 gives you a nice plan and an unsafe robot. Layer 2 without Layer 1 gives you a safe robot solving the wrong problem.

Layer 1 — The engagement loop (how to approach any problem)

Six steps. Each one produces a short written artifact a non-engineer can read. Writing it down is the point — it forces the judgment into the open.

The most important step is Frame, and the most surprising lesson is this: a lot of the problem usually doesn’t need AI at all. A rule engine or a config change already handles it. Say so out loud. You earn trust by not over-building.

The single most valuable habit: the deterministic / AI / human split

For every step, ask: “Is there a right answer a computer can check exactly?”

• Yes, and it’s a rule or a calculation → plain code (deterministic). Matching records, adding up totals, comparing to a threshold, spotting an exact duplicate. Code is cheaper and it is never wrong here. Do not let the AI do this.
• No — it needs reading, judgment, or language → the AI model. Reading a messy document, guessing a category, spotting a near-duplicate, writing a summary.
• It’s high-stakes or hard to undo → a human. Paying money, changing a policy, anything you can’t take back.

A memorable failure mode: asking an AI to add up numbers and compare them to a limit. It’s slower, costs more, and is occasionally wrong at the one thing you most needed to be exact. Give that to code.

And when you do use the model, route by difficulty: a small cheap model by default, a bigger model only when the cheap one is unsure or the amount at stake is large. Track what each call costs. Most work is easy; don’t pay premium prices for it.

Layer 2 — The three pillars (how to make the agent safe)

An “agent” is just a loop: think, pick a tool, use it, look at the result, think again. Left alone, that loop will happily do something dumb or dangerous. The three pillars are how you stop that.

Pillar 1 — Harness (give it a workplace and a memory)

You wouldn’t drop a new hire in an empty room. Give the agent:

• A playbook — numbered rules it must follow, written in a plain file a non-engineer can edit. Rules live in a document, not buried in code.
• A memory — lessons from past cases, tagged by situation, that it can look up and add to. Next time it starts smarter.
• A small set of tools — the specific actions it’s allowed to take, and nothing else. Some tools are “read-only” (safe); a few are “sensitive” (spend money) and are treated differently.

Pillar 2 — Loop (keep it on a leash)

Four guardrails, plus one rule that matters more than all of them:

• It can’t declare its own success. When it thinks it’s done, it hands off to the tests, which decide if it really is. (A robot that grades its own homework always passes.)
• Humans approve the scary stuff. Sensitive actions pause and wait for a person to approve or reject. If a person says no, the agent re-plans — it doesn’t try the same thing again.
• A budget. A hard cap on how many steps it can take. If it hits the cap, it hands the case to a human instead of spinning forever.
• A stuck-detector. If it keeps repeating the same move, nudge it once, then stop it.

The rule above all four: safety lives in the code, not in the prompt. Don’t ask the AI nicely not to pay a suspicious invoice — make it impossible in code. A prompt is a suggestion; code is a wall. Build the wall.

Pillar 3 — LLM Ops (measure everything, and let it improve)

After each run:

• Trace every model and tool call — what it cost, how long it took.
• Score it with fixed safety checks (did it investigate first? did it avoid paying anything dangerous? were sensitive actions approved by a human?).
• Have a second model judge the outcome, safety first.
• Write one lesson back to memory so the next run is better.

The outer loop — getting better without going rogue

Systems should improve over time — but improvement is exactly when unsafe changes sneak in. So you govern it:

1. Settings are versioned. Tolerances and limits are a numbered record, not scattered constants. You can always see who changed what.
2. Propose, then project, then promote. Before changing a setting, simulate the effect with the same exact engine the real system uses — so the prediction matches reality. Show the trade-off. Then a human promotes the change to a new version.
3. Some things can never be dialed. Widening a price tolerance is a legitimate business choice. Auto-approving a fraud signal is never a dial — no setting can turn it on. Keep that line bright.

The honest version of “did it improve?” is “more work is now automatic, and zero dangerous things slipped through.” Not “our accuracy score went up” — because once you change the rules, your old answer key is out of date, and pretending otherwise is how you fool yourself.

Anti-patterns (what NOT to do)

• Don’t use AI where plain code is correct and cheaper.
• Don’t reach for a fancy database when a simple keyed lookup does the job.
• Don’t fine-tune a model when a better prompt and smart routing would do.
• Don’t build a swarm of agents when one well-run agent works.
• Don’t ship a judgment step with no test behind it.
• Don’t let the agent take a high-stakes action without a human.
• Don’t lose the paper trail — write every decision down.

Every one of these is the same mistake: adding complexity that doesn’t buy safety or value. Complexity is a cost, not a feature.

How to apply this to a completely different problem

The method is the reusable part; the domain is swappable. To move this from accounts-payable to, say, HR onboarding, expense audits, or support-ticket triage, you change four things and keep everything else:

1. The example data — realistic cases for the new domain, including the messy and dangerous ones.
2. The system of record — whatever the “source of truth” is (the HR system, the expense platform, the ticket queue).
3. The judgment table — the deterministic / AI / human split for the new steps.
4. The playbook — the rules the agent must follow.

The tests, the safety guardrails, the human-approval flow, the measurement, the “cheapest reliable option” habit, the plain-language artifacts — all of it carries over unchanged. That’s what makes it a framework and not just one app.

Hard-won build lessons (the things that actually bit us)

• Build an offline mode first. Make the whole thing run with no API key, using a fake but deterministic stand-in. Now anyone can run it, demos are reproducible, and you can test without spending money. Drop in a real key later; the code path is identical.
• Make the agent replayable and stateless. Given the same case and the same human decisions, it should produce the exact same steps every time. This is what lets it run on cheap serverless infrastructure and makes demos trustworthy.
• The prediction must use the real engine. If your “what-if” projection uses different logic than production, it will lie. Use the same code, and the projection matches what actually happens.
• Be honest in the numbers. If your fake documents make extraction look 100% accurate, say plainly that this proves the plumbing, not real-world accuracy. Use conservative assumptions for money claims. Put every assumption on screen. Trust is worth more than an impressive chart.
• Tests are the ship gate, not a formality. The rule we used: zero “false negatives” — nothing that needed a human was ever auto-approved. If that number isn’t zero, you don’t ship.
• Deployment is part of the build. Know where state lives and what resets. Surprises here erode trust fast.

Why this is written in plain language

• Plain language is a test of understanding. If a step can’t be explained in one clear sentence, it isn’t understood well enough to trust.
• The people who approve the work aren’t engineers. A VP funds it, a controller owns the rules, a domain expert judges the risk. They can only trust what they can follow.
• Principles travel; specifics don’t. The AP details won’t help someone building for HR. The principles will.
• It compounds. Written once, it becomes onboarding for the next engineer and a checklist for the next build.

If you remember nothing else: you no longer write the solution — you define the loop. Put each kind of work where it belongs, make the scary actions impossible without a human, test before you trust, and write it down so everyone can see why. Get the definition right and the AI builds and runs the rest.