Inspiration

Most recipe tutorials are designed around an ideal sequence: follow the instructions, reach the expected result, and continue to the next step. But real cooking rarely works that way—especially for beginners.

Dough may be too cold, too soft, sticky, or cracked. Roasted peaches may release too much liquid or collapse before assembly. At exactly the moment when a user needs the most help, a conventional recipe usually provides the least guidance.

We created Peachy Peachy around a simple idea:

A failed checkpoint should not be the end of a tutorial. It should become another designed path.

Instead of treating cooking as a single linear sequence, Peachy Peachy models it as an interactive process with observable states, recovery actions, and opportunities to return to the main recipe flow.

What Peachy Peachy Does

Peachy Peachy is a mobile-first, interactive tutorial for making a French peach tart.

The current Build Week demo focuses on two critical parts of the recipe:

  • tart dough;
  • roasted peaches.

At key moments, the tutorial pauses at a checkpoint and helps the user evaluate what they can actually observe. For example, the dough may be firm and workable, too soft and sticky, or too cold and beginning to crack.

Each recognized state is connected to a vetted response. Depending on the situation, the outcome may be:

  • full recovery and return to the original recipe;
  • continuation with reduced quality;
  • repurposing the ingredients;
  • restarting when recovery is no longer responsible.

The demo also includes hand-drawn state illustrations and an animation showing the shallow press response of properly prepared dough.

How We Built It

We separated the system into two layers.

The first layer is a closed set of checkpoints and observable state IDs. AI may help map the user’s reported observations to one of these existing states, but it cannot create a new state or freely invent cooking advice.

The second layer is a curated knowledge manifest containing the corresponding recovery nodes. Once a state has been identified, the application retrieves the appropriate recovery path from this vetted local knowledge base.

This produces a deliberate safety boundary:

AI classifies the observation; the curated knowledge base provides the guidance.

The current prototype uses MiniMax for runtime inference. Codex and GPT-5.6 were used extensively during development to inspect and implement the repository, structure the knowledge system, review state and recovery logic, integrate the interface and visual media, debug the application, and validate the final submission.

The human team remained responsible for product scope, recipe interpretation, food-safety boundaries, recovery decisions, and visual approval.

The application was built as a React and TypeScript web project with a mobile-first interface. The final repository includes an English demo path, integrated state media, a root README with setup instructions and architecture documentation, 30 passing automated tests, and a successful production build.

Challenges

One of the largest challenges was deciding what the AI should not be allowed to do.

A fully generative cooking assistant may sound flexible, but unrestricted generation is risky when advice concerns food handling, ingredient condition, or whether a failed preparation can still be used. We therefore designed Peachy Peachy as a closed-state system rather than an open-ended advice generator.

Another challenge was translating expert judgment into observations that a beginner could realistically make. Instructions such as “check whether the dough is correct” are not useful unless the interface explains what “correct” looks and feels like. We had to convert technical distinctions into visible and tactile evidence without oversimplifying them.

Visual communication was also difficult. The animation could not be decorative only—it had to show a meaningful physical response, such as the shallow indentation produced by gently pressing properly conditioned dough. We iterated on the storyboard and final media until the motion communicated the intended state clearly.

Finally, we had to keep the Build Week scope disciplined. The broader concept could support many desserts, photo-assisted diagnosis, substitutions, and community features, but we limited the submitted demo to one peach tart workflow and a small number of thoroughly defined checkpoints.

What We Learned

We learned that the most useful role for AI is not always to generate more content. In Peachy Peachy, its value comes from helping interpret an uncertain situation within carefully defined boundaries.

We also learned that recovery should not be represented as a single binary result. “Fixed,” “still usable but different,” “better repurposed,” and “must restart” are meaningfully different outcomes, and a responsible tutorial should communicate those differences clearly.

Codex and GPT-5.6 helped us move between product reasoning and implementation quickly. They were especially valuable for repository inspection, consistency review, test correction, interface integration, and identifying gaps between our intended architecture and the actual runnable product.

Most importantly, the project changed how we think about tutorials. A good tutorial should not only describe the perfect path. It should remain useful when reality diverges from the plan.

Accomplishments

During OpenAI Build Week, we turned an early product concept, recipe research, and visual direction into a runnable application with:

  • a structured checkpoint and recovery architecture;
  • a curated knowledge manifest;
  • observable dough and roasted-peach states;
  • integrated recovery routing;
  • hand-drawn state media and animation;
  • a complete English demonstration path;
  • automated tests and production-build validation.

Peachy Peachy demonstrates that failure does not have to be treated as the end of an instructional experience. It can be designed as the beginning of the next useful step.

Built With

Share this project:

Updates