The Implementation Manager asks for a change in Slack, or a ticket lands in Linear. Mason brings it to the kitchen. That is an order 🧾. A crew of AI cooks preps it, cooks it, tastes it, times it, and serves it. Nothing leaves the kitchen until automatic inspectors say it is good. Humans make the meaningful decisions. AI does the chore work.
Click each step. Every step has an owner, a proof it must show, and a rule for what happens when it fails. A dish only moves forward with proof, and only a tool can move it.
Mason has his own browser and his own private LOS. He replays the exact sandbox payload into it, so he tests with real data in seconds.
| Field | On the test site | In the LOS | |
|---|---|---|---|
| 📥 What Mason typed | |||
| 📤 What the dealer sees | |||
| Field | In the LOS | In RouteOne |
|---|
Every cook has one job, its own tools, and a clear list of things it never does. The small grey name on each card is the real agent behind the costume.
Watch them work together on one order. Each message flies from one cook to the next, and only the two cooks who talk light up. Humans make the meaningful decisions: what to cook, the answers to business questions, what ships. The AI crew does the chore work.
Not every order needs the most expensive chef. The OpenAI Decisions API reads the order and picks a recipe size. A routing board then picks the AI model and how hard it should think for each step. Quota meters swap chefs when one runs low.
Mason brings orders from the Implementation Manager and from Linear: requests, tickets, bugs. Internal tasks too. All go through the same router.
Sorts every order into no code small fix full chain. If it cannot answer, the head chef decides and writes the reason down.
A dashboard row says which model and effort to use per step, for example a strong model to build and a fast one for small fixes.
Every launch and every move prints one line, so anyone can see who cooks, how hard, and what comes next.
Routing is not a guess. Every dish has exactly one state, and the ticket graph lists the only legal moves out of it. The router asks the graph which roles may work next. Any other move is refused and printed. Some moves belong to humans only 👤: the plating check, the panel decision and the merge.
Watch one dish walk the graph, or tap a state to print its valid next states. The real graph has more states (scoping, held and older ones); this is the main path.
Questions, config, research. No kitchen station used.
One small change, lighter model, same inspectors.
New features. Every inspector, every proof.
The kitchen holds several Claude accounts and Codex. An hourly quota watch reads each one. Below 25% left = starving, new work prefers the other provider. Below 10% = disabled for routing. Back above 15% = recovered. Running cooks finish their dish; only new launches move. Labels stay generic (Claude 1, Claude 2), never account names.
If Claude cooked it, a GPT model reviews it. If GPT cooked it, Claude reviews it. Two different "palates" catch different mistakes. Unknown cook model = review refused, never a same-provider default.
The head chef never launches a generic chatbot. Each cook starts in its own lab harness, set up for that one job.
Claude Code or Codex, whichever cooks that step best. The routing board picks the model and how hard it thinks.
The second chef only reads and reviews. A cook cannot publish; only the publisher can. Each role gets a short tool list.
Short role rules, compressed skills and a context budget. When the context gets big, the cook saves notes and starts fresh.
Small scripts run at session start and before and after every tool call. They block unsafe moves, log every step and nudge the cook back on track.
Every step in the kitchen is built so an AI cook can check its own work. A cook never just says "done". It runs a real check, saves the proof and prints one result line. If the check fails, the dish goes back with the exact reason, gets fixed and is checked again.
Each station ends with its own automatic check: a test run, a verdict script, a database query, a timing run. The cook does not decide that it is done. The check decides.
Every pass leaves proof: test logs, a caught mutant, a verdict file, screenshots, database rows, a speed report. No proof means not done, even if the reply says "success".
A fail names the exact cause, for example mutant_survived or db_row_missing. The dish goes back to the cook who can fix it, and the same check runs again.
Every check script has its own test and a mutant: a broken copy of the check that the test must catch. So a check can never quietly stop checking.
impl-done, verify-pass, perf-fail, staging-pass. The head chef moves orders on these lines, not on long chat replies.Two kinds of inspector work together. Machines run the same checks the same way every time. AI judges on the OpenAI Decisions API handle things that need reading and judgment. The rule: AI may suggest, but only a script can record a verdict, and the script refuses anything malformed.
Does the code do what the order asks? The cook writes the tests first, then the code, plus one full browser test that clicks through the app like a person.
Are the loan workflow files safe? It finds broken JSON, missing or duplicate IDs, unsafe handler files and steps that point to nothing.
Is the code clear without notes? An added code comment blocks the dish. Good names and tests explain the intent.
Do the tests really test? A script breaks the fix on purpose. If the tests still pass, they are too weak and the dish goes back.
Is it correct, easy to change and secure? A second chef reads the change with a checklist. The AI suggests; only the verdict script records.
Is the money rule right for every possible input, not only for the test examples? Rules for fees, limits and eligibility are written as math theorems in Lean. A test checks a few cases; a proof covers all of them.
theorem fee_le_cap : ∀ amount, fee amount ≤ cap"For any loan amount, the fee is never above the cap." Lake must build the proof at the exact code version. If the code has the cap off by one, the proof does not build and the dish goes back. Then the OpenAI Decisions API scores the result.
Does it really work for a person? The taste tester proves every acceptance rule in a real browser on its own copy of the app, checks the database and saves screenshots, video and traces.
When a cook says done, plain LOS checks run first: config files, IDs, handler files, handler code, broken references, type imports and added comments. No AI, no cost, an answer in seconds. A fail goes straight back to the cook with the exact line.
Only a dish that passes them gets questions from the OpenAI Decisions API: the code rules, plus questions for each core loan flow the change touched (decisioning, failed rules, stips, adverse actions, pricing, task flows, workflows). A fail in a hard flow sends the dish back. Answers are saved per code version, so the same version is never asked twice.
Loans talk to credit bureaus, dealer networks and pricing partners. Every provider adapter is proven against the real provider API (its test environment) on a lane, before it reaches staging. No AI guessing: endpoints, fields and test personas come from the provider's own docs and real answers. Anything unknown is flagged, never made up.
By default every lane talks to fake providers, not real ones. The test picks the answer it needs, like a clean report or a sanctions hit, and the fake confirms which answer it sent.
A fake proves our side works. Only a real provider answer proves the integration.
To prove an integration works, a lane calls the provider's real test system. Only a lane whose ticket has written permission can do it. Logins come from the password vault and never show. Every real answer is saved.
Test systems only, never live ones. Test people only, never real customers.
Mason has his own copy of the app with real providers allowed, and his own browser that stays logged in. He sees every request that comes in and every call that goes out, so he knows exactly what is going on. Provider traffic rides the Tailscale exit node, so it leaves from the approved Fuse address.
He records the video and screenshots himself and posts the proof.
A real provider answer is saved as a new case in the mock registry. From then on, every mock lane can replay that exact answer in seconds, with no real call and no cost. Real lanes keep the fakes honest; mock lanes keep the kitchen fast.
Good cooks need good stoves. These are the pieces that let 25 stations cook at once without bumping into each other.
Each station gets its own copy of the code, its own running app, database, test data and provider mocks, plus its own two browsers: Playwright clicks through the app like a person, and Chrome DevTools measures speed and every network call. A queue builds one station at a time per machine, so builds never fight. Real provider logins come from the vault, checked for parity.
Lanes sit on internal IPs behind NAT. Private DNS points each lane name to the internal address, and the proxy serves it with the wildcard certificate. Only the LAN and Tailscale can reach it, so tests see real HTTPS without exposing anything.
Credit bureaus and dealer networks only accept traffic from approved addresses. Every provider test rides in one container that exits through the Fuse IP, never a laptop. "IP not allowed" = first check the truck.
Station browsers reset after each test. Mason has a separate browser that stays logged in to the admin tools and the app, so he can check, record videos and take screenshots any time.
Every station streams logs and CPU to Grafana. The detective reads logs to find the exact line of a bug. The photographer proves the log stream for each verified dish.
Every station gets its own secure web address under one wildcard certificate, served by one shared web gateway.
Every decision, answer and root-cause fix is saved. Before anyone asks a question, the kitchen searches memory first. Found = apply it, no new question.
A laptop and a big desktop both cook. Same scripts, same router, same gates. Any path that only exists on one machine is treated as a bug.
Every order, station and question shows live on a board. It accepts changes only from tools, so the board can never drift from reality.
Credentials come from the password vault and are used in place. They never appear in chat, logs, reports, commits or this page.
Every merged change lands on staging, a shared copy of the app with made-up data only. First Chef's Check proves the change by itself. Then the Chaos Critic tries to break it on purpose: it puts on a hat, acts like that person, and lets a seeded monkey click around. People decide what happens with each finding.
Chef's Check waits for the deploy, then opens only the screens the change touched. Every acceptance check needs proof: a screenshot with a numbered red box on what is new. A success reply alone never counts. A pass means staging-pass. A fail sends the dish back to the kitchen.
A monkey clicks, types and jumps between screens at random. A seed number controls the random choices, so the same seed gives the same steps. A bug found by chance can be shown again on purpose.
Each run picks a hat, a person to act like: 😈 troublemaker, 🧑💼 loan officer, 🙋 applicant in a hurry, 🧾 underwriter, 📱 phone on a slow network, 🛠️ admin. Each hat looks for the problems that person would hit.
Each finding gets its own EXP id, with screenshots of every step, what we expected and what happened. Mason posts it in the kitchen thread. No ticket is made automatically: people in triage decide.
Allowed test targets only, made-up data only, never production.
Staging is shared, so nobody may flood it. For the hard tests Mason builds a custom lane only for chaos: its own copy of the app, database and fake providers. A load tool sends thousands of made-up users at once, and the chaos monkey switches providers off and on in the middle of the rush. Nothing may get lost, nothing may be sent twice, and the slowest 1 in 100 users must still get an answer in under 1 second.
A chaos lane is set up for one test. It has its own app, database and fake providers, so a crash there never touches the build lanes, staging or production.
A load tool acts like thousands of made-up users who apply at the same time. It grows step by step: 10, 100, 1,000, then 5,000. It measures how long the slowest 1 in 100 users waits.
In the middle of the rush the chaos monkey switches a provider off, like the credit bureau or the dealer network, then on again. Applications must wait and retry once. None may get lost or be sent twice.
Each run has a seed number. After a fix, Mason runs the same seed again: the same users, the same switch at the same moment. Each finding gets an EXP id and goes to triage. People decide.
Custom lanes and made-up data only. Never production, never a real provider.
The desktop keeps 20 build lanes and 5 staging lanes working at all times. A lane only counts if a live cook is on it. Each lane is its own private copy of the app, database and browser, so nobody bumps into anyone. On the 5 staging tables each change gets Chef's check 🍽️, then exploratory testing 🎩 and monkey testing 🐒. Lanes live on internal IPs behind NAT, never open to the internet, yet each one gets real HTTPS names (app, API, database console) on the shared wildcard certificate, provisioned automatically.
A simulation of a real shift. Mason brings orders from the Implementation Manager and from Linear. The head witch sends each one to a free station. Inspectors send bad dishes back. On staging, Chef's Check proves each dish, then a tester in many hats 🎩 and a seeded monkey 🐒 look for surprises. Their findings go to triage, not back to the oven. Press Break a stove to see the kitchen fix itself.
Kitchens break. Stoves go cold, a cook freezes, a delivery fails. Timers ring all night, and every ring means: find what is stuck and fix it now. The kitchen also improves itself: every piece of feedback for the agents is saved and ranked, and the top items become automatic fixes and new features, tested and live for every agent. A self-evolving harness.
🔧 Infra crew repairs stations: rebuilds stacks, checks credentials, swaps a broken station, frees disk. One task, then it leaves.
🛠️ Harness engineer improves the kitchen itself: scripts, gates, cook instructions. Every change comes with a real test and a mutant that must fail.
📚 Learnings board: the top 15 lessons each get an automatic check in the shift doctor. A failed check is a finding to fix the same turn.
🩺 Bootstrap doctor: at every shift start it checks routing, station floor, publisher count, tool versions and memory before any cooking.
Mason posts a kitchen board every morning and an update every 3 hours, with screenshots of every screen that changed. Times are in EST. ETAs come from the last 6 hours of real cooking times, not guesses. Emails are posted in Slack too, so Mason reads them. He is also proactive: he offers help nobody asked for, like adding a client's dealer list to the LOS, inviting a client user or testing a reported bug, waits for a person to say go, then does every part.
Reading the order, asking questions.
Being built and reviewed.
Being verified on its own copy of the app.
Verified, bundled every hour into one deploy.
Live on staging.
Proven again on staging.
Blocked. Always with the question and lettered options a) b) c).
Failed a check with a named blocker. Back to its station.
Many changes reach the LOS every day, for many clients. The FDE does not read them all. Mason sorts every change and sends the FDE a stream of only the important ones: money math, credit rules, provider calls, database changes and who can see what. Each item says what changed and why it matters, so the FDE can review it and act at once: approve, ask a question or send it back. Routine changes, like text, colors and tests, are proven by the inspectors and only counted. So one FDE can look after more clients.
Money math, credit rules, provider calls, database changes and who can see what. A mistake there costs money or trust, so a person looks at it.
Text, colors, tests and tidy-ups that do not change behavior. The inspectors already proved them, so they never fill the FDE's day.
Each item says which client, what changed, why it matters and the proof. The FDE reads one short item, not the whole code change.
The FDE spends time only where a person adds value. The rest of the day goes to clients: calls, decisions and new work.