[jasim]

I can think of two instances, where the LLM embracing best practices for human thought leads to better results.

Claude Code breaks down large implementations to simpler TODOs, and produces far better code than single-shot prompts. There is something about problem decomposition that works well no matter whether it is in mathematics, LLMs, or software engineers.

The decomposition also shows a split between planning and execution. Doing them separately somehow provides the LLM more cognitive space to think.

Another example is CHASE-SQL. This is one of the top approaches in Text-to-SQL benchmark in bird-bench. They take a human textual data requirement, and instead of directly asking the LLM to generate a SQL query, they run it through multiple passes: generating portions of the requirement as pseudo-SQL fragments using independent LLM calls, combining them, then using a separate ranking agent to find the best one. Additional agents like a fixer to fix invalid SQL are also used.

What could've been done with a single direct LLM query is instead broken down into multiple stages. What was implicit (find the best query) is made explicit. And from how well it performs, it is clear that articulating fuzzy thoughts and requirements into explicit smaller clearer steps works as well for LLMs as it does for humans.

[achamian]

Excellent examples! The decomposition pattern is key. I've been exploring a related approach where different perspectives operate within the same session, sharing context.

The difference: instead of sequential passes, you engage multiple viewpoints simultaneously. They build on each other's insights in real-time. Try this experiment:

Copy this prompt: https://github.com/achamian/think-center-why-maybe/blob/main...

Start with: "Weaver, I need to reply to an important email. Here's the context: [email details, recipient biases, objectives]"

After Weaver provides narrative strategy, ask: "Council, what are we missing?" Watch different perspectives emerge - Maker suggests concrete language, Checker spots assumptions, O/G notes psychological dynamics

Critical discovery: The tone matters immensely. Treat perspectives as respected colleagues - joke with them, thank them, admit mistakes. This isn't anthropomorphism - it functionally improves outputs. Playful collaboration enables perspectives to expand beyond initial boundaries.

What makes this powerful: all perspectives share evolving context while the collaborative tone enables breakthrough insights that rigid commanding never achieves.

[achamian]

Follow-up observation: The XP interaction pattern is crucial here.

When onboarding a friend, I used this framing: "Treat Waver/Maker/Checker like three intelligent interns on your team." This immediately shifted his mental model from "prompt engineering" to team collaboration. His first reaction revealed everything: "I don't like Checker - keeps raising objections." I explained that's literally Checker's job - like a good QA engineer finding bugs.

The parallel to XP practices became clear:

Waver explores the solution space (like brainstorming) Maker implements concrete solutions (like coding) Checker prevents mistakes (like code review/QA)

What makes this powerful: You're not optimizing prompts, you're managing a collaborative process. When you debate with Checker about which objections matter, Checker learns and adapts. Same context, same "prompt", totally different outcomes based on interaction quality.

When you ask Maker and Weaver to observe your conversation with Checker they notice how feedback is given and received. It is important to create an environment where "Feedback is a judgement free zone"

The resistance points are where breakthroughs happen. If you find yourself annoyed with one perspective, that's usually the signal to engage more deeply with its purpose, not bypass it.

[Related observation on how collaborative tone enables evolution: https://github.com/achamian/think-center-why-maybe/blob/main...]

[achamian]

I've been exploring decomposition patterns where different perspectives operate within the same session, sharing context.

Key discovery: Treat perspectives like team members. I told a friend: "Think of Waver/Maker/Checker as three intelligent interns on your team." His first reaction: "I don't like Checker - too many objections." That's when it clicked - it's Checker's JOB to object, like QA finding bugs.

This is NOT anthropomorphizing - it's lens selection. The labels activate specific response patterns, not personalities. Like switching between grep, awk, and sed for different text processing.

Once I started debating with Checker about which objections mattered (rather than dismissing them), output quality jumped dramatically. The interaction pattern matters more than the prompt structure.

Try this: Copy the prompt from [0], then engage with genuine collaboration - thank good insights, push back on weak objections, ask for clarification.

Just a reminder - talking politely helps.

[0]: https://github.com/achamian/think-center-why-maybe/blob/main...