5 ms·

The reason I use plan then implement is because I can adjust the plan, whereas if I get it to implement straight away, it might (and often does) make the wrong

by figmert 2mo ago

The reason I use plan then implement is because I can adjust the plan, whereas if I get it to implement straight away, it might (and often does) make the wrong decisions that will be harder to adjust, or I'd have to adjust it after the fact.

canpan 2mo ago
One big pain point is not seeing the thinking trace. I noticed using pi with a self hosted model that I could spot, stop and correct my prompt much faster. With claude etc I have to first wait for it to think 3 minutes and then notice it got completely off the path I wanted. I still use a plan, because my local model is not as smart as opus, but I can iterate much faster.
- carterschonwald 2mo ago
  this so true. its really hard to make sure a model isnt going off the rails if i dont see full cot. the fact that oai and anthropic models hide it now has made them less reliable. which is a shame
  - trollbridge 2mo ago
    The great news is you can use DS-V-Pro, MiMo-V2.5-Pro, GLM-5.2, or K3 and see everything. I tend to use 5.6-Sol now more for one shot type of tasks where all I want is the answer and I’m not going to read the reasoning.
    - carterschonwald 2mo ago
      5.6 sol is pretty good, its definitely very very well tuned, i'm not quite sure which of the others i should use near term, but theyre doing great work
- WilcoKruijer 2mo ago
  I’ve seen people have success figuring out model reasoning by adding a required `reasoning` parameter to tool calls. Might be worth experimenting with this for the `write` tool call in a coding agent harness.
  - embedding-shape 2mo ago
    Also "divide and conquer" is still applicable. Tired of waiting 10 minutes for the model to come up with a plan that ends up being wrong? Divide the problem into pieces and attack the pieces individually, worst case scenario the model spends 2 minutes and got some detail wrong, but way easier to correct the tiny stuff. Once you've done with the pieces, do one "integrate them together" part, then you have a fully formed plan with less chance of wrong stuff in it. Yes, this requires a bit more interactivity than "prompt model then come back after making and drinking a coffee", but personally I prefer that.

by figmert 2mo ago

canpan 2mo ago

One big pain point is not seeing the thinking trace. I noticed using pi with a self hosted model that I could spot, stop and correct my prompt much faster. With claude etc I have to first wait for it to think 3 minutes and then notice it got completely off the path I wanted. I still use a plan, because my local model is not as smart as opus, but I can iterate much faster.

carterschonwald 2mo ago
this so true. its really hard to make sure a model isnt going off the rails if i dont see full cot. the fact that oai and anthropic models hide it now has made them less reliable. which is a shame
- trollbridge 2mo ago
  The great news is you can use DS-V-Pro, MiMo-V2.5-Pro, GLM-5.2, or K3 and see everything. I tend to use 5.6-Sol now more for one shot type of tasks where all I want is the answer and I’m not going to read the reasoning.
  - carterschonwald 2mo ago
    5.6 sol is pretty good, its definitely very very well tuned, i'm not quite sure which of the others i should use near term, but theyre doing great work
WilcoKruijer 2mo ago
I’ve seen people have success figuring out model reasoning by adding a required `reasoning` parameter to tool calls. Might be worth experimenting with this for the `write` tool call in a coding agent harness.
- embedding-shape 2mo ago
  Also "divide and conquer" is still applicable. Tired of waiting 10 minutes for the model to come up with a plan that ends up being wrong? Divide the problem into pieces and attack the pieces individually, worst case scenario the model spends 2 minutes and got some detail wrong, but way easier to correct the tiny stuff. Once you've done with the pieces, do one "integrate them together" part, then you have a fully formed plan with less chance of wrong stuff in it. Yes, this requires a bit more interactivity than "prompt model then come back after making and drinking a coffee", but personally I prefer that.