Diverge then converge with LLMs
One of the patterns I’ve found particularly helpful with LLMs is the diverge-then-converge pattern.
Diverge & Converge
Since LLMs are neural networks, when we give agents slightly different prompts, we make their “thinking” travel through different neural pathways (at least, that’s how I think of it).
That makes LLMs really helpful at suggesting different solutions to a problem.
But LLMs are also really good at summarizing, organizing, and synthesizing vast amounts of information.
When we put those two abilities together, we get an amazing tool to help us solve problems.
Here are three examples where I use the diverge-then-converge pattern.
Code Review
I have a code review skill that first diverges by having an orchestrator agent spin up three sub-agents to review code. Each sub-agent has a specific focus:
- Correctness
- Security
- Simplicity
If there are UI changes, I add a fourth sub-agent that compares the resulting design with what was requested.
But rather than read those “raw” results immediately, I have the orchestrator agent categorize the results into important, nice-to-haves, and nits in an HTML file that I can review.
Bug Fixes
I know some people have created loops for fixing bugs: issue comes into error tracker -> robot picks it up -> fixes it -> opens PR -> merges PR.
In my experience, that works for simple errors.
But when I try that for more complex errors, that loop leads to shallow fixes:
the agent will solve the obvious, terminal problem (“let me add a not
is_nil(arg) clause”) rather than fixing the root cause (“we shouldn’t allow
these values to be nil”).
And yet, the majority of the time, I want the root-cause fix. That’s why I like to have a diverge-then-converge pattern with the agents.
Just as with code review, I have an orchestrator agent spin up sub-agents to look for a fix with different aims.
- Simple fix (sometimes
not is_nil(arg)is all that’s needed) - Thorough fix (often suggests multi-step changes, closer to root cause fix)
- Creative fix (helpful to catch system design flaws. Sometimes this is the root issue)
Then, I have the orchestrator agent summarize and synthesize the suggested fixes, so I can decide which course of action we should take. Often, it ends up being a combination of two of the three approaches.
Design Variants
I stole this idea from Tomasz Tomczyk when we were pairing on his workflow. He had a design skill that would create three alternative designs for a given page based on three different companies’ styles (e.g. GitHub, Stripe, Figma).
In my case, I have the orchestrator agent spin up three sub-agents to create the same design in three different ways:
- Minimal (trying to capture only the essentials)
- Bold (a more opinionated design)
- Unexpected (rethinks the approach)
Once the agents are done, they output the designs in HTML so I can review them. Sometimes, there’s a clear winner, and we move on. But the benefit of having three different approaches is that I can choose parts of each that might work together.
And that’s when I tell the agent to combine the pieces that I like into a final design. The orchestrator agent then goes and creates a new design with all of my preferences.