breadchris

You’ve probably had this experience.

You open an AI tool, type a reasonable request, and get back something that is technically correct and practically useless. You refine it. It improves. You refine it again. It improves further. But you can’t quite tell why.

The problem is rarely just the model. It’s the mental model.

If you treat AI like a search engine, you ask for facts. If you treat it like an oracle, you ask for answers. If you treat it like a conversation partner, you negotiate through dialogue.

But large language models are generative systems that respond to constraints. Every message you send modifies the active specification: tone, scope, assumptions, structure, audience.

breadchris

There was a stone hall by the river, built low and thick against the weather. People came to it from the surrounding lands, not because it was beautiful, but because of what happened inside.

In the center of the hall stood an iron cylinder, heavy and ringed, set into a cradle of stone. A rod fit closely within it. When black powder was poured inside and set alight, the rod leapt upward with force enough to shake the beams. Sometimes it struck the roof. Sometimes it bent. Each time it fell back hot and useless, and the air filled with smoke.

Those who watched were impressed.

They spoke of power. They spoke of what might be done if the force could be made larger still. They learned to pack the powder more tightly, to seal the iron more carefully, to send the rod higher with each attempt.

And each time, when the smoke cleared, the hall was quiet again.

breadchris

You haven’t really tasted a cherry until you’ve eaten one warm from the tree it grew on.

Not because it’s romantic, but because that’s when the chemistry is intact. Sugar has finished forming. Acids are still bright. Aromatics haven’t been dulled by cold storage, transport, or time. Once that cherry is picked too early or shipped too far, cooking becomes an act of compensation—more sugar, more acid, more technique layered on in an attempt to recover something that never arrived.

Most traditional dishes exist because someone noticed what an ingredient could tolerate—and what it rewarded. Stews, roasts, ferments, breads: these are not cultural accidents. They are adaptations. The method fits the material. When cooking works, it’s because the food is being treated in a way that makes sense for what it is.

That idea has become harder to see.

Modern kitchens are defined by abundance. Almost everything is available all the time. Ingredients are displaced from their original environments and asked to perform eve

breadchris

Compiling Dinner

When you read a recipe, you’re already programming. Ingredients are inputs. Actions—chop, stir, simmer—are instructions. The kitchen is your runtime environment, and you, the cook, are the processor. If you follow the recipe to the letter, you get the expected output: a finished dish. Miss a step, and you’ve introduced a bug. Burn the onions, and you’ve hit a runtime error.

Seen this way, recipes are languages, and cooking is compilation.

⸻

Recipes as Grammar

breadchris

Sketching Compilers Beyond Code

Every programmer remembers the first time they encountered a compiler not as a tool, but as a system. The pipeline—lexing, parsing, semantics, code generation—was presented as the machinery that turned human-readable source into machine-executable instructions. It felt both arcane and essential, a rite of passage into serious computer science.

But the notion of a compiler has always been broader than C turning into assembly. A compiler is any bridge between intent and execution. It takes structure in one domain, transforms it through rules, and produces something runnable in another.

For decades, that metaphor lived mostly inside programming languages. With Large Language Models, it’s beginning to expand.

⸻

breadchris

Great — here’s a pitch deck skeleton built directly from your transcript themes and the memo. Each slide has the core idea + bullets you could expand with visuals later:

⸻

Pitch Deck Skeleton: The World’s Best List App

⸻

1. Title Slide • App name / tagline (e.g. “Lists, but alive.”)

breadchris

The Anatomy of a Good List

Five years ago, I made a list of every independent coffee shop in my city. It was nothing fancy — just a quick way to decide where to go on Saturday mornings. But people started sharing it. Friends passed it to friends. Strangers sent me suggestions to add. Before long, it had a life of its own.

That’s the thing about a good list: once it’s useful, it stops belonging only to you. Some lists fade after a single use. Others become part of how people think and decide.

⸻

breadchris

Most software today is a patchwork. A customer complains to support. That request is passed to the product manager. The product manager writes a ticket. A developer implements it with whatever context made it through the game of telephone. The result isn’t a cohesive product. It’s a stack of reactions.

Protoflow rejects this cycle.

We aren’t building yet another productivity tool. We’re not selling infrastructure, or a new way to host your app, or a fancy wrapper around an LLM. We’re offering a way to think. A way to develop—in the full sense of the word.

Protoflow is an ideology about building software that feels whole.

breadchris

Every new app begins the same way. You reach for a familiar scaffold: a Flask app, a Next.js starter, maybe a Spring Boot template. It’s muscle memory. You’ve done this before. Your mental model is primed—the stack, the setup, the steps. You scaffold the project, install dependencies, spin up the dev server. There's comfort in the ritual.

Early progress comes easy. You wire up the ORM, sketch your data models, add the first CRUD endpoints. The tests pass. The API returns exactly what it should. It feels like progress because it is progress. But it’s also the part of the project you’ve already solved in every previous app.

Then the real work begins.

You’re asked to implement a new feature—a more opinionated search, a billing integration, group permissions—and suddenly your momentum halts. Your elegant user model collides with the new requirements. The schema that once seemed minimal now feels rigid. Your CI pipeline complains about a version mismatch. That starter template you grabbed three weeks ago didn’t

breadchris

The most successful CLIs follow a core principle:

Minimize surface area. Maximize momentum.

Protoflow’s purpose is simple but powerful: Help builders stay in flow while turning tasks into working, testable prototypes.

Let’s start from use cases, distill the mental model, and then define a minimal CLI that truly serves its purpose.

🔁 Distilled Workflow (Mental Model)