Deliberate Pacing for Human Oversight in Agentic Software Development

arXiv:2611.09550v1 [cs.SE] 6 Nov 2026

Deliberate Pacing for Human Oversight in Agentic Software Development Tobias Reichel

Michèle Stassen

Anamaria Mojica-Hanke

Heidelberg University Heidelberg, Germany tobias.reichel@uni-heidelberg.de

Eindhoven University of Technology Eindhoven, Netherlands m.a.stassen@student.tue.nl

University of Passau Passau, Germany anamaria.mojica-hanke@uni-passau.de

Maria Teresa Baldassarre

Sebastian Baltes

Alexander Serebrenik

University of Bari Bari, Italy mariateresa.baldassarre@uniba.it

Heidelberg University Heidelberg, Germany sebastian.baltes@uni-heidelberg.de

Eindhoven University of Technology Eindhoven, Netherlands a.serebrenik@tue.nl

Steffen Herbold University of Passau Passau, Germany steffen.herbold@uni-passau.de

Abstract—Agentic AI increasingly enables software development activities to proceed without continuous human involvement. While this autonomy may accelerate development, it also raises questions about when developers can meaningfully oversee software development done by agents. We propose deliberate pacing: intentionally adjusting when and how autonomous development proceeds to preserve opportunities for meaningful oversight. Drawing on an exploratory multivocal literature review of 20 sources, we identify three factors motivating this vision: changing relative costs of human involvement, the timing of oversight opportunities, and interdependencies between pacing decisions across the software development life cycle. We argue that neither uninterrupted autonomy nor frequent human intervention is universal. Instead, pacing should balance opportunities to understand and influence consequential decisions against costs in human attention, development time, and rework. We outline a research agenda to investigate when deliberate pacing is beneficial, how intervention timing affects oversight, and how pacing decisions interact across development activities. Index Terms—agentic AI, human oversight, software development processes, deliberate pacing.

I. I NTRODUCTION Contemporary software engineering approaches prioritize acceleration and adaptable processes, such as faster release cycles, more frequent feature releases, quicker review processes, and increased developer productivity [24], [31], [43]. Recent industry and research narratives frame AI as a means of further accelerating software development [12], [35]. Historically, many software development activities and decisions required direct human involvement, even as automation reduced the time needed for individual steps. AI agents can increasingly perform such activities without continuous human involvement, although their effects on development speed vary across studies. A controlled experiment reported large speedups

for an isolated programming task [37], while experienced open-source developers worked more slowly with AI tools on their own repositories [4]. A follow-up to the latter study found indications of a speedup instead, although the authors caution that changes in participant selection make the true effect difficult to measure [5]. Practitioners further argue that understanding, debugging, and modifying code, rather than writing it, are important bottlenecks that faster code generation does not necessarily resolve [20]. Whatever the exact productivity gains, agentic AI changes how development activities are performed by allowing agents to make and implement decisions while developers attend to other work. This shift raises concerns about development approaches prioritizing speed. Agentic AI enables substantial parts of a software system to be prototyped with limited human involvement, potentially allowing consequential decisions to be implemented before developers evaluate them. Studies report risks associated with AI-assisted development, including delivery stability [3] and security [13], [38]. These findings point to the importance of activities beyond code generation, such as design, problem analysis, compliance assurance, and critical evaluation of AI-generated artifacts [1], [25], [26], [44]. Studies of AI’s impact on the software development life cycle (SDLC) likewise emphasize continued human involvement in planning and testing [17]. However, human involvement does not necessarily ensure meaningful oversight. Developers must have sufficient information to understand relevant decisions and opportunities to influence them. Consider an agent that selects an architectural dependency and proceeds to implement the corresponding components and tests without requesting human input. By the time a developer reviews the results, several artifacts may

depend on that decision, and reconsidering it may require validating requirements, and understanding generated code may substantial rework. Intervening earlier could avoid such costs, account for a growing proportion of development effort. This but may also interrupt productive autonomous execution before does not necessarily make human involvement more expensive sufficient information is available for an informed decision. in absolute terms, but changes its relative cost compared Deciding where developers should intervene is therefore not to autonomous execution. Although developers have long enough. The timing also determines whether their involvement performed other work while automated tools execute, agentic AI can influence autonomous development. extends asynchronous execution to activities involving design In this paper, we distinguish between speed and pace. Speed and implementation decisions. Earlier research on code review is how quickly software is developed, measured as output per bots already illustrates that automating development activities unit of time. Pace is how that speed is distributed over time. can affect both throughput and developer communication [51]. We define deliberate pacing as intentionally adjusting when Deliberate pacing decisions must therefore consider not only and how autonomous development proceeds to create opportu- how much an intervention delays autonomous execution, nities for meaningful human oversight. Such adjustments may but also how much human attention it requires and what include pausing an agent before consequential decisions are opportunities for oversight it creates. implemented, postponing subsequent activities until a human Second, the timing of human involvement shapes opportunireview is completed, or changing when intermediate results ties for meaningful oversight. Developers have long delegated are presented for evaluation. Not all oversight requires slowing work to automated tools, but increasingly autonomous agents down autonomous execution. Developers may also monitor can also make decisions about requirements, design, impleongoing activities or review completed work asynchronously. mentation, and testing. Human involvement may consequently Whether deliberate pacing is beneficial therefore depends on shift from performing these activities to supervising, validating, the opportunities for oversight that creates relative to its costs or revising decisions made by agents. However, involving in time, human attention, and development throughput. a human does not necessarily ensure meaningful oversight: We present a vision of deliberate pacing as a means developers must have sufficient information to understand of preserving meaningful human oversight in agentic relevant decisions and the opportunity to influence them. In software development. Our central proposition is that the particular, reviewing an agent’s work after completion is not timing of human intervention matters: retrospective review may always equivalent to intervening before consequential decisions not provide the same opportunities to influence autonomous are implemented. Conversely, intervening too early may provide development as intervention before consequential decisions insufficient information for an informed decision. Deliberate are implemented. Drawing on a multivocal literature review pacing can create opportunities for oversight at moments when (MLR) of 20 sources on slowing down software development, developers have both sufficient information and the ability we examine three factors that motivate this vision: the changing to act upon it. Without such opportunities, teams may also relative costs of human involvement, the timing of opportunities accumulate cognitive and intent debt [47], as developers lose for meaningful oversight, and the interdependencies between shared understanding of the system or decisions diverge from pacing decisions across the SDLC. Rather than proposing the goals and constraints intended to guide development. universal checkpoints or advocating slower development as an Third, pacing decisions must be considered across the end in itself, we outline a research agenda for investigating entire SDLC. Meaningful oversight may be enabled through when, where, and how deliberate pacing enables meaningful different interventions at different stages of development, and oversight more effectively than uninterrupted autonomous their costs and benefits cannot always be assessed indepenexecution followed by retrospective evaluation. dently. For example, human validation of requirements may prevent misunderstandings from propagating into design and II. V ISION implementation, while independent validation of test oracles We argue that deliberate pacing preserves opportunities for may identify discrepancies between implemented behavior meaningful human oversight by determining when agents act and intended functionality. However, these interventions are autonomously and when human intervention is needed. Prior not necessarily interchangeable: Reviewing an implementation research shows that developers’ autonomy preferences vary with cannot always compensate for requirements that fail to reflect experience, motivating configurable autonomy [15]. Agentic stakeholder needs. Furthermore, delaying an intervention may AI adds a temporal dimension: not only how much autonomy allow autonomous agents to build subsequent decisions upon to grant, but when to interrupt it for human oversight. Three assumptions that have not yet been validated, potentially factors motivate our vision. increasing the cost of later corrections. Conversely, frequent First, agentic AI changes the relative costs and opportunities interruptions may impose unnecessary delays and coordination for human involvement. Traditionally, software development overhead without improving outcomes. We therefore argue required substantial human effort to produce artifacts, even that pacing decisions should be evaluated not only by their when developers relied on automated tools. Agentic AI can immediate costs and benefits, but also by how they affect prior perform increasingly complex development activities with and subsequent opportunities for meaningful oversight across limited human intervention, potentially reducing execution time the SDLC. considerably. Consequently, activities such as reviewing designs, Together, these factors motivate our vision of deliberate

asking whether a feature or piece of code is worth adding [16], [27], [40], [52]. Several grey literature sources in our MLR link slowing down to software craftsmanship. They argue that software craftsmanship requires careful thinking, focus, deliberate practice, and a deep understanding of the intended result [32], [40], [42]. None of the academic sources in our MLR mention slowing down as a core aspect of software craftsmanship, although it has been studied in academic work outside our sample, for example in a literature review by Sundelin et al. [48]. However, two sources note that rapid development is sometimes necessary or desirable [8], [28]. In rapidly changing environments such as dynamic markets, it III. F OUNDATIONS FOR D ELIBERATE PACING is essential for a company’s success to respond quickly to To inform our vision, we conducted an exploratory MLR improve its competitiveness [8], [28]. The goal shifts from of 20 sources (8 academic and 12 grey literature), following delivering quality to delivering sufficient quality on time to gain the guidelines of Garousi et al. [14]. Table I lists the search or keep a competitive advantage [28], but as a company grows terms we used in ACM Digital Library, IEEE Xplore, and and the product evolves, the quality should be incrementally Scopus. For the grey literature, we queried Google Search increased [8]. A quickly developed minimum viable product with “slow software development”, “slow programming move- can be used to test the market and confirm that there is demand. ment”, and “slow code movement”. We ran the search in an Afterwards, developers must take time to code with quality incognito browser window while logged out of Google to and maintenance in mind to minimize the previously accrued minimize personalization. We filtered the search results based technical debt and build a more reliable product [45]. on whether they helped answer our question: “Why and under A second recurring rationale for slowing down software which circumstances do individuals, teams, and organizations development is the long-term sustainability of software systems intentionally slow down in software development?” as well as software development practices. The underlying Through inductive thematic analysis, we identified five problem is an imbalance in how innovation and maintenance are recurring themes: slowing down for software quality, slowing valued [36], [39]. An uncritical focus on innovation overlooks down for long-term sustainability, slowing down for care what happens after innovation, and how much everyday society and ethics, slowing down as resistance to acceleration, and depends on stable, older technologies [36]. Due to the fast pace developing at an appropriate pace. The first three concern of innovation, developing with maintenance and longevity in motivations for slowing down, while the last two address the mind requires deliberately taking time. Another aspect of slowbroader questions of why speed is prioritized and how an ing down for sustainability is critically evaluating a project’s appropriate pace can be determined. dependencies so that fewer dependencies need to be kept up to date and unnecessary complexity is reduced [27], [39]. Crichton TABLE I discusses the need for a “slow code” movement toward stable S EARCH Q UERY FOR B IBLIOGRAPHIC DATABASES libraries and programming languages that preserve backward compatibility [10]. (“software development” OR “software engineering”) AND The theme of slowing down for care and ethics comes mainly ( (“slow food” OR “slow tourism” OR “slow travel” OR “citta slow” OR “cittaslow” OR “slow city” OR “slow housing” OR “slow living” OR “slow from Human-Computer Interaction (HCI) research, which has art” OR “slow cinema” OR “slow design” OR “slow journalism” OR “slow argued for slowing down design processes to create space education” OR “slow philosophy” OR “slow writing” OR “slow reading” OR “slow science” OR “slow research” OR “slow university” OR “slow work” OR for critical reflection, ethical deliberation, and community “slow management” OR “slow fashion” OR “slow consumption” OR “slow involvement [2], [19]. For example, a case study of communitytechnology”) OR centered design describes tensions between responding quickly (“mindful development” OR “mindful software” OR “deliberate development” OR “deliberate software” OR “reflective software” OR “reflective development” to urgent crises and taking time to build trust with community OR “thoughtful software” OR “reflective development”) AND (“speed” OR partners [19]. While rapid action may be necessary in urgent “slow” OR “fast” OR “rhythm” OR “pace” OR “temporal”) OR situations, excessively prioritizing speed can limit opportunities (“good enough software” OR “good enough development”) ) for reflection and sideline community perspectives [2], [19]. In this context, slowing down means creating time for reflection, Slower and more thoughtful software development, which discussion, and engagement with those affected by the system. is characterized by an emphasis on careful design and writing Lack of time within a project can lead to technical elements quality code, can contribute to software quality [50]. This being prioritized over ethical deliberation and can conflict with emphasis does not necessarily imply that extensive design up the time required for participatory community research [2]. front is needed [33]. Code can be rewritten and redesigned, Rapid iteration and market-driven pressures can further hinder as long as a developer pauses to think and takes the time to ethical considerations [34]. Meanwhile, prioritizing high-quality create something worth making [33]. An important part of standards over development speed can improve a development carefully thinking through solutions is reducing complexity by team’s ability to identify and address ethical concerns [34]. pacing as a means of enabling meaningful human oversight without unnecessarily sacrificing the benefits of autonomous development. Deliberate pacing may involve pausing an agent before consequential decisions are implemented or postponing subsequent activities until human evaluation is complete. However, meaningful oversight may also be achieved without slowing down autonomous execution, for example through asynchronous monitoring or retrospective review. The challenge is to determine when deliberate pacing offers benefits that cannot be achieved as effectively through uninterrupted autonomous execution.

Software security shows similar tensions [41], [49]. A project’s ability to maneuver depends on the available time, budget and competence, as well as the type of software project and stage of development. Under tight time constraints, security may be deprioritized, especially when security is viewed as a cost without real gain [49]. Sources in the theme of slowing down as resistance to acceleration question the assumption that delivery speed, developer productivity, and innovation are inherently desirable and asking why and for whom software is built. A recurring critique in the sources is that of Silicon Valley’s development culture, particularly Facebook’s slogan “move fast and break things” [46]. Halperin and McElroy [19] criticize the temporal logic of acceleration and instantaneity, which views time as a quantitative resource to optimize. Disruptive companies set the ideals against which software development is measured. However, in what Bialski calls “middle tech”, where software is more often maintained rather than developed as a disruptive innovation, a negotiated culture of “good enoughness” reconciles ideals of innovation with everyday compromise [6]. The sources also challenge growth-driven economic systems. Developers may not be able to restructure these systems, but they can change the processes that guide development [34], for example by incrementally improving code quality in a start-up [8], designing more slowly [50], or creating room for discussion and critical reflection [34]. Pargman and Wallsten [36] calls for questioning who benefits from new technologies and who is disadvantaged by them. The final theme, developing at an appropriate pace, addresses how teams meet the need to stay competitive and respond to urgent situations while still taking the time that quality, maintainability, ethical deliberation, and stakeholder engagement require. Developing at an appropriate pace means spending the time that is needed on the relevant dimensions given the context, problem, stakeholders, and aims of the project. What constitutes ‘sufficient’ time cannot be determined universally ahead of development as it is a situational decision that requires continuous negotiation [6]. Developing at an appropriate pace therefore involves moving between varying development speeds and balancing between care and compromise [6], urgency and care [19], and innovation and maintenance [36], [39]. Except from the sources that discuss AI coding, such as Zechner [52], the sources in our MLR assume that developers write the code themselves, so the time they take for reflection is also the time they spend producing the code. Agentic AI separates the two. An agent can implement a feature, add a dependency, or refactor a module quickly, while the reflection that our identified themes propose still takes human time. The questions that the sources raise remain relevant, such as whether a feature [16], [40], [52] or dependency is worth adding [10], [27], [39] or whose perspectives a design takes into account [2], [19]. With agents, however, developers need to ask these questions at points in the SDLC where they can still act on the answer. Developing at an appropriate pace then means deciding when an agent proceeds on its own and when it waits for human judgment.

IV. F UTURE P LANS To develop our vision into a full-length research contribution, we propose three research questions concerning deliberate pacing and meaningful human oversight in agentic software development. RQ1: When does meaningful human oversight benefit from deliberate pacing? Through developer interviews, recorded development sessions, and agent execution traces, we will examine when developers allow agents to proceed uninterrupted and when they introduce deliberate pauses for human evaluation. We will identify consequential decisions and assess whether interventions enable developers to recognize potential problems, question assumptions, and influence subsequent agent actions. We will also examine the costs of these interventions in human attention, development time, and avoided or incurred rework. These observations will help identify circumstances in which deliberate pacing offers benefits that justify its costs. RQ2: How does the timing of pacing interventions affect meaningful human oversight? We will compare different arrangements of human oversight, including continuous monitoring, deliberate pauses before consequential decisions are implemented, and retrospective review [11]. We will assess developers’ ability to identify, understand, and influence agent decisions, the emotions they experience [18] and express [9] during oversight, as well as the associated costs in human effort, development time, and subsequent rework. RQ3: How do pacing interventions across the SDLC interact in enabling meaningful human oversight? We will investigate how interventions in one development activity affect the need for and effectiveness of oversight in subsequent activities, including their combined costs and benefits. Since controlled experiments would require us to study different interventions and their interactions in a longitudinal manner across the whole SDLC, they are very high-effort and, therefore, only suitable to test approaches for which there is already evidence for their effectiveness. To address this, we will develop new research methods. On the one hand, we will explore quasiexperiments [23] as substitue for randomized control trials. Such experiments can combine data from software repositories with developer surveys to explain the underlying processes. On the other hand, simulation-based methods [21] will estimate how different pacing approaches interact. Together, these studies will provide empirical evidence on when deliberate pacing is warranted and inform principles for coordinating autonomous execution and meaningful human oversight across the SDLC. V. C ONCLUSION In this paper, we present a vision of deliberate pacing as a means of preserving meaningful human oversight in agentic software development. We motivate our vision by a MLR on slow software development. We identified five recurring themes in 20 sources (8 academic and 12 grey literature) such as slowing down for software quality, for long-term sustainability, care and ethics, as resistance to acceleration, and developing at an appropriate pace. We argue that agentic AI changes the

conditions under which speed, quality and human involvement must be balanced. Deliberate pacing should be assessed by how much an intervention delays the execution, how much human attention it requires, and what opportunities for human oversight it creates. Oversight requires that developers have sufficient information and can act on it at the moment of intervention. Finally, we argue that deliberate pacing decisions must be considered across the entire SDLC. A late intervention can cost more than an earlier intervention would have. In the future, we plan to research when human oversight benefits from deliberate pacing and how it is affected by the timing of the interventions. Additionally, we will investigate the impact of deliberate pacing across the SDLC by using new research methods which allow us to simulate these complex interactions between activities in the SDLC. The research community must not only focus on developing such slow and fast practices, but also live by them, since we shape future generations both through our research and through our roles in the academic education system. In the past, we have often made the mistake of not following the practices that we preach: we write about best practices without following them [30] and advocate for open science [7], [29], yet often do not make our resources available [22]. We should not repeat this mistake with the speed that AI seemingly offers. ACKNOWLEDGMENT Some of the ideas presented in this paper emerged from discussions during the Shonan Meeting No. 228, “Envisioning the Future of (eXtended Reality) Software Engineering.” We are grateful to the meeting organizers and participants for their insightful contributions and the fruitful discussions that helped shape this work. R EFERENCES [1] M. Barenkamp, J. Rebstadt, and O. Thomas, “Applications of AI in classical software engineering,” AI Perspect., vol. 2, no. 1, 2020. [2] M. Barry et al., “Temporal awareness and ethical reflection: Chronopolitical considerations for HCI research,” in Proc. ACM DIS, 2026. [3] M. Beane et al., “DORA state of AI-assisted software development 2025,” Google, Tech. Rep., 2025. [Online]. Available: https: //dora.dev/research/2025/dora-report/ [4] J. Becker et al., “Measuring the impact of early-2025 AI on experienced open-source developer productivity,” arXiv:2507.09089, 2025. [5] J. Becker et al., “We are changing our developer productivity experiment design,” https://metr.org/blog/2026-02-24-uplift-update/, 2026. [6] P. Bialski, Middle Tech: Software Work and the culture of good enough. Princeton University Press, 2024. [7] R. F. Boisvert, “Incentivizing reproducibility,” Commun. ACM, vol. 59, no. 10, 2016. [8] G. Booch, “Developing the future,” Commun. ACM, vol. 44, no. 3, 2001. [9] N. Cassee et al., “Negativity in self-admitted technical debt: how sentiment influences prioritization,” Empirical Software Engineering, vol. 30, no. 2, p. 54, 2025. [Online]. Available: https://doi.org/10.1007/ s10664-024-10611-z [10] D. Crichton. Programming as craft. [Online]. Available: https: //techcrunch.com/2018/02/24/programming-as-craft/ [11] S. Dhanorkar, S. Passi, and M. Vorvoreanu, “Human oversight of agentic systems in practice: Examining the oversight work, challenges, and heuristics of developers using software agents,” in Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency (FAccT 2026). ACM, 2026, pp. 6438–6465. [Online]. Available: https://doi.org/10.1145/3805689.3812402 [12] H. Fawareh and F. M. Alanazi, The Significance of AI Technologies to Enhance Productivity, Efficiency, and Software Quality Within the Software Development Process. Springer, 2026.

[13] Y. Fu et al., “Security weaknesses of Copilot-generated code in GitHub projects: An empirical study,” ACM Trans. Softw. Eng. Methodol., vol. 34, no. 8, 2025. [14] V. Garousi, M. Felderer, and M. V. Mäntylä, “Guidelines for including grey literature and conducting multivocal literature reviews in software engineering,” Inf. Softw. Technol., vol. 106, 2019. [15] A. Ghorbani et al., “Autonomy is an acquired taste: Exploring developer preferences for github bots,” in Proceedings of the 45th International Conference on Software Engineering (ICSE), 2023, pp. 1405–1417. [Online]. Available: https://doi.org/10.1109/ICSE48619.2023.00123 [16] S. Goedecke. The just-say-no engineer was a zirp phenomenon. [Online]. Available: https://www.seangoedecke.com/the-just-say-no-engineer-wasa-zirp-phenomenon/ [17] D. A. González-Rueda et al., “CMM-AISE: A cognitive maturity model for AI-assisted software engineering,” in Proc. IEEE ICSME, 2026. [18] D. Grassi et al., “Self-monitoring of developers’ emotions: The case of agile retrospective meetings,” ACM Transactions on Software Engineering and Methodology, vol. 35, no. 6, pp. 164:1–164:38, 2026. [Online]. Available: https://doi.org/10.1145/3766064 [19] B. A. Halperin and E. McElroy, “Temporal tensions in digital story mapping for housing justice: Rethinking time and technology in community-based design,” in Proc. ACM DIS, 2023. [20] Harsh, “AI is creating a new kind of tech debt — and nobody is talking about it,” https://dev.to/harsh2644/ai-is-creating-a-new-kind-of-techdebt-and-nobody-is-talking-about-it-3pm6, 2026. [21] S. Herbold, “What should a software team spend on agents? simulationbased cost optimization of mixed AI-human teams,” arXiv:2610.20394, 2026. [22] R. Heumüller et al., “Publish or perish, but do not forget your software artifacts,” Empir Software Eng, vol. 25, no. 6, 2020. [23] V. B. Kampenes et al., “A systematic review of quasi-experiments in software engineering,” Inf. Softw. Technol., vol. 51, no. 1, 2009. [24] G. Kudrjavets and A. Rastogi, “Does code review speed matter for practitioners?” Empirical Software Engineering, vol. 29, no. 1, p. 7, 2024. [Online]. Available: https://doi.org/10.1007/s10664-023-10401-z [25] H.-P. H. Lee et al., “The impact of generative AI on critical thinking: Self-reported reductions in cognitive effort and confidence effects from a survey of knowledge workers,” in Proc. ACM CHI, 2025. [26] J. T. Liang, C. Yang, and B. A. Myers, “A large-scale survey on the usability of AI programming assistants: Successes and challenges,” in Proc. ACM/IEEE ICSE, 2024. [27] D. Low. Nuggets #34: who’s checking the ingredients? [Online]. Available: https://www.linkedin.com/pulse/nuggets-34-whos-checkingingredients-david-low-zeose/ [28] W. Mellis, “Software quality management in turbulent times – are there alternatives to process oriented software quality management?” Softw. Qual. J., vol. 7, 1998. [29] D. Mendez et al., “Open science in software engineering,” in Contemporary empirical methods in software engineering, 2020. [30] A. Mojica-Hanke et al., “Perspective of software engineering researchers on machine learning practices regarding research, review, and education,” Empir Software Eng, vol. 32, no. 1, 2027. [31] M. V. Mäntylä et al., “On rapid releases and software testing: A case study and a semi-systematic literature review,” Empir Software Eng, vol. 20, no. 5, 2014. [32] The craft of slowness: Why handwritten code might be your next superpower. [Online]. Available: https://nameocean.net/article/the-craftof-slowness-why-handwritten-code-might-be-your-next-superpower/ [33] L. Nelson. The slow code movement. [Online]. Available: https: //lairdnelson.wordpress.com/2014/08/ [34] L. Olson et al., “Who speaks for ethics? how demographics shape ethical advocacy in software development,” in Proc. ACM FAccT, 2025. [35] E. Paradis et al., “How much does AI impact development speed? an enterprise-based randomized controlled trial,” in Proc. IEEE/ACM ICSESEIP, 2025. [36] D. Pargman and B. Wallsten, “Resource scarcity and socially just internet access over time and space,” in Proc. ACM LIMITS, 2017. [37] S. Peng et al., “The impact of AI on developer productivity: Evidence from GitHub Copilot,” arXiv:2302.06590, 2023. [38] N. Perry et al., “Do users write more insecure code with AI assistants?” in Proc. ACM CCS, 2023. [39] T. Petricek. The timeless way of programming. [Online]. Available: https://tomasp.net/blog/2022/timeless-way/

[40] A. Piccolboni, The Ascetic Programmer: How asceticism benefits programming, science, and the arts. Self-published, 2023. [Online]. Available: https://asceticprogrammer.info/book [41] H. C. Pöhls et al., “The complexity of cyber security in private and professional everyday life — an ethnographic-informatic collaborative approach,” in HCI for Cybersecurity, Privacy, and Trust, A. Moallem, Ed. Springer Nature Switzerland, 2025, pp. 105–124. [42] F. Ray. The slow code movement: Reclaiming the joy of coding. [Online]. Available: https://web.archive.org/web/20241006072614/https: //bettersoftware.uk/2024/09/11/the-slow-code-movement-reclaimingthe-joy-of-coding/ [43] D. Rosenberg et al., “Rapid, evolutionary, reliable, scalable system and software development: the resilient agile process,” in Proc. ICSSP, 2017. [44] P. G. Sakhalkar, “AI-assisted code and vulnerability management: Transforming modern software development,” JCSTS, 2025. [45] D. Shaw. The slow code movement: Think fast, code slow. [Online]. Available: https://medium.com/@dshaw /the-slow-code-movement9ffa228349c8

[46] G. Shih. (2012) Zuckerberg’s letter to investors. [Online]. Available: https://www.reuters.com/article/world/zuckerbergs-letter-to-investorsidUSTRE8102MT [47] M.-A. Storey, “From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI,” arXiv:2603.22106, 2026. [48] A. Sundelin et al., “Towards an anatomy of software craftsmanship,” ACM Trans. Softw. Eng. Methodol., vol. 31, no. 1, 2021. [49] I. A. Tøndel et al., “Influencing the security prioritisation of an agile software development project,” Comput. Secur., vol. 118, 2022. [50] J. Ventrella. The case for slow programming. [Online]. Available: https://ventrellathing.wordpress.com/category/slow-movement/ [51] M. S. Wessel et al., “Quality gatekeepers: investigating the effects of code review bots on pull request activities,” Empirical Software Engineering, vol. 27, no. 5, p. 108, 2022. [Online]. Available: https://doi.org/10.1007/s10664-022-10130-9 [52] M. Zechner. Thoughts on slowing the fuck down. [Online]. Available: https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-thefuck-down/

Related documents

• AssureCode: Structured Justification for Trustworthy Agentic Coding#1414363
• AssureCode: Structured Justification for Trustworthy Agentic Coding#1406521
• Specifying and Maintaining Agentic Workflows: An Empirical Study of GitHub Agentic Workflows#1063474
• Vibe-GUIDE: A Graph-based User Interface in IDEs for Oversight in Vibe Coding#1050050
• AgentPack: A Dataset of Code Changes, Co-Authored by Agents and Humans#1123950