Fluffy, American-style pancakes were on the menu for this lazy Sunday morning.
We'd made pancakes before, but never the proper fluffy ones, so we did the obvious thing and googled a few recipes. Just as predictably, they all said different things, and some of them seemingly contradicted each other. We picked one that looked reasonable, followed it, and ate the result. The pancakes were good, but could have been fluffier. We had a few theories about what to change next time, but nothing certain. The likely plan was to trial-and-error our way through other recipes, or tweak the ingredients for the next batch.
However, given that it's 2026, an option is to ask an LLM to help us out. This got us wondering what the best way to ask the LLM would be. Here are some of the possible options that came to mind.
1. "Just give me a recipe"
Tell the LLM what we made today, that it wasn't fluffy enough, and ask it to recommend the ingredients and method for next time.
This is fast. We get a recipe, try it, maybe it's better. But we've learned nothing, and if it's still not fluffy we are back where we started, guessing.
2. "Help me understand what drives fluffiness"
Ask the LLM how ingredients like eggs, flour, baking powder, and preparation like pan temperature each contribute to fluffiness, and then suggest adjustments to the recipe based on that.
With this approach, we're not just collecting an answer, we are collecting a little bit of a model of the problem. We understand which levers exist and roughly which way to push them. The recipe we get out the other end is better, and we can adapt it without necessarily needing to re-ask the LLM.
3. "How do chefs actually think about this?"
Ask the LLM to research how chefs approach the "fluffy pancake problem" at its root, how the levers span both ingredients and preparation, and how each ingredient shapes the properties of the final result, fluffiness in particular.
This is the most work to set up and the slowest to read. It's also the one that gives the deepest, most transferable result. We come out understanding the problem, not just holding an answer to it.
The point isn't that 3 is "good" and 1 is "bad"
When drafting this post, the first instinct was to call option 1 the lazy way and option 3 the proper way. But that isn't quite right.
They're just three different ways to approach the same problem, and which one makes sense depends on what the problem is actually worth to us:
- In a hurry, and it's a one-off? Option 1 is fine. Get the recipe, move on.
- Bit of time, but not that invested? Option 2.
- Actually want to get good at making pancakes and potentially similar morning treats? Option 3.
All else equal, option 3 will give a better result than 2, and 2 better than 1. But that's not because one used a smarter model. It's the same model every time, and it isn't about clever wording either. The difference is how the problem is framed before attempting to solve it.
What this comes down to
The first is that the framing did more of the work than the model did. All three could have been run through the same LLM, returning three different levels of usefulness. Newer models are getting better at supplying that structure themselves, which helps. But a lot of what makes an answer useful still lives outside the model, such as how much time we have, how much we care, and what we want out of it.
The second is that none of this is prompt engineering. There was no magic phrasing or optimisation trick; the three options differ in how much of the problem we set out to solve, not in how it was worded. We read up on how something works, apply it to the specific case, and get a feel for which inputs matter most. A good cook or engineer used the same problem-solving steps long before LLMs, and they're the same ones now. The tooling changed. The way a problem is approached didn't, and it won't.
We're going to try again next weekend. We haven't decided which of the three we'll do. It probably depends on how much of a hurry we're in.