AI Recipe Modifier: When Recipe AI Actually Helps

A bounded tool, not a general-purpose cooking chatbot

Camilla Velasquez, NYT Cooking's general manager, says the system starts from the recipe itself, then uses the publication's substitution guide and reader comments, before applying what the team describes as AI drawing on its expertise. That order matters. It leans on NYT Cooking's existing knowledge and reader-tested patterns instead of letting open-ended model output run the show.

In practice, it handles simple swaps - like replacing ground pork with ground beef - and it can manage bigger adjustments tied to dietary needs. It can also refuse when a request would push the dish too far from what it's meant to be. Asked to turn gochujang buttered noodles into a cookie, for example, it redirected the user to a more appropriate cookie recipe.

That refusal isn't a failure to help. A system that accepts every request might produce something that sounds reasonable but doesn't actually hold together. Being able to say, in effect, "this isn't the same kind of recipe anymore" is more useful when the job is to adapt trusted instructions.

Changes are visible and reversible

When the recipe is modified, the changed parts show up in a distinct red-orange color. The app also labels the version as an AI modification that hasn't been tested or endorsed by the original recipe's creators. Readers can toggle between the adjusted version and the original.

That's a real trust issue. People need to know when something changed and who should take responsibility for it. If substitutions were hidden, they could be mistaken for the author's tested approach. Making edits visible - and letting readers back out to the original - keeps the recipe's baseline intact while still showing what the AI is doing.

The feature launched as an iOS-only beta. The Times also said users could hide it, which matters. A new capability isn't automatically a win for every subscriber. Letting people opt out reduces the cost of experimentation for anyone who just wants the original experience.

The tool did more than swap ingredients

Other tests showed the same overall idea - different kinds of adjustments, with changes spread where they need to be:

• In a grain bowl, cauliflower replaced broccoli, and delicata squash was added. The instructions adjusted how the squash was cut and increased the olive oil so the vegetables could cook together.
• A pasta and chickpea stew was adapted to use diced tomatoes instead of whole tomatoes. When asked for more vegetables, the tool offered options that fit the dish and added them to the cooking sequence.
• A waffle recipe was changed into a yeasted version, including an overnight rest in the refrigerator.
• A peanut noodle recipe was adjusted for less heat, with added vegetables, udon noodles, and rockfish. The instructions separated cooking the fish from the tofu and updated the noodle steps for the new pasta.
• A sauerkraut recipe was expanded with carrots, garlic, and kale, including suggested prep steps and additional salt for the larger batch.

What these examples underline is simple: the value here isn't "AI invents a new dish whenever you ask." It's "AI can do the connective work of adapting a method" - figuring out what to cut, when to add an ingredient, and which quantities or steps need to move.

The reader still has to evaluate the result

The chicken recipe test also showed a downside. The modified instructions suggested returning the shredded breast meat to the pot for about another half hour while the dumplings cooked. The tester held some meat back instead of following the step fully. The portion that stayed simmering was noticeably less succulent than the meat removed earlier.

This isn't a minor quibble. The instructions looked integrated and mostly sensible, but one timing decision changed the meal's quality. The tool can generate a recipe that reads clearly - and still fail to match what a human-tested version delivers.

So the takeaway is mixed. It handled several common changes well, but the end result still requires judgment. The feature can reduce the work involved in adapting a recipe, but it can't guarantee that every variation will be as good as the original.

A recipe is a designed outcome, not a bag of ingredients

A published recipe reflects choices made for a reason - a specific cut of meat, a sequence of steps, a particular balance of flavors, a texture the author is trying to hit. Substituting an ingredient can work, but it can also drift away from the author's intent.

That's why the feature's "hard redirect" matters. If a request changes the dish's core identity, the right move is often to point you to a different recipe instead of pretending the original can stretch endlessly. This is a useful pattern for AI products: be clear about what the system is responsible for, and stop when a request crosses the line.

Disclosure is necessary, but it doesn't solve everything

Labeling a recipe as AI-modified and untested is the right baseline. It tells users what they're looking at and avoids implying the original creator approved the variation. But disclosure alone doesn't automatically make every suggestion safe or useful.

People may still trust a polished set of instructions, especially when the change appears inside a publication whose recipes they already rely on. The interface therefore has to make uncertainty obvious, keep the original recipe available, and avoid presenting generated edits as if they're equivalent to tested editorial work.

There's also responsibility on the publisher's side. The Times says recipe editors helped shape the original rules and evaluated the feature's output. That involvement adds domain judgment, but it doesn't mean every generated recipe was individually tested. That distinction has to stay clear for both readers and the people whose work feeds the system.

AI should reduce friction, not replace the reason people subscribe

NYT Cooking isn't just a database of ingredient lists. It includes recipes created and tested by professionals, editorial judgment, and an ongoing relationship with readers. Some commenters objected because they feared AI would dilute that human contribution.

That concern is reasonable. If a publisher leans on AI to produce more content while cutting the people responsible for quality, the product may be cheaper to run but less valuable to users. Velasquez said the team didn't plan to publish fewer recipes and is hiring more than before. Those statements help, but the real test is what happens to the quality and visibility of human editorial work as the feature grows.

Design for a real constraint, not a technology demo

The best use cases here are pretty ordinary: you're missing one ingredient, you've got a different pan, you need to adjust a recipe, or you want to use what's already in your kitchen. These changes can save a trip to the store or make a recipe available to someone who would otherwise skip it.

That may sound incremental, but removing a recurring point of friction is exactly where product value shows up. The team doesn't need to argue that AI cooks better than a recipe author. It just needs to help readers complete the task they came for.

A good evaluation question is: What can the user do now that was difficult or inconvenient before? If the answer is only "interact with an AI feature," then the product is solving an adoption problem - not a user problem.

Put guardrails in the workflow

A bounded feature works better when it has clear limits and interface choices that explain its role. In this case, multiple decisions reinforce each other:

• Use trusted context first. Start from the original recipe and the publisher's substitution knowledge.
• Make edits visible. Highlight what differs instead of silently replacing the author's instructions.
• Keep the original available. Let users compare versions and go back to the tested recipe.
• Label the status. Make clear that the generated version hasn't been tested or endorsed by the recipe's creator.
• Redirect when appropriate. Don't shove a request into a recipe that no longer matches what it's supposed to be.
• Let users opt out. The core product shouldn't feel worse to readers who don't want the feature.

These aren't a universal checklist for every AI product. The right controls depend on what a wrong answer costs. But the underlying principle is solid: design should communicate provenance, reversibility, and limits - not just deliver an output.

Treat user feedback as part of quality control

The launch drew a strong reaction from commenters, including threats to cancel subscriptions and questions about how to disable the feature. That reaction doesn't automatically mean the feature is useless. In testing, it handled several practical changes well. What it does suggest is that the product team made a change in a community that has high expectations about human expertise and editorial identity.

The company's response - saying users could hide the feature and keeping it in beta - recognizes that adoption isn't just about whether the model works. It's also about whether people accept where the feature sits inside the product. Early feedback can show that mismatch before a broader rollout makes the decision harder to reverse.

For product teams, the lesson is to evaluate at least three things separately: whether the model produces usable outputs, whether the interface helps users understand what they're seeing, and whether the feature fits the relationship people already have with the product. A system can pass the first test and still fail the other two.