Persona Panels: Grounding Coding Agents in Expert Judgment

How our coding agents convene a persona panel of engineering thought leaders to produce sharp judgment instead of the average of all opinions

LLMs are averaging machines. Asking it for direction on a specific scenario will produce an answer that is the most probable blend of all relevant viewpoint in its training data.

The Persona Panel skill is our solution to this in scenarios where instead the most relevant and qualified answer is needed. The skill consists of a small roster of well-known engineering thought leaders (Fowler, Martin, Beck, Evans, Cagan, etc) each captured as a seed files, and convened upon request for grounded inputs.

An LLM as an Averaging Machine

The median of strong opinions is never the best opinion.

Take the following scenario. Your OrderService is 1,200 lines long and needs to be refactored, but the question is how. The answer to this “how” depends on trade-offs, can be approached from different angles, and in order to be useful must be based on certain beliefs and theory of what “correct” is measured against in this situation.

Asking your coding agent (LLM) for a direction (or to perform the refactoring) will produce an output that incorporates many plausible points; Single Responsibility Principle, extracting separate classes, doing it incrementally vs in a bigger restructuring, etc. Everything will be (probably) technically sound, yet still not optimal.

Why not? Because software decisions can only be “correct” when accompanied by appropriate principles, assumptions, tradeoffs and theoretical grounding that guide getting to that specific answer. There is a reason every team defines their coding standards and “PR acceptance criteria” — without them the winner is the one with the strongest voice.

The inability of LLMs to achieve this grounding is, in the most literal sense, regression to the mean. LLMs take millions of books, blog posts, and Stack Overflow answers and squeeze them into a single probabilistic output. When asked a judgment question, you are effectively asking 10,000 authors to agree on one answer. The median of strong opinions is usually not the best opinion.

The above matters most for the critical engineering decisions, not for everyday coding. Architecture decisions, design trade-offs, refactoring strategies, “should we even build this?” debates . These are the situations where the value lives in the reasoning, and where averaged reasoning becomes worthless.

Persona Prompting as Selective Retrieval

Our fix is the following: instead of letting the LLM be everyone, we ground it to be someone specific. Someone who’s most well known principles, tradeoffs and way of reasoning is extremely relevant to the topic at hand.

We do this grounding by relying on a identity, a well-known persona, by naming them. Someone whose ideas are densely and distinctively represented in the training data. Example, “Martin Fowler” is anchored to specific books (Refactoring, Patterns of Enterprise Application Architecture), a specific vocabulary (code smell, Feature Envy, Extract Method), and specific opinions (favour small, safe, reversible moves over big rewrites; understand what you have before you decide where to go). The name acts as a retrieval key into a particular region of the latent space, one shaped by decades of consistent, opinionated writing.

This is the conceptual core of the technique. A persona prompt changes “which neighbourhood of the model’s knowledge gets activated”, and therefore which frame of reasoning will be most strongly applied to what we ask next.

The concrete implementation of this “naming” is done by a seed file. For each persona, we have a short Markdown document (typically 30 to 50 lines) that re-surfaces the persona’s core beliefs, vocabulary, and characteristics. The seed file does not try to capture everything about the persona, but just enough to anchor the generation so the LLM does not drift back toward generic advice.

The Skill Structure

The whole system fits in a small folder of Markdown files. There are three layers: the panel skill itself, the task skills that invoke it, and the persona seed files it loads.

harness/skills/
├── persona-panel/
│   ├── use-persona-panel.md        ← the meta-skill to convene a panel
│   └── personas/
│       ├── eric-evans.md           ← seed files per persona
│       ├── vaughn-vernon.md
│       ├── alistair-cockburn.md
│       ├── martin-fowler.md
│       ├── robert-c-martin.md
│       ├── kent-beck.md
│       ├── marty-cagan.md
│       ├── kent-c-dodds.md
│       ├── harrison-chase.md
│       └── bret-taylor.md
└── <various_other_skills>/
    ├── critique-coding-plan.md     ← invokes use-persona-panel.md
    ├── design-domain-model.md      ← invokes use-persona-panel.md
    ├── write-adr.md                ← invokes use-persona-panel.md
    └── ...etc                      ← invokes use-persona-panel.md

The arrows of dependency run one way. The task skills (critique-coding-plan, design-domain-model, write-adr, etc.) describe what needs to be evaluated and reference use-persona-panel.md as the mechanism for how to evaluate it. The panel skill in turn loads two to four persona seed files based on the problem. Nothing here is more than a few hundred lines of Markdown end-to-end.

Each seed file follows a shared template — frontmatter plus sections for invoke-when, core principles, signature moves, and a structured output format.

Our current persona panel covers the following disciplines:

• Eric Evans for strategic Domain-Driven Design
• Vaughn Vernon for tactical DDD
• Alistair Cockburn for hexagonal architecture and port/adapter boundaries
• Martin Fowler for refactoring and enterprise patterns
• Robert C. Martin for SOLID, Clean Code, and the Dependency Rule
• Kent Beck for TDD and Tidy First
• Marty Cagan for product thinking and should-we-build-it
• Kent C. Dodds for frontend testing strategy
• Harrison Chase for LLM application architecture
• Bret Taylor for AI agents and product-engineering strategy in regulated domains

The coverage is deliberate to the task we do most: domain, architecture, code craft, testing, product, and AI.

From Solo Persona to Panel: Engineering Disagreement

A single persona sharpens output, but the highest leverage usage we found was to assemble personas into panels and asking them to debate. This way, we don’t just get the single POV of one persona, but tap into collective intelligence by letting these personas sharpen their answers against each other.

For each persona panel discussion, the following output is produced:

• Diagnosis: what the personas see as the core we’re addressing in the topic at hand
• Recommendation : the panel’s preferred collective approach
• Trade-offs : what their approach costs
• Disagreements with the panel : where each persona would individually push back on the others

That last field is the most important one in the entire skill. It is the field that forces the model to generate genuine tension rather than convergence. Without it, three personas tend to politely agree with each other. With it, the model has to commit each persona to a position and then explicitly defend it against the others. Here is the full schema, derived from the Fowler file:

---
name: <identifier>
display_name: <human name>
discipline: <one-line discipline label>
description: <one-paragraph invoke-when, used by the harness loader>
---

# <Persona Name> - <Discipline>
> <One-line characterisation in their own voice>

## Important: this is a seed, not a ceiling
<reminder to go beyond the file>

## Invoke when
- <situations where this persona adds value>

## Do NOT invoke when
- <situations where a different persona is the right call>
- <explicitly names which persona owns those cases>

## Core principles
- <the 5–7 beliefs that drive their reasoning>

## Signature moves
- <named techniques, patterns, or refactorings they reach for>

## Pairs well with
- **<other persona>** - <what they unlock together>

## Anti-patterns they call out
- <smells, mistakes, or shortcuts this persona names and refuses>

## Output format
**As <Persona Name>:**
- **Diagnosis:** <what they see>
- **Recommendation:** <what they'd do, with named moves>
- **Trade-offs:** <what their approach costs>
- **Disagreements with the panel:** <where the others would push back>

Use The Right Experts at the Right Time

Not every persona belongs in every conversation. One of the things we learned quickly is that the panel works best when its composition matches the stage of work, when the personas around the table are the ones who would actually be in the room at that point in real life.

We compiled the panel to ensure there is good coverage accross our development workflow:

• In the planning phase, the relevant voices are Cagan (asking whether this is even the right thing to build), Evans (shaping the domain model that the work will live inside), Vernon (designing the tactical pieces — aggregates, entities, value objects), and Cockburn (deciding which layer owns what).
• In the build phase, Kent Beck (TDD, separate structural from behavioural), Dodds, Cockburn (architecture) and Harison Chase (applied AI).
• In the review phase, Martin Fowler and Robert Martin.
• In the fix phase, Fowler, Martin and Beck.

The insight is that the LLM is never trying to channel all ten personas at once. At any moment, it is being asked to hold two or three specific viewpoints that are directly relevant to the activity at hand.

Simplicity as Sophistication

The most useful LLM techniques are often not technical but epistemic. They are about helping the model access the right parts of what it already knows, at the right time. The persona panel skill is proof of this — it is a very basic idea captured in a few markdown files, yet it has a disproportionate impact on how we use coding agents everyday.

Get Started

We have open-sourced the persona panel as a standalone starter kit at engineering-persona-panel-example. It contains the panel skill, the full set of persona seed files, and an example task skill that wires the panel into a plan critique workflow. Clone the repo, drop the folder into your project, point your AI coding agent at use-persona-panel.md, and you are up and running. From there, swap in personas that match your domain, add your own task skills, and make it yours.