SearcharxivSearch

arXiv subjects

George Digkas

Publications and source records attributed to George Digkas.

3 recordsLinked to original sources

When Friction Helps: Transaction Confirmation Improves Decision Quality in Blockchain Interactions

In blockchain applications, transaction confirmation is often treated as usability friction to be minimized or removed. However, confirmation also marks the boundary between deliberation and irreversible commitment, suggesting it may play a functional role in human decision-making. To investigate this tension, we conducted an experiment using a blockchain-based Connect Four game with two interaction modes differing only in authorization flow: manual wallet confirmation (Confirmation Mode) versus auto-authorized delegation (Frictionless Mode). Although participants preferred Frictionless Mode and perceived better performance (N=109), objective performance was worse without confirmation in a counterbalanced deployment (Wave 2: win rate -11.8%, p=0.044; move quality -0.051, p=0.022). Analysis of canceled submissions suggests confirmation can enable pre-submission self-correction (N=66, p=0.005). These findings suggest that transaction confirmation can function as a cognitively meaningful checkpoint rather than mere usability friction, highlighting a trade-off between interaction smoothness and decision quality in irreversible blockchain interactions.

cs.HC

Bugdar: AI-Augmented Secure Code Review for GitHub Pull Requests

As software systems grow increasingly complex, ensuring security during development poses significant challenges. Traditional manual code audits are often expensive, time-intensive, and ill-suited for fast-paced workflows, while automated tools frequently suffer from high false-positive rates, limiting their reliability. To address these issues, we introduce Bugdar, an AI-augmented code review system that integrates seamlessly into GitHub pull requests, providing near real-time, context-aware vulnerability analysis. Bugdar leverages fine-tunable Large Language Models (LLMs) and Retrieval Augmented Generation (RAGs) to deliver project-specific, actionable feedback that aligns with each codebase's unique requirements and developer practices. Supporting multiple programming languages, including Solidity, Move, Rust, and Python, Bugdar demonstrates exceptional efficiency, processing an average of 56.4 seconds per pull request or 30 lines of code per second. This is significantly faster than manual reviews, which could take hours per pull request. By facilitating a proactive approach to secure coding, Bugdar reduces the reliance on manual reviews, accelerates development cycles, and enhances the security posture of software systems without compromising productivity.

cs.CR

Can Clean New Code reduce Technical Debt Density?

While technical debt grows in absolute numbers as software systems evolve over time, the density of technical debt (technical debt divided by lines of code) is reduced in some cases. This can be explained by either the application of refactorings or the development of new artifacts with limited Technical Debt. In this paper we explore the second explanation, by investigating the relation between the amount of Technical Debt in new code and the evolution of Technical Debt in the system. To this end, we compare the Technical Debt Density of new code with existing code, and we investigate which of the three major types of code changes (additions, deletions and modifications) is primarily responsible for changes in the evolution of Technical Debt density. Furthermore, we study whether there is a relation between code quality practices and the 'cleanness' of new code. To obtain the required data, we have performed a large-scale case study on twenty-seven open-source software projects by the Apache Software Foundation, analyzing 66,661 classes and 56,890 commits. The results suggest that writing "clean" (or at least "cleaner") new code can be an efficient strategy for reducing Technical Debt Density, and thus preventing software decay over time. The findings also suggest that projects adopting an explicit policy for quality improvement, e.g. through discussions on code quality in board meetings, are associated with a higher frequency of cleaner new code commits. Therefore, we champion the establishment of processes that monitor the density of Technical Debt of new code to control the accumulation of Technical Debt in a software system.

cs.SE