My question might seem stupid, but ReAct pattern seems to always work and actually gives great results in the other hand we have the plan pattern and to be honest i cannot think of how it's exactly used in production system, im not sure if this is correct but how it's technically implemented is you give the LLM context and you tell it, hey give me your plan to how you will solve this thing, so now it will build the plan but won't it also follow the same plan in the ReAct pattern to solve that exact problem? I want learn from people that used the planning pattern in production, how and why you used it? and how do you enforce the LLM the follow the plan exactly?
Comments
verdverm•29m ago
LLMs are unreliable, which is why I use the plan pattern
1. describe what you want in a paragraph or two
2. tell it to write a plan.md, iterate and review multiple times
3. implement and test, iterate and review multiple times
Putting in more effort upfront, human in the loop planning, has a higher probability of getting out something you want, in my (vibes based) experience. Use many fresh sessions and different models for this. You want them to focus more on the current state, the intent of the changes, the complexities. What you don't want is a step-by-step plan for changing the code, which effectively is putting the thinkin / implementation in markdown first. The implementation will go much better with a well designed and vetted plan. This is where I spend more of my effort these days.
KISS but detailed enough to provide framing and guidelines without being prescriptive, because we know humans too miss edge cases and need to rethink or pivot strategies.
verdverm•29m ago
1. describe what you want in a paragraph or two
2. tell it to write a plan.md, iterate and review multiple times
3. implement and test, iterate and review multiple times
Putting in more effort upfront, human in the loop planning, has a higher probability of getting out something you want, in my (vibes based) experience. Use many fresh sessions and different models for this. You want them to focus more on the current state, the intent of the changes, the complexities. What you don't want is a step-by-step plan for changing the code, which effectively is putting the thinkin / implementation in markdown first. The implementation will go much better with a well designed and vetted plan. This is where I spend more of my effort these days.
KISS but detailed enough to provide framing and guidelines without being prescriptive, because we know humans too miss edge cases and need to rethink or pivot strategies.