software project managers

Abstract: Generative AI and agentic coding are accelerating software development, leading to concerns about technical debt. But two less visible forms of debt, cognitive debt and intent debt, are emerging as key risks to software health. Cognitive debt is the absence or erosion of a team's shared understanding where no one can confidently explain how a system works or predict the impact of a change. Intent debt is the lack of clearly articulated goals, constraints, and rationale that explain what the system is for and guide how it should evolve. This paper presents Cognitive Tours, a tool designed to mitigate and repair cognitive and intent debt. Cognitive Tours is a web-based prototype for creating and following curated paths connecting user needs, design decisions, code, tests, and open questions. AI-assisted skills help audit existing waypoints and tours for possible problems or staleness and suggest candidates for new ones; humans decide what matters, verify relationships, and construct the narrative. This division of work deliberately preserves productive friction: the sensemaking involved in selecting, explaining, and revising a tour, which is intended to foster and share understanding. Our demonstration uses a tour of Cognitive Tours itself to introduce the tool and illustrate its design decisions and interaction mechanisms. A proposed evaluation agenda concludes the paper. A demo is available at https://cognitive-tours-demo.vercel.app/

Abstract: Modern issue tracking systems are used to log an issue and track it from its inception to closure. Issue reports with diverse discussions from stakeholders can be large and verbose, making them challenging to analyze quickly. Our developer interviews revealed that they struggled with the diverse information in issue reports and demanded automated techniques to classify and summarize information. We designed a tool, iSum (issue summarizer), that helps with the automatic classification and summarization of information types discussed in issue reports. The summarizer offers two views: 1. Developer View takes an issue report as input and outputs visualized summaries of information in the report. 2. Manager View takes a suite of all issue reports under a given software project as inputs and shows the prevalence and trends of different information types across the reports. We evaluated iSum through three studies. 1. In an empirical study over two benchmarks, iSum offers, on average, 11-13% higher F1-scores than state-of-the-art baselines to detect information types. 2. We conducted a user study in task-based setup with 30 developers to determine iSum's effectiveness in issue exploration scenarios. Results showed increased productivity and accuracy with iSum compared to manual inspection. 3. We assessed iSum's feasibility for development and management tasks. It proved useful to both developers and project managers for issue comprehension and trend monitoring.

Abstract: The Model Context Protocol (MCP) enables LLM agents to access external tools and data. Studying its software ecosystem requires connecting server interfaces, the projects that configure these servers, and their development activity. However, this information is scattered across directories, package registries, configuration files, and repository histories. We present MCP-Eco, a relational dataset that integrates these sources and links consumer configuration declarations to candidate server projects. Its frozen release contains 16,880,899 records across 19 Parquet tables, covering 78,302 candidate server projects, 16,165 candidate consuming repositories, and 9,200 configuration declarations. Of these declarations, 5,975 resolve to 5,138 distinct repository-server pairs. The dataset also includes tool, resource, and prompt descriptions, declared dependencies, and associated development records, including pull requests, reviews, issues, and commits. Provenance fields distinguish directory-reported capabilities from those observed through live probing and document discovery sources and declaration-matching methods. These connections support research on MCP interface design, configuration practices, and repository maintenance, while enabling practitioners to inspect tool schemas and existing integration configurations. The dataset and accompanying analysis scripts are publicly available at https://huggingface.co/datasets/mcp-research-alliance/mcp-ecosystem Demo video: https://www.youtube.com/watch?v=N7TqnNneSfU

Abstract: De-siloing can create groupthink; silos can prevent knowledge sharing and reduce research efficiency. The same tension appears in research systems built with large language model (LLM) agents, yet their organization is usually fixed by design. I propose treating laboratory structure and information sharing as experimental variables. I introduce Labtune, an open framework for bounded research workflows with user-selected laboratory organization, communication policy, model configuration and budget. Users can choose among six editable designs, from multidisciplinary silos and transdisciplinary teams to co-leaders, hub-and-spoke structures, flat co-labs and a single scientist. Information sharing can independently vary from none to high detail, with an optional channel for conditional abstractions called wisdom. Sharing is enforced by the controller at phase barriers rather than through unrestricted agent chat, while delegation does not create additional budget or permissions. Development evidence is separated from protected confirmation, and an optional multi-lab layer allows laboratories with different structures to exchange filtered information. Labtune is an idea and system-description paper, not a benchmark result. Its contribution is to make laboratory organization and information sharing configurable and measurable under matched budgets. I do not claim that one design or level of sharing is best; the aim is to create a concrete experimental space in which those differences can be tested.

Abstract: A companion line of work audited individual cognitive-architecture LLM systems in depth and found that module names and module computations are empirically independent claims. This paper asks how far that gap extends across the system class. We pre-registered a census protocol (sample frame, metrics, and acceptance criteria frozen before any sample was downloaded) and surveyed the 59 most-starred Python repositories declaring cognitive architecture on GitHub, plus five classic architectures as a historical control. We measure a testability gap. First, an auditability gap: 22% of repositories document no code reference whatsoever. Second, an integrity gap: 42% of repositories have at least one dangling reference, and within that subgroup the median fraction is 8%, the top quartile 19.6%, and the maximum 79.5%; one 148-star system documents paths of which a majority do not exist. Three of four pre-registered hypotheses were falsified: the integrity gap is not universal (58% of repositories either offer no checkable references or offer references that all resolve); claim density does not predict dangling rate (rho = -0.10); and the classical-architecture control does not significantly outperform (p = 0.059 with five controls, all at zero dangling). Exactly one repository in 59 (1.7%) ships executable falsification criteria for its own claims. A second pre-registered round classified every dangling path by git lifetime: 85.5% of dangling references (159 of 186) are ghosts - paths that never existed at any commit - against 14.5% that were once real and later removed.

Abstract: Research on requirements-to-code tasks needs examples in which a genuine requirement is paired with the change that implemented it. Existing user-story collections, however, largely contain isolated or synthetic text. To address this limitation, we present STORY2DIFF, a dataset of 7,785 English user stories linked to merged pull requests from January 2017 to July 2026. The dataset is mined from a set of 982 public Java and Python repositories. Each record in the dataset combines the original issue, extracted Connextra elements, the associated pull request and commit metadata, a file-level diff capturing the code changes introduced by the associated pull request, and the affected files before and after the change. The tool we built to mine STORY2DIFF can be used to repeat the automatic extraction of the records, using different parameters (e.g., a different timeframe). The dataset can support a variety of tasks, including requirement discovery, traceability, change- impact estimation, and requirements-aware code generation. Dataset: https://github.com/riganelli/user-story-mining-pipeline/ releases/tag/V4.0.1. Video: https://youtu.be/qOhXUeyeiTQ.

Abstract: Microservice architectures aim to localize change, yet feature requests may require implementation across service boundaries. We investigate how well such downstream scope can be anticipated before implementation begins. Using issue--pull-request--commit traceability and implementation evidence corrected through targeted human adjudication, we reconstruct 866 repository-traceable feature requests from 13 open-source microservice projects and map their implementations to validated service boundaries. Cross-service changes occur in 101 requests (11.7%) and exhibit broader implementation footprints, particularly higher code churn, but no clear difference in lead time. Pre-implementation evidence provides limited cross-project predictive signal: the strongest leave-one-system-out model reaches a project-macro Macro-F1 of 0.484, but its advantage over the majority baseline is not significant after Holm correction and is sensitive to small evaluation folds. A local LLM offers no reliable improvement over classical models. Downstream workload is substantially harder to estimate, as learned models do not consistently outperform training-fold median baselines. A simple service-mention heuristic also performs comparably to learned scope triage. These findings show that early feature-request evidence is more useful for lightweight cross-service scope triage than for automated scope determination or precise workload estimation.

Abstract: Post-quantum cryptography (PQC) standards establish algorithms for quantum-safe systems, but empirical evidence about how software projects implement and maintain PQC support remains limited. We investigate this implementation and maintenance work by mining 114,361 commits and 5,713 issues across 179 open-source repositories. We use human annotation and validated LLM classification to identify PQC algorithms in commits, classify their adoption status and deployment mode, and identify technical challenges in issue discussions. The commit classification for PQC algorithms reveals that 90% of commits concern maintenance of existing support. From the issue discussions, we construct an 11-category taxonomy of recurring technical challenges. Build, packaging, and dependency failures, along with functional defects, account for approximately half of categorized issues. To examine how PQC support evolves, we use time-series analysis and first implementations of individual algorithms within repositories around NIST standardization milestones. After the 2024 finalization, standardized algorithm names appeared in more than 80% of the PQC development changes analyzed, although earlier names such as Kyber continued to appear. Development activity increased over the observation period. Our milestone analysis, however, did not find a significant increase in first implementations. Migration plans should therefore account for sustained maintenance, prioritize build reliability and integration testing, and track both standardized and predecessor algorithm names. We make the dataset, taxonomy, annotations, and analysis pipeline publicly available.

Abstract: Commit messages provide records of code changes and help developers understand and maintain software. To reduce the manual effort involved in writing them, commit message generation (CMG) approaches automatically generate commit messages that describe code changes in natural language. Existing CMG approaches generally treat CMG as a standalone task and optimize generated messages primarily for similarity to developer-written references. However, this objective may not properly reflect the practical usefulness of generated commit messages. This limitation matters in current AI-assisted software engineering workflows, where commit messages are used as shared information to serve different software engineering activities. To fill this gap, we propose TraceMsg, which uses issue-commit traceability, a representative software engineering activity, to guide commit message generation. TraceMsg is a collaborative multi-agent framework that coordinates message generation, traceability reasoning, and feedback-guided refinement, allowing generated messages to serve traceability while using reasoning feedback to guide issue-conditioned refinement. We evaluate TraceMsg on six open-source projects. The experimental results show that TraceMsg achieves an average Hit@1 of 0.893 and an MRR of 0.911, improving Hit@1 and MRR by 13.16% and 38.75%, respectively, over the best baseline for each metric.

Abstract: With the emergence of specification-driven development (SDD), software modeling has regained strategic importance as a way to translate human intentions, requirements, and design decisions into precise specifications that can guide both developers and AI-assisted development tools. Despite the renewed relevance of modeling in SDD, empirical evidence remains limited on when its benefits outweigh the socio-technical effort required to create, communicate, synchronize, and maintain software models in industrial practice. This study investigates when software modeling generates value in industrial practice. We analyzed 405 survey responses collected from software practitioners. The questionnaire combined closed items concerning UML use, benefits, barriers, and improvement mechanisms with open-ended questions about current use, difficulties, and worthwhile contexts. Most respondents associated modeling with integration discussions (90 percent) and shared understanding (82 percent), but also reported time pressure (85 percent) and the effort required to create and maintain models (80 percent). Selective modeling, model-code synchronization, and collaborative support emerged as conditions that improve its viability, whereas only 24 percent reported daily UML use. Software modeling pays off when its expected contextual value exceeds the socio-technical friction required to create and sustain it. Its value is therefore contingent, not universal.

Abstract: Can AI make Software Engineering (SE) -- the discipline -- obsolete? And can it make software engineers -- the professionals -- redundant? This paper argues that the rise of capable AI coding agents makes SE and software engineers essential, not obsolete: the missing foundation without which AI-assisted development produces misleadingly plausible, unverifiable, and ultimately untrustworthy software. Three structural properties of large language models (probabilistic generation, agnosticism, and semantic statelessness) create a structural vacuum that no amount of training can eliminate. Filling it requires four knowledge levers: methodological knowledge, domain knowledge, design choices, and process choices. All four must be reified as persistent artifacts, and each requires the software engineer as methodologist, mediator, and custodian.

Abstract: One practitioner we interviewed said their team writes "must" instead of "should" when instructing a coding agent, because the agent may treat "should" as optional. Small wording choices matter because agents often fill gaps in their instructions with their own assumptions. Spec-driven development (SDD) asks developers to write a specification, plan, and tasks before the agent writes code. SDD frameworks provide templates for these artifacts, but the templates do not help developers judge whether they have written enough or clearly enough. We studied what good SDD specifications contain. We scored the artifacts of 114 open-source SDD repositories against ISO/IEC/IEEE 29148 and derived practices from the highest-scoring ones. The resulting framework, EPIC, has 40 practices in 10 quality dimensions that guide developers in making expectations and decisions explicit in specifications, plans, and tasks for coding agents. The majority of SDD practitioners (N=15) endorsed every practice. Repositories in the top third of specification quality spent 11.8% of their commits on bug fixes, compared with 20.4% in the bottom third, and had a median of 4x as many contributors. Developers can use EPIC to find and fill the gaps in a specification before the agent does.

Abstract: Context. Agentic software engineering requires mechanisms to coordinate and govern agents' work. The framework motivating this study proposes a methodological harness with eight mechanisms: context engineering, persistent shared knowledge, executable specifications, N-version mindset and parallel agents, normative specifications, structured consultation, evidence-based acceptance, and graduated autonomy. These are realized through artifacts such as rule or context files, specifications, and architectural decision records, but the framework had not been empirically validated at repository scale. Objective. We analyze to what extent and how this harness is observable in repositories with agentic activity. RQ1 characterizes adoption through artifact prevalence, breadth, co-occurrence, and temporal evolution; RQ2 examines rule files - a key observable artifact and persistent source of agent instructions - to assess how their content reflects the proposed mechanisms. Method. From the AIDev dataset of 116,211 GitHub repositories, we analyzed 5,435 using a design stratified by visibility, measured through stars as an indicator of popularity and/or reputation. For RQ1, we detected and quantified artifacts and introduction dates for the seven observable mechanisms. For RQ2, we qualitatively coded rule files from 150 repositories. Results. Population prevalence of at least one mechanism is 21.7%, versus 65.3% among the most visible repositories. Multi-mechanism configurations are rare. Where rule files exist, they almost always guide the agent and state norms, while persistent shared knowledge, executable specifications, structured consultation, and graduated autonomy appear only in a minority. Conclusions. The harness is empirically observable, but mainly through isolated mechanisms rather than the integrated system proposed by the framework.

Abstract: Expert-driven Bayesian networks can support recurring software decisions when historical data are limited, but quantifying their conditional probability tables (CPTs) requires many probability judgments. Semi-automatic methods reduce direct elicitation, yet practitioners have little comparative evidence from operational decision processes. We report an embedded case study comparing the Weighted Sum Algorithm (WSA) and Ranked Nodes Method (RNM) as complete elicitation-and-quantification pipelines in two contexts within a single software research and development (R&D) organization: feature selection for Internet of Things projects and user interface design selection. Within each context, the pipelines shared the graph, root priors, and decision evidence. We evaluated them through 15 expert-defined model-walkthrough scenarios and retrospective reconstructions of alternatives recorded in decision meetings. WSA matched 7/7 and 6/8 walkthrough expectations, whereas RNM matched 4/7 and 4/8. Both pipelines placed the selected alternatives near the top of the retrospective rankings. Their complete distributions nevertheless differed: the median total variation distance was 0.304 across four distinct feature patterns and 0.340 across seven distinct design patterns, rising to 0.890 for one design pattern. These results concern two ordinal value-estimation models in one organization. They show that similar shortlist behavior does not imply equivalent representations of uncertainty. For comparable software decision-support models, method selection and validation should consider node semantics, the judgments experts can provide, calibration requirements, complete output distributions, and the intended downstream use of the probabilities.

Abstract: AI coding agents increasingly support software development beyond code completion, including planning, implementation, testing, and repository-level task execution. Their practical use, however, often remains only weakly connected to established software engineering practices. The aim of this work is to develop and evaluate a lightweight, spec-driven lifecycle for governed agentic software engineering. The lifecycle combines established software engineering practices with repository-local guidance through specifications, AGENTS.md, and phase-specific agent skill files. The approach was developed in the context of the FHNW course AI-assisted Software Development and applied by students to business-oriented software use cases. Its educational and practical applicability is explored through a student survey combining closed rating items with open-ended questions. The contribution of this work is a process-oriented framework that enables AI coding agents to operate with bounded autonomy within an explicit, reviewable, and test-oriented software development lifecycle.

Abstract: Cross-platform mobile frameworks promise code reuse, shorter delivery cycles, and lower implementation effort, but their trade-offs relative to native development remain difficult to assess objectively. Many comparisons rely on simplified applications, inconsistent feature sets, or a narrow set of metrics. This paper compares five implementations of the same plant-management application: native iOS, native Android, Flutter, React Native, and Kotlin Multiplatform. The shared approaches target both Android and iOS, yielding eight executable variants. Guided by ISO/IEC 25010, the study examines time behavior, implementation footprint, source-code organization, and observable rendering responsiveness. All implementations share the same domain, backend services, functional requirements, and benchmark contract. The supplied dataset contains 2,000 completed runs per variant and covers authenticated and cached retrieval, image transfer and decoding, list rendering and scrolling, local synchronization, and media upload. Backend preparation and framework-specific UI drivers are analyzed separately from the primary client workflow. Native records the lowest non-UI client subtotal on both operating systems, with Kotlin Multiplatform the closest cross-platform implementation, while operation and UI-wrapper rankings vary by task. The shared approaches contain less authored mobile source than the native applications combined, and the source inventory shows different patterns of file size, organization, and dependency use. Rather than identifying a universally superior technology, the study shows that each approach's advantages and costs depend on the quality attribute, workload, platform, and measurement boundary.

Abstract: Background: Code quality metrics are intended to measure latent properties of software source code. Although numerous code metrics have been proposed and used, their construct validity is rarely evaluated. Thus, the extent to which code metrics actually measure what they claim to measure is often unclear. Aim: Drawing from modern measurement theory, we investigate the construct validity of common class-level, object-oriented code quality metrics by identifying their factor structure using Exploratory Factor Analysis (EFA). The metrics were extracted from the Apache Maven project by three software tools: Designite, JHawk, and Understand. The factor structure was later verified using Confirmatory Factor Analysis (CFA) on 22 randomly selected open source projects meeting a predetermined eligibility criteria. Results: 24 code quality metrics that correspond to six constructs: Cohesion, In-Coupling, Out-Coupling, Size, Sub-Inheritance (related to subclasses), and Sup-Inheritance (related to superclasses) were revealed in the underlying factor structure. Ten metrics did not correspond to any known dimension of software quality and were removed in the EFA. Ten additional metrics exhibited low loadings in the CFA, suggesting their removal from the final measurement model. Size, Cohesion, Inheritance, and Coupling were the constructs retained, with subcategories identified for Inheritance and Coupling. Conclusions: Our results strongly support the construct validity of 24 code quality metrics. Coupling and Inheritance are revealed as multidimensional constructs, since they require measuring two different concepts, revealed as sub-categories in our analysis, and Complexity may be better explored in a multilevel model. Overall, our study demonstrates the value of applying modern measurement theory and latent variable modeling in validating software code quality metrics.

Abstract: Human-centric AI for software engineering means keeping humans responsible for work performed with AI. In Open Source Software (OSS), AI lowers the cost of implementing changes, but reviewing someone else's contribution remains comparatively expensive, so some projects now restrict who may contribute implementations while still welcoming other participation---not because the code is AI-generated, but because it no longer justifies the review cost. We call the resulting form a stewardship community: a small core retains implementation authority while a broader community continues to shape the software without writing code, and access to coding increasingly depends on approval rather than self-initiated contribution. This raises a broader question: what happens to the human community when coding agents let maintainers replace implementation work once supplied by external contributors? For human-centric software engineering, keeping humans in control of AI agents is not enough: AI can replace implementation labor while weakening how OSS communities renew themselves.

Abstract: Architectural decision records (ADRs) have become a popular lightweight mechanism for documenting architectural knowledge in software projects. However, there is limited empirical evidence on the kinds of architectural concerns captured in ADRs and how well their contents align with established architectural knowledge concepts and documentation practices. In this paper, we propose an automated text-mining and classification approach for analyzing ADRs at scale. We apply this approach to a dataset of ADRs extracted from ~550 open-source repositories, combining topic modeling, LLM-based classification, and template compliance checks. Our analysis examines decision taxonomies and quality attributes, and the degree to which ADRs adhere to the MADR template. Our findings show that ADRs frequently capture existence, technology, and process-related decisions, while alternatives, decisions drivers, and some quality concerns remain under-documented. We also observe recurring mismatches between ADR contents and template sections. These insights into current documentation practices provide architects with valuable information to reflect on how ADRs are and should be used to effectively deal with architectural knowledge. Furthermore, our automated approach is adaptable to other architectural tasks.