#  Is AI the better programming partner?
Human-Human Pair Programming vs. Human-AI pAIr Programming

Qianou Ma  Carnegie Mellon UniversityPittsburghUSA<EMAIL_ADDRESS>,
Tongshuang Wu  Carnegie Mellon UniversityPittsburghUSA<EMAIL_ADDRESS>and
Kenneth Koedinger  Carnegie Mellon UniversityPittsburghUSA<EMAIL_ADDRESS>
###### Abstract.

The emergence of large-language models (LLMs) that excel at code generation
and commercial products such as GitHub’s Copilot has sparked interest in
human-AI pair programming (referred to as “pAIr programming”) where an AI
system collaborates with a human programmer. While traditional pair
programming between humans has been extensively studied, it remains uncertain
whether its findings can be applied to human-AI pair programming. We compare
human-human and human-AI pair programming, exploring their similarities and
differences in interaction, measures, benefits, and challenges. We find that
the effectiveness of both approaches is mixed in the literature (though the
measures used for pAIr programming are not as comprehensive). We summarize
moderating factors on the success of human-human pair programming, which
provides opportunities for pAIr programming research. For example, mismatched
expertise makes pair programming less productive, therefore well-designed AI
programming assistants may adapt to differences in expertise levels.

Pair Programming, LLM, Human-AI Interaction, Copilot, AI-Assisted Programming

##  1\. Introduction

Pair programming was first introduced in the 1990s as part of the Agile
software development practice (Beck, 1999). In its original definition, pair
programming describes the practice of two programmers working together on the
same task using a single computer, keyboard, and mouse. One programmer in the
pair, the “driver,” performs the coding (typing) and implements the task,
while the other programmer, the “navigator,” aids in planning, reviewing,
debugging, and suggesting improvements and alternatives. Over time, pair
programming has evolved and adapted to different contexts and purposes. Now,
it is used in a wide range of settings, including education, industry, and
open-source software development (Alves De Lima Salge and Berente, 2016;
Umapathy and Ritzhaupt, 2017).

Recent advances in code-generating large-language models (LLMs) have led to
the widespread popularity of commercial AI-powered programming assistance
tools such as GitHub Copilot (GitHub, 2021), which advertises itself as “your
AI pair programmer.” For pAIr programming, instead of two humans working on a
single computer, it is the programmer and the LLM-based AI that work together
on the same task. The shift in the paradigm raises the questions: _Is the AI
programming partner comparable to a human pair programmer? Are they applicable
to the same contexts, can they achieve similar or better performance, and
should people interact with them in the same way?_

In this work, we delve into the current state of research on human-human and
human-AI pair programming to uncover their similarities and differences, and
we hope to inspire better evaluations and designs of code-generating LLMs as a
pAIr programmer. We start by reviewing the application context, methods, and
tasks for both human-human and human-AI pair programming literature (Section
2), then dive into fine-grained comparisons of their measurements of success
(Section 3), as well as the contributing moderators, e.g., pair compatibility
factors like expertise (Section 4).

We find that (1) prior work on both pair programming paradigms has observed
mixed results in _quality_ , _productivity_ , _satisfaction_ , _learning_ ,
and _cost_ , (2) pAIr programming has yet to develop comprehensive
measurements, and (3) key factors to pAIr’s success have been largely
unexplored.

Building on our exploration, we then discuss views and challenges of
characterizing AI as a pair programmer, and elaborate on future opportunities
for developing best practices and guidelines for human-AI pair programming
(Section 5). First, we argue that moderating factors that bring challenges to
human-human pair programming (e.g., compatibility and communication) unveil
opportunities to improve human-AI pair programming. It can be promising to
exploit the differences between a human and an AI partner (e.g., more
customizable expertise level and more adaptable communication styles) to
design for more successful human-AI pair programming experiences. Second, we
encourage future research to explore the best deployment environment for
human-AI pair programming. While most human-AI pair programming works have
focused on assisting professional developers, we hope to inspire more future
works in the learning context (or, student-AI pair programming), and we
highlight potential challenges involved.

##  2\. Contexts, Methods, and Tasks

Human-human pair programming originated as a practice in the software
engineering industry (Beck, 1999) and then become a popular collaborative
learning practice in classrooms (Umapathy and Ritzhaupt, 2017). Therefore, in
this paper, we compare human-human and human-AI pair programming in both the
industry and education contexts, as they are the most common contexts.

We adhere to the original definition of human-human pair programming to
closely resemble human-AI interaction on a single device. Other modes of
interaction exist for comparing human and human-AI teams in programming tasks,
such as computer-mediated collaborative learning (Sankaranarayanan et al.,
2020) and distributed pair programming (da Silva Estácio and Prikladnicki,
2015), but they are beyond the scope of this paper.

For human-AI pair programming, most current works have been evaluating Copilot
using case studies (e.g., (Bird et al., 2023)) or experimental studies (e.g.,
(Vaithilingam et al., 2022)) with experienced programmers in the industry.
Similar to human-human pair programming, researchers tried to mimic a
realistic professional development environment in their task setup. For
example, Barke et al. (2022) invited 20 participants, mostly doctoral students
and software engineers, to complete tasks such as developing Chat Client and
Server. However, there is a lack of non-invasive field observation studies
like what human-human pair programming studies have done (Sillitti et al.,
2012; Plonka et al., 2011).

Few recent works have explored using LLM-based programming environments or
Copilot with students. For example, Kazemitabaar et al. (2023) used a
controlled experimental study with 69 novice students from 10 to 17 years old
working on 45 Python code-authoring and code-modifying tasks. However,
existing works on human-AI pair programming are mostly in lab experiments, and
there is still a lack of large-scale study (McDowell et al., 2002) and
classroom deployment (Nagappan et al., 2003; Williams et al., 2002) as in the
human-human pair programming literature.

When setting up comparison groups, existing pAIr programming works have been
comparing the human-AI pair against human-human (Imai, 2022) or human solo
(e.g., compare developers’ work when they use Copilot or the default code
completion tool) (Vaithilingam et al., 2022). No current study sets up a
three-way comparison for human-AI, human-human, and human-solo.

#### Summary:

In comparison to human-human pair programming works, existing pAIr studies
lack realistic deployment in the workspace or classroom, and a larger sample
size would also be desirable. Researchers of both pair programming paradigms
use various study designs to examine what affects the effectiveness of pair
programming. In Section 3 and Section 4, we compare the variables and
measurements they used to further uncover what is lacking in pAIr studies.

Table 1. Comparison of Outcome Variables and Moderators for Human-Human Pair
Programming vs. Human-AI pAIr Programming

Outcomes |  Human-Human vs. Human Solo |  Human-AI (Copilot)
---|---|---
Quality |  2 significantly lower defect density for complex code 0 no difference for simpler code (Sison, 2009) 2 significantly higher percentage of test cases passed (Williams and Upchurch, 2001) |  -2 vs. Human-Human: more lines of code deleted in next session (lower quality) (Imai, 2022) 2 vs. Human Solo: significantly improve correctness score and reduce encountered errors for novice students (Kazemitabaar et al., 2023) 0 vs. Human Solo: no significant difference in task success (Peng et al., 2023) or task success rate in given time (Vaithilingam et al., 2022)
Productivity |  -2 significantly fewer lines of code per person hour writing simpler code, 0 no significant difference writing more complex code (Sison, 2009) 2 29% shorter time to complete task (pair speed advantage = 1.4) (Padmanabhuni et al., 2012) |  2 vs. Human-Human: more lines of added code (Imai, 2022) 2 vs. Human Solo: 55.8% reduction in completion time (Peng et al., 2023) 2 vs. Human Solo: significantly increase task completion and reduce task completion time for novice students (Kazemitabaar et al., 2023) 0 vs. Human Solo: no significant difference in the task completion rate in given time (Vaithilingam et al., 2022)
Satisfaction |  2 higher self-ratings of satisfaction (Salleh et al., 2011) -1 students with greater self-confidence and self-efficacy less enjoy the pair programming experience (Thomas et al., 2003) |  2 vs. Human Solo: higher self-ratings of satisfaction (Vaithilingam et al., 2022; Bird et al., 2023; Kalliamvakou, 2022)
Learning |  2 higher grades, exam scores (Nagappan et al., 2003), and retention (McDowell et al., 2006) 2 significantly higher gains in exam performance in female students than male students (Maguire et al., 2014) |  0 vs. Human Solo: no significant difference in immediate and retention post-test performance of novices, students with more prior experiences have more learning gains from AI code generator (Kazemitabaar et al., 2023)
Cost |  -2 increased management workload to match, schedule a pair, resolve collaboration conflict, assess individual contributions, etc. (Ally et al., 2005) 2 reduced teaching staff workload (grading one assignment from a pair) (Williams and Upchurch, 2001) |  No experiment yet. Vaithilingam et al. (2022); Bird et al. (2023) hypothesized that human-AI may lead to more unnecessary debugging vs. Human Solo

Moderators |  Human-Human vs. Human Solo |  Human-AI (Copilot)
---|---|---
Task Types & Complexity |  Complex task improve quality, simple one does not (Sison, 2009); debugging is perceived as less enjoyable or effective than comprehension or refactoring (Chaparro et al., 2005) |  -
Compatibility (E.g., Expertise) |  Random pairing led to incompatible partners and conflicts during work (Nagappan et al., 2003). Expertise: improve quality more effectively if pair is similarly skilled (Salleh et al., 2011); less-skilled students learn more and enjoy more (Maguire et al., 2014; Chaparro et al., 2005); if knowledge gap is large, less-skilled programmers may tend to be more passive and disengaged (Chong and Hurlbutt, 2007) |  -
Communication |  Conversations with intermediate-level details contribute to pair programming success (Freudenberg et al., 2007); different types of discourse lead to more attempts or more debug success (Murphy et al., 2010) |  -
Collaboration |  Over-reliance leads to conflicts and impedes satisfaction and learning, as work is entirely burdened on one partner (Williams et al., 2002; Nagappan et al., 2003); educators recommend regular role-switching to ensure equitable learning in collaboration (Umapathy and Ritzhaupt, 2017) |  -
Logistics |  Scheduling difficulties (Begel and Nagappan, 2008), teaching & evaluating individual responsibility and accountability are important to collaboration success (Preston, 2006), but can lead to increased management costs (Ally et al., 2005; Sun and Marakas, 2009) |  -

##  3\. Mixed Outcomes

Literature reviews of human-human pair programming have suggested various
benefits as well as mixed effects. In the industry context, according to Alves
De Lima Salge and Berente (2016), pair programming improves code quality,
increases productivity, and enhances learning outcomes. However, according to
Hannay et al. (2009), pair programming improves quality and shortens duration,
but it increases effort, higher quality comes at the expense of considerably
greater effort, and reduced completion time comes with lower quality. In the
education context, pair programming brings benefits including higher quality
software, student confidence in solutions, increased assignment grades, exam
scores, success/passing rates in introductory courses, and retention (Umapathy
and Ritzhaupt, 2017; Hanks et al., 2011; McDowell et al., 2006). All the
reviews on human-human pair programming acknowledged that even though meta-
analysis can show an overall trend and significant effect size, individual
studies could report contradictory outcomes (see examples in Table 1).

For human-AI pair programming, existing works mainly focus on quality,
productivity, and satisfaction, and already demonstrated mixed results in
quality and productivity (Imai, 2022; Barke et al., 2022; Vaithilingam et al.,
2022) (see examples in Table 1). Additionally, there is not enough research
for a comprehensive review, so we cannot reach any conclusion on the
effectiveness of human-AI pair programming yet. It is also hard to compare the
human-human and human-AI pair programming literature, as they differ in what
outcomes and measurements they adopt.

Therefore, in the top rows of Table 1, we listed the most common outcome
variables in both literature (_quality_ , _productivity_ , _satisfaction_ ,
_learning_ , and _cost_) and some sample work to demonstrate the mixed
outcomes and various measures. We elaborate on the variety of ways to measure
some of the listed outcomes as follows.

###  3.1. Quality

In human-human pair programming literature, quality can be measured using
defect density, perceptual effort measure, readability, functionability, the
number of test cases passed, code complexity, scores, expert opinions, etc.
(Sun and Marakas, 2009; Salleh et al., 2011; Alves De Lima Salge and Berente,
2016).

###  3.2. Productivity

In human-human pair programming literature, duration, effort, and productivity
are all types of “efficiency” outcomes that involve time and accomplishment.
Productivity can be measured in terms of the number of completed tasks in a
fixed unit of time, duration can be measured as the amount of elapsed or total
time used to complete a fixed number of tasks to a certain standard, and
effort can be measured as twice the duration, the person-hours required, etc.
(Alves De Lima Salge and Berente, 2016). We use productivity as an aggregated
outcome variable of different measures, for consistency with the human-AI
literature.

In current human-AI works, some measures are arguably too simplified as
evaluation metrics, for example, Imai (2022) used the number of lines of added
code as the measure of productivity; however, the nature of interaction with
Copilot (tab to accept suggestions) is likely to contribute to more added
lines in the human-Copilot condition, and how valid would it represent the
notion of productivity is questionable.

Note that some researchers have examined programmers’ perceived productivity
when working Copilot and found that it most strongly correlated with the
general acceptance rate of AI-generated code (Ziegler et al., 2022). This is
not included in Table 1 to stay consistent with the human-human pair
programming literature, as perceived productivity is a different measure than
actual productivity.

###  3.3. Learning

In human-human pair programming literature, learning can be assessed by
quantitative measures such as assignment grades, exam scores, passing rate,
and retention rate, or qualitative measures of higher-order thinking skills
(McDowell et al., 2006; Umapathy and Ritzhaupt, 2017; Hanks et al., 2011).

###  3.4. Cost

In terms of cost, there is the observation that participants faced challenges
in understanding and debugging Copilot’s generated code, which leads to the
hypothesis that human-AI pair programming could cost additional efforts and
hinder programmers’ task-solving effectiveness (Vaithilingam et al., 2022;
Bird et al., 2023). However, Dakhel et al. (2022) shows that although
Copilot’s code could be less correct than human code, its bugs are easier to
debug than human errors. There is currently no work that experimentally
characterizes the costs of human-AI pair programming.

#### Summary:

The literature on human-human pair programming has shown mixed results in many
outcome variables, including _quality_ , _productivity_ , _satisfaction_ ,
_learning_ , and _cost_. For human-AI pair programming, or mostly human-
Copilot in this paper, there are still only few works with incomprehensive
measures, but a mixed outcome is also observed. We further review the
potential causes of mixed outcomes of both modes of pair programming in
Section 4.

##  4\. Moderators

In search of the explanations of the cost-benefit of human-human pair
programming experiences, researchers have found moderators such as _task type
& complexity_ (Hannay et al., 2009), _compatibility_ factors like expertise
(Preston, 2006; Arisholm et al., 2007), _communication_ (Plonka et al., 2011;
Freudenberg et al., 2007; Chong and Hurlbutt, 2007), _collaboration_ factors
like over-reliance and role-switching (Williams et al., 2002; Hannay et al.,
2010; Salleh et al., 2011), and _logistics_ difficulties including scheduling
and training (Begel and Nagappan, 2008; Hannay et al., 2009) (as shown in the
bottom rows of Table 1).

These key factors influence the success of human-human pair programming. If
they work well, pair programming helps programmers catch errors more easily,
solve problems more quickly, review code more thoroughly, and produce overall
higher-quality code; it also promotes knowledge sharing among team members,
which can lead to a more cohesive and effective team. If not, challenges such
as scheduling and finding suitable pairs with compatible working styles
usually result in a low cost-efficiency in pair programming, and slow down the
development process if there are conflicts or disagreements between pair
partners (Begel and Nagappan, 2008; Cockburn and Williams, 2001).

For human-AI pair programming’s moderators, much was unexplored – we do not
know what could make human-AI pair programming more or less effective.
Therefore, in this section, we discuss the key moderators that are examined in
the human-human pair programming literature, and individual examples of
moderating effects are provided in Table 1.

###  4.1. Task Types & Complexity

For task type and task complexity, Chaparro et al. (2005) found that debugging
tasks lead to less satisfaction and perceived efficacy compared to
comprehension and refactoring tasks. Hannay et al. (2009) found that the
duration is shorter for low complexity tasks, at the expense of lower quality
results, and quality is higher when complexity is higher, but it requires
considerably greater effort. Arisholm et al. (2007) found that the moderating
effect of complexity also depends on the expertise of the pair, where
“benefits of correctness on complex system apply mainly to juniors, whereas
the reductions in duration to perform the tasks correctly on the simple system
apply mainly to intermediates and seniors.”

###  4.2. Compatibility

Salleh et al. (2011) listed multiple factors for pair compatibility, such as
personality, perceived skills, actual skills (expertise), self-esteem, gender,
and work ethic. Thomas et al. (2003) found that paired students with similar
self-confidence levels produce their best work. Hannay et al. (2010) found
that Big Five personality traits only have modest predictive value on pair
programming performance, and expertise, task complexity, and country have
stronger prediction power in comparison. There also seems to be evidence that
women benefit from pair programming more than men do (Preston, 2006; Hanks et
al., 2011).

Expertise as a compatibility factor has been extensively studied in the human-
human pair programming literature. For example, researchers found that a
student pair performs the best when their expertise is similar (Salleh et al.,
2011) and students preferred to be paired with similarly skilled partners
(Chaparro et al., 2005). However, in industry, Jensen (2005) reported that
when both members were near the same capability level and strongly
opinionated, the collaboration was counter-productive and troublesome.

In the introductory programming context, Lui and Chan (2006) found that
pairing up novices results in a larger improvement in productivity than
pairing up experts. However, there are concerns about the risk of “the blind
leading the blind” if they don’t have an expert to consult with (Ally et al.,
2005). Researchers also found that less-skilled students learn and enjoy more
than more-skilled students in pair programming (Chaparro et al., 2005; Maguire
et al., 2014). However, when the knowledge gap is too large, students can be
less satisfied and the benefits of quality may be smaller (Padmanabhuni et
al., 2012). Chong and Hurlbutt (2007) reported that a novice programmer
collaborating with an expert may become disengaged, have lower self-esteem,
and be afraid of slowing down or annoying their more-skilled partner (Ally et
al., 2005).

###  4.3. Communication

According to Freudenberg et al. (2007), “the key to the success of pair
programming [is] the proliferation of talk at an intermediate level of detail
in pair programmers’ conversations.” Researchers also found that pair
programming eliminates distracting activity and enables programmers to focus
on productive activity (Sillitti et al., 2012), which could be why engaging
communications contribute to the success of pair programming. Murphy et al.
(2010) used transactive analysis to break down communication by different
types of transactions, and they found that attempting more problems associated
with more completion transactions and debugging success correlated with more
critique transactions. Some other works pointed out the social support aspect
of communication (Chong and Hurlbutt, 2007) and an explanation effect where
the verbalization of the thought process makes it clearer (Bird et al., 2023).

In human-human pair programming, programmers spend about $1/3$ of the time
primarily focusing on communication (Plonka et al., 2011), which forces them
to concentrate, rationalize, and explain their thoughts (Sillitti et al.,
2012; Hannay et al., 2009). In human-AI pair programming, Mozannar et al.
(2022) has shown that an analogous $1/3$ amount of time is spent communicating
with Copilot, such as thinking and verifying (22.4%) Copilot’s suggestion,
which may be replicating the self-explanation effects in some ways, and prompt
crafting, which takes 11.56% of the time. These activities are arguably
efforts to understand and communicate with Copilot. However, there is no other
human to co-verify the answers, and there is no study that evaluate the
communicative nature of human-Copilot interaction as human-human pair
programming.

###  4.4. Collaboration

How well partners collaborate have been important factors that affect pair
programming effectiveness (Ally et al., 2005; Sun and Marakas, 2009), and
cooperative behavior and positive interdependence are key to pair programming
success (Preston, 2006).

Collaboration can fail in various ways in a human-human pair. For example, the
free-rider problem, where the entire workload is on one partner while the
other remains a marginal player, can result in less satisfaction and learning
(Williams et al., 2002; Nagappan et al., 2003). In human-AI pair programming,
educators are worried that easily available code-generation tools may lead to
cheating, and over-reliance on AI may hinder students learning (Becker et al.,
2023). However, no study has formally evaluated it.

For human-human pair programming, there is a suggested collaboration pattern
of role-switching – two software developers periodically and regularly switch
between writing code (driver) and suggesting code (navigator), aiming to
ensure that both are engaged in the task and alleviate the physical and
cognitive load borne by the driver (Alves De Lima Salge and Berente, 2016;
Plonka et al., 2011).

Some researchers Freudenberg et al. (2007) argue that the success of pair
programming should be attributed to communication rather than “the differences
in behavior or focus between the driver and navigator,” as they found both
driver and navigator worked on similar levels of abstraction. Nevertheless,
instructors still recommend drivers and navigators to regularly alternate
roles to ensure equitable learning experiences (Umapathy and Ritzhaupt, 2017).

In human-AI interaction, given Copilot’s amazing capability to write code in
different languages, some have argued that Copilot can take on the role of the
“driver” in pair programming, allowing a solo programmer to take on the role
of the “navigator” and focus on understanding the code at a higher level
(Imai, 2022). However, while it is possible for humans to offload some API
lookup and syntax details to Copilot, humans still need to jump back into the
driver’s seat frequently and fluidly switch between the thinking and writing
activities (Mozannar et al., 2022). It is ultimately the human programmer’s
sole responsibility to understand code at the statement level (Sarkar et al.,
2022).

###  4.5. Logistics

Logistical challenges, including scheduling difficulties, teaching and
evaluating collaboration for the pair, and figuring out individual
accountability and responsibility (Begel and Nagappan, 2008; Preston, 2006),
can add to the management cost of human-human pair programming (Ally et al.,
2005; Sun and Marakas, 2009).

In human-AI pair programming, some may argue that the human is solely
responsible in the human-AI pair (Sarkar et al., 2022), but the accountability
of these LLM-based generative AI is still under debate (Becker et al., 2023).
There may be new logistics issues for the human-AI pair, such as teaching
humans how to best collaborate with Copilot. There could also be unique
challenges as in every human-AI interaction scenario, such as bias, trust, and
technical limitations – much to be explored. More study would be needed to
empirically and experimentally verify the moderating effects of different
variables in human-AI pair programming.

#### Summary:

Human-human pair programming literature have found moderators including _task
type & complexity_, _compatibility_ , _communication_ , _collaboration_ , and
_logistics_. However, there is a lack of in-depth examination of potential
moderating effects in current pAIr works.

##  5\. Discussion and Future Work

###  5.1. LLM, Your pAIr Programmer?

Before the occurrence of LLM-based tools that claim to be “your AI pair
programmer (GitHub, 2021),” people have already been developing AI-powered
systems to assist programmers, such as code completion tools (e.g., Tabnine),
code refactoring and formal verification systems, and code synthesis and
debugging tools. The evaluation focus has mostly been on usability design,
cost-efficiency, and productivity (Myers et al., 2016; Mozannar et al., 2022),
but not on the feasibility of using these AI-assisted programming tools as the
pair programming partner.

With recent advancements in generative LLM technologies, commercial AI tools
like Copilot which are capable of offering real-time code suggestions and
feedback beyond auto-completion seem to have a closer resemblance to a pair
programming partner (Bird et al., 2023). Many studies have evaluated and
critiqued Copilot’s ability to generate correct, efficient (Dakhel et al.,
2022; Nguyen and Nadi, 2022), secure (Pearce et al., 2021; Asare et al.,
2022), readable (Al Madi, 2023), and verifiable (Wong et al., 2022) code.
Without doubt, Copilot generates defects and errors in its suggested code, but
humans are far from error-free either. A programmer cannot be and does not
need to be perfect to bring benefit into the pair programming experiences, but
would Copilot be qualified as a programming partner?

In answering this question, researchers start to look into the interaction
dynamics between programmers and the claimed AI pair programmer. Some
researchers argue against the characterization of AI-assisted programming as
pair programming. They believe that the analogy to human-AI pair programming
is rather superficial, as what makes human-human pair programming effective
(e.g., productive communication) disappear in human-AI pair programming.
According to Sarkar et al. (2022), “LLM-assisted programming ought to be
viewed as a new way of programming with its own distinct properties and
challenges.”

We used the phrase “human-AI pAIr programming” in this paper, simply because
we adopt the definition of pair programming that a pair work on the same
device and the same task, so we can conveniently compare human and AI as a
pair programming partner. As reviewed in Section 3 and Section 4, Copilot and
a human partner share a lot of similar outcomes in pair programming, but the
moderators for human-AI pair programming are less examined. We believe that
this comparison is meaningful in that it helps us derive insights to keep
improving LLM-based programming tools.

Note that in this paper, we mostly covered studies using the VSCode Extension
Copilot. Tools like ChatGPT may support the communication aspect better than
Copilot (Thorp, 2023), and there are also Bard developed by Google ([n. d.])
and an experimental version of Copilot Labs by Github ([n. d.]), which support
more functionalities such as fix bug, clean, and customizable prompts. Those
tools may already improve the human-AI pair programming interaction in some
ways, so future studies could also compare across a variety of LLM-based
programming tools.

There is another challenge to describing AI as a pair programmer, following
the debate on anthropomorphizing user interfaces (Shneiderman and Maes, 1997)
and ongoing discussion as AI demonstrates increasing capabilities to replicate
human behaviors (Tan, 2023; Li and Suh, 2021). The concern is that
anthropomorphized AI could mislead designers and deceive users, impede user
agency and responsibility, have deeper ethical and social risks, and may not
be more effective anyways.

However, in educational literature, researchers have been trying to make
agents provide naturalistic and human-like interactions with students, using
teachable agents (Ogan et al., 2012; Bodenheimer et al., 2009), pedagogical
agents (Mayer and DaPra, 2012; Lin et al., 2013; Lusk and Atkinson, 2007),
conversational agent (Sankaranarayanan et al., 2020; Robe and Kuttal, 2022),
etc. Kuttal et al. (2021) explored the trade-off of using a human vs. AI agent
as the pair programming partner. They found that human-human and human-AI led
to similar productivity, code quality, and self-efficacy results, and students
“trusted and showed humility towards agents.” They also found that AI agents
successfully facilitated knowledge transfer while failing at providing logical
explanations or discussions.

Those anthropomorphized agents mostly seem to be effective in improving
learning and motivation (Heidig and Clarebout, 2011; Schroeder et al., 2013).
Some explained the effects using social agency theory (Mayer and DaPra, 2012),
cognitive load theory (Lin et al., 2013), and social cues related multimedia
learning principles (Mayer, 2014). How well can we apply these theories to
LLM-supported AI agents, and what’s different in industry versus educational
context would be interesting to explore. More works are welcomed to create a
shared vocabulary for this field.

Table 2. Challenges in Human-Human Pair Programming _Yield_ Opportunities for Human-AI pAIr Programming Moderating Factors |  Human-Human Challenges |  Human-AI Opportunities
---|---|---
Task Types & Complexity: pair work better if the task is not too simple and good for collaboration (Sison, 2009; Chaparro et al., 2005) |  Hard to design suitable tasks of appropriate complexity level |  AI may be used to generate collaboration tasks and adjust tasks complexity
Compatibility: pairs with similar skill levels and compatible working styles work better (Salleh et al., 2011; Chaparro et al., 2005) |  Hard to find a similarly skilled or compatible partner |  AI partner should adjust to human skill level and adapt to be compatible with different people
Communication: pairs work better with productive conversations (Freudenberg et al., 2007), and critiques lead to more debugging success (Murphy et al., 2010) |  Hard to teach effective communication and constructive criticism |  AI partner should support productive conversations and provide critiques
Collaboration: pairs work better with positive interdependence (Preston, 2006) and clear and balanced responsibilities (Nagappan et al., 2003) |  Hard to teach collaboration and prevent free riders |  AI should support positive social interactions and collaboration and avoid over-assist that eliminates human’s need to engage
Logistics: pair programming is costly to implement because of management challenges (Ally et al., 2005; Sun and Marakas, 2009) |  Hard to schedule and assess individual contributions in a pair |  Scheduling is no longer a problem, but humans should be accountable and responsible when using AI-generated code

###  5.2. LLM, A Better pAIr Programmer?

As reviewed in Section 3, previous literature has explored a variety of
measures to evaluate different aspects of human-human pair programming, while
the current exploration in human-AI pair programming is quite limited. Murillo
and D’Angelo (2023) have proposed evaluation metrics for LLM-based creative
code writing assistants in software engineering. More works could use more
valid measures in the human-human pair programming literature to explore how
to best help humans and LLM-based AI programming assistant collaborate
together. It would also be interesting to have a study setup with three
conditions – human-human, human-AI, and human solo – working on the same task.

Previous literature suggested some key factors in the success of human-human
pair programming, as summarized in Table 1. These moderators that cause
challenges for human-human pair programming may yield opportunities to explore
in human-AI pair programming (Table 2). For example, self-efficacy can lead to
a difference in satisfaction (Thomas et al., 2003) and gender can lead to a
difference in learning (Maguire et al., 2014), do these compatibility
moderators influence pAIr too? Can we improve pAIr outcomes using insights
derived from human-human literature (e.g., simulate an AI partner with similar
self-efficacy levels and the same gender)? Therefore, in general, we can ask
the following questions for future works: _Could these factors be implemented
for human-AI pair programming? Would they make human-AI pair programming more
effective, less effective, or have no influence, and why?_

#### Task Types & Complexity

As we know from the human-human pair programming literature, a good
collaborative task of the right complexity is important, but creating or
choosing such tasks can be difficult. Meanwhile, LLMs help educators
efficiently generate instructional materials such as questions (Wang et al.,
2022), question-answers (Kumar et al., 2022), feedback (Dai et al., 2023), and
hints (Pardos and Bhandari, 2023), which could be of similar quality as human-
authored content. There is also work that suggested the preliminary success in
using LLM to break down problems into sub-questions (Sonkar et al., 2023).
Therefore, based on the insight from human-human pair programming literature
and the known capacities of LLM, there is an open question to explore in
human-AI pAIr programming: can LLM be configured to generate a task type with
collaborative learning goals and customize task complexity for a programmer?

#### Compatibility - Expertise

In terms of the compatibility factor expertise, the pair programming
literature suggests that matching partners with a similar level of expertise
may be the best in promoting productivity and learning (Alves De Lima Salge
and Berente, 2016; Hannay et al., 2009; Chaparro et al., 2005). Evaluation
studies show that GPT3-based models can be an above-average student in a CS1
classroom (Puryear and Sprint, 2022; Finnie-Ansley et al., 2022) and its
performance gets worse when the code becomes more complicated (Yetiştiren et
al., 2022). GPT4 even does better at solving introductory and basic
programming problems (although its correctness is still not comparable to a
developer in practice) (Bubeck et al., 2023). We can also purposefully
generate bugs and let the models make mistakes (Kang et al., 2022), so
potentially, we may create an AI partner with a similar skill level to novice
students. Future works can examine how to configure AI to adapt to student’s
skill levels and whether it will be effective or not.

#### Other Compatibility Factors

Researchers have explored how to let LLMs generate interaction based on a
designed persona and reasonably replicate human behavior (Aher et al., 2022;
Horton, 2023), and in education, Cao (2023) let LLMs interact with students
while role-playing as different fictional characters to help reduce students’
anxiety and increase motivation. There are possibilities to personalize an AI
partner with different personality traits or the other pair compatibility
factors like gender, ethnicity, and self-esteem that Salleh et al. (2011)
proposed. Potentially, it can be used to increase programmers’ motivation
and/or engagement, but how useful it is for human-AI pair programming is yet
to be examined.

#### Communication

For communication, we know the social aspect of a conversation matter (Chong
and Hurlbutt, 2007) and that some types of discourse could be more effective
to facilitate debugging (Murphy et al., 2010) in human-human pair programming.
Therefore, since LLM-based tools such as ChatGPT are able to simulate social
interaction, it would be interesting to explore if LLM can support different
types of communication, can the different components of communication be
replicated in an LLM-based programming assistant, and whether it is effective
or not.

#### Collaboration

In terms of collaboration, it is frequently reported that creating smooth
collaboration is challenging in both industry (Begel and Nagappan, 2008) and
educational context (Nagappan et al., 2003; Williams et al., 2002). Given that
the free-rider problem reduce pair programming’s effectiveness (Nagappan et
al., 2003) and regular role-switching potentially alleviates the driver’s
cognitive load and ensures balanced learning outcomes (Alves De Lima Salge and
Berente, 2016; Umapathy and Ritzhaupt, 2017), it would be interesting to
explore if LLM-based AI can be configured to avoid over-help, support role-
switching, and how to best support the human-AI pair to collaborate.

#### Logistics

Logistics-wise, the use of Copilot as a programming partner may have the
special advantage of avoiding scheduling logistics, but there are also
concerns of accountability that need to be addressed (Finnie-Ansley et al.,
2022; Bird et al., 2023). In general, there will be ethical risks and social
implications of using AI in pair programming at the workplace and in
educational contexts, which needs deeper examination in future works.

###  5.3. LLM, Students’ pAIr Programmer?

As reviewed in Section 2, most current studies that evaluate the efficacy of
Copilot are conducted with experienced software developers. If we estimate
Copilot’s problem-solving abilities as an average student in introductory
programming classes, evaluating its performance when pairing up with a
professional software developer with much more expertise may not bring enough
benefit to the professional. Therefore, working with LLM’s current
capabilities, it seems like a student-AI pair programming setup would be the
most promising to explore, so the next question is: how should we best support
student-AI pair programming?

#### Re-prioritize programming skills.

Co-working with AI requires a special skill set, and future work could explore
how to support students to better develop these crucial skills. Bird et al.
(2023) argued that the popularity of LLM-based programming assistants will
result in the growing importance of reviewing code as a skill for developers.
Nonetheless, in Perscheid et al. (2017)’s interview, none of the professional
developers remembered training on debugging at school. There is already rich
literature on debugging and testing instructions (Ahrendt et al., 2009; Smith
et al., 2012; McCauley et al., 2008), but logistical challenges like the lack
of instructional time still exist (McCauley et al., 2008; Fitzgerald et al.,
2010), and educators need to better prepare students with debugging and
testing skills needed to work with unreliable AI.

#### Integrate AIEd frameworks.

On the theoretical side, Holstein et al. (2020) developed a framework to map
ways to mutually augment humans and AI in education, for example, by
augmenting interpretation, action, scalability, and capacity. Future works can
use existing theories in the AI education space to improve the design of the
AI pAIr programming partner, and further investigate if LLMs bring new focus
and affordances to previous human-AI education frameworks.

#### Support explanation and communication with students.

Previous attempts of using AI agent as pair programming partner have shown
some preliminary success in knowledge transfer and retention (Robe and Kuttal,
2022; Han et al., 2010), and the limitation discussed was the lack of
discussion and explanation (Kuttal et al., 2021). Nowadays, as an LLM-based
agent can support more natural interaction and provide good quality
explanations in the introductory programming context (Leinonen et al., 2023),
it would be interesting to explore if LLM-based AI could resolve some
limitations mentioned in pedagogical and conversational agent works before.
Self-reflection and explanation techniques may also be adopted to make up for
the communication aspect as in human-human pair programming.

#### Match expertise with students.

As discussed in Section 4, matching expertise is a tricky problem. Lui and
Chan (2006) found that expert-expert pair may not gain as much of an advantage
over an expert solo programmer, in comparison to novice-novice pair vs. a solo
novice. Meanwhile, pairing two novices together raise concerns of “the blind
leading the blind,” but pairing a novice with an expert may lead to lower
self-esteem of the novice (Ally et al., 2005). Given all these complexities,
when it comes to a student-AI pair and when we only care about the student’s
learning gains, there are a lot of research questions to ask. If we have full
control of the perceived skill level of the AI partner, should we configure it
to be similar to the student, slightly higher-skilled, or a lot better? Would
it be beneficial to have both a peer AI agent but also a tutor AI agent to
assist if students get stuck?

#### Avoid over-helping students.

For programming learners, it would be important to configure the LLM-based
programming assistant to avoid over-help. In the few studies that examined
novice interaction with Copilot (Prather et al., 2023) or a customized
programming environment based on LLM-based code generation model Codex
(Kazemitabaar et al., 2023). Prather et al. (2023) found that novices do have
unique interaction patterns with Copilot and a tendency to rely on and trust
the generated code too much. Kazemitabaar et al. (2023) discussed design
implications including control over-use and support complete novices. There
have also been concerns about academic integrity and changing perception of
learning when LLM-based programming tools become easily accessible to students
(Becker et al., 2023; Puryear and Sprint, 2022; Prather et al., 2023), which
need further explorations for student-AI pair programming.

#### Boost students’ self-confidence.

Last but not least, pair programming has been shown to benefit students with
lower self-efficacy and self-confidence levels (Thomas et al., 2003) and women
(Maguire et al., 2014) more, which could make it a pedagogical tool to engage
more vulnerable or underrepresented populations in CS. When an AI is
introduced in pair programming, would the same benefit retains? How should we
present the AI differently to make it compatible to students with different
confidence levels? How do we mitigate the risks of unreliable but seemingly
authoritative AI? LLMs may be an opportunity to address some existing
challenges in student-student pair programming (as summarized in Table 2), but
there are still a lot of open questions to ask.

##  6\. Conclusion

This paper has discussed the concept of human-AI pair programming (pAIr
programming). We found that both human-human and human-AI pair programming
have benefits and challenges, but current research did not give us a clear
answer on the efficacy of human-AI pair programming. Human-human pair
programming literature yield insights on what study designs should pAIr
researchers adopt (e.g., more realistic observations), what outcomes and
measures should pAIr researchers use to evaluate their work (e.g., use more
valid quality and productivity measurements, and further investigate cost),
and what moderators should pAIr researchers consider to further analyze the
pAIr process and improve pAIr design (e.g, compatibility, communication,
etc.).

In conclusion, more valid and comprehensive measurements are needed to
evaluate pAIr, more comparisons can be drawn between human-human vs. human-AI
pair programming, and more works can explore how to best support LLM-assisted
programming with insights from the rich literature on human-human pair
programming.

###### Acknowledgements.

Thanks to Ken’s lab members for giving feedback on this work. Thanks to Dr.
Stephen MacNeil for coming up with the creative “pAIr” keyword for this
project.

## References

  * (1)
  * Aher et al. (2022) Gati Aher, Rosa I Arriaga, and Adam Tauman Kalai. 2022\.  Using Large Language Models to Simulate Multiple Humans and Replicate Human Subject Studies.  (Aug. 2022).  arXiv:2208.10264 [cs.CL] http://arxiv.org/abs/2208.10264
  * Ahrendt et al. (2009) Wolfgang Ahrendt, Richard Bubel, and Reiner Hähnle. 2009\.  Integrated and Tool-Supported Teaching of Testing, Debugging, and Verification. In _Teaching Formal Methods_. Springer Berlin Heidelberg, 125–143.  https://doi.org/10.1007/978-3-642-04912-5_9
  * Al Madi (2023) Naser Al Madi. 2023\.  How Readable is Model-generated Code? Examining Readability and Visual Inspection of GitHub Copilot. In _Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering_. Association for Computing Machinery, New York, NY, USA, 1–5.  https://doi.org/10.1145/3551349.3560438
  * Ally et al. (2005) Mustafa Ally, Fiona Darroch, and Mark Toleman. 2005\.  A framework for understanding the factors influencing pair programming success.  In _Extreme Programming and Agile Processes in Software Engineering_. Springer Berlin Heidelberg, Berlin, Heidelberg, 82–91.  https://doi.org/10.1007/11499053_10
  * Alves De Lima Salge and Berente (2016) Carolina Alves De Lima Salge and Nicholas Berente. 2016.  Pair Programming vs. Solo Programming: What Do We Know After 15 Years of Research?. In _2016 49th Hawaii International Conference on System Sciences (HICSS)_. 5398–5406.  https://doi.org/10.1109/HICSS.2016.667
  * Arisholm et al. (2007) Erik Arisholm, Hans Gallis, Tore Dyba, and Dag I K Sjoberg. 2007.  Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise.  _IEEE Trans. Software Eng._ 33, 2 (Feb. 2007), 65–86.  https://doi.org/10.1109/TSE.2007.17
  * Asare et al. (2022) Owura Asare, Meiyappan Nagappan, and N Asokan. 2022\.  Is GitHub’s Copilot as Bad as Humans at Introducing Vulnerabilities in Code?  (April 2022).  arXiv:2204.04741 [cs.SE] http://arxiv.org/abs/2204.04741
  * Barke et al. (2022) Shraddha Barke, Michael B James, and Nadia Polikarpova. 2022\.  Grounded Copilot: How Programmers Interact with Code-Generating Models.  (June 2022).  arXiv:2206.15000 [cs.HC] http://arxiv.org/abs/2206.15000
  * Beck (1999) Kent Beck. 1999\.  _Extreme programming explained: embrace change_.  Addison-Wesley Longman Publishing Co., Inc., USA.  https://dl.acm.org/doi/10.5555/318762
  * Becker et al. (2023) Brett A Becker, Paul Denny, James Finnie-Ansley, Andrew Luxton-Reilly, James Prather, and Eddie Antonio Santos. 2023.  Programming Is Hard - Or at Least It Used to Be: Educational Opportunities and Challenges of AI Code Generation. In _Proceedings of the 54th ACM Technical Symposium on Computer Science Education V. 1_ (Toronto ON, Canada) _(SIGCSE 2023)_. Association for Computing Machinery, New York, NY, USA, 500–506.  https://doi.org/10.1145/3545945.3569759
  * Begel and Nagappan (2008) Andrew Begel and Nachiappan Nagappan. 2008.  Pair programming: what’s in it for me?. In _Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement_ (Kaiserslautern Germany). ACM, New York, NY, USA.  https://doi.org/10.1145/1414004.1414026
  * Bird et al. (2023) Christian Bird, Denae Ford, Thomas Zimmermann, Nicole Forsgren, Eirini Kalliamvakou, Travis Lowdermilk, and Idan Gazit. 2023\.  Taking Flight with Copilot: Early insights and opportunities of AI-powered pair-programming tools.  _Queueing Syst._ 20, 6 (Jan. 2023), 35–57.  https://doi.org/10.1145/3582083
  * Bodenheimer et al. (2009) Bobby Bodenheimer, B Sanders, M R Kramer, K Viswanath, R Balachandran, Kadira Belynne, and Gautam Biswas. 2009.  Construction and Evaluation of Animated Teachable Agents.  _J. Educ. Technol. Soc._ (2009).  https://www.semanticscholar.org/paper/2899ac4dfe209db4767ec01b5df337079bada517
  * Bubeck et al. (2023) Sébastien Bubeck, Varun Chandrasekaran, Ronen Eldan, Johannes Gehrke, Eric Horvitz, Ece Kamar, Peter Lee, Yin Tat Lee, Yuanzhi Li, Scott Lundberg, Harsha Nori, Hamid Palangi, Marco Tulio Ribeiro, and Yi Zhang. 2023.  Sparks of Artificial General Intelligence: Early experiments with GPT-4.  (March 2023).  arXiv:2303.12712 [cs.CL] http://arxiv.org/abs/2303.12712
  * Cao (2023) Chen Cao. 2023.  Scaffolding CS1 Courses with a Large Language Model-Powered Intelligent Tutoring System. In _Companion Proceedings of the 28th International Conference on Intelligent User Interfaces_ (Sydney, NSW, Australia) _(IUI ’23 Companion)_. Association for Computing Machinery, New York, NY, USA, 229–232.  https://doi.org/10.1145/3581754.3584111
  * Chaparro et al. (2005) E A Chaparro, Aybala Yuksel, Pablo Romero, and Sallyann Bryant. 2005.  Factors Affecting the Perceived Effectiveness of Pair Programming in Higher Education.  _Annual Workshop of the Psychology of Programming Interest Group_ (2005).  https://www.semanticscholar.org/paper/c095f0d9b17cd9c2851000534740e7cc087253fa
  * Chong and Hurlbutt (2007) Jan Chong and Tom Hurlbutt. 2007.  The Social Dynamics of Pair Programming. In _29th International Conference on Software Engineering (ICSE’07)_. ieeexplore.ieee.org, 354–363.  https://doi.org/10.1109/ICSE.2007.87
  * Cockburn and Williams (2001) Alistair Cockburn and L Williams. 2001.  The costs and benefits of pair programming.  _Computer Science_ (2001).  https://www.semanticscholar.org/paper/5ff7b75b20fdbfae23587b660b7093aec2f48e69
  * da Silva Estácio and Prikladnicki (2015) Bernardo José da Silva Estácio and Rafael Prikladnicki. 2015\.  Distributed Pair Programming: A Systematic Literature Review.  _Information and Software Technology_ 63 (July 2015), 1–10.  https://doi.org/10.1016/j.infsof.2015.02.011
  * Dai et al. (2023) Wei Dai, Jionghao Lin, Flora Jin, Tongguang Li, Yi-Shan Tsai, Dragan Gasevic, and Guanliang Chen. 2023.  Can Large Language Models Provide Feedback to Students? A Case Study on ChatGPT. (April 2023).  https://doi.org/10.35542/osf.io/hcgzj
  * Dakhel et al. (2022) Arghavan Moradi Dakhel, Vahid Majdinasab, Amin Nikanjam, Foutse Khomh, Michel C Desmarais, Zhen Ming, and Jiang. 2022\.  GitHub Copilot AI pair programmer: Asset or Liability?  _ArXiv_ (2022).  https://doi.org/10.48550/ARXIV.2206.15331
  * Finnie-Ansley et al. (2022) James Finnie-Ansley, Paul Denny, Brett A Becker, Andrew Luxton-Reilly, and James Prather. 2022\.  The Robots Are Coming: Exploring the Implications of OpenAI Codex on Introductory Programming. In _Australasian Computing Education Conference_ (Virtual Event, Australia) _(ACE ’22)_. Association for Computing Machinery, New York, NY, USA, 10–19.  https://doi.org/10.1145/3511861.3511863
  * Fitzgerald et al. (2010) Sue Fitzgerald, Renée McCauley, Brian Hanks, Laurie Murphy, Beth Simon, and Carol Zander. 2010\.  Debugging From the Student Perspective.  _IEEE Trans. Educ._ 53, 3 (Aug. 2010), 390–396.  https://doi.org/10.1109/TE.2009.2025266
  * Freudenberg et al. (2007) S Freudenberg, Pablo Romero, and Benedict Du Boulay. 2007\.  Talking the talk: Is intermediate-level conversation the key to the pair programming success story?. In _AGILE 2007_. unknown, 84–91.  https://doi.org/10.1109/AGILE.2007.1
  * Github ([n. d.]) Github. [n. d.].  GitHub Copilot Labs.  https://githubnext.com/projects/copilot-labs/.  https://githubnext.com/projects/copilot-labs/ Accessed: 2023-5-19.
  * GitHub (2021) GitHub. 2021.  Your AI pair programmer: Copilot.  https://github.com/features/copilot.  https://github.com/features/copilot Accessed: 2022-10-5.
  * Google ([n. d.]) Google. [n. d.].  Bard.  https://bard.google.com/.  https://bard.google.com/ Accessed: 2023-5-19.
  * Han et al. (2010) Keun-Woo Han, Eunkyoung Lee, and Youngjun Lee. 2010.  The Impact of a Peer-Learning Agent Based on Pair Programming in a Programming Course.  _IEEE Trans. Educ._ 53, 2 (May 2010), 318–327.  https://doi.org/10.1109/TE.2009.2019121
  * Hanks et al. (2011) Brian Hanks, Sue Fitzgerald, Renée McCauley, Laurie Murphy, and Carol Zander. 2011\.  Pair programming in education: a literature review.  _Comput. Sci. Educ._ 21, 2 (June 2011), 135–173.  https://doi.org/10.1080/08993408.2011.579808
  * Hannay et al. (2010) Jo E Hannay, Erik Arisholm, Harald Engvik, and Dag I K Sjoberg. 2010.  Effects of Personality on Pair Programming.  _IEEE Trans. Software Eng._ 36, 1 (Jan. 2010), 61–80.  https://doi.org/10.1109/TSE.2009.41
  * Hannay et al. (2009) Jo E Hannay, Tore Dybå, Erik Arisholm, and Dag I K Sjøberg. 2009.  The effectiveness of pair programming: A meta-analysis.  _Information and Software Technology_ 51, 7 (July 2009), 1110–1122.  https://doi.org/10.1016/j.infsof.2009.02.001
  * Heidig and Clarebout (2011) Steffi Heidig and Geraldine Clarebout. 2011.  Do pedagogical agents make a difference to student motivation and learning?  _Educational Research Review_ 6, 1 (Jan. 2011), 27–54.  https://doi.org/10.1016/j.edurev.2010.07.004
  * Holstein et al. (2020) Kenneth Holstein, Vincent Aleven, and Nikol Rummel. 2020\.  A Conceptual Framework for Human–AI Hybrid Adaptivity in Education.  _Artificial Intelligence in Education_ 12163 (June 2020), 240\.  https://doi.org/10.1007/978-3-030-52237-7_20
  * Horton (2023) John J Horton. 2023\.  Large Language Models as Simulated Economic Agents: What Can We Learn from Homo Silicus?  (Jan. 2023).  arXiv:2301.07543 [econ.GN] http://arxiv.org/abs/2301.07543
  * Imai (2022) Saki Imai. 2022\.  Is GitHub Copilot a Substitute for Human Pair-programming? An Empirical Study. In _2022 IEEE/ACM 44th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion)_. ieeexplore.ieee.org, 319–321.  https://doi.org/10.1145/3510454.3522684
  * Jensen (2005) Randall W Jensen. 2005\.  A Pair Programming Experience.  _ACCU - professionalism in programming Overload_ 13, 65 (Feb. 2005).  https://accu.org/journals/overload/13/65/jensen_254/
  * Kalliamvakou (2022) Eirini Kalliamvakou. 2022\.  Research: quantifying GitHub Copilot’s impact on developer productivity and happiness.  https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/.  https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/ Accessed: 2022-10-13.
  * Kang et al. (2022) Sungmin Kang, Juyeon Yoon, and Shin Yoo. 2022.  Large Language Models are few-shot testers: Exploring LLM-based general bug reproduction.  _ArXiv_ (2022).  https://doi.org/10.48550/ARXIV.2209.11515
  * Kazemitabaar et al. (2023) Majeed Kazemitabaar, Justin Chow, Carl Ka To Ma, Barbara J Ericson, David Weintrop, and Tovi Grossman. 2023.  Studying the effect of AI Code Generators on Supporting Novice Learners in Introductory Programming.  (Feb. 2023).  arXiv:2302.07427 [cs.HC] http://arxiv.org/abs/2302.07427
  * Kumar et al. (2022) Shobhan Kumar, Arun Chauhan, and Pavan Kumar C. 2022\.  Learning Enhancement Using Question-Answer Generation for e-Book Using Contrastive Fine-Tuned T5. In _Big Data Analytics_. Springer Nature Switzerland, 68–87.  https://doi.org/10.1007/978-3-031-24094-2_5
  * Kuttal et al. (2021) Sandeep Kaur Kuttal, Bali Ong, Kate Kwasny, and Peter Robe. 2021\.  Trade-offs for Substituting a Human with an Agent in a Pair Programming Context: The Good, the Bad, and the Ugly. In _Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems_ (Yokohama, Japan) _(CHI ’21, Article 243)_. Association for Computing Machinery, New York, NY, USA, 1–20.  https://doi.org/10.1145/3411764.3445659
  * Leinonen et al. (2023) Juho Leinonen, Paul Denny, Stephen MacNeil, Sami Sarsa, Seth Bernstein, Joanne Kim, Andrew Tran, and Arto Hellas. 2023\.  Comparing Code Explanations Created by Students and Large Language Models.  (April 2023).  arXiv:2304.03938 [cs.CY] http://arxiv.org/abs/2304.03938
  * Li and Suh (2021) Mengjun Li and Ayoung Suh. 2021.  Machinelike or Humanlike? A Literature Review of Anthropomorphism in AI-Enabled Technology. In _Hawaii International Conference on System Sciences 2021 (HICSS-54)_.  https://aisel.aisnet.org/hicss-54/in/ai_based_assistants/5/
  * Lin et al. (2013) Lijia Lin, Robert K Atkinson, Robert M Christopherson, Stacey S Joseph, and Caroline J Harrison. 2013.  Animated agents and learning: Does the type of verbal feedback they provide matter?  _Comput. Educ._ 67 (Sept. 2013), 239–249.  https://doi.org/10.1016/j.compedu.2013.04.017
  * Lui and Chan (2006) Kim Man Lui and Keith C C Chan. 2006.  Pair programming productivity: Novice–novice vs. expert–expert.  _Int. J. Hum. Comput. Stud._ 64, 9 (Sept. 2006), 915–925.  https://doi.org/10.1016/j.ijhcs.2006.04.010
  * Lusk and Atkinson (2007) Mary Margaret Lusk and Robert K Atkinson. 2007.  Animated pedagogical agents: does their degree of embodiment impact learning from static or animated worked examples?  _Appl. Cogn. Psychol._ 21, 6 (Sept. 2007), 747–764.  https://doi.org/10.1002/acp.1347
  * Maguire et al. (2014) Phil Maguire, Rebecca Maguire, Philip Hyland, and Patrick Marshall. 2014.  Enhancing collaborative learning using pair programming: Who benefits?  _AISHE-J_ 6, 2 (June 2014).  https://ojs.aishe.org/index.php/aishe-j/article/view/141
  * Mayer (2014) Richard E Mayer. 2014\.  Principles based on social cues in multimedia learning: Personalization, voice, image, and embodiment principles.  _The Cambridge handbook of multimedia learning_ 16 (2014), 345–370.  https://books.google.com/books?hl=en&lr=&id=r3rsAwAAQBAJ&oi=fnd&pg=PA345&ots=iUhQ53T8QY&sig=5tQyKi_f-7aILMxRLuwGTLIix3c
  * Mayer and DaPra (2012) Richard E Mayer and C Scott DaPra. 2012.  An embodiment effect in computer-based learning with animated pedagogical agents.  _J. Exp. Psychol. Appl._ 18, 3 (Sept. 2012), 239–252.  https://doi.org/10.1037/a0028616
  * McCauley et al. (2008) Renee McCauley, Sue Fitzgerald, Gary Lewandowski, Laurie Murphy, Beth Simon, Lynda Thomas, and Carol Zander. 2008.  Debugging: A Review of the Literature from an Educational Perspective.  _Computer Science Education_ 18, 2 (June 2008), 67–92.  https://doi.org/10.1080/08993400802114581
  * McDowell et al. (2002) Charlie McDowell, Linda Werner, Heather Bullock, and Julian Fernald. 2002.  The effects of pair-programming on performance in an introductory programming course. In _Proceedings of the 33rd SIGCSE technical symposium on Computer science education_ (Cincinnati, Kentucky) _(SIGCSE ’02)_. Association for Computing Machinery, New York, NY, USA, 38–42.  https://doi.org/10.1145/563340.563353
  * McDowell et al. (2006) Charlie McDowell, Linda Werner, Heather E Bullock, and Julian Fernald. 2006.  Pair programming improves student retention, confidence, and program quality.  _Commun. ACM_ 49, 8 (Aug. 2006), 90–95.  https://doi.org/10.1145/1145287.1145293
  * Mozannar et al. (2022) Hussein Mozannar, Gagan Bansal, Adam Fourney, and Eric Horvitz. 2022.  Reading between the lines: Modeling user behavior and costs in AI-assisted programming.  _ArXiv_ (2022).  https://doi.org/10.48550/ARXIV.2210.14306
  * Murillo and D’Angelo (2023) Ambar Murillo and Sarah D’Angelo. 2023.  An Engineering Perspective on Writing Assistants for Productivity and Creative Code.  _The Second Workshop on Intelligent and Interactive Writing Assistants_ (2023).  https://cdn.glitch.global/d058c114-3406-43be-8a3c-d3afff35eda2/paper1_2023.pdf
  * Murphy et al. (2010) Laurie Murphy, Sue Fitzgerald, Brian Hanks, and Renée McCauley. 2010.  Pair debugging: a transactive discourse analysis. In _Proceedings of the Sixth international workshop on Computing education research_ (Aarhus, Denmark) _(ICER ’10)_. Association for Computing Machinery, New York, NY, USA, 51–58.  https://doi.org/10.1145/1839594.1839604
  * Myers et al. (2016) Brad A Myers, Amy J Ko, Thomas D LaToza, and Youngseok Yoon. 2016\.  Programmers are users too: Human-centered methods for improving programming tools.  _Computer_ 49, 7 (July 2016), 44–52.  https://doi.org/10.1109/MC.2016.200
  * Nagappan et al. (2003) Nachiappan Nagappan, Laurie Williams, Miriam Ferzli, Eric Wiebe, Kai Yang, Carol Miller, and Suzanne Balik. 2003\.  Improving the CS1 experience with pair programming. In _Proceedings of the 34th SIGCSE technical symposium on Computer science education_ (Reno Navada USA). ACM, New York, NY, USA.  https://doi.org/10.1145/611892.612006
  * Nguyen and Nadi (2022) N Nguyen and Sarah Nadi. 2022.  An Empirical Evaluation of GitHub Copilot’s Code Suggestions.  _2022 IEEE/ACM 19th International Conference on Mining Software Repositories (MSR)_ (2022).  https://doi.org/10.1145/3524842.3528470
  * Ogan et al. (2012) Amy Ogan, Samantha Finkelstein, Elijah Mayfield, Claudia D’Adamo, Noboru Matsuda, and Justine Cassell. 2012.  “Oh dear stacy!”: social interaction, elaboration, and learning with teachable agents. In _Proceedings of the SIGCHI Conference on Human Factors in Computing Systems_ (Austin, Texas, USA) _(CHI ’12)_. Association for Computing Machinery, New York, NY, USA, 39–48.  https://doi.org/10.1145/2207676.2207684
  * Padmanabhuni et al. (2012) Venkata Vinod Kumar Padmanabhuni, Hari Praveen Tadiparthi, and Sagar Madina Muralidhar Yanamadala. 2012\.  Effective pair programming practice-an experimental study.  _Journal of Emerging Trends in Computing and Information Sciences_ 3, 4 (2012), 471–479.  http://www.agilemethod.csie.ncu.edu.tw/agileMethod/download/2012papers/2012%20Effective%20Pair%20Programming%20Practice-%20An%20Experimental%20Study/Effective%20Pair%20Programming%20Practice-%20An%20Experimental%20Study.pdf
  * Pardos and Bhandari (2023) Zachary A Pardos and Shreya Bhandari. 2023.  Learning gain differences between ChatGPT and human tutor generated algebra hints.  (Feb. 2023).  arXiv:2302.06871 [cs.CY] http://arxiv.org/abs/2302.06871
  * Pearce et al. (2021) Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2021\.  Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions.  (Aug. 2021).  arXiv:2108.09293 [cs.CR] http://arxiv.org/abs/2108.09293
  * Peng et al. (2023) Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023.  The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.  (Feb. 2023).  arXiv:2302.06590 [cs.SE] http://arxiv.org/abs/2302.06590
  * Perscheid et al. (2017) Michael Perscheid, Benjamin Siegmund, Marcel Taeumel, and Robert Hirschfeld. 2017.  Studying the advancement in debugging practice of professional software developers.  _Software Quality Journal_ 25, 1 (March 2017), 83–110.  https://doi.org/10.1007/s11219-015-9294-2
  * Plonka et al. (2011) Laura Plonka, Judith Segal, Helen Sharp, and Janet van der Linden. 2011.  Collaboration in Pair Programming: Driving and Switching. In _Agile Processes in Software Engineering and Extreme Programming - 12th International Conference, XP 2011, Madrid, Spain, May 10-13, 2011. Proceedings_ , Vol. 77. unknown, 43–59.  https://doi.org/10.1007/978-3-642-20677-1_4
  * Prather et al. (2023) James Prather, Brent N Reeves, Paul Denny, Brett A Becker, Juho Leinonen, Andrew Luxton-Reilly, Garrett Powell, James Finnie-Ansley, and Eddie Antonio Santos. 2023\.  “It’s Weird That it Knows What I Want”: Usability and Interactions with Copilot for Novice Programmers.  (April 2023).  arXiv:2304.02491 [cs.HC] http://arxiv.org/abs/2304.02491
  * Preston (2006) David Preston. 2006\.  Using collaborative learning research to enhance pair programming pedagogy.  _SIGITE Newsl._ 3, 1 (Jan. 2006), 16–21.  https://doi.org/10.1145/1113378.1113381
  * Puryear and Sprint (2022) Ben Puryear and Gina Sprint. 2022.  Github copilot in the classroom: learning to code with AI assistance.  _J. Comput. Sci. Coll._ 38, 1 (Dec. 2022), 37–47.  https://dl.acm.org/doi/pdf/10.5555/3575618.3575622
  * Robe and Kuttal (2022) Peter Robe and Sandeep Kaur Kuttal. 2022.  Designing PairBuddy—A Conversational Agent for Pair Programming.  _ACM Trans. Comput.-Hum. Interact._ 29, 4 (May 2022), 1–44.  https://doi.org/10.1145/3498326
  * Salleh et al. (2011) Norsaremah Salleh, Emilia Mendes, and John Grundy. 2011\.  Empirical Studies of Pair Programming for CS/SE Teaching in Higher Education: A Systematic Literature Review.  _IEEE Trans. Software Eng._ 37, 4 (July 2011), 509–525.  https://doi.org/10.1109/TSE.2010.59
  * Sankaranarayanan et al. (2020) S Sankaranarayanan, S R Kandimalla, S Hasan, and others. 2020\.  Agent-in-the-loop: Conversational agent support in service of reflection for learning during collaborative programming.  _Artif. Intell._ (2020).  https://link.springer.com/chapter/10.1007/978-3-030-52240-7_50
  * Sarkar et al. (2022) Advait Sarkar, Andrew D Gordon, Carina Negreanu, Christian Poelitz, Sruti Srinivasa Ragavan, and Ben Zorn. 2022.  What is it like to program with artificial intelligence?  (Aug. 2022).  arXiv:2208.06213 [cs.HC] http://arxiv.org/abs/2208.06213
  * Schroeder et al. (2013) Noah L Schroeder, Olusola O Adesope, and Rachel Barouch Gilbert. 2013.  How Effective are Pedagogical Agents for Learning? A Meta-Analytic Review.  _Journal of Educational Computing Research_ 49, 1 (July 2013), 1–39.  https://doi.org/10.2190/EC.49.1.a
  * Shneiderman and Maes (1997) Ben Shneiderman and Pattie Maes. 1997.  Direct manipulation vs. interface agents.  _Interactions_ 4, 6 (Nov. 1997), 42–61.  https://doi.org/10.1145/267505.267514
  * Sillitti et al. (2012) Alberto Sillitti, Giancarlo Succi, and Jelena Vlasenko. 2012\.  Understanding the impact of Pair Programming on developers attention: A case study on a large industrial experimentation. In _2012 34th International Conference on Software Engineering (ICSE)_ (Zurich). IEEE, 1094–1101.  https://doi.org/10.1109/ICSE.2012.6227110
  * Sison (2009) Raymund Sison. 2009\.  Investigating the Effect of Pair Programming and Software Size on Software Quality and Programmer Productivity. In _2009 16th Asia-Pacific Software Engineering Conference_. 187–193.  https://doi.org/10.1109/APSEC.2009.71
  * Smith et al. (2012) Joanna Smith, Joe Tessler, Elliot Kramer, and Calvin Lin. 2012.  Using peer review to teach software testing. In _Proceedings of the ninth annual international conference on International computing education research_ (Auckland, New Zealand) _(ICER ’12)_. Association for Computing Machinery, New York, NY, USA, 93–98.  https://doi.org/10.1145/2361276.2361295
  * Sonkar et al. (2023) Shashank Sonkar, Lucy Liu, Debshila Basu Mallick, and Richard G Baraniuk. 2023.  CLASS Meet SPOCK: An Education Tutoring Chatbot based on Learning Science Principles.  (May 2023).  arXiv:2305.13272 [cs.CL] http://arxiv.org/abs/2305.13272
  * Sun and Marakas (2009) W Sun and G Marakas. 2009\.  The True Cost of Pair Programming: Development of a Comprehensive Model and Test.  _Americas Conference on Information Systems_ (2009).  https://www.semanticscholar.org/paper/647fc48650e4f19962c8a6feb87f3bdedde9dd04
  * Tan (2023) Chenhao Tan. 2023\.  On AI Anthropomorphism - Human-Centered AI - Medium.  https://medium.com/human-centered-ai/on-ai-anthropomorphism-abff4cecc5ae.  https://medium.com/human-centered-ai/on-ai-anthropomorphism-abff4cecc5ae Accessed: 2023-4-23.
  * Thomas et al. (2003) Lynda Thomas, Mark Ratcliffe, and Ann Robertson. 2003\.  Code warriors and code-a-phobes: a study in attitude and pair programming.  _SIGCSE Bull._ 35, 1 (Jan. 2003), 363–367.  https://doi.org/10.1145/792548.612007
  * Thorp (2023) H Holden Thorp. 2023\.  ChatGPT is fun, but not an author.  _Science_ 379, 6630 (Jan. 2023), 313\.  https://doi.org/10.1126/science.adg7879
  * Umapathy and Ritzhaupt (2017) Karthikeyan Umapathy and Albert D Ritzhaupt. 2017.  A Meta-Analysis of Pair-Programming in Computer Programming Courses: Implications for Educational Practice.  _ACM Trans. Comput. Educ._ 17, 4 (Aug. 2017), 1–13.  https://doi.org/10.1145/2996201
  * Vaithilingam et al. (2022) Priyan Vaithilingam, Tianyi Zhang, and Elena L Glassman. 2022\.  Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models. In _Extended Abstracts of the 2022 CHI Conference on Human Factors in Computing Systems_ (New Orleans, LA, USA) _(CHI EA ’22, Article 332)_. Association for Computing Machinery, New York, NY, USA, 1–7.  https://doi.org/10.1145/3491101.3519665
  * Wang et al. (2022) Zichao Wang, Jakob Valdez, Debshila Basu Mallick, and Richard G Baraniuk. 2022.  Towards Human-Like Educational Question Generation with Large Language Models. In _Artificial Intelligence in Education_. Springer International Publishing, 153–166.  https://doi.org/10.1007/978-3-031-11644-5_13
  * Williams and Upchurch (2001) Laurie Williams and Richard L Upchurch. 2001.  In support of student pair-programming. In _Proceedings of the thirty-second SIGCSE technical symposium on Computer Science Education_ (Charlotte North Carolina USA). ACM, New York, NY, USA.  https://doi.org/10.1145/364447.364614
  * Williams et al. (2002) Laurie Williams, Eric Wiebe, Kai Yang, Miriam Ferzli, and Carol Miller. 2002.  In support of pair programming in the introductory computer science course.  _Comput. Sci. Educ._ 12, 3 (Sept. 2002), 197–212.  https://doi.org/10.1076/csed.12.3.197.8618
  * Wong et al. (2022) Dakota Wong, Austin Kothig, and Patrick Lam. 2022\.  Exploring the Verifiability of Code Generated by GitHub Copilot.  _ACM on Programming Languages_ (2022).  https://www.semanticscholar.org/paper/b5051fedaf17836f6b2a042cc4af4155159795c5
  * Yetiştiren et al. (2022) Burak Yetiştiren, Işik Özsoy, and Eray Tüzün. 2022.  Assessing the Quality of GitHub Copilot’s Code Generation. In _18th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE ’22)_.  https://doi.org/10.1145/3558489.3559072
  * Ziegler et al. (2022) Albert Ziegler, Eirini Kalliamvakou, X Alice Li, Andrew Rice, Devon Rifkin, Shawn Simister, Ganesh Sittampalam, and Edward Aftandilian. 2022.  Productivity assessment of neural code completion. In _Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming_ (San Diego CA USA). ACM, New York, NY, USA.  https://doi.org/10.1145/3520312.3534864


# Searches for high energy solar flares with Fermi-LAT

G. Iafrate  INAF - Astronomical Observatory of Trieste, Italy and INFN
Trieste, Italy  F. Longo  INFN Trieste, Italy and Dipartimento di Fisica,
Trieste, Italy  on behalf of the Fermi Large Area Telescope Collaboration

###### Abstract

The Fermi Large Area Telescope (LAT) has been surveying the sky in gamma rays
from 30 MeV to more than 300 GeV since August 2008\. Fermi is the only mission
able to detect high energy $(>\text{few hundreds MeV})$ emission from the Sun
during the new solar cycle 24: the Solar System Science Group of the Fermi
team is continuously monitoring high energy emission from the Sun searching
for flare events. Preliminary upper limits $(>100\text{ MeV})$ have been
derived for all solar flares detected so far by other missions and experiments
(RHESSI, Fermi GBM, GOES). Upper limit for flaring Sun emission (integrated
over one year of data) has also been derived. Here we present the analysis
techniques as well as the details of this search and the preliminary results
obtained so far.

Figure 1: Solar flares detected by RHESSI and analysed in this search,
superimposed on a count map of LAT data ($E>200\textnormal{ MeV}$) for a
easier localization in the sky. There is no evidence of correlation between
flare positions and excesses of the LAT events.

##  I Introduction

_Fermi_ was successfully launched from Cape Canaveral on 2008 June 11. It is
currently in an almost circular orbit around the Earth at an altitude of 565
km having an inclination of 25.6∘ and an orbital period of 96 minutes. After
an initial period of engineering data taking and on-orbit calibrationFermi ,
the observatory was put into a sky-survey mode in August 2008. The observatory
has two instruments onboard, the Large Area Telescope (LAT)LAT , a pair-
conversion gamma-ray detector and tracker (energy range 30 MeV - $>300$ GeV)
and a Gamma-ray Burst Monitor (GBM), dedicated to the detection of gamma-ray
bursts (energy range 8 keV - 40 MeV). The instruments on _Fermi_ provide
coverage over the energy range measurements from few keV to several hundreds
of GeV.

Here we report Fermi LAT limits on emission $>100\text{ MeV}$ for the few
flares detected by other missions over the past year. Solar flares are the
most energetic phenomena that occur within our Solar System. A flare is
characterized by the impulsive release of a huge amount of energy, previously
stored in the magnetic fields of active regions. During a flare plasma of the
solar corona and chromosphere is accelerated and electromagnetic radiation
covering the entire spectrum is emitted. The production of $\gamma$-rays
involves flare-accelerated charged-particle (electrons, protons and heavier
nuclei) interactions with the ambient solar atmosphere. Electrons accelerated
by the flare, or from the decay of $\pi^{\pm}$ secondaries produced by nuclear
interactions, yield X and $\gamma$-ray bremsstrahlung radiation with a
spectrum that extends to the energies of the primary particles. Proton and
heavy ion interactions also produce $\gamma$-rays through $\pi^{0}$ decay,
resulting in a spectrum that has a maximum at 68 MeVshare .

The frequency of solar flares follows the 11 year solar activity cycle. Most
intense flares occur during the maximum, but intense flares can occur also in
the rising and decreasing phases of the cycle. The new solar activity cycle 24
has started at the beginning of year 2008, the maximum is predicted in year
2012. _Fermi_ has been launched during the minimum of the solar cycle, so the
frequency and the intensity of solar flares will increase throughout most of
the mission. If the goal of a 10-year mission life is achieved, _Fermi_ will
operate for nearly the entire duration of solar cycle 24. During this time,
_Fermi_ will be the only high-energy observatory ($>\text{few hundreds MeV}$)
to complement several solar missions at lower energies: RHESSI, GOES, SoHO,
Coronas.

##  II Previous observations

The 2005 January 20 solar flare produced one of the most intense, fastest
rising and hardest solar energetic particle events ever observed in space or
on the ground. $\gamma$-ray measurements of the flareshare06 grechnev
revealed what appear to be two separate components of particle acceleration at
the Sun: i) an impulsive release lasting $\sim 10$ min with a power-law index
of $\sim 3$ observed in a compact region on the Sun and, ii) an associated
release of much higher energy particles having a spectral index $\leq 2.3$
interacting at the Sun for about two hours. Pion-decay $\gamma$-rays appear to
dominate the latter component. Such long-duration high-energy events have been
observed before, most notably on 1991 June 11 when the EGRET instrument on
CGRO observed $>50$ MeV emission for over 8 hourskanbach . It is possible that
these high-energy components are directly related to the particle events
observed in space and on Earth.

_Fermi_ will improve our understanding of the mechanisms of the $\gamma$-ray
emission by solar flares thanks to its large effective area, sensitivity and
high spatial and temporal resolution.

##  III Monitor of solar cycle 24

The solar cycle 24 has started at the beginning of 2008, but actually we are
in an extended period of minimal solar activity. We are seeing an interesting
diminished level of activity. There are some discussion ongoing if sunspots
and flares ever return and how unusual is this behaviornugget . A closer look
at the daily values of three indices: F10.7 (10 cm radio flux from the Sun),
the total solar irradiance TSI, and the classical sunspot number give only a
little appearance of a up-turn. In the modern era there is no precedent for
such a protracted activity minimum, but there are historical records from a
century ago of a similar pattern (transition between cycles 13 and 14, 107
years ago).

Activity is expected to pick up in the next months. In the meanwhile is a good
opportunity to use the excellent data available from many satellites to
improve LAT analysis of solar flares and practise in flare monitoring and
analysis, to be ready when the first intense flare of cycle 24 will arrive.

##  IV Data selection

Since August 2008 flares detected by RHESSI and GOES have been continuously
monitored, analysing LAT data for flare events potentially detectable by the
LAT and computing upper limits on the solar high energy emission. Solar flares
have been searched in LAT data from Augusr 2008 to the end of August 2009. LAT
data have been analysed in the time intervals of flares detected by GBM,
RHESSI and GOES. A zenith cut of $105^{\circ}$ has been applied to eliminate
photons from the Earth’s albedo. For this analysis the “Diffuse” classLAT
selection has been adopted, corresponding to the events with the highest
photon classification probability, using the IRFs (Instrumental Response
Functions) version P6_V3.

##  V Analysis method

The list of flares detected by RHESSIrhessi  and the _Solar Monitor_ web
sitesolarmonitor  were monitored constantly at a daily basis. Flares seen by
RHESSI and GOES with more than $10^{5}$ counts (detected by RHESSI) have been
selected. For each of these flares start and end time of the event in _Fermi_
MET (Mission Elapsed Time), the position of the Sun during the flare and the
angle of the Sun direction with the LAT boresight have been computed.

The excess of events in the LAT data has been searched for flares within the
LAT field of view (angle with the LAT boresight $<80^{\circ}$). Although the
Sun is a moving source in the sky, covering about $1^{\circ}$ per day, in this
analysis the Sun has been considered as a fixed source, due to the short
duration of the flare events ($<1$ h). As analysis method a likelihood fitting
technique has been used, performed with a model that includes the Sun as a
point source and fixed galactic and extragalactic diffuse emission.

Moreover, the upper limit of high energy solar emission integrated on more
than one year of flares has been computed. LAT data of flares detected by
RHESSI have been collected (data selected one hour before and five hours later
with respect RHESSI flares, because of the long duration of high energy
emission). The position of the Sun has been computed using a JPL library
interfaceJPL  and then data have been centered on the istantaneous solar
position. Successively these data have been merged and the analysis has been
performed, using the standard likelihood technique provided by the LAT
ScienceTools package (v9r15). Since the Sun is a moving source in the sky, the
problem is to compute the correct galactic and extragalactic diffuse
background emission as the Sun moves through the sky. In order to evaluate the
diffuse background in proper way the fake source method has been used. The
fake Sun follows the real Sun along the same path (i.e. the ecliptic) but at
an angular distance of $30^{\circ}$. The fake Sun is therefore exposed to the
same celestial sources as the true Sun and the events observed in the frame
centered on the fake Sun make a good description of the diffuse background.
The model for the likelihood analysis is composed by two fixed components
(quiet Sun and fake Sun) obtained in previous analysisquietSun moriond AIP
and the flaring Sun free component.

##  VI Results

At 20:14:42.77 UT on 02 November 2008, _Fermi_ -GBM triggered and located a
very soft and bright eventgcn . The event location was RA = 217.6 deg, Dec =
-15.7 deg ($\pm 1.1$ deg), in excellent agreement with the Sun location. The
time of the event coincides with the solar activity reported in GOES solar
reports (event 9790: onset at 20:12 UT, max at 20:15 UT, end at 20:17, B5.7
flare). This is the first GBM detection of a solar flare. _Fermi_ -GBM
triggered on a solar flare a second time at 19:37:46.39 UT on 28 October
2009gcn2 . LAT data have been selected in the energy range 100 MeV - 300 GeV,
according to the solar activity detected by GOES and RHESSI: no high energy
emission has been detected by the LAT for both events.

From August 2008 to August 2009 RHESSI has detected 200 flares with $>10^{5}$
counts. The highest energy band in which most of these flare have been
observed by RHESSI is 3-6 keV. Few flares ($<20$) have been observed in the
energy band 6-12 or 12-25 keV. Flares outside the LAT field of view and the
ones that occurred while the LAT was transiting in the SAA have been
discarded. As a result LAT data of 80 flares have been analysed and the upper
limit on the high energy ($>100\textnormal{ MeV}$) emission has been computed
for each of these flares. No significant emission has been detected.

The preliminary upper limit on the emission of the flaring Sun integrated over
one year of flares in LAT data is $5.67\cdot 10^{-7}\text{photons
cm}^{-2}\text{ s}^{-1}$. This value is derived from a cumulative analysis of
all the 80 flares with a time of six hour around each trigger time (one hour
before and five hours later), taking into account the quiet sun
componentquietSun2 . A more detailed analysis is in preparation.

##  VII Conclusions

Solar flare events have been searched in the first year of LAT data (August
2008 - August 2009). Up until now there is no evidence of high energy emission
from solar flares detected by the LAT, while the quiet Sun emission has been
detectedquietSun moriond AIP . However, the Sun is at the minimum of its
activity cycle and no intense flare has occurred. The solar activity is
expected to rise in the next months, reaching the maximum in 2012.

We will continue to monitor the active regions of the Sun and to improve our
analysis techniques, waiting for an intense flare detectable by the LAT.

###### Acknowledgements.

The _Fermi_ LAT Collaboration acknowledges support from a number of agencies
and institutes for both development and the operation of the LAT as well as
scientific data analysis. These include NASA and DOE in the United States,
CEA/Irfu and IN2P3/CNRS in France, ASI and INFN in Italy, MEXT, KEK, and JAXA
in Japan, and the K. A. Wallenberg Foundation, the Swedish Research Council
and the National Space Board in Sweden. Additional support from INAF in Italy
for science analysis during the operations phase is also gratefully
acknowledged. Work supported by Department of Energy contract DE-
AC03-76SF00515.

## References

  * (1) A. Abdo _et al._ , 2009, _Astroparticle Physics_ , Volume 32, Issue 3-4, p. 193-219.
  * (2) W. B. Atwood _et al._ , 2009, _The Astrophysical Journal_ , 697 1071.
  * (3) G. Share, R. Murphy, 2007, _GLAST FIRST SYMPOSIUM_ , AIP Conference Proceedings, 921.
  * (4) G. Share _et al._ , 2006, _BAAS_ , 38, 255.
  * (5) V.V. Grechnev, 2008, _Sol. Phys._ , 252, 149.
  * (6) G. Kanbach _et al._ , 1993, _A &AS_, 97, 349.
  * (7) L. Svalgaard, 2009, _RHESSI Science Nugget 99_.
  * (8) _Rhessi flare list_ , http://hesperia.gsfc.nasa.gov/hessidata/dbase/hessi_flare_list.txt.
  * (9) _Solar Monitor_ , http://www.solarmonitor.org/.
  * (10) http://iau-comm4.jpl.nasa.gov/access2ephs.html.
  * (11) E. Orlando _Fermi-LAT Observation of quiescent solar emission_ , proceedings of $31^{\text{st}}$ ICRC.
  * (12) M. Brigida, 2009, 44th Rencontres de Moriond Proceedings.
  * (13) N. Giglietto, 2009, AIP Conference Proceedings, 1112 238.
  * (14) C. Kouveliotou, _GCN Circular 8477_.
  * (15) P.N. Bath, _GCN Circular 10105_.
  * (16) E. Orlando _Fermi-LAT Observation of Quiescent Solar Emission_ , these proceedings.