arXiv subjects

Italo Santos

Publications and source records attributed to Italo Santos.

At least 19 recordsLinked to original sources

arXiv2026

Cognitive Debt in the GenAI Era - Listening to Practitioners' Voices on the Loss of Understanding

Fast-paced AI-assisted software development risks reducing developers' understanding of the systems they build. This growing gap between what the system does and what developers understand about it, described as ``cognitive debt'', is not new, but AI has exacerbated it. This has led to a recent surge in blog posts and online discussions, in which practitioners recognize and write about cognitive debt, and share their experiences well before academic studies can capture them. To understand their concerns and inform future research and practice, we conduct a grey literature review of 76 sources, focusing on how cognitive debt is conceptualized and manifests, its contributing factors, its consequences, and the practices to prevent, detect, and mitigate it. We find that cognitive debt can accumulate unnoticed behind working code and passing tests, particularly when developers accept AI-generated solutions without building understanding. Practitioners report consequences such as harder maintenance and debugging, fragmented knowledge in the team, and reduced productivity. They propose practices such as documenting design rationale, review-sized changes, comprehension gates, and knowledge-sharing rituals, along with signals like reliability metrics to detect it. Our findings give software teams a structured view of emerging practical approaches in AI-assisted development and stress the need to preserve human understanding alongside faster code production.

cs.SE↗

arXiv2026

Enjoying the Product but Not Joining the Builders: Investigating Why Students Don't Contribute to OSS

Open-source software (OSS) participation provides students with authentic exposure to collaborative, real-world software development, yet active contributions remain limited. This short paper presents an exploratory study of computing students' perceptions, knowledge, and experiences with OSS at the University of Hawai'i at Manoa. We administered a survey and analyzed 122 responses using both quantitative and qualitative methods. Students reported moderate OSS familiarity and frequent OSS use in coursework and personal projects, yet only 12.3% actively contributed and engagement with OSS communities was limited. Key barriers included skill gaps (72.89% of non-contributors), time constraints (59.81%), and codebase complexity (66.67% of contributors), often alongside imposter syndrome (36.45%). Students indicated that more time, mentorship, beginner-friendly issues, better onboarding/documentation, and curricular incentives (e.g., course credit) would most increase participation, while most reported their courses do not require or incentivize OSS contributions (58.20%). Grounded in a single institutional context, this study provides a nuanced understanding of how curriculum structure, faculty encouragement, and competing academic demands shape OSS participation. These insights inform the design of targeted curricular and institutional interventions aimed at supporting student onboarding and participation in OSS communities.

cs.SE↗

arXiv2026

Extending LLM-based support for software engineers with ADHD

Software engineering workflows are often not designed to accommodate the needs of developers with Attention Deficit Hyperactivity Disorder (ADHD), despite known challenges related to task initiation, sustained attention, and completion. At the same time, large language models (LLMs) are increasingly integrated into programming tools, but existing systems do not account for neurodiversity or support structured progression across development tasks. In this work, we present Tether 2.0, an LLM based assistant designed to support software engineers with ADHD through workflow oriented interaction across planning, coding, debugging, and review. The tool was named Tether 2.0 because it builds upon the open source code and foundations of the original Tether system. Our approach combines structured interaction modes, activity aware context, and persistent memory to support task progression and continuity. We evaluate the system through expert feedback and hands on use with a software engineer with ADHD. Our results indicate that Tether 2.0 supports requirement clarification, task decomposition, incremental implementation, debugging, and completion, while enabling users to maintain progress and resume work after interruptions. These findings suggest that LLM based assistants can support direction, sustained progress, and learning in software development when designed with workflow structure and context aware interaction.

cs.SE↗

arXiv2026

Technostress in the Age of AI: A Preliminary Study with Software Professionals

The rapid adoption and evolution of AI are changing software engineering work and requiring professionals to repeatedly adapt their knowledge, practices, and skills. Although technological adaptation has long characterized software development, less is known about how these new and recurring pressures manifest as technostress. This preliminary exploratory study investigates AI related technostress among software professionals. We conducted a survey and performed a thematic analysis of responses from 121 software professionals across 26 countries reporting their recent experiences with AI at work. Our findings suggest that AI related technostress emerges not only from adapting to rapidly changing technologies, but also from having to manage the work, technical responsibilities, and professional changes that accompany their adoption. This characterization shows that AI introduces pressures beyond learning and using new tools, affecting how software professionals perform and remain accountable for technical work and how they prepare for the future of their careers.

cs.SE↗

arXiv2026

Software Project Management with LLM-Based Automation: Coordination, Validation, and Governance in Practice

As software engineering has evolved, development environments have increasingly integrated automated support for tasks such as testing, analysis, and code generation, requiring project management to coordinate both human work and automated workflows. In this paper, we investigate how software project managers perceive changes in their work and learning demands associated with LLM-based automation. Motivated by a gap in software engineering research, which has largely focused on task-level and developer-centered uses of LLMs, we adopted an exploratory case study approach to capture managerial perspectives on automation in practice. Based on the experience of software project managers working in a large, multi-project software organization, our analysis indicates that LLM-based automation influences planning, estimation, coordination, monitoring, and governance activities rather than introducing new formal management practices. Participants described LLMs as becoming embedded in everyday project work, producing uneven effects on productivity, increasing the need for review and validation, and reducing visibility into task execution. These effects contribute to greater reliance on managerial judgment and coordination. Learning demands were perceived as experiential and incremental, centered on understanding LLM capabilities and limitations, critically assessing generated artifacts, and guiding responsible use within teams. The findings provide empirical evidence on how software project management work is adapted in contexts where LLM-based automation is integrated into ongoing software development practice.

cs.SE↗

arXiv2026

''You Can't Open an LLM With a Screwdriver'': The De-Democratization of Software

Claims that generative AI will soon write all of the code have led to predictions that programming is nearing its end. In this vision paper, we argue against this assumption that broader access to code generation necessarily democratizes software development, i.e., everyone can code but we have to distinguish between access and control: by access, we mean the ability of more people, including non-experts and less-experienced developers, to generate code-like artifacts with AI; by control, we mean the capacity to inspect, evaluate, integrate, maintain, and govern those artifacts as dependable software. While AI may broaden access to code production, control may become more concentrated among those who own or understand the code, software practices, infrastructure, evaluation practices, and deployment pipelines. Grounded in an expert panel, our vision paper argues that AI does not eliminate software engineering expertise but shifts where that expertise becomes most critical. The locus of software engineering expertise is shifting toward intent specification: orchestrating and governing AI behavior, evaluating software behavior, and integrating software systems. We conclude this paper by identifying research opportunities for education, tools, and policy that can help the software engineering community respond to the AI era with greater agency, accountability, and adaptability.

cs.SE↗

arXiv2026

Exploring Quantum Software Testing Across Research and Practice: Emerging Results from a Multivocal Literature Review

This paper presents preliminary findings from a multivocal literature review investigating how quantum software testing is characterized across academic and practitioner-oriented sources. Our study integrated peer-reviewed studies with gray literature, including blogs, tutorials, forums, technical reports, documentation pages, and company webpages. Our results indicate a rapidly evolving but fragmented ecosystem involving classical adapted testing approaches, quantum-specific techniques, statistical validation methods, simulators, debugging environments, and verification frameworks. The reviewed material also revealed recurring challenges related to scalability limitations, hardware noise, probabilistic execution, limited observability, and immature tooling ecosystems. These findings provide an initial characterization of how research and practice currently discuss quantum software testing challenges, techniques, and tooling.

cs.SE↗

arXiv2026

Understanding LLM Usage Among Early-Career Software Engineers in Practice

Despite the rapid adoption of Large Language Models in professional software engineering, limited research has investigated how early career professionals develop effective AI assisted work practices during their transition into industry. We report findings from a mixed methods survey with 75 novice software engineers who actively use LLM supported tools in their daily work. Our results show that LLMs are embedded in routine software engineering activities, including coding, debugging, testing, documentation, and problem solving. Effective use depends on traditional software engineering competencies, such as debugging, testing, and architectural reasoning, together with critical thinking, output verification, prompt engineering, and continuous human oversight. We also identify a gap between workplace expectations and university preparation, with most participants reporting limited formal education on practical LLM use. These findings have implications for software engineering education, organizational onboarding, and workforce development in AI assisted software engineering.

cs.SE↗

arXiv2026

Exploring Dependence, Overreliance, and Addiction Related Behaviors Associated with Large Language Model Use Among Software Engineers

The widespread adoption of Large Language Models (LLMs) has changed how software engineers perform everyday development activities. While these systems provide substantial support for tasks such as code generation, debugging, and documentation, their increasing integration into professional workflows has also raised questions regarding developers' reliance on these tools and the emergence of dependence, overreliance, and addiction-related behaviors. This study investigates how software engineers experience the use of LLMs during professional software development, with attention to behavioral patterns associated with dependence, overreliance, and addiction-related behaviors. An exploratory survey was conducted with 119 software practitioners. The data were analyzed using descriptive statistics and qualitative thematic analysis of participants' open-ended responses. Participants primarily described functional dependence, with LLMs becoming integrated into routine software engineering activities because of the productivity and efficiency they provide. Responses also suggested patterns consistent with overreliance, particularly through prioritizing LLMs over documentation or peer consultation while continuing to verify generated outputs. Reports associated with addiction-related behaviors were less common and primarily reflected difficulty moderating use or emotional attachment to the technology rather than impaired control. The findings suggest that LLMs are becoming a habitual component of professional software engineering practice. While most reported use appears functional, the results indicate the importance of promoting appropriate reliance by supporting trust calibration, professional judgment, and verification throughout software development.

cs.SE↗

arXiv2026

How Many Interviews Are Enough in a Software Engineering Study? Preliminary Findings on Sample Size and Saturation

Background. Interview based studies are widely used in empirical software engineering to investigate human, organizational, and socio technical phenomena, yet interview sample adequacy and saturation are reported inconsistently across the literature. Aims. This paper investigates how interview sample adequacy and saturation are operationalized in empirical software engineering research. Method. We analyzed papers published between 2016 and 2025 across major software engineering venues, focusing on interview sample sizes, saturation discussions, and sample adequacy justifications. Results. Preliminary findings indicate substantial variation in sample sizes, from highly specialized small sample studies to broader investigations involving large interview datasets. Studies involving fewer than 12 interviewees were common and frequently associated with specialized industrial contexts or constrained organizational access. However, the most recurrent range was 13 to 24 interviewees, suggesting that moderate sized samples represent the most common configuration in empirical software engineering research. Saturation and sample adequacy justification were heterogeneous, with many studies relying on implicit or contextual reasoning rather than explicit methodological discussion. Conclusions. Our findings provide initial empirical insights into methodological reporting practices in interview based software engineering research and contribute to ongoing discussions regarding qualitative rigor and transparency.

cs.SE↗

arXiv2026

The Influence of Fraudulent AI-Generated Responses on Software Engineering Surveys

Background: Large Language Models (LLMs) introduce new concerns regarding fraudulent or AI assisted participation in software engineering surveys. Aims: This study investigates how suspicious or potentially AI assisted responses may affect the validity of software engineering survey findings. Method: We conducted a secondary analysis of four software engineering survey datasets using manual identification of suspicious responses, automated AI generated text detection, descriptive statistical analysis, and thematic analysis. We compared findings obtained from the original and manually cleaned datasets. Results: Quantitative findings generally remained stable after filtering suspicious responses, although some demographic and analytical variables showed moderate variation, affecting the interpretation of specific participant groups and contextual characteristics. In contrast, qualitative findings were more strongly influenced by changes in contextual framing, code prominence, and the nature of the evidence supporting interpretation, shaping how participants' experiences and study contexts were interpreted and characterized. Conclusions: AI assisted participation may influence software engineering survey findings differently depending on the type of analysis being conducted. The findings reinforce the importance of combining multiple validation procedures, particularly in studies relying on open ended responses.

cs.SE↗

arXiv2026

From Generic to Personalized: Exploring Persona-Aware Code Review Explanations

Code review is essential for ensuring software quality and supporting collaboration, yet prior work shows that developers can interpret code review comments differently. These differences can hinder effective communication, particularly in collaborative settings. To address this challenge, we explore the potential of personified code review explanations. We report initial findings from an ongoing mixed-methods user study in which developers evaluated persona-aligned review comments across multiple code snippets. Our results suggest that preferences for explanation styles vary across problem-solving styles, experience levels, and roles. Across problem-solving style profiles, developers valued explanatory depth, learning support, practical suggestions, and risk awareness over conciseness, highlighting the need to balance personalization with clarity and trust. Based on these findings, we outline a vision for inclusive, human-centered AI-assisted code review systems that adapt feedback to developers' problem-solving preferences.

cs.SE↗

arXiv2026

How Software Engineering Students Use LLMs to Write Research Papers: An Experience Report

Large language models are increasingly becoming part of software engineering education, including activities involving empirical software engineering and evidence synthesis. This paper reports an educational experience involving the integration of reflective LLM use into an empirical methods assignment in a third-year software architecture course. Students were asked to develop a short research paper using either a rapid review or a gray literature review methodology and to disclose how LLMs were used throughout the assignment. We analyzed 146 student disclosure statements using a cross-analysis process combining LLM-assisted categorization with manual verification and refinement by the researchers. The reflections describe how students incorporated LLMs during activities such as brainstorming, methodological clarification, organization of findings, and writing refinement, while also reporting concerns regarding inaccuracies and verification of generated content. This experience report discusses lessons learned and educational implications for integrating AI-assisted technologies into empirical software engineering education.

cs.SE↗

arXiv2026

Academic Integrity and Emotional Responses to Inappropriate LLM Use in Software Engineering Education

Academic integrity in higher education is increasingly shaped by complex socio-technical environments marked by automated tools, evolving institutional practices, and heightened performance pressures. Within this context, large language models (LLMs) are becoming prevalent in software engineering education, further blurring boundaries around acceptable assistance and authorship. This study investigates how software engineering students describe their emotional experiences after using LLMs in ways they perceive as academically inappropriate. We conducted a cross-sectional survey with 116 undergraduate students. Results show emotionally heterogeneous responses. Indifference was most frequent, including among students who recognized risks to learning and academic standing. Guilt and anxiety were reported in relation to moral discomfort and concern about penalties. Relief and satisfaction were evident primarily in deadline-driven contexts and situations of unclear guidance.

cs.SE↗

arXiv2026

SLRMentor: An LLM-Based Tool Supporting Learning of SLR in Software Engineering

This paper presents SLRMentor, a conversational assistant designed to support both learning about the systematic literature review process and the execution of planning activities in software engineering. The tool offers general guidance on SLR methodology and supports key planning tasks, including search string construction and reasoning about inclusion and exclusion criteria, with explanations grounded in established SLR guidelines. A pilot validation with graduate students suggests that SLRMentor helps clarify the SLR process and planning decisions, lowers initial barriers for novice researchers, and supports learning while still requiring active methodological judgment.

cs.SE↗

arXiv2026

Teaching Empathy in Software Engineering Education in the Age of Artificial Intelligence

Empathy has been discussed as a relevant human capability in software engineering, particularly in activities that require understanding users, stakeholders, and the societal implications of technological systems. This relevance becomes more pronounced in the context of artificial intelligence, where software increasingly participates in decisions that affect diverse individuals and communities. However, limited guidance exists on how empathy can be integrated into technical software engineering education in ways that connect with the development of AI-enabled systems. This study investigates teaching practices that educators use to incorporate empathy into software engineering courses. Using qualitative analysis of educator-reported practices, we identified five categories through which empathy is operationalized within technical coursework: societal framing of AI systems, fairness and accessibility considerations in design and evaluation, representation of diverse users, stakeholder role awareness and responsibility, and structured reflection and feedback during development processes. The findings indicate that empathy can be embedded within core development activities rather than taught as a separate topic, enabling students to reason about bias, accessibility, accountability, and the societal consequences of AI technologies. These results contribute a structured view of how empathy-oriented practices can be incorporated into software engineering education to support the preparation of students who will develop AI-enabled systems.

cs.CY↗

arXiv2026

LLM Use, Cheating, and Academic Integrity in Software Engineering Education

Background: Cheating in university education is commonly described as context dependent and influenced by assessment design, institutional norms, and student interpretation. In software engineering education, programming oriented coursework has historically involved ambiguity around collaboration, reuse, and external assistance. Recently, large language models (LLMs) have introduced additional mediation in the production of code and related artifacts. Aims: This study investigates how software engineering students describe experiences of using LLMs in ways they perceived as inappropriate, disallowed, or misaligned with course expectations. Method: A cross sectional survey was conducted with 116 undergraduate software engineering students from multiple countries, combining quantitative summaries with qualitative data. Results: Reported LLM cheating practices occurred primarily in programming assignments, routine coursework, and documentation tasks, often in contexts of time pressure and unclear guidance. Use during quizzes and exams was less frequent and more consistently identified as a violation. Students reported awareness of academic and professional consequences regarding LLM cheating, while formal sanctions were perceived as limited. Conclusions: Our study indicates that reported LLM misuse in software engineering is associated with assessment and instructional conditions, suggesting a need for clearer alignment between assessment design, learning objectives, and expectations for LLM use.

cs.CY↗

arXiv2026

Team Diversity Promotes Software Fairness: An Experiment on Fairness-Aware Requirements Prioritization

\textbf{Background:} Fairness and diversity are receiving growing attention in software engineering, particularly as AI and machine learning systems increasingly influence decision-making processes. While fairness is often examined at the algorithmic or data level, there is limited understanding of how it is addressed during the early stages of software development. Moreover, little is known about how team diversity affects fairness-related decisions in software projects. \textbf{Aims:} This study investigates how diversity in software teams influences fairness-aware behavior during requirements prioritization. \textbf{Method:} A controlled experiment was conducted with 27 pairs of software engineering students, including 13 LGBTQ diverse pairs and 14 non diverse pairs. Each pair prioritized user stories with varying fairness implications. Descriptive statistics were used to analyze attitudes and prioritization outcomes, and thematic analysis was applied to examine the reasoning behind participants' decisions. \textbf{Results:} Both groups demonstrated general alignment with fairness principles, prioritizing features that promoted equitable treatment and rejecting those that posed fairness risks. However, LGBTQ diverse pairs were more consistent in rejecting fairness risking stories and made fewer fairness related misprioritization errors. Their reasoning emphasized inclusion, non discrimination, and ethical responsibility, whereas non diverse pairs adopted a more pragmatic, goal oriented perspective. \textbf{Conclusions:} The findings indicate that fairness should be considered from the earliest stages of software development. Team diversity can enhance the identification and interpretation of fairness issues during requirements analysis, fostering more reflective and inclusive decision making.

cs.SE↗