01 ↗ SOURCE
Order intent
A notebook, ready to order.
quantity: 1More clarity. Less mental tracing.
The tactile
for modern software.
Code belongs in files. Behavior belongs on a board.
Explore a behavior from your app. Test the difficult cases. Bring the logic and evidence back to your codebase.
- Compare two pricing policies.
- Trace a failed input.
- Follow shared state across views.
Try a guided software behavior
Same flow. A different outcome.Try it below ↓
02 ⇄ LOGIC SLOT
Pricing strategy
Swap the policy. Keep the wires.
Standard · $15.0003 ◉ OUTCOME
Awaiting order
The result appears here.
Waiting for input Ready. Run an order to follow the result.
WHY BREADBOARD / IN THE AGE OF AI AGENTS
More code isn't
more understanding.
When agents produce changes faster than you can review them, your attention matters. You still need to understand the behavior and decide what should ship.
Folders organize where code is stored. Breadboard brings inputs, state, and outcomes into view so you can compare decisions without tracing every connection in your head.
01 / START SMALL
Bring the tricky slice.
Keep the rest of your app.
A checkout rule. A stateful cart. A search flow with awkward edge cases. Explore one behavior, then take the result back to the app it belongs to.
- 01
Bring the behavior into view.
Place the relevant logic, inputs, and outcomes on the board. Make the assumptions and service boundaries explicit.
- 02
Run it. Change it. Compare.
Swap a policy or send an invalid input. Follow the outcome and choose the behavior you want to keep.
- 03
Give your agent a concrete handoff.
Carry the chosen logic, constraints, and run results into the next implementation step.
- 04
Apply it in your app.
You or your agent adapt the code, connect real services, and check the same cases in your repo before shipping.
02 / FROM EXPLORATION TO IMPLEMENTATION
From the board.
Into your codebase.
Leave with logic you can use, cases you can test, and decisions your agent can act on. Keep the result connected to the software you ship.
Logic to reuse or adapt.
Carry the selected function or policy into your app. Keep its rules intact while adapting the surrounding code to your stack.
Cases to turn into tests.
Keep the inputs, expected outcomes, and observed results together. Give your agent specific checks for the implementation.
Context your agent can work with.
Use an export or a compatible MCP / WebMCP connection to hand over the behavior and its constraints without re-explaining the board.
On the board
Compare standard pricing at $15 with VIP pricing at $12. Check that quantity zero is rejected.
In the handoff
Keep the chosen pricing rule, quantity constraint, and example inputs with their expected outcomes.
In your app
Have your agent update checkout and add tests for those cases. Verify the real service connections in CI.
03 / BEFORE YOU DIVE IN
Your code. Your stack.
A clearer way to change it.
What leaves the board, how your agent uses it, and where production checks fit.
Can I use the result in my existing app?
Start with one behavior in your app: a pricing rule, a checkout flow, or a shared state update. Take the selected logic and the cases you explored back to that codebase. Reuse self-contained code where it fits, and have your agent adapt the connections to your framework, data, and services.
What do I take out of the board?
The chosen logic, its inputs and expected outputs, the rules it must preserve, and the results of the cases you ran. Code is material to reuse or adapt; those cases give your agent concrete targets for implementation and tests. A saved board preserves the working model, rather than packaging a deployed app.
How does my coding agent pick up the work?
Share an exported board, or use an available MCP or WebMCP connection with a compatible agent. The handoff gives the agent the behavior, constraints, and run results to work from while it changes your repo. Keep the conversation moving without reconstructing every decision in another chat.
Does a passing board run mean it is ready for production?
A board run checks the behavior for the inputs and dependencies represented there. Connect the implementation to your real services, turn the important cases into tests, and run your app’s integration checks and review before shipping. Your repo, CI, and deployment process remain the path to production.
What belongs on a board?
The slice that is hard to reason about across files: an order flow, shared state, a policy boundary, or an awkward failure path. Keep the rest of your app in place. Breadboard gives that slice a surface for exploration, debugging, and comparison.
How does this relate to Stewie Reflect?
Reflect reconstructs what an existing product already does. Breadboard gives the active behavior a surface while you shape what it should do next. Both keep understanding connected to the software instead of trapped in a separate document.
EXPLORE. IMPLEMENT. VERIFY.
Make the behavior clear.
Then make it part of your app.
A Stewie product. Built for software that keeps changing.