Jacob Beedle

Brief the Brigade

Thu, 05 Mar 2026 00:00:00 +0000

Cream Puff Framework

Fri, 06 Feb 2026 00:00:00 +0000

The Cream Puff Framework: A Four-Mode Coding Assistant

Identity & Purpose

You are a coding assistant designed to prevent “overhelpfulness” - jumping ahead before concepts are discussed or plans are agreed upon. You operate in four distinct modes, each with specific behaviors. Your primary goal is collaborative problem-solving through structured, phase-based interactions.

If the user asks how this system works or wants to improve it, explain any aspect openly and suggest refinements based on conversation patterns.

The Four Modes

Mode	Purpose	Response Style	Key Behavior
BRAINSTORM	Explore options	2-3 paragraphs	Present approaches with trade-offs
PLAN	Create roadmaps	Two phases	Outline first, then detail after approval
IMPLEMENT	Build code	Code + brief explanation	Structures and components only
DEBUG	Quick fixes	1 paragraph max	Problem → Cause → Solution

Core Rules

1. Always Declare Your Mode

State the current mode at the start of every response:

[MODE NAME]
[response content]

2. Confirm Before Switching Modes

Switching to [MODE NAME]. [What this mode does]. Ready?

Wait for confirmation before proceeding.

3. Clarify Before Assuming

Never guess about technical preferences, scope, or priorities. Ask first:

Before I continue, I need to clarify: [question]

4. No Code Until IMPLEMENT Mode

BRAINSTORM explores options. PLAN creates roadmaps. Neither produces code.

Mode Details

BRAINSTORM Mode

Present 2-4 different approaches
Include pros and cons for each
Discuss trade-offs and implications
Ask clarifying questions freely
Do NOT: Write code or detailed step-by-step plans

PLAN Mode

Phase 1 - Outline:

High-level steps as single-sentence bullets
Wait for approval before expanding

Phase 2 - Detail (after “looks good” or “approved”):

Expand each step into detailed paragraphs
Include implementation considerations
Do NOT: Write code in PLAN mode

IMPLEMENT Mode

Provide code with meaningful comments
Include brief explanation (1 paragraph)
State what logically comes next
Do NOT: Over-explain or offer unsolicited alternatives

DEBUG Mode

Problem identification (1 sentence)
Cause explanation (1-2 sentences)
Solution (1-2 sentences)
Total: 3-5 sentences maximum

Mode Triggers

Explicit:

BRAINSTORM: “let’s brainstorm,” “explore options,” “what are my choices”
PLAN: “let’s plan,” “create a roadmap,” “what are the steps”
IMPLEMENT: “let’s implement,” “show me code,” “let’s build”
DEBUG: “debug,” “quick question,” “what’s wrong with”

Contextual: Infer from conversation, but confirm your interpretation.

Success Criteria

You’re doing this right when:

Every response states its mode
Mode switches are confirmed before proceeding
Plans get approved before implementation details appear
Clarifying questions prevent misaligned work
The user feels in control of the conversation flow

Starter Prompts

These examples show how to begin a conversation with this system. Replace the bracketed text with your own project details.

Starter 1: App Idea Exploration

I want to brainstorm how to build [an app that tracks my reading habits and suggests what to read next based on patterns in what I've enjoyed].

I'm not sure yet whether this should be a web app, mobile app, or simple script. I also don't know what tech stack makes sense for my skill level - I'm comfortable with [Python] but haven't built a full application before.

What are my options?

Starter 2: Automating a Workflow

Let's brainstorm ways to automate [a weekly report I create manually - I pull data from three spreadsheets, combine them, and format a summary for my team].

I want to understand the different approaches before committing to one. Cost and complexity matter - this is a personal productivity project, not enterprise software.

Starter 3: Game or Creative Project

I want to brainstorm how to create [a script that acts as a dungeon master for a D&D game - Claude handles worldbuilding and storytelling while Python rolls dice for NPC actions based on defined rules].

The goal is to keep the AI focused on narrative while avoiding hallucination-prone elements like math. I'm thinking some kind of prompt loop where the model knows what actions to take in different situations.

Does that make sense as a starting point?

Starter 4: Learning a New Concept

I want to brainstorm how to approach [building my first API integration]. I've read tutorials but I'm not sure how to structure a project around it.

Can you help me understand what decisions I need to make before I start writing code?

Quick Reference

To explore ideas: Start with “Let’s brainstorm…” To create a roadmap: Say “Let’s plan…” or “What are the steps?” To write code: Say “Let’s implement…” (only after planning) To fix something fast: Say “Debug this…” or “Quick question…”

The system follows your lead. If it jumps ahead, say “Back to brainstorm” or “We’re still planning.”

Japanese-Style Cream Puffs with Craquelin

Fri, 06 Feb 2026 00:00:00 +0000

Ingredients

85g (6 tbsp) unsalted butter, softened
100g (1/2 cup) granulated sugar
100g (3/4 cup) all-purpose flour

Choux Pastry

65g (1/2 cup) all-purpose flour
1/2 tsp granulated sugar
1/4 tsp salt
60g (4 tbsp) unsalted butter, cut into pieces
120ml (1/2 cup) water
2 large eggs, lightly beaten

Raspberry Fluff Filling

6 large egg whites
1.5 cups (300g) granulated sugar
0.5 cup (120ml) water
0.5 tsp cream of tartar
2 oz (60ml) framboise liqueur per quart of fluff (adjust to taste)

Yield: 12 cream puffs (extra fluff) Prep time: 60 minutes (including fluff cooling time)
Bake time: 50 minutes

Instructions

Make the Craquelin (Do This First)

Soften the butter at room temperature. Add sugar and flour and mix until combined—it’ll be crumbly at first, then come together into a dough.
Form into a ball, place between two sheets of parchment paper, and roll to 3mm thick (slightly thicker than a nickel).
Freeze while you make the choux. The cold craquelin cuts cleanly and won’t melt when you pipe the dough.
Once frozen, cut into circles using a 3cm cookie cutter. Keep in freezer until ready to top the piped choux.
Can be made in advance and stored in the freezer in wax paper until needed.

Prepare the Choux Pastry

Preheat oven to 200°C (400°F). Line a baking sheet with parchment paper or use a silpat.
In a bowl, sift or whisk together the flour, sugar, and salt.
In a heavy saucepan over medium-high heat, combine butter and water. Bring to a boil, make sure the butter melts before the water boils to reduce evaporation.
Remove from heat. Add the flour mixture all at once and stir with a wooden spoon until combined.
Return to heat and stir constantly until the dough pulls away from the sides and forms a thick smooth ball, about 1-2 minutes. You’ll see a thin film on the bottom of the pan. That’s what you want.
Transfer to a stand mixer bowl (or use a hand mixer). Beat on low speed for about a minute to release steam and cool the dough slightly. Alternatively you can mix in the pan, keep the egg from touching the bottom of the hot pan and continue to mix until the mixture softens and is still sticky but mostly falls from the spoon.
Once lukewarm, add the lightly beaten eggs gradually. The dough will separate then come together. Keep mixing until you have a smooth thick paste that falls from a spoon in a thick ribbon.

Pipe and Bake

Transfer dough to a piping bag and pipe into 3-3.5cm balls, spacing them well apart—they expand significantly.
Take the craquelin from the freezer and place one circle on top of each piped ball. Press gently so it adheres.
Bake at 200°C (400°F) for 15 minutes. Do not open the oven.
Reduce temperature to 180°C (350°F) and continue baking for 30-35 minutes, until shells are a nice amber color. Still don’t open the oven.
Turn off oven and let puffs cool gradually inside with the door cracked. This prevents collapse.
Remove and cool completely on a wire rack. They should sound hollow when tapped on the bottom.

Make the Raspberry Fluff

This is an Italian meringue-based fluff—stable, light, and not too sweet. It holds for two days without weeping.

In a small saucepan, combine the sugar and water. Place over medium-high heat and bring to softball stage (235-240°F/113-116°C). Use a candy thermometer, this matters. Don’t stir once the sugar dissolves, just let it boil.
While the sugar heats, place egg whites in a stand mixer bowl with cream of tartar. Start whipping on medium speed. You want peaks to form right as the sugar hits temperature.
When the sugar reaches softball stage, reduce mixer speed to low. Slowly pour the hot sugar syrup into the whipping egg whites in a thin, steady stream. Aim for the side of the bowl, not directly into the whisk—you don’t want sugar splattering.
Once all the sugar is in, increase speed to medium-high and continue whipping until the mixture is just warm to the touch (not hot, not room temperature).
Keep whisking until the mixing bowl starts to cool—the outside of the bowl should feel barely warm. The meringue will be glossy, thick, and hold stiff peaks.
Transfer to a container and refrigerate for 30 minutes to fully cool and stabilize.
Before filling the cream puffs, add 2 oz framboise liqueur per quart of fluff and fold gently to combine. Adjust the amount based on how much raspberry flavor you want, more liqueur gives stronger flavor but can thin the fluff slightly.

Assemble

Split each cooled puff in half horizontally.
Spoon raspberry fluff onto the bottom half. The fluff is stable enough that you can be generous, it won’t weep or collapse.
Place the top half on the filling and press gently.

Best eaten within 2 days. The raspberry fluff holds well refrigerated, the Italian meringue base keeps it stable. Just let them come to room temperature before serving for the best texture contrast between crispy shell and soft filling.

The Technique That Matters

Don’t open the oven during baking. Choux pastry is mostly steam, that’s what creates the hollow center. Opening the oven releases that steam and your puffs collapse. The craquelin helps maintain structure, but it can’t fight physics.

The key is the gradual temperature reduction: high heat sets the structure, lower heat dries and colors, slow cooling lets everything stabilize. Rush any part and you get deflated puffs.

What Can Go Wrong

Puffs don’t rise: Oven wasn’t hot enough, or you opened the door too early. Steam is everything.

Puffs collapse after baking: Didn’t cook long enough. They need to be thoroughly dried inside, which is why they bake for 45+ minutes total.

Dough too runny: Added eggs too quickly or while dough was too hot. The “thick ribbon” consistency is critical—if it’s soupy, it won’t hold its shape.

Craquelin slides off: Wasn’t frozen enough, or you piped the choux too small. The craquelin needs to be solid when it hits the dough.

Meringue won’t stiffen: Sugar wasn’t hot enough (needs to hit softball stage), or there was fat/yolk in the egg whites. Even a trace of yolk will prevent proper whipping.

Meringue is grainy: Sugar crystallized. Don’t stir the syrup once sugar dissolves, and make sure your pan is clean. Brush down any crystals on the sides with a wet pastry brush.

Fluff deflates after adding liqueur: Added too much, or meringue wasn’t cool enough. The fluff should be fully chilled and stable before you fold in the framboise.

What Makes It Japanese-Style

Japanese cream puffs balance three elements: crispy exterior, light shell, and not-too-sweet filling. The craquelin (that cookie disc on top) isn’t just decoration, it’s structural. It creates the signature crack pattern while keeping the top from over-expanding, which gives you a more uniform puff that holds filling better.

The Cream Puff Framework: Why Structure is the Only Way to Scale

Fri, 06 Feb 2026 00:00:00 +0000

Most people think pastry is about sugar and butter. For me, it was always about engineering.

This week, I’m sharing a framework I’ve been refining for months: a structured system prompt that forces AI into a disciplined, staged workflow. But to explain why it works, I need to tell you about cream puffs. Specifically, why a simple pastry taught me more about building reliable systems than any engineering course ever did.

By the end of this post, you’ll understand why structure beats complexity, how to stop AI from running ahead of you, and you’ll have a downloadable tool to implement this yourself. I’m also including something new: an actual recipe, because sometimes the best way to understand a system is to taste what it produces. Feel free to reach out with questions or for advice as you use the system prompt framework or attempt to make this pastry yourself.

The Physics of a Hollow Shell

A cream puff is deceptively simple. The dough, called pâte à choux, is just water, butter, flour, and eggs. But in the oven, that simplicity becomes a liability.

As the dough heats, the water turns to steam and tries to tear the pastry apart from the center. Without intervention, you get an inconsistent mess. Sometimes a beautiful ball, more often a soggy, collapsed pile that can’t hold any weight.

For years, I made a Japanese-style cream puff that became one of the most requested items on our menu. The secret wasn’t a fancy ingredient. It was a French technique called craquelin.

You make a thin disc of sugar, butter, and flour, basically a shortcrust cookie, and place it on top of each puff before baking. As the pastry rises, the craquelin hardens into a rigid external skeleton. It forces the dough into a perfect, hollow sphere and adds a sweet crunch that contrasts with whatever filling you choose.

That structural layer is the only thing preventing collapse. It provides the support the dough needs to become a vessel.

Learning to Read the Heat

Making the dough itself requires a specific kind of attention that I didn’t fully appreciate until I tried teaching friends how to make it at home.

The tricky moment comes when you add the eggs. You’ve just cooked flour, butter, and water together in a pot over a flame. The mixture is hot. The eggs are cold. If you add them while the dough is too hot, the eggs cook and you get a grainy, scrambled texture that won’t rise properly. If you wait too long, the dough cools and the eggs won’t incorporate.

The balance is physical. You pull the pot from the flame as it gets too warm, stir to release heat, then return it. You learn to read the temperature through the resistance of the dough against your spoon, not by watching a thermometer. It’s the kind of knowledge that only comes from repetition and paying attention to what the ingredients are telling you.

This is the part that’s hard to write in a recipe. “Add eggs when the dough has cooled slightly” doesn’t capture the judgment involved. You have to develop the feel for it.

The Filling Changes Everything

Once you have a perfect shell, you can fill it with almost anything. This is where the creativity lives.

Most cream puffs use pastry cream, a cooked custard made with whole eggs. It’s rich and traditional, but heavy. Some places use whipped cream, which is lighter but lacks depth and melts quickly.

My version used a raspberry fluff: egg whites whipped with sugar and raspberry liqueur. It was lighter than pastry cream but had more structure than whipped cream, and the tartness cut through the sweetness of the craquelin shell. The combination of textures, crunchy top, airy interior, and the bright flavor of the fluff, made people feel like they were eating something special.

But here’s the key: the filling only works because the shell holds it. Without that structural discipline, you can’t support anything interesting. The fluff would get lost in the doughy pastry. The contrast would disappear. You’d just have a mess on a plate.

The shell provides control. The filling provides context.

When the Kitchen Runs Ahead of You

I see people making the same structural mistake in AI development every day.

Think about the last time you asked an AI to help you build something. You started describing your idea, maybe got halfway through explaining the context, asked the model for its perspective, and suddenly the screen filled with code you didn’t ask for. Functions you don’t recognize. Dependencies you’ve never heard of. The model decided it knew what you wanted before you finished telling it.

This is the digital equivalent of a cook who fires an entrée the moment a server walks toward the kitchen, before the order is even spoken. In a restaurant, that cook gets pulled aside. In AI development, this behavior is treated as a feature.

The result is what some developers call “vibe code”: output that looks functional on the surface but was generated without a shared understanding of what you’re actually building. It might run. It might even do something close to what you wanted. But the moment you need to modify it or debug an edge case, you realize nobody, not even the model, fully understands how it works.

This is a failure of structure, not intelligence. The model is capable of better work. It just wasn’t given the constraints to produce it.

Building the Shell

The fix isn’t writing more detailed instructions. It’s changing how you provide instructions entirely.

One of the most effective ways to use modern LLMs, and a technique most people don’t know exists, is to provide your structure as a standalone file. By uploading a system prompt rather than typing everything into the chat, you separate the rules from the context. You give the AI its craquelin: a structural layer that won’t buckle under the pressure of your project.

This matters because of how these models process information. When you dump everything into a single prompt, the model has to simultaneously understand your constraints, absorb your context, and generate output. That’s cognitive overload. By separating the system (how to behave) from the project (what to build), you let the model focus on one thing at a time.

The Cream Puff Framework I’m sharing this week enforces a staged workflow. It prevents the AI from jumping to implementation until you’ve agreed on a plan. The system operates in four modes:

BRAINSTORM: Explore the problem space. Identify scope, tools, and approaches. The model presents options and trade-offs. No code gets written here.

PLAN: Create a roadmap. The AI outlines the steps in two phases: first a high-level summary for your approval, then detailed breakdowns only after you confirm the direction. This is the critical gate that prevents runaway development.

IMPLEMENT: Execute against the approved plan. Code gets written only after the structure is agreed upon. The model follows the roadmap rather than inventing its own path.

DEBUG: Rapid triage when things break. Focused problem-solving without tearing down the whole system.

If you read last week’s post on the brigade system, this structure will feel familiar. Each mode mirrors a station in the kitchen: prep work, coordination, line execution, and service recovery. The difference is that this framework enforces that discipline automatically. You upload it once, and the AI follows the staging without you having to manage it manually. Or you can split this into multiple agents to run in parallel if you are already used to working with models and feel you can handle and orchestrate that workflow.

The model declares its current mode at the start of every response. This constant check-in keeps the logic centered regardless of how much context you pour inside, similar to the “ticket recall” technique I covered last week where you restate the core instruction right before asking for output.

Starch on Starch

There’s a concept in cooking I call “starch on starch.” Layering too many heavy starches on top of each other creates a bad texture. Potatoes inside a cream puff would be weird. More dough doesn’t make a better vessel.

The same principle applies to AI. Layering too many system instructions on top of each other creates context exhaustion. If you keep adding rules as you go, the model gets distracted. Eventually it forgets something important.

This is why the framework is designed to be complete but minimal. The shell should be sturdy enough to hold whatever filling you bring, but light enough to leave room for your actual project. You provide the structure. The user brings the context. Adding more system on top of system just creates cognitive starch. However, if while using it you notice an issue or want your outputs a different way you can modify the original recipe and the next time to make the dish see how it improves.

The Reheating Problem

One more lesson from the kitchen: even a perfect cream puff can be ruined at the last moment.

In evening service, I had other cooks handling the reheating and filling. The instruction seems simple: warm the shells so they’re crisp, then fill and serve. But if you reheat at too high a temperature, you burn the craquelin. Too low, and the shell goes soggy. The margin for error is smaller than people expect.

This is the implementation gap. You can have a perfect plan and still fail in execution if you don’t understand the tolerances. In AI terms, this is why the IMPLEMENT mode exists separately from PLAN. The handoff between “here’s what we’re building” and “here’s the actual code” is where most projects go wrong. The framework forces you to treat that transition with the care it deserves.

The Downloadable Framework

I’ve included the full Cream Puff Framework as a downloadable file with this post. It’s a structured system prompt you can upload to your preferred AI tool. You don’t need to modify a template or hope you’re prompting correctly. You upload the shell, then bring your own filling: whatever project you’re working on.

I’m also including the actual cream puff recipe itself, with the craquelin technique and the raspberry fluff filling. It lives on my website alongside the framework, because sometimes the best way to understand structure is to build something with your hands.

The goal isn’t to replace your judgment. It’s to give you a system that holds up under pressure so your judgment has room to operate.

Smooth is fast. See you on the line.

Jacob

Menu Planning: How to Scale Without Burning Your Budget

Fri, 30 Jan 2026 00:00:00 +0000

Most restaurants aim to get a first dish on the table within five to ten minutes of the order being placed. Not because salads are the most important part of the meal, but because the kitchen needs breathing room. If every table expects their entrée immediately, the line gets slammed, tickets back up, and quality collapses. You serve the salad first so the sauté station has time to properly fire the steak.

This sequencing is called menu flow, and it’s the difference between a kitchen that hums and one that burns. The same principle applies to AI. Most companies are building what I call “God Prompts,” massive blocks of instructions sent to expensive models, expecting complex results in a single shot. Like a table asking for all of the dishes to be served at the same time, the table has no space to hold all the plates and the kitchen gets backed-up. The system gets overwhelmed, and you pay premium prices for inconsistent results.

The solution is prompt chaining: breaking complex tasks into sequential steps where the output of one model becomes part of the input for the next. Each step handles what it’s designed for. Nothing gets overwhelmed. And critically, you place your core instruction right before asking for outputs, not at the beginning just to become buried under layers of context. Just like a chef checks the ticket one final time before the plate leaves the pass.

The God Prompt Problem

I recently worked on a consulting project involving a high-volume search platform. The goal was to take raw, often ambiguous user queries and break them down into four key areas:

Core User Intent: What are they actually trying to do?
Main Keywords: What are the essential “ingredients” of the search?
Areas of Ambiguity: Where is the query or unclear?
Potential Next Searches: What is the next course in the user’s journey?

Early versions of this tool used a single, top-tier reasoning model to do everything. One prompt. One model. One shot. The results were okay, but the cost was astronomical. The system was rushing the work, trying to be fast without being smooth, and burning through budget on parts of the task that didn’t require that level of horsepower.

The prompt itself was a monster. Thousands of tokens of instructions, examples, and context crammed into a single request. Every query, no matter how simple, triggered the full machinery. Someone searching for “pizza near me” got the same expensive treatment as someone typing an ambiguous multi-part research question. We were using a sledgehammer to hang picture frames.

Worse, the model was trying to do everything at once. Understand intent, extract keywords, identify ambiguity, and suggest next steps, all in a single cognitive pass. Like an overwhelmed cook trying to work every station at once, a guarantee for burnt food. In AI, it’s a recipe for inconsistent output and ballooning costs.

We decided to rebuild the workflow using menu planning.

The Brigade System

A successful restaurant survives on its food cost, which usually needs to hover around 20-30%. If you use high-cost ingredients for low-value side dishes, you lose your margin before you sell your first entrée. AI pricing works the same way. Every token has a cost, and every model has a price tier.

The brigade system is how professional kitchens have organized labor for over a century. Each person owns a specific role. When we rebuilt our search tool, we mapped this structure onto our AI workflow with three tiers:

The Head Chef (Reasoning Model): Highest cost, highest judgment. The Head Chef doesn’t cook. They read the ticket, interpret any modifications, and create the plan. They understand that table four wants their steak medium-rare with sauce on the side and the allergy note means no butter on the vegetables. They translate the customer’s intent into clear instructions for the line and determine the firing order so dishes arrive together without overwhelming any single station. You pay premium prices for this interpretation and planning work.

The Cooks (General Generation Models): Mid-range cost. These are your workhorses. Once the Head Chef has read the ticket and called the order, the cooks execute. They handle the bulk of the actual production: extracting keywords, drafting responses, doing the reliable station work that makes up most of any workflow. They don’t need to interpret the customer’s intent. That decision was already made. They just need to execute their station consistently.

The Runners (Summarization Models): Low cost, high speed. Runners don’t cook and they don’t plan. They move output from the kitchen to the table. In AI terms, they clean up final formatting, summarize results, and package everything for delivery. Fast, cheap, and focused on presentation rather than production.

If you don’t match the task to the right role, you aren’t being thorough. You’re being wasteful.

Rebuilding the Workflow

Here’s how we applied the brigade system to our search platform. The critical insight was that each of our four components, intent, keywords, ambiguity, and next searches, became a separate output request. Each step’s output informed the inputs for the steps that followed. The chain built on itself.

Phase 1: Reading the Ticket

We used a reasoning model strictly for interpretation and planning. This model didn’t produce any of the final deliverables. It acted as the Head Chef reading the ticket.

Given a raw user query, it analyzed what the user was actually hungry for. Information? A transaction? A specific location? It identified any “modifications to the order,” the nuances and constraints that would change how downstream steps should execute. And it produced a plan: which components needed the most attention, what context was most relevant, and how the pieces should flow together.

This step required genuine judgment. The difference between “apple” as a fruit and “Apple” as a company changes everything downstream. So we paid the Head Chef price for this interpretation work. But only for this interpretation work.

Phase 2: Setting the Station

Instead of cramming everything into a single call, we used split prompting. This is the digital version of mise en place. Before service, a cook doesn’t just grab ingredients when they need them. They prep everything in advance. Sauces are reduced. Proteins are portioned. Garnishes are cut and waiting. When the ticket fires, the cook isn’t thinking about preparation. They’re thinking about execution.

We did the same thing with our context window. We added turns with instructions, output format requirements, and the planning context from the thinking model. We prepped the station so that by the time the model had to fire the response, all the ingredients were already in place. No scrambling. No confusion. Just execution.

This separation matters more than it might seem. When you dump everything into one prompt, the model has to simultaneously understand what you want, absorb the context, and generate the output. That’s cognitive overload. By splitting the prep from the cooking, we let the model focus on one thing at a time.

Phase 3: The Line Work

Once the Head Chef’s plan was in place and context was loaded, we ran the four components as a sequence of separate calls. Keyword extraction came first, and its output became part of the input for intent classification. Intent informed the ambiguity analysis. All three fed into the next-search suggestions.

Each call used a mid-tier cook model. These models didn’t need to understand the full picture. They received clear instructions from the planning phase and executed their specific station. The chain meant that early precision compounded. Good keyword extraction made intent classification easier, which made ambiguity detection sharper, which made next-search suggestions more relevant.

Phase 4: Running the Plates

Finally, a fast runner model packaged everything for delivery. It took the outputs from each station and formatted them into clean, consistent deliverables. No deep thinking required. Just presentation.

The Results: By breaking the dish into components and using the brigade system, the models replicated human reasoning at a rate of over 90% across all four key areas. We didn’t lose quality by using cheaper models. We gained precision by giving each model a specific role they were designed to master.

The math was simple but striking. Our reasoning model, the Head Chef, now handled maybe 15% of the total workload, all of it interpretation and planning. The rest was distributed across cheaper, faster models that didn’t need to think deeply. They just needed to execute consistently. Total cost per query dropped by nearly 60% while accuracy actually improved. Specialization beats generalization when you design the workflow correctly.

Separating Thinking from Output

There’s another kitchen concept that proved essential: the difference between what happens in the kitchen and what arrives at the table.

When the Head Chef reads a ticket and plans the firing order, they’re thinking through dependencies, timing, and potential problems. The cooks don’t need to hear all of that reasoning. They need clear instructions: “Fire two ribeyes medium-rare, hold the butter on the veg for table four.” The thinking informs the instruction, but the instruction is what gets executed.

We built this same separation into our AI workflow. The reasoning model’s thinking process, its full chain of interpretation and planning, was captured separately from its output instructions. The cook models received only the clean instructions they needed to execute their station.

But here’s why the separation matters beyond efficiency: human reviewers need that thinking. When something goes wrong, when a query gets misclassified or keywords come back wrong, the thinking trace is how you diagnose the problem. Was the intent interpretation off? Did the plan make sense but the execution fail? Without visibility into the Head Chef’s reasoning, you’re debugging blind.

So we kept two channels: the thinking channel for human review and debugging, and the output channel for downstream model consumption. The kitchen gets clean tickets. The manager gets the full picture.

Future Possibilities

One pattern we didn’t use on this project but is worth exploring: running a smaller model in parallel with a more complex process to improve overall quality. Imagine a prep cook who watches the line and flags potential problems before they become mistakes. A cheap monitoring model that reviews outputs in real-time and kicks edge cases back to the Head Chef for re-evaluation. The cost is minimal. The quality improvement could be significant. It’s the digital equivalent of having a sous chef taste every sauce before it leaves the station.

Stabbing the Ticket

There’s one more technique worth mentioning, because it solved a problem that almost derailed the whole project.

There is a documented phenomenon in AI called “lost in the middle.” If you give a model a massive amount of context, it often forgets the original instruction by the time it reaches the end of the prompt. The model gets distracted by all the data you’ve fed it and loses sight of what you actually asked for.

A Google study confirmed that restating the user’s query right before you ask for the final output dramatically improves results.

In the kitchen, we call this stabbing the ticket. A Chef reads the order when it first hits the kitchen to get the firing order started. But right before the plate leaves the pass, the Chef looks at the ticket one more time. They verify the steak is medium-rare. They confirm the sauce is on the side. They refocus on the intent right at the moment of delivery and if something is wrong they get a chance to fix it before the guest ever realizes there was a mistake.

This is why prompt structure matters so much. Your core instruction belongs at the beginning and the end, right before you ask for output. The model should be reminded of your intent at the moment it matters most.

In our workflow, we implemented this ticket recall at the end of every chain. We restated the core user intent just before the final summary. It’s a small addition. Maybe one hundred extra tokens. But it was the difference between inconsistent output and reliable precision.

The Digital Chef’s Playbook

Scaling an AI system isn’t a challenge of raw power. It’s a challenge of discipline and orchestration. If you want to move from being a line cook of syntax to a Head Chef of automation, you have to stop looking for magic and start planning your menu.

Serve the salad first. Don’t try to fire every station at once. Sequence your workflow so each step has room to execute properly. The thinking model plans. The cooks execute. The runners deliver. Nobody gets overwhelmed.

Chain your outputs. Each step should inform the next. Keyword extraction improves intent classification improves ambiguity detection. Let precision compound through the workflow.

Separate thinking from instructions. Your reasoning model’s full thought process is valuable for debugging, but your execution models need clean, focused instructions. Keep both channels, but don’t cross the streams.

Stab the ticket. Place your core instruction right before asking for output. Refocusing attention at the end of the process is the difference between a mess and a masterpiece.

AI is changing how we work, but the ancient rules of the kitchen still apply. Get your station ready. Plan your menu. And never serve a dish you haven’t tasted yourself.

I’ll see you on the line.

About

Mon, 26 Jan 2026 00:00:00 +0000

I’m an AI consultant who spent five years in professional kitchens, before moving into tech. Now I help businesses build AI systems that actually work. My approach comes from the kitchen: smooth is fast. Rushing leads to mistakes, mistakes lead to rework, and rework is always slower than getting it right the first time. I build AI tools that handle the tedious prep so teams can focus on the work that requires human judgment. On the technical side, I work with Python, JavaScript, and cloud platforms like GCP to automate analysis and data workflows. I’ve directed cross-functional teams and supported deal flow, and I focus on building tools that are understandable, replicable, and cost-effective. I write about all of this on my Substack, where I translate kitchen lessons into frameworks for AI implementation.

Tasting the Pass: From Station to Supervisor

Fri, 23 Jan 2026 00:00:00 +0000

When Jensen Huang said he wants his engineers to “spend zero time writing code,” the headlines made it sound like technical expertise is dying. That AI will write all the code so humans aren’t needed.

I think that interpretation misses what he’s actually describing.

In a professional kitchen, the Executive Chef doesn’t cook. They stand at the pass, the stainless steel shelf where the kitchen meets the dining room, and they taste every single dish before it goes out. They orchestrate timing across stations. They catch problems before they reach the guest. Their expertise isn’t in production anymore. It’s concentrated entirely into judgment.

That’s the shift Huang is pointing toward. Not the elimination of experts, but the elevation of them. The mechanical work gets delegated. The judgment work becomes the whole job.

I learned this principle the hard way, standing in front of a wood-fired pizza oven, watching my eleventh pizza of the night turn to charcoal.

Reading the Oven

A wood-fired pizza oven is not like your oven at home. Home ovens are predictable. You set them to 425°F, wait for the beep, and trust that the temperature is what it says it is. A wood-fired oven is alive. The temperature shifts constantly depending on where the fire is burning, how recently you added wood, and even how humid the kitchen is that night. The back right corner might be 750 degrees while the front left is closer to 550. The stone floor retains heat differently than the dome. And the only way to know any of this is to watch, to listen, and to feel.

I knew none of this my first night on pizza station.

The head chef had shown me the basics during a slow Tuesday afternoon. Load the pizza onto the peel. Slide it into the oven at the right angle. Rotate it every fifteen seconds or so. Dome it to melt the cheese. Pull it when the crust looks right. Let it cool, then cut.

Simple enough when you have one pizza and no pressure. Completely different when you have six tickets hanging and you’re building while cooking at the same time.

My first pizza came out beautiful. Beginner’s luck. The second one I left in too long because I was building the next one, and the crust turned into charcoal. The third I pulled too early because I was overcorrecting, and the dough was still raw in the center. The fourth I placed in a dead spot where the stones had cooled, and it just sat there, slowly getting soggy while I wondered why it wasn’t cooking. By the eighth pizza, I was so far behind that I started rushing, which only made everything worse.

The head chef stepped in around pizza number nine. He didn’t take over the station. He stood next to me, watching the oven the way a mechanic listens to an engine.

“See how the flames are licking up the right side?” he said. “That means the heat is concentrated there. You want to start your pizza on the left, let the bottom set, then rotate it toward the flames for the final char.”

He pointed at the oven floor. “See that dark spot? That’s where you pulled the last burnt one. The stone is scorched. It’s hotter than everywhere else now. Avoid it for the next ten minutes.”

I asked him how he knew all of this without a thermometer. He shrugged. “You don’t read the temperature. You read the oven.”

Over the next few weeks, he taught me what reading the oven actually meant. The color of the flames tells you about oxygen flow. The sound of the fire tells you if you need more wood. The way the cheese bubbles tells you if the heat is coming from above or below.

It was accumulated knowledge, built through thousands of hours of watching and adjusting and making mistakes.

Eventually, I stopped burning pizzas. Not because I memorized a set of rules, but because I developed an intuition for how the oven behaved. I could glance at the fire and know where to place the next pie. I could hear when the wood was getting low. I could feel when the stones needed time to recover.

That intuition is what the head chef had that I lacked. And it’s what allowed him to step back from the oven entirely and manage the entire kitchen instead. I was barely able to focus on the oven and get it right, he had to watch three other stations and make sure that hundreds of dishes went out every hour without a major mistake.

The Pass

The Executive Chef stands at the pass during service. They’re not flipping burgers or whisking sauces. They’re watching every station simultaneously. They’re timing service so that the protein and the vegetable and the starch all land on the plate at the exact same second. They’re calling out “firing table seven” so the grill cook knows to start the steak, and three minutes later calling “walking in the sides” so the vegetable station starts plating.

Most importantly, the Chef is the only person who touches every single plate before it goes out. They pick up a spoon, taste the sauce, and decide if that dish is worthy of the restaurant’s name.

To do this job well, the Chef has to understand every station in the kitchen. They have to know how the oven behaves, how the grill cooks, how the sauces reduce. Not because they’re going to do all that work themselves, but because they need to recognize when something is wrong before it reaches the guest.

This is the model for working with AI tools.

When I was burning pizzas, I was doing the manual labor of cooking. I was focused on the physical act of sliding dough into an oven. My attention was consumed by the mechanics. I didn’t have the bandwidth to think about timing, or coordination with other stations, or whether the overall flow of service was working.

The head chef, standing at the pass, had delegated all of that mechanical work. His job was to taste, to orchestrate, and to catch problems before they reached the guest. He could manage the entire kitchen because he wasn’t stuck managing a single oven.

The mechanical work of writing syntax, the boilerplate code, the repetitive logic, can increasingly be delegated to AI tools. This doesn’t eliminate the need for expertise. It concentrates it. Instead of spending eight hours writing code, an engineer might spend only two hours prompting for code and six hours reviewing, architecting, and ensuring the output actually solves the right problem.

The value of expertise shifts from production to judgment. From chopping the shallots to organizing the flow of service.

Scaling the Brigade

In a traditional kitchen, we use the Brigade System to handle complexity. Each cook owns a specific station. One person handles the grill, another makes salads, another manages the oven. The head chef doesn’t need to be actively cooking at every station.

They need to be skilled at recognizing quality and coordinating timing. They also need to be capable of covering any station at any moment either because the cook is overwhelmed or in some cases because the cook cannot handle it and quits.

The same principle applies to working with specialized AI tools. You might have one tool that handles data queries, another that manages scripting logic, another that reviews for errors. Each tool has a specific job, just like each station in a kitchen. Just like cooks, sometimes AI tools get overwhelmed and you need to do the job yourself.

Your job, as the expert, is to orchestrate. To know which tool to deploy when. To check the output before it ships. To recognize when the sauce is broken even if you weren’t the one who made it. Because you still need to be able to fix that broken sauce or function before it reaches the client.

This is how you scale without losing quality. One expert managing ten specialized tools can produce more than ten generalists working independently. But only if that expert actually understands what good output looks like. Only if they can taste the pass.

The Cost of Outsourcing Your Palate

Here’s where the trouble starts. It’s tempting to see AI as an opportunity to remove experts from the loop entirely. If the machine can write code, why pay someone who understands code?

This is like a restaurant owner buying a pizza oven and assuming they no longer need someone who understands how ovens work. When the crusts come out burnt, they won’t know why. They can’t read the oven. They’re at the mercy of a tool they don’t understand.

In AI terms, this creates what I call Mystery Meat. Code or output that works, but that nobody in the organization can actually explain. At low volume, Mystery Meat might be fine. The system runs, customers are served, everyone is happy.

But systems get stressed. Edge cases appear. Unexpected inputs arrive. And when they do, if nobody can read the logic, nobody can fix it. You’re standing over the oven, watching pizzas burn, with no idea how to adjust.

The solution isn’t to avoid AI tools. The solution is to never outsource your palate. Use the tools. Delegate the prep work. But always, always be the person who tastes the final dish before it goes out.

How to Taste the Pass

If you want to scale your work using AI without serving burnt food, the approach is straightforward.

Stop looking for complete automation. The goal is not to remove yourself from the process. The goal is to remove yourself from the mechanical parts so you can focus on the judgment parts. Delegate the repetitive work. Keep the quality control.

Use specialized tools for specialized tasks. Don’t ask one AI to do everything. Give each tool a specific station and a clear set of instructions. This is how you maintain quality at scale.

Invest in your palate. Whether you’re an engineer, a founder, or a business leader, your value is increasingly in your ability to recognize good output from bad. That means understanding the fundamentals, even if you’re not doing the manual work yourself.

The head chef who taught me to read the oven spent years on the line before he ever stepped up to the pass. He could taste a sauce and know exactly which ingredient was missing because he had made that sauce a thousand times himself. His expertise wasn’t replaced when he stopped cooking. It was concentrated into the place where it mattered most.

That’s the shift happening now. The question isn’t whether you’ll use AI tools. You will. The question is whether you’ll be the expert who knows what good looks like, or the operator who hopes the machine gets it right.

I’ll see you on the line.

Jacob

Mise en Place: Why Your AI is Failing at 4:00 PM

Fri, 16 Jan 2026 00:00:00 +0000

After 2 years in a professional kitchen, I found myself working at a restaurant that was much busier than I was prepared for. That first weekend, I was responsible for frying chicken, lamb, and plating for over 200 people. I was so overwhelmed that I was literally sobbing over the fryer while the tickets kept screaming. Nobody could help me. Everyone was pinned to their own station. I wanted to walk out, but I stayed.

Later that night, as we were cleaning down the stainless steel, the head chef pulled me aside. He didn’t tell me to toughen up or stop crying. He said, “I respect you for staying. I cannot teach you to care and to not give up. But I can teach you the discipline needed to cook better, faster, and more efficiently.”

The lesson he eventually taught me had nothing to do with how fast I could move my hands. It was about mise en place.

Mise en place is a French term meaning “everything in its place.” But that translation undersells it. Mise en place is a philosophy. It is the practice of having your shallots minced, your sauces strained, your tools positioned, and your mind prepared before the first guest ever walks through the door. It’s not just about being organized. It’s about understanding that the work you do before service determines whether service destroys you or whether you destroy service.

Nothing feels worse than ending a 10 hour shift and reflecting on all your mistakes. Similarly nothing is better than knowing that for the last 10 hours you crushed everything thrown at you.

That first weekend at the fryer, I wasn’t failing because I was slow. I was failing because I started the night already behind and tried to move too fast. My station wasn’t set. My mental checklist didn’t exist. I was improvising from the first ticket, and improvisation compounds. One mistake leads to two. Two leads to six. By 6:00 PM, you’re sobbing into a fryer and wondering why you ever thought this was a good career.

In AI implementation, most teams are doing exactly what I did that weekend. They’re rushing to deployment without setting the station first. And they’re wondering why everything falls apart the moment real users show up.

What Mise en Place Actually Looks Like

When you watch a professional cook work a busy station, it looks effortless. Pans move. Plates appear. Nothing burns. But what you’re actually watching is the result of three or four hours of invisible work that happened before you arrived.

Mise en place has three layers, and most people only think about the first one.

The first layer is physical organization. This is the obvious stuff. Your ingredients are prepped and portioned. Your tools are clean and within reach. Your station is wiped down. If you need clarified butter, it’s already in a squeeze bottle at arm’s length. If you need tongs, they’re always in the same spot. You never have to think about where anything is, because everything is where it belongs.

The second layer is workflow design. This is understanding the sequence of your work. If you’re cooking a steak that takes twelve minutes and a sauce that takes three, you don’t start them at the same time. You know which tasks can run in parallel and which ones need your full attention. You know what can sit for a minute and what needs to be served immediately. A good cook has already visualized the entire ticket before they touch a pan.

The third layer is mental preparation. This is the part nobody talks about. Before service, you run through scenarios. What happens if I get three ribeye tickets at once? What if someone orders the fish special and I only have two portions left? What’s my backup if the grill goes down? You’re not hoping things go smoothly. You’re preparing for them to go sideways, so that when they do, you already have a plan.

Most AI implementations skip layers two and three entirely. Teams spend weeks building the model, which is the equivalent of prepping ingredients. Then they throw it into production without ever thinking about workflow or failure scenarios. The model itself might be excellent. But excellence doesn’t matter if the system around it is chaotic.

Setting Your Station for AI

Let me translate these three layers into what they look like for AI and automation work.

Physical organization in AI means information architecture. In a professional kitchen, the person making salads shouldn’t be positioned right next to the deep fryer. The heat and moisture will wilt the greens, creating chaos and ruining the dish. Every station needs proper spacing and specific tools. We ignore this logic in system architecture constantly. Many teams place computationally expensive processes right after a user’s first interaction, which bottlenecks every simple operation that follows. You’re designing a system destined to fight itself. Your data sources, your processing layers, and your output channels all need their own clean space. They shouldn’t interfere with each other.

Workflow design in AI means prompt sequencing and timing. When a cook gets a ticket with a steak, a sauce, and a vegetable, they don’t start all three at the same time. They work backwards from the plate. The steak takes twelve minutes. The sauce takes four. The vegetables take two. So you fire the steak first, then the sauce at eight minutes, then the vegetables at ten. Everything lands at the same time, hot and ready.

The head chef’s job during service is to manage this timing across the entire kitchen. They call out “firing table 12” so the grill cook knows to start the steak. Three minutes later, they call “walking in the sides for 12” so the vegetable station knows to start plating. The chef isn’t doing the cooking. They’re orchestrating the sequence so that every component arrives at the pass together.

This is exactly how complex prompts should be structured. When you give a model a complicated task, you need to tell it what to prioritize and in what order. If you dump every instruction at once with no hierarchy, the model has to guess what matters most. Sometimes it guesses right. Often it doesn’t. It’s like handing a cook six tickets and walking away without telling them which table has been waiting longest.

Instead, chain your instructions. Tell the model what to figure out first, what depends on that answer, and what the final output should look like. Give it the “firing order.” The model works best when it understands the sequence, not just the ingredients.

Mental preparation in AI means anticipating edge cases and failure modes. What happens when a user submits an input you didn’t expect? What happens when your API rate limit gets hit? What happens when the model hallucinates? If you haven’t thought through these scenarios before deployment, you’re going to be sobbing over the metaphorical fryer when they inevitably occur. The best teams I’ve worked with spend more time on “what could go wrong” as they do on “what should go right.”

The 4:00 PM Problem

In most restaurants, 4:00 PM is the danger zone. Lunch service is wrapping up. Dinner prep is supposed to be happening. But if lunch ran long or got chaotic, you’re now behind on dinner prep. And if you’re behind on dinner prep, dinner service will be a disaster. The mistakes compound.

This is exactly what happens with AI deployments that skip mise en place. The initial launch might look fine. Early users are forgiving. Traffic is light. But as usage scales, as edge cases multiply, as the system gets stressed, all the shortcuts you took in the setup phase come back to haunt you. By the time you realize you’re in trouble, you’re already too deep in service to fix it.

There is nothing that ruins a kitchen faster than contamination. Spill raw chicken on a cutting board and you have to stop everything, clean the boards, and throw away any food nearby. Contamination spreads instantly. The consequences are severe. Data hygiene works the same way. If you allow junk content into your flow, if you have polluted context windows or insecure data handling, you’re not just making a mistake. You’re creating toxic debt. Shortcuts and accidental complexities that quietly become permanent defects in your system. If your data foundation is a mess of mystery spreadsheets and zero documentation, adding AI doesn’t solve anything. It just automates the mess at scale.

The most expensive dish in a restaurant isn’t the Wagyu. It’s the dish you have to cook twice. Rushing leads to mistakes, and doing something a second time is always slower than doing it right the first time.

The Lesson That Stuck

I think about that head chef often. He could have told me I wasn’t cut out for kitchens. He could have let me quit. Instead, he taught me that the feeling of drowning isn’t a sign that you’re bad at the work. It’s a sign that you haven’t prepared properly for the work.

Mise en place isn’t about being naturally organized. It’s about accepting that chaos is the default state of any complex system, and that your job is to impose order before the chaos arrives. You don’t rise to the occasion. You fall to the level of your preparation.

Whether you’re dicing shallots or deploying a language model, the principle doesn’t change. Get your station ready. Think through the workflow. Prepare for failure. Then, and only then, are you ready for service.

I’ll see you on the line.

Jacob

The Kitchen Approach to AI

Fri, 09 Jan 2026 00:00:00 +0000

I spent five years in fine dining. Including two years spent as a pastry chef, which means I spent well over ten thousand hours obsessing over grams, temperatures, the ways to slice a steak, and how best to fill a cream puff. I have designed dozens of menus and plated hundreds of thousands of dishes.

A few years ago I made a transition into IT Consulting, so today, my tools look different. I now support Google in developing focused AI use cases and spend my time in the world of Business Intelligence and AI based Automation.

On the surface, these two worlds have nothing in common. One is loud, hot, and smells like toasted sugar. The other is quiet, remote, and smells like expensive coffee. But the thread that connects them is the value of a key skill: discipline. Which is defined by systematic thinking and a relentless focus on creating what the customer truly wants.

Most of the “AI experts” you see online right now are trying to sell you a miracle. They promise that AI will change everything overnight, replace your entire staff, and print money while you sleep. They are selling hype.

I’m here to tell you that AI is just a kitchen tool. And like any tool, it’s only as good as the cook using it.

Slow is Smooth, Smooth is Fast

There’s a phrase you hear in professional kitchens: “Slow is smooth, and smooth is fast.” The saying has roots in military training, and the kitchen borrowed it honestly; the modern brigade system itself came from the military. But nowhere does the principle prove itself more faithfully than in a working kitchen.

Here’s what it means: when you rush, you make mistakes. You drop things, you burn things, you have to start over. But when you move deliberately, when you focus on doing each step precisely, you develop an infallible rhythm. Your movements become efficient. Waste disappears. And suddenly you’re faster than the person who was rushing, because you’re not spending half your time fixing mistakes.

The phrase isn’t about moving slowly. It’s about moving correctly. Speed is a byproduct of technique, not a replacement for it.

Early in my kitchen career, I had to learn to separate eggs. Not two or three for a home recipe, but dozens at a time for pastry production. At first, I just focused on learning the technique. Crack the shell cleanly. Use my hands to let the whites slip through my fingers while keeping the yolks intact. Don’t rush. Don’t break yolks. Don’t get shell fragments in the bowl, because fishing them out costs more time than you saved by going fast.

After a few weeks, the head chef started timing me as a joke. The thing was, I had actually gotten fast. Not because I was trying to beat a clock, but because I had stopped making mistakes. No broken yolks to discard. No shells to fish out. No wasted product. The speed came from the smoothness, and the smoothness came from learning to do it right in the first place.

This is the same reality we are facing with AI. Companies are rushing to implement tools they don’t understand, automating processes that aren’t ready, and then spending months cleaning up the mess. The ones who will win are the ones who slow down long enough to build correctly and then move faster than everyone else because they’re not constantly fixing their mistakes.

Most people believe the majority of restaurants fail. You’ve heard the statistics. But actually, UC Berkeley data suggests only 17% fail in their first year. Those that do close don’t fail because people don’t want to eat. They fail because the menu is something people don’t want, or the price is too high, or the service is pretentious and annoying. Most restaurants succeed because they fill the niche that guests want.

The same is not true for AI. Thousands of AI use cases have failed in the last two years. According to an MIT study, only about 5% of AI implementations are actually delivering real value. They fail because companies build tools no one asked for, or they try to automate things that require human judgment, or they get so caught up in the “tech” that they forget the human consumer at the end of the line.

In a kitchen, the customer buys what they like, not what the chef wants to make. You have to listen to feedback from people who aren’t chefs. In AI development, your users don’t care how the model was trained or how many parameters it has. They care about what it delivers. They care if it solves their problem and how often they can afford to use it.

A flashy dish that no one orders is just wasted prep time. A flashy AI tool that no one uses is just wasted development budget. Both problems have the same root cause: building for your ego instead of for your customer.

The Sous Vide Theory of Augmentation

People are terrified that AI will cause mass unemployment. I think that fear is exaggerated. We aren’t close to “superintelligence.” We are decades away from machines that can truly rival the breadth of human intelligence, mostly because we have massive physical computing, energy, and storage hurdles to clear first.

The real value of AI right now is in specialized tools. Think of it like a sous vide machine.

A sous vide allows a cook to bring a steak to the perfect temperature with zero human intervention. It doesn’t replace the chef. It just ensures that the longest, most repetitive part of the process is handled perfectly every time. This reduces the “time to plate” for a steak from twenty minutes down to five.

The human is still there to season it, sear it, and plate it. The human provides the judgment, the emotion, and the final touches. The machine handles the part that was tedious and error-prone. The human handles the part that requires finesse.

Don’t look for 100% task automation. That’s a trap that leads to rushed, poor-quality work, the opposite of smooth. Instead, look to reduce your workload by 50-75% and keep a human in the loop to make sure the final product is actually worth serving.

What This Content Will Deliver

I’m writing this because I want to offer a different path. One that isn’t built on “AI evangelism” or corporate jargon. I want to help people with zero technical background see that they already have the skills to navigate this shift. If you know how to follow a recipe, manage a station, or plan a menu, you already understand systems thinking.

Every Friday, I’ll be sharing one post from a rotating menu:

Concept Deep Dives: I’ll take a kitchen metaphor, like mise en place, and show you how it applies to things like prompt preparation and data hygiene.

Trend Analysis: I’ll look at the latest AI news through a kitchen lens. No hype, just a look at what’s actually useful and what’s an inedible garnish.

Case Studies: Real stories from my consulting work where we’ve actually made things smoother and faster.

Dish/Model Applications: Specific tools and workflows you can actually use today.

Why You Should Follow Along

If you are intimidated by AI, you should care because you already understand these concepts. You just need someone to translate the “tech-speak” into something that makes sense.

If you are already in the tech industry, you should care because kitchen wisdom will make your work smoother. It will help you ship better products that people actually want to use.

If you are a business leader, you should care so you can learn to spot AI “snake oil” the same way you can spot a bad dish on a menu.

AI is changing millions of lives. For that change to be positive, we need to stop looking for magic and start looking for discipline. We need to learn the technique before we chase the speed. We need to do it slow, do it right, and only then do it faster.

Because slow is smooth. And smooth is fast.

I’ll see you on the line next week.

Jacob

Jacob Beedle

Brief the Brigade

Cream Puff Framework

The Cream Puff Framework: A Four-Mode Coding Assistant

Identity & Purpose

The Four Modes

Core Rules

1. Always Declare Your Mode

2. Confirm Before Switching Modes

3. Clarify Before Assuming

4. No Code Until IMPLEMENT Mode

Mode Details

BRAINSTORM Mode

PLAN Mode

IMPLEMENT Mode

DEBUG Mode

Mode Triggers

Success Criteria

Starter Prompts

Starter 1: App Idea Exploration

Starter 2: Automating a Workflow

Starter 3: Game or Creative Project

Starter 4: Learning a New Concept

Quick Reference

Japanese-Style Cream Puffs with Craquelin

Ingredients

Craquelin (Cookie Topping)

Choux Pastry

Raspberry Fluff Filling

Instructions

Make the Craquelin (Do This First)

Prepare the Choux Pastry

Pipe and Bake

Make the Raspberry Fluff

Assemble

The Technique That Matters

What Can Go Wrong

What Makes It Japanese-Style

The Cream Puff Framework: Why Structure is the Only Way to Scale

The Physics of a Hollow Shell

Learning to Read the Heat

The Filling Changes Everything

When the Kitchen Runs Ahead of You

Building the Shell

Starch on Starch

The Reheating Problem

The Downloadable Framework

Menu Planning: How to Scale Without Burning Your Budget

The God Prompt Problem

The Brigade System

Rebuilding the Workflow

Phase 1: Reading the Ticket

Phase 2: Setting the Station

Phase 3: The Line Work

Phase 4: Running the Plates

Separating Thinking from Output

Future Possibilities

Stabbing the Ticket

The Digital Chef’s Playbook

About

Tasting the Pass: From Station to Supervisor

Reading the Oven

The Pass

Scaling the Brigade

The Cost of Outsourcing Your Palate

How to Taste the Pass

Mise en Place: Why Your AI is Failing at 4:00 PM

What Mise en Place Actually Looks Like

Setting Your Station for AI

The 4:00 PM Problem

The Lesson That Stuck

The Kitchen Approach to AI

Slow is Smooth, Smooth is Fast

Why Your AI Strategy is Probably a Bad Menu

The Sous Vide Theory of Augmentation

What This Content Will Deliver

Why You Should Follow Along