1 Introduction↩︎

Large Language Models (LLMs) are increasingly used to support a wide range of Software Engineering (SE) tasks [1], [2]. To address the collaborative nature of software development, recent SE-oriented multi-agent systems, such as ChatDev and MetaGPT [3], [4], organize LLM agents around software development workflows and assign them roles that mirror those in software teams. These systems primarily differentiate agents by their responsibilities, defining what each agent does. However, in human software teams, individuals differ not only in the work they perform but also in how they approach it, due to characteristics such as personality, emotional state, and work style. Psychology research has shown that personality traits are associated with individual job performance [5], [6]. At the team level, personality composition influences team effectiveness and performance [7], [8]. SE research similarly suggests that personality and personality diversity affect team outcomes [9]–[11]. Beyond relatively stable personality traits, transient emotional states also influence behavior, decision-making, and performance [12]. These findings raise the question of whether personality and emotion profiles similarly shape the behavior and performance of LLM-agent teams.

Prior research has shown that persona-based prompts can influence LLM behavior [13], [14] and can steer LLM outputs toward specific roles or human subpopulations [15]. Similarly, emotion-oriented prompting studies indicate that emotional cues can influence LLM behavior and performance [16]. In SE, persona-guided prompting has been shown to improve code generation in single-agent settings [17]. Beyond SE, studies of multi-agent LLM systems have found that assigning agents different personality traits, such as Big Five-based traits, can influence team performance [18]. However, while prior work has examined personality- and emotion-based prompting in individual LLMs and non-SE multi-agent settings, their impact on collaborative SE teams remains largely unexplored. Understanding this relationship can provide insights into how agent profiles should be designed in multi-agent SE systems.

To address this gap, we conduct a systematic study of how personality and emotion profiles influence the performance and behavior of LLM teams on collaborative SE tasks. We refer to a personality and emotion configuration assigned to an agent as a profile, and to the corresponding natural-language description that reflects a profile, a specific SE task role, and work-style tendencies as a persona description.

We investigate two profile settings: shared-profile teams, in which all agents use the same profile, and mixed-profile teams, in which agents are assigned different profiles. We evaluate these settings across four LLMs representing multiple model families and capability levels.

Because a systematic study of profile effects requires a principled approach to profile construction, we develop a psychology-informed framework that integrates

• Big Five personality traits [19], [20] (i.e., conscientiousness, openness, and extraversion),

• SE-relevant work styles from the O*NET taxonomy [21], [22] (i.e., innovation, adaptability, achievement orientation, intellectual curiosity, attention to detail, cautiousness, and tolerance for ambiguity as well as their opposing behavioral poles),

• emotion categories grounded in basic emotion theory and SE emotion research [23], [24] (i.e., anger, fear, disgust, sadness, neutral, and happiness), and

• task roles (i.e., planner, implementer, and reviewer for code generation; writer and supervisor for code review).

We treat personality, emotion, and task role as experimental factors, and derive work styles from personality profiles to construct coherent persona descriptions.

Using this framework, we study two common SE tasks: code generation and code review. We select code generation as a widely studied application of LLMs in SE and as a direct measure of a team’s ability to produce executable solutions [1], [2], [25]. We select code review as a complementary activity in which LLMs evaluate software artifacts and provide natural language feedback [26], [27]. Together, these tasks cover both code-producing and code-evaluating forms of LLM-based SE work. We address the following three research questions:

RQ1: How do different shared-profile configurations affect the performance of LLM teams?

RQ2: How do mixed-profile and shared-profile team configurations differ in their impact on LLM team performance?

RQ3: How do personality and emotion profiles influence coordination and collaboration behaviors within LLM teams?

In summary, our study makes the following contributions:

• We propose a psychology-informed framework for constructing persona descriptions for LLM agents in software engineering tasks by integrating personality traits, SE-relevant work styles, emotions, and task roles.

• We investigate how personality and emotion profiles influence LLM team performance and collaborative behavior, and how profile assignment strategies (shared-profile versus mixed-profile teams) affect task outcomes.

• We conduct a large-scale empirical study of 78 agent-profile configurations across two software engineering tasks, including 54 shared-profile configurations and 24 mixed-profile configurations, using four LLMs spanning three model families and four scales.

The remainder of this paper is structured as follows. 2 reviews related work. 3 describes our profile-construction framework and methodology for the two selected SE tasks. 4 outlines the experimental setup, including models, datasets, metrics, and implementation details. 5 presents the results for our research questions. 6 discusses the implications of our findings. 7 discusses threats to validity. 8 concludes the paper.

2 Related Work↩︎

2.1 Multi-Agent LLM Systems in SE↩︎

Multi-agent LLM systems have become a common approach for organizing complex SE tasks. These systems decompose development activities across multiple agents and coordinate their interactions through structured workflows. For example, ChatDev models software development as a virtual software company in which agents assume different development roles [3], while MetaGPT organizes collaboration through role-specific procedures and intermediate artifacts [4]. More general frameworks, such as AutoGen, CAMEL, and AgentVerse, support collaboration through role instructions, shared context, and multi-step interactions [28]–[30]. Collectively, these systems establish role assignment and coordination as key design dimensions of LLM teams. However, they primarily differentiate agents through their assigned responsibilities. In contrast, we investigate agent profiles as an additional design dimension within role-based LLM teams rather than proposing a new coordination architecture.

2.2 Personality, Emotion, and Personas in Human Teams and LLM Agents↩︎

Human software developer teams differ not only in assigned responsibilities but also in personality traits, affective states, and work styles. Psychology research has shown that personality traits are associated with individual job performance [5], [6], while team personality composition is linked to team effectiveness [7], [8]. SE studies similarly suggest that personality and personality diversity influence software team outcomes [9]–[11]. Emotions also play an important role in software development work. Prior research has shown that workplace experiences can shape how people feel and behave [12], and SE studies have examined developers’ emotions and sentiment during software development and communication [24], [31]. Together, these findings suggest that team outcomes depend not only on assigned responsibilities but also on how team members approach their work.

Recent LLM research suggests that personality- and emotion-related characteristics can be induced through prompting. Prior studies have examined personality-oriented prompts and their effects on LLM behavior [13], [14], while persona prompts have been used to guide outputs toward specific roles, perspectives, or user populations [15]. Emotion-oriented prompting has similarly been shown to influence LLM responses [16]. Within software engineering, personality-guided prompting has been studied for code generation [17], and persona- and personality-based approaches have been used to diversify LLM-driven testing behavior [32], [33]. Beyond SE, personality-based agent configurations have been shown to influence multi-agent collaboration [18], while persona-driven agents have been used in social simulation [34].

Despite these advances, the effects of personality and emotion profiles in multi-agent SE systems remain largely unexplored. It remains unclear how personality and emotion profiles influence the performance and behavior of LLM teams on collaborative SE tasks, whether mixed-profile teams differ from shared-profile teams, and how profile assignments shape team interactions. Our work addresses this gap through a systematic study of psychology-informed agent profiles in multi-agent SE workflows.

2.3 LLM-Based Code Generation↩︎

Code generation is one of the most widely studied applications of LLMs in software engineering. Benchmarks such as HumanEval, MBPP, and LiveCodeBench evaluate generated solutions using execution-based measures of functional correctness [35]–[37]. Prior work has explored a broad range of approaches, including model design and training data [38]–[40], prompting strategies and LLM-based coding techniques [1], [2], [25], feedback-driven repair [41], [42], and agent-based workflows [43], [44]. These studies have established code generation as a standard setting for evaluating LLM-based software engineering systems. In our work, we use code generation as an execution-based task that enables direct evaluation of team outputs through functional correctness.

2.4 LLM-Based Code Review↩︎

Code review is a central software engineering practice in which developers inspect code changes and provide feedback [45]. Such feedback often addresses correctness, maintainability, readability, and project-specific conventions. LLM-based automated code review extends this practice by generating natural-language feedback on code changes. Prior work has studied pre-trained models for review-comment generation [46], LLM-based automated reviewers [26], and multi-agent review systems such as Hydra-Reviewer [27]. We use code review as a complementary reference-based task in which generated feedback is compared against human-written review comments. Together with code generation, this task enables us to study personality and emotion profile effects under both execution-based and reference-based evaluation settings.

3 Methodology↩︎

In this section, we describe the persona-construction framework and the multi-agent workflows for the two tasks, corresponding to Stages 1, 2, and 4 in 1. The profile-assignment strategy and evaluation setup, corresponding to Stages 3 and 5, are described in 4 .

3.1 Psychology-Informed Persona Framework↩︎

We construct role-specific persona descriptions from two psychology-informed components, personality and emotion, and derive SE-relevant work styles to adapt these components to task-specific roles. Personality defines the agent’s stable disposition[20], emotion specifies its temporary affective state[47], and work styles reflect work-related tendencies in how the agent approaches software-development tasks[21], [48].

3.1.0.1 Personality

We adopt the Five-Factor Model as the basis for personality [19], [20], which characterizes personality along five dimensions: Conscientiousness, Agreeableness, Neuroticism, Openness, and Extraversion. Because our goal is to study personality profiles that are likely to influence SE task performance, we focus on Conscientiousness, Openness, and Extraversion, as prior work [49] has reported reliable associations between these traits and programming aptitude. In contrast, no such association has been consistently observed for Agreeableness or Neuroticism [49]. Each selected trait is assigned one of two levels, High or Low. A personality profile is therefore defined by a combination of trait levels (e.g., Low Conscientiousness, High Openness, and Low Extraversion), yielding \(2^3 = 8\) possible personality profiles. To provide a baseline, we also include an all-Neutral profile in which all three traits are described as balanced, resulting in nine personality profiles in total.

3.1.0.2 Emotion

We select emotions based on both basic emotion theory and empirical studies of developer affect in SE. A systematic literature review reports that anger, fear, disgust, sadness, joy, love, and happiness are among the most frequently studied emotions in SE research [24]. Because considering all emotions reported in the literature would substantially increase the profile space, we focus on emotions that are both commonly observed in SE studies [24] and represented in basic emotion theory [23]. Accordingly, we select anger, fear, disgust, sadness, and happiness. To establish a baseline, we also include a neutral state representing the absence of explicit emotion, resulting in six emotion conditions in total.

3.1.0.3 Work styles

Persona descriptions also include work-related tendencies drawn from the O*NET Work Styles taxonomy, which defines 21 work-style variables within the Worker Characteristics [21]. For the candidate pool, we start with the ten work styles that have the highest O*NET Impact scores in the O*NET profile for software developers [50]. We exclude Dependability, Integrity, and Perseverance because their opposite poles would mostly describe the agent as unreliable, unethical, or unwilling to persist, rather than meaningfully capture variation in how the agent approaches software engineering work. The remaining seven styles are Innovation, Adaptability, Achievement Orientation, Intellectual Curiosity, Attention to Detail, Cautiousness, and Tolerance for Ambiguity. For each work style, we manually defined a contrasting behavioral tendency based on the style’s description in O*NET (e.g., Innovation versus Preference for Proven Methods). These paired tendencies are later used to construct distinct agent profiles. The other pairs are Adaptability versus Preference for Routine, Achievement Orientation versus Minimal-Sufficiency Focus, Intellectual Curiosity versus Practical Focus, Attention to Detail versus Big-Picture Focus, Cautiousness versus Action-First Decisiveness, and Tolerance for Ambiguity versus Need for Clarity and Structure. In total, we have 14 candidates.

3.1.0.4 Role and Task

The role component defines the agent’s responsibility in the task. In code generation, we use three roles: Planner, Implementer, and Reviewer. In code review, we use two Writers and one Supervisor. The same profile can be expressed differently depending on the role. For example, a cautious Implementer may make conservative code changes, while a cautious Reviewer may more carefully consider potential risks before accepting a solution. We describe the full workflows in 3.2 and 3.3 .

3.1.0.5 Persona generation

We generate persona descriptions using a fixed two-step procedure. Given a task type, role, personality profile, and emotion condition, the generator first selects three work styles from the candidate pool. Because O*NET defines work styles as work-related personal characteristics [21], we use them as supporting descriptors to make persona descriptions more concrete.

Rather than considering all possible work-style combinations, which would substantially increase the design space, we fix the number of selected work styles at three. For each persona description, the generator is instructed to choose three work styles from the candidate pool that fit the target profile, task, and role, while avoiding both sides of the same work-style pair. We set this number to three as a reasonable balance between concreteness and conciseness. This choice keeps the generation process tractable while ensuring a comparable amount of work-style information across persona descriptions.

In the second step, the generator synthesizes the role, personality profile, selected work styles, emotion condition, and task type into a coherent persona description of 120 to 180 words. We selected this range to provide sufficient space for expressing all profile components while keeping the description concise. We use Claude Sonnet 4.6 for this generation step because of its strong instruction-following and natural-language generation capabilities [51], [52]. The resulting persona descriptions are fixed prior to evaluation and reused across all evaluated LLMs.

2 shows an example input and output for the code-generation task. The example uses the Planner role, the LLH personality profile (Low Conscientiousness, Low Openness, and High Extraversion), and the anger emotion condition. The generated persona translates these abstract profile attributes into a role-specific behavioral description tailored to the task context. In this example, the Planner is characterized as decisive, action-oriented, and inclined toward familiar solution strategies, while the anger condition introduces a more impatient planning style.

3.2 Task 1: Code Generation↩︎

For code generation, we use three agents: Planner, Implementer, and Reviewer. This decomposition follows the design logic of prior multi-agent code-generation systems that separate planning, code writing, validation, and repair into distinct agent roles [43], [44]. 3 illustrates the code-generation workflow. The Planner first produces a natural-language solution plan for the programming problem. Using both the problem statement and the generated plan, the Implementer produces an initial implementation. The implementation is then executed against the public test cases, and the resulting feedback is provided to the Reviewer. If all public tests pass, the Reviewer is informed that the implementation passed the public test suite. Otherwise, the feedback includes the first failing test case together with its expected and actual outputs. Private tests are never exposed to the agents and are reserved exclusively for final evaluation. This setup follows the public-feedback repair protocol used in LiveCodeBench-style code-generation benchmarks [37]. Using the current implementation and public-test feedback, the Reviewer decides whether the solution should be accepted or revised, producing either an Accept or Revise decision together with review comments. When a revision is requested, the Implementer receives the previous implementation, test feedback, and review comments, and generates an updated solution.

We allow up to three revision rounds. This choice is consistent with prior multi-agent collaboration studies that limit iterative interactions to three rounds [53], [54]. The workflow terminates when the Reviewer accepts the solution or when the revision limit is reached. In the latter case, the most recent implementation is returned as the final team output.

3.3 Task 2: Code Review↩︎

For code review, each team consists of two Writers and one Supervisor. This design is inspired by Hydra-Reviewer, which employs multiple review agents to examine code changes from different review perspectives before integrating their outputs [27]. We adopt a simplified version of this workflow to maintain a controlled experimental setting while preserving its multi-perspective review structure. 4 illustrates the overall process. Each task instance consists of a code patch and its associated review context, and the team produces natural-language review comments. The two Writers are assigned complementary review dimensions. Writer 1 focuses on defects, robustness, and style, while Writer 2 focuses on maintainability, performance, and extensibility. Both Writers receive the same patch context but generate comments only for their assigned dimensions.

After the Writers produce their initial reviews, the Supervisor receives the patch context and both review outputs. The Supervisor integrates the reviews into a prioritized set of comments, removes unsupported or redundant feedback, and decides whether revisions are required. If revisions are requested, the selected Writer(s) receive the Supervisor’s feedback and revise their comments accordingly. The process continues until the Supervisor accepts the integrated review or the maximum number of revision rounds is reached. As in the code-generation task, we allow up to three revision rounds. The final team output is the Supervisor’s integrated review from the last iteration.

4 Experimental Setup↩︎

4.1 Experimental LLMs↩︎

We evaluate four instruction-tuned LLMs spanning three model families and four parameter scales: Qwen2.5-1.5B-Instruct, Llama-3.1-8B-Instruct, Mistral-Small-24B-Instruct, and Qwen2.5-32B-Instruct [55]–[57]. We use general-purpose instruction-tuned models rather than code-specialized models because our agents must follow role, personality, emotion, and collaboration instructions in addition to performing SE tasks. These model families also appear frequently in recent code-generation and code-related evaluations [58]–[61]. For brevity, we refer to them as Qwen 1.5B, Llama 8B, Mistral 24B, and Qwen 32B throughout the paper. The 1.5B and 8B models are served without weight quantization, whereas the 24B and 32B models use 4-bit Activation-aware Weight Quantization (AWQ) [62] to reduce memory consumption and improve inference efficiency. All experiments use greedy decoding with temperature set to 0, producing a single deterministic completion per task instance. Although prior persona-based studies have used non-zero temperatures to increase behavioral variation [63], our objective is to isolate the effects of profile assignments under a deterministic evaluation protocol. For code generation, this setup is also consistent with pass@1 functional-correctness evaluation [35] and recent studies that report pass@1 results using greedy decoding [64], [65].

4.2 Datasets↩︎

For each task, we evaluate all models and profile conditions on the same set of task instances. This controls for instance-level variation and ensures that observed performance differences are attributable to model and profile configurations rather than differences in the evaluated problems. For code generation, we use release v6 of the code-generation lite subset of LiveCodeBench (LCB), which contains 1,055 problems [37]. For code review, we use the patch-level review dataset released with Hydra-Reviewer, which is built on the CodeReview and CodeReview-New datasets [27], [46]. The released FinalDataset contains 18,138 review instances, each consisting of a code patch, review context, and human-written review comments.

To make the evaluation computationally tractable while maintaining statistical representativeness, we randomly sample task instances using a fixed seed and a finite-population sample-size calculation with a 95% confidence level and a 5% margin of error [66]. This results in 282 code-generation problems and 377 code-review instances.

4.3 Profile Configurations and Baseline↩︎

We evaluate two profile-assignment strategies: shared-profile and mixed-profile. Under a shared-profile assignment, all agents in a team are assigned the same personality and emotion profile. Combining nine personality profiles with six emotion conditions yields 54 shared-profile configurations. For each configuration, persona descriptions are generated separately for each role using the procedure described in 3.1 . Because persona generation is role-specific, the 54 shared-profile configurations produce 162 persona descriptions for the code-generation task and 162 for the code-review task. For each model and task, we vary only the assigned profile configuration while holding all other experimental conditions constant. Consequently, any performance differences observed can be attributed to differences in the assigned profiles.

Under mixed-profile assignment, different roles within the same team may be assigned different personality and emotion profiles. The full mixed-profile design space is prohibitively large: assigning any of the 54 profile configurations to each of the three roles would produce \((54^3 = 157{,}464)\) possible assignments. To make the analysis tractable, we first identify the top three shared-profile configurations for each model–task pair based on their performance under the shared-profile setting. We then recombine these profiles across roles to construct mixed-profile teams. Using the top-performing shared profiles restricts the search space to a small set of promising candidates while still allowing us to examine whether heterogeneous profile assignments can outperform homogeneous ones. Excluding the three uniform assignments already evaluated in the shared-profile setting, this procedure yields 24 mixed-profile configurations. Combined with the 54 shared-profile configurations, this results in 78 team-profile configurations for each model–task pair.

We define a separate self-report baseline for each model–task pair. To approximate a model’s default behavioral tendency for a given task, we prompt the model to identify the personality and emotion profile that best describes its behavior in the absence of an assigned profile, allowing a Neutral response when no clear tendency is reported. We do not treat this self-reported profile as a ground-truth characterization of the model. Rather, it serves as a reference condition representing how the model describes its own default behavior under our profile framework. If the resulting profile corresponds to one of the 54 shared-profile configurations, we reuse the existing evaluation result for that configuration. Otherwise, we generate the corresponding persona descriptions and evaluate it as an additional baseline condition. The self-report baseline is evaluated separately and is not included among the 78 team-profile configurations. We use it as a reference point for assessing the effects of explicit profile assignment.

4.4 Evaluation Metrics↩︎

4.4.1 Code generation↩︎

For code generation, we use pass@1 as the task-performance metric. A task is considered “passed” only if the final implementation passes all public and private tests during the final evaluation. Compilation errors, runtime errors, timeouts, and wrong outputs are counted as failures.

4.4.2 Code review↩︎

For code review, we evaluate the final Supervisor output against human-written review comments. Following prior automated review-comment evaluation practice [27], [46], we use smoothed BLEU-4 [67] to compare generated review suggestions with human-written reference comments. We use BLEU as a relative measure of reference alignment for comparing profile conditions, rather than as a comprehensive measure of review quality.

4.4.3 Behavioral measures↩︎

For RQ3, we analyze three behavioral signals extracted from intermediate workflow traces: revision behavior, token usage, and sentiment polarity. Revision behavior characterizes how profiles influence the tendency of teams to revise intermediate outputs before reaching a final decision. Token usage measures the computational cost of collaboration, while sentiment polarity captures the tone of interactions during the collaboration process.

For revision behavior, we report the revision rate, defined as the proportion of task instances that enter at least one revision round. In code generation, this occurs when the Reviewer requests a revision. In code review, it occurs when the Supervisor requests revisions from one or more Writers. Because revision rate alone does not distinguish productive revisions from unnecessary ones, we additionally measure over-revision for code generation. An instance is classified as over-revised if the Reviewer requests a revision even though the current implementation already passes the full evaluation test suite. This metric captures cases when revision continues even after functional correctness has already been achieved.

For token usage, we report instance-level measures across the full workflow for both tasks, including total prompt and completion tokens, the number of model calls, and average tokens per call. These measures separate token-cost differences due to more model calls from those due to longer responses.

For sentiment polarity, we analyze review-oriented messages exchanged during revision loops: Reviewer messages in code generation and messages from all three roles in the code-review task. We use SentiCR, an SE-specific sentiment analysis tool designed for code-review interactions, to label message sentiment [68]. SentiCR was evaluated on code-review comments and reported 83.03% accuracy, 67.84% precision, 58.35% recall, and 0.62 F-score for detecting negative comments. We measure negativity as the proportion of analyzed messages labeled negative by SentiCR.

4.4.4 Statistical Analysis↩︎

We use logistic mixed-effects models to analyze binary outcomes in the shared-profile experiments [69]. For code generation, we model pass@1, revision behavior, and over-revision. For code review, we model revision behavior. Because each task instance is evaluated repeatedly across profile configurations and LLMs, observations from the same instance are not independent. We therefore fit a separate model for each outcome, including a random intercept for task instance to account for instance-level variability.

Each model includes emotion, conscientiousness, openness, extraversion, and LLM model as fixed effects. We model personality traits separately rather than treating each personality profile as a categorical factor in order to estimate the marginal effect of each personality dimension. The neutral personality profile is excluded because the personality factors are modeled as high-versus-low contrasts rather than as a three-level design. For the over-revision analysis, we additionally exclude Qwen 1.5B because no over-revision events occur for that model under any shared-profile configuration. We do not include personality-trait interaction terms because our analysis focuses on the effects of individual personality dimensions, and including higher-order interactions would substantially increase model complexity while reducing the interpretability of the resulting estimates. We fit all models using lme4 [70]. Main effects are assessed using likelihood-ratio tests, and pairwise comparisons are reported as odds ratios with Benjamini–Hochberg FDR correction [71]. For pairwise emotion contrasts, we use happiness as the reference condition because it is the only positive-valence emotion in our study [72]. For personality traits, we compare high and low levels of each trait.

5 Results↩︎

We organize the results according to the research questions (RQs) introduced in 1 . Throughout this section, profile configurations are abbreviated as e-C/O/E, where e denotes emotion (a = anger, d = disgust, f = fear, h = happiness, n = neutral, and s = sadness), and C/O/E denote the levels of Conscientiousness, Openness, and Extraversion, respectively (H = high, L = low, and N = neutral). For example, f-HLH denotes a profile with fear, high conscientiousness, low openness, and high extraversion. SR denotes the self-report baseline. Complete results for all evaluated configurations will be made available on the companion website [73].

RQ1: How do different shared-profile configurations affect the performance of LLM teams?

Code generation. 5 (a) summarizes code-generation performance over the 54 shared-profile configurations for each model, and 1 reports the corresponding best, worst, and self-report baseline configurations for each model. Across models, the gap between the best and worst shared-profile configurations ranges from 7.09 to 11.35 percentage points in pass@1, corresponding to 20–32 additional solved problems out of 282. This result indicates that profile assignment can substantially affect code-generation performance.

Although all four models are sensitive to profile choice, the highest-performing profile differs across models. The best shared-profile configurations are fear-LLL and disgust-HHH for Qwen 1.5B, neutral-NNN for Llama 8B, happiness-HHH for Mistral 24B, and sadness-HHH for Qwen 32B. This suggests that profile effectiveness is model-dependent rather than universally transferable across LLMs.

2.2pt

Code review. Across models, the gap between the best and worst profile configurations ranges from 0.515 to 1.074 BLEU score, corresponding to an 8.3% to 18.9% relative improvement over the weakest configuration (5 (b)). Consistent with the code-generation results, profile assignment substantially affects task performance. However, the highest-performing profile again varies across models and tasks.

Statistical analysis. To examine which profile factors contribute to code-generation performance, we fit the mixed-effects model described in 4 , using pass@1 as the binary outcome. The model shows significant main effects of emotion (\(\chi^2{=}20.53\), \(df{=}5\), \(q{=}.004\)), conscientiousness (\(\chi^2{=}6.40\), \(df{=}1\), \(q{=}.023\)), and openness (\(\chi^2{=}4.36\), \(df{=}1\), \(q{=}.049\)), but not extraversion (\(q{=}.075\)). Pairwise comparisons indicate that the strongest effects are associated with emotion and conscientiousness. Relative to happiness, anger (OR=0.79, \(q<.001\)) and fear (OR=0.84, \(q=.009\)) significantly reduce the odds of solving a problem. High conscientiousness also slightly reduces the odds of passing compared with low conscientiousness (OR=0.92, \(q=.030\)). Although openness exhibits a significant main effect, its high-vs-low contrast does not remain significant after FDR correction. Overall, these results suggest that emotional state and conscientiousness have a measurable influence on code-generation performance, whereas extraversion contributes little explanatory power after controlling for the other profile factors. Baseline comparison. We additionally compare the 54 shared-profile configurations against the self-report baseline for each model–task pair, using the self-report baseline values reported in 1. The amount of above-baseline improvement varies substantially across models. Qwen 1.5B exhibits the largest improvement opportunity, with 38 of 54 profiles outperforming the baseline in code generation (70.4%) and 35 of 54 in code review (64.8%). At the other extreme, Qwen 32B shows little room for improvement, with only one profile exceeding the baseline in code generation and none doing so in code review. The intermediate models exhibit task-dependent behavior: Llama 8B has only 4 above-baseline profiles in code generation but 40 in code review, while Mistral 24B shows relatively few above-baseline profiles in either task. Overall, profile prompting can outperform the self-report baseline, but the magnitude of the opportunity varies considerably across models and tasks.

To assess whether effective profiles transfer across models, we rank the 54 shared-profile configurations by performance within each model and compute pairwise Spearman rank correlations between the resulting rankings. For code generation, the average pairwise correlation is close to zero (\(\bar{\rho}=0.049\)). Although Mistral 24B and Qwen 32B exhibit a moderate positive correlation (\(\rho=0.495\)), the overall pattern indicates weak agreement across model pairs. A similarly weak pattern is observed for code review (\(\bar{\rho}=0.095\)). These results suggest that profile effectiveness is largely model- and task-specific rather than driven by a universally effective personality–emotion configuration.

RQ2: How do mixed-profile and shared-profile team configurations differ in their impact on LLM team performance?

To answer this RQ, we first examine performance variation across the 24 mixed-profile configurations and then assess whether the best mixed-profile configuration outperforms the best shared-profile configuration.

2.2pt

Variation within mixed-profile assignments. 6 shows that mixed-profile assignment introduces clear performance variation, even though it only evaluates 24 recombinations of strong shared profiles. 2 reports the best and worst mixed assignments, together with the self-report baseline and the best shared-profile result for each model and task. For code generation, the best–worst gap among the 24 mixed-profile assignments ranges from 3.19 to 8.51 percentage points in pass@1 across models, corresponding to 9 to 24 additional solved problems out of 282. The largest spread occurs for Qwen 32B, where the mixed-profile gap corresponds to 24 solved problems, matching the magnitude of the best–worst gap observed among shared-profile configurations. For code review, the 24 mixed-profile configurations produce BLEU gaps from 0.411 to 1.103, comparable to the shared-profile gaps in RQ1. These results indicate that role-specific profile assignment remains an important source of performance variation even when all candidate profiles are drawn from a small set of strong shared-profile configurations.

Comparison with shared-profile assignment. We next compare mixed-profile assignments against two reference points shown in 2: the self-report baseline and the best shared-profile configuration. Relative to the self-report baseline, a majority of mixed-profile assignments improve performance in most model–task pairs. The strongest effect is observed for Qwen 1.5B: all 24 mixed-profile assignments outperform the baseline in code generation and 22 of 24 in code review. In contrast, Qwen 32B exhibits the least improvement opportunity, with only 6 of 24 mixed-profile assignments exceeding the baseline in either task. Llama 8B and Mistral 24B fall between these extremes, with the proportion of above-baseline mixed-profile assignments varying by task.

Compared with the best shared-profile result, mixed-profile assignment achieves higher best-case performance in 6 of the 8 model–task pairs. This pattern is consistent across the three larger models: Llama 8B, Mistral 24B, and Qwen 32B attain better peak performance under mixed-profile assignment in both code generation and code review. Only Qwen 1.5B best mixed-profile assignment does not surpass the best shared-profile result in either task. These results suggest that role-specific profile specialization can provide additional gains beyond assigning the same profile to all agents.

RQ3: How do personality and emotion profiles influence coordination and collaboration behaviors within LLM teams?

We report the three behavioral signals defined in 4 : revision behavior, token usage, and sentiment polarity for the shared-profile configurations.

Revision behavior. In code generation, revision behavior varies widely across models and profiles. As shown in 3, the instance-level revision rate ranges from 43.3% for Qwen 1.5B to 87.6% for Llama 8B. Clear differences also emerge across profiles: fear exhibits the highest overall revision rate among emotions (76.7%), whereas happiness exhibits the lowest (58.7%). Among personality traits, conscientiousness shows the strongest effect, with high-conscientiousness profiles revising substantially more often than low-conscientiousness profiles (74.8% vs. 58.3%).

The mixed-effects model described in 4 supports these descriptive patterns. Emotion and conscientiousness are the strongest predictors of revision requests (emotion: \(\chi^2=1569.97\), \(df=5\), \(q<.001\); conscientiousness: \(\chi^2=2273.38\), \(df=1\), \(q<.001\)). Although openness (\(\chi^2=86.73\), \(df=1\), \(q<.001\)) and extraversion (\(\chi^2=42.97\), \(df=1\), \(q<.001\)) are also statistically significant, their effects are considerably smaller. Pairwise comparisons show that fear increases the odds of revision by 3.95\(\times\) relative to happiness (\(q<.001\)), while high conscientiousness increases the odds by 2.83\(\times\) relative to low conscientiousness (\(q<.001\)). Overall, fear and high conscientiousness consistently shift teams toward a more revision-intensive workflow. Because revisions may be either beneficial or unnecessary, we next examine over-revision.

2.4pt

As shown in 3, over-revision follows the same broad pattern as revision behavior. Fear has the highest overall over-revision rate (13.0%), while happiness has the lowest (4.3%). The largest personality difference again appears for conscientiousness: high-conscientiousness profiles over-revise almost twice as often as low-conscientiousness profiles (11.3% vs. 5.9%). The mixed-effects model supports this pattern: over-revision is significantly associated with emotion and conscientiousness (emotion: \(\chi^2=1025.46\), \(df=5\), \(q<.001\); conscientiousness: \(\chi^2=712.26\), \(df=1\), \(q<.001\)), while openness and extraversion are not significant. Pairwise comparisons show that fear has the strongest effect, increasing the odds of over-revision by 6.37\(\times\) (\(q<.001\)) relative to happiness, while high conscientiousness increases the odds by 2.72\(\times\) (\(q<.001\)) relative to low conscientiousness. Together, these findings suggest that fear and high conscientiousness encourage additional scrutiny, but that scrutiny often persists even after a correct solution has been reached.

Revision is also common in code review, although the overall revision rate varies substantially across models, ranging from 59.1% for Qwen 32B to 98.3% for Llama 8B. Among emotions, disgust has the highest overall revision rate (88.8%), while happiness has the lowest (72.2%). Conscientiousness again produces the clearest personality effect, with high-conscientiousness profiles revising more frequently than low-conscientiousness profiles (83.8% vs. 76.7%). The mixed-effects model supports these observations: revision behavior is significantly associated with emotion (\(\chi^2=2370.90\), \(df=5\), \(q<.001\)), conscientiousness (\(\chi^2=765.14\), \(df=1\), \(q<.001\)), openness (\(\chi^2=268.21\), \(df=1\), \(q<.001\)), and extraversion (\(\chi^2=22.76\), \(df=1\), \(q<.001\)). Pairwise comparisons show that disgust (OR=4.46, \(q<.001\)) and fear (OR=3.78, \(q<.001\)) have much higher revision odds than happiness, and high-conscientiousness profiles have 1.83\(\times\) the revision odds of low-conscientiousness profiles (\(q<.001\)). These results indicate that the same profile factors that drive revision behavior in code generation also promote more revision-intensive collaboration in code review. Due to space constraints, the complete results table is provided on the companion website [73].

Token usage. Token usage largely mirrors the revision-behavior results. In code generation, fear consumes the most tokens on average across models (15.4K tokens per instance), while happiness consumes the fewest (12.9K). Conscientiousness again exhibits the largest personality effect, with high-conscientiousness profiles using substantially more tokens than low-conscientiousness profiles (16.1K vs. 12.3K tokens per instance). This increase is driven by both more frequent interactions and longer responses. Fear averages 6.48 model calls per instance and 2.38K tokens per call, compared with 5.66 calls and 2.29K tokens per call for happiness. Similarly, high-conscientiousness profiles average 6.42 calls and 2.50K tokens per call, compared with 5.63 calls and 2.18K tokens per call for low-conscientiousness profiles.

A similar pattern appears in code review. Disgust and fear consume the most tokens on average (23.3K and 23.1K tokens per instance, respectively), while happiness consumes the fewest (20.0K), corresponding to roughly 16% and 15% higher token usage. Conscientiousness again shows the clearest personality effect, with high-conscientiousness profiles using 22.6K tokens per instance compared with 21.0K for low-conscientiousness profiles. Unlike code generation, however, these differences are driven primarily by additional model calls rather than longer responses. Disgust and fear average 9.25 and 9.07 calls per instance, respectively, compared with 7.86 for happiness, while tokens per call remain nearly constant. A similar pattern holds for conscientiousness. This difference is likely due to the review prompts, which constrain the number and length of generated review comments. Overall, caution-oriented profiles, particularly fear and high conscientiousness, consistently increase the computational cost of collaboration.

Sentiment analysis. We also examine whether negative sentiment separates the best and worst shared-profile configurations for each model–task pair following the sentiment metric defined in 4 . Across both tasks, sentiment provides only weak separation. In code generation, Reviewer negativity differs only slightly between the best and worst configurations, and the direction is not consistent across models. The largest absolute best–worst gap is 0.017. In code review, sentiment differences are similarly small, with the largest absolute best–worst gap across roles being 0.059. These results suggest that negativity is not a robust explanation for performance differences in either task.

6 Discussion↩︎

Our findings show that agent profiles based on personality and emotion are more than decorative prompt text. In our experiments, the task, workflow, role instructions, decoding settings, and persona-generation procedure are fixed, while only the assigned profile varies. The resulting differences in performance, revision behavior, and token usage therefore arise from the assigned profile condition. We do not interpret these results as evidence that LLMs possess real personalities or emotions. Rather, personality and emotion profiles act as prompt-level behavioral controls that influence how agents participate in a multi-agent workflow. This finding suggests that agent profiles should be treated as an experimental factor. Practitioners should therefore evaluate profile choices in the target model–task setting rather than adopting profiles from prior work. Since profile choices can affect both performance and collaboration behavior, future studies should report profile configurations and explore profile optimization.

Our behavioral analyses also reveal a cost–performance tradeoff. Fear and high conscientiousness consistently increase revision activity, over-revision, and token consumption. However, this additional effort does not consistently translate into better performance. These results suggest that more collaboration is not necessarily more effective, highlighting the need for mechanisms that distinguish productive revisions from unnecessary ones. Practitioners should therefore consider computational cost alongside solution quality when selecting profile configurations.

Finally, the mixed-profile results suggest that different roles may benefit from different behavioral tendencies. The best mixed-profile configuration outperforms the best shared-profile configuration in six of eight model–task settings, indicating that assigning the same profile to all agents is often suboptimal. For tool builders, this creates an opportunity to support automated profile search, and adaptive profile assignment mechanisms that balance performance and cost while tailoring profiles to specific agent roles.

7 Threats to validity↩︎

External validity. Our study covers two SE tasks, two three-agent workflows, 78 profile configurations, and four instruction-tuned LLMs, but these settings are still only part of the broader design space. Other models, workflows, role structures, or profile assignments may lead to different results. Our mixed-profile evaluation explores recombinations of high-performing shared profiles rather than the complete assignment space; other combinations may exhibit different behavior.

Internal validity. LLM behavior can be sensitive to prompt wording, role definitions, and workflow design. To reduce this threat, we keep the tasks, workflows, role instructions, prompt templates, and persona descriptions fixed across configurations. We also set the temperature to zero to reduce sampling-related variation and improve reproducibility. For code generation, execution results may depend on the runtime environment. We therefore run all evaluations under the same test and execution environment.

8 Conclusion↩︎

This study examined personality and emotion profiles as a design dimension in LLM teams for SE. For both tasks, profile assignments influenced task performance and team behavior. The gap between the best and worst shared-profile configurations reached 11.35 percentage points in code generation and 18.9% relative improvement in code review, while mixed-profile teams outperformed the best shared-profile configuration in six of eight model–task settings by 0.3%–3.0%. In contrast, profiles such as fear and high conscientiousness increased revision activity, over-revision, and token consumption without consistent performance gains. These findings position agent profiles as an important design consideration in multi-agent SE systems, suggesting that effective systems depend not only on model selection and workflow design but also on how agents are prompted to carry out their assigned roles.

References↩︎