Skip to content

Adapting AI Assistants to Developer Interaction Style

Cognitive style shapes how developers converse with Copilot — tailoring per-developer configuration only pays back when team size and tool maturity offset the maintenance cost.

A mixed-methods think-aloud study of 27 developers using GitHub Copilot chat identifies five interaction modes and ten underlying needs mapped to problem-solving style and experience (Richards et al., ICSME 2026). A single default Copilot/Cursor/Claude Code configuration is implicitly tuned for one cognitive style and silently underperforms for the others.

Scope and Caveats

Generalising from the Richards et al. study requires explicit limits:

  • Single recent paper, n=27. Qualitative, not independently replicated. The earlier Barke et al. 2023 grounded-theory study names only two modes (acceleration, exploration) — the literature hasn't converged on how many distinct modes exist.
  • Copilot chat, not coding agents. Modes shift when automation rises to autonomous agent (Chen et al., CHI 2026); a persona file for chat workflows may misroute sub-agent dispatch.
  • Style, not skill. The framework rests on Kirton's Adaption-Innovation theory — describing cognitive style, not capability. Tailoring config to style without measuring outcome can lock in a comfortable workflow that isn't productive.

Treat this page as vocabulary for per-developer assistant configuration, not proof every developer needs their own persona file.

The Two-Mode Baseline

The stable literature result is bimodal. Barke et al. (2023) name them:

Mode What the developer is doing What the assistant should do
Acceleration Clear goal, constrained prompts Concise output, minimal explanation, exact patches
Exploration Unsure how to proceed, open-ended prompts Alternatives, rationale, verbose output

The 2026 paper subdivides this into five style-anchored modes, but every refinement sits on the same axis: constrained-output preference vs generative-output preference (Richards et al., 2026).

The Configuration Lever

The default Copilot favours one mode's input distribution and penalises the other. Three per-developer levers shift it back:

  • Copilot custom chat modes — .chatmode.md files define tailored AI roles per task (security reviewer, test generator, architect), each with its own system prompt and tool defaults (Thornton, 2026).
  • Cursor rules and persona packs — .cursorrules plus packs like cursor-claude-personas ship 38 role-based templates that switch behaviour without re-prompting (Maurya, 2026).
  • Claude Code instruction files and sub-agent allowlists — CLAUDE.md, .claude/agents/, and tool allowlists pre-condition every interaction at a per-repo or per-user scope.

Granularity is a choice: project-wide, role-based, or per-developer. The Richards et al. finding argues for the rightmost; the failure conditions below constrain when that's a good trade.

Why It Works

Conversational assistants are not deterministic UIs. The chat surface routes through a model whose output is heavily conditioned by the input distribution — prompt style, system instructions, examples, allowed tools. Exploration-mode developers submit open-ended prompts and tolerate verbose output; acceleration-mode developers submit constrained prompts and reject verbosity (Barke et al., 2023).

Persona configuration shifts the effective input distribution to match each developer's natural mode: .chatmode.md adds a system prompt, .cursorrules injects standing instructions, persona packs pre-load role expectations (Thornton, 2026). Both groups see lower prompt-tax and lower rejection rate from the same model under different conditioning. The mechanism is input-distribution alignment, not theatre.

When This Backfires

Configuration overhead is fixed; the productivity payoff scales with cognitive-style variance. Five conditions where the trade goes the wrong way:

  • Small teams (under ~5 active developers). The cognitive-style variance Richards et al. measure across 27 strangers is largely absent in a tight team self-selected for one methodology. Shared default plus opt-out wins on TCO.
  • Tools changing rapidly. When the assistant moves from copilot to autonomous agent in 6–12 months — current state for Claude Code, Codex, Cursor — copilot-era taxonomies misfire on agent-mode work (Chen et al., 2026).
  • Onboarding new developers. Defaulting a new hire into someone else's persona accelerates style alignment but masks whether they'd have developed a more effective style on their own. Pair with Deliberate AI-Assisted Learning.
  • Regulated codebases. Per-developer persona drift breaks traceability — which persona, owned by whom, produced which change — at the audit boundary. Single-persona orgs trade productivity for auditability and may be right to.
  • Standardising on the wrong style. Cognitive style is not capability. Tailoring config to comfortable style can lock in a workflow that feels productive but isn't (the Productivity Experience Paradox). Pair any rollout with outcome telemetry — intervention rate, time-to-merge, revision rate — or it optimises only chat comfort.

Example

A 12-developer platform team standardises on Copilot. Default chat mode is the GitHub-provided baseline. Two developers — both experienced, both shipping comparable code — complain about opposite problems:

  • Developer A ("acceleration"): "Copilot keeps explaining things I didn't ask for. I want the patch, not the lecture."
  • Developer B ("exploration"): "Copilot gives me one answer when I want to see three. I waste prompts asking for alternatives."

The team's resolution is two .chatmode.md files committed to the repo:

<!-- .github/chatmodes/concise.chatmode.md -->
---
description: Acceleration mode — patch-first, no preamble
---

You are a coding assistant. Output the smallest patch that solves the request.
Skip preamble, alternatives, and rationale unless explicitly asked.
If multiple approaches exist, pick the one that requires fewer surrounding changes.

<!-- .github/chatmodes/exploratory.chatmode.md -->
---
description: Exploration mode — alternatives-first, rationale included
---

You are a coding assistant. When a request admits multiple solutions, list 2–3 with
one-line trade-offs before picking one. Show the rationale you used to pick.
Treat the first turn as discovery, the second as commitment.

Developers select per-task, not per-identity — and the team tracks intervention rate per chat mode for one sprint to confirm the personas correspond to real output differences, not just preference. If intervention rate doesn't differ across modes, the personas are theatre and get removed.

Key Takeaways

  • The mechanism is input-distribution alignment, not personality matching — .chatmode.md, .cursorrules, and CLAUDE.md work because they shift the model's effective conditioning to match each developer's natural prompting style.
  • The literature splits on mode count — five style-anchored modes in Richards et al. 2026, two in Barke et al. 2023, and a different decomposition again under agent-mode automation (Chen et al. 2026) — so build vocabulary around the two-mode baseline and treat finer subdivisions as advisory.
  • Per-developer config overhead is fixed; the payoff scales with team size, style variance, and tool stability. Below ~5 developers, in fast-moving agent tooling, or under compliance, a shared default wins on TCO.
  • Pair any persona rollout with outcome telemetry (intervention rate, revision rate, time-to-merge) — without it, the configuration optimises chat comfort, not output quality.
Emerging — single recent source Last reviewed: 2026-06-19
Feedback