Paper deep dive
AI Policies: Help or Hindrance? A Software Developer's Perspective
Samuel Ferino, Rashina Hoda, John Grundy, Christoph Treude, Hashini Gunatilake
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:AI policies introduced by software organisations to mitigate LLM-related risks such as sensitive information leaks and unauthorised usage are not useful if software developers do not engage with them. We draw on 19 software developer interviews to show how AI policies help and hinder developers. We suggest approaches to support managers and decision makers with a developer-centric approach to introducing AI policies.
Tags
Links
- Source: https://arxiv.org/abs/2609.16496v1
- Canonical: https://arxiv.org/abs/2609.16496v1
Trouble viewing inline? Open PDF directly â
Full Text
35,891 characters extracted from source content.
Expand or collapse full text
Department: Head Editor: Name, x@email AI Policies: Help or Hindrance? A Software Developerâs Perspective Samuel Ferino Monash University Rashina Hoda Monash University John Grundy Monash University Christoph Treude Singapore Management University Hashini Gunatilake Monash University AbstractâAI policies introduced by software organisations to mitigate LLM-related risks such as sensitive information leaks and unauthorised usage are not useful if software developers do not engage with them. We draw on 19 software developer interviews to show how AI policies help and hinder developers. We suggest approaches to support managers and decision makers with a developer-centric approach to introducing AI policies. Introduction According to the 2025 Google Cloud ROI of AI report, 88% of early adopters leveraging LLM-powered software report a positive return on investment, with 70% citing immediate pro- ductivity gains across enterprise IT operations [1]. However, security and risk concerns remain the primary barrier to scaling AI, as highlighted by the 2026 McKinsey AI Trust Maturity Survey of nearly 500 organisations [2]. Deloitteâs 2026 State of AI Survey indicates that data privacy and security issues are the top concern among respondents (73%), followed by legal, intellectual property, and regulatory compliance risks (50%) [3]. Recent research findings underscore these concerns, demonstrating that LLMs remain vul- nerable to security and privacy attacks such as jailbreaking and data poisoning [4]. Despite these high operational and security stakes, organisational governance has fallen be- hind. The same Deloitte Survey reports that only 21% of companies maintain a mature governance IEEE SoftwarePublished by the IEEE Computer SocietyŠ 2026 IEEE 1 arXiv:2609.16496v1 [cs.SE] 15 Sep 2026 Department Head framework for autonomous AI agents, amplifying risks surrounding data privacy and centralised visibility, such as unmonitored employee usage of AI tools [3]. Addressing these governance gaps requires organisations to introduce or update their AI usage policies, structures, and workflows. However, such structural adaptations can incur substantial costs in terms of time and financial resources and disrupt existing software develop- ment processes [5], [6]. Consequently, organisa- tions must carefully balance risk mitigation with the impact of process changes on the humans working within those boundaries. Neumann et al. [7] tried to address this gap by investigating how developers and agile coaches in three German organisations adopt GenAI tools, focusing on regulatory conditions. Their 17 semi- structured interviews reveal that a mismatch be- tween top-down governance and bottom-up prac- tices (e.g., prohibiting LLMs without providing practical alternatives) drives shadow IT because policy is perceived as impractical. Similarly, Ro- nanki et al. [8] investigated best practices for responsible adoption of LLMs through a multi- case study with three organisations involving developers, product owners, and scrum masters. Their findings cover seven trustworthy AI com- pliance recommendations, such as âavoid task- misaligned fine-tuned LLMsâ, ârestructure busi- ness processes to integrate LLMsâ, and âprioritise usefulness over strict accuracyâ. Khojah et al. [9] investigated the implica- tions of LLM policies in software organisations through the lens of engineering managers. Their interview study with 11 managers highlighted how organisations formulate these policies and the drivers behind them. However, while man- agerial perspectives shed light on policy design, understanding developersâ perspectives is critical to understand the impact of LLM company poli- cies in software development, since no amount of governance and policy will help if developers do not engage with them. To capture a vital developer perspective, we interviewed 19 software developers across four regions in North America, Latin America, Eu- rope, and Australasia. We sought to answer the question: How do organisational AI policies (on LLM-based tools) for software develop- ment impact software developers? Through our empirical findings, we provide insights into what helps and hinders software developers when it comes to AI policies. By illuminating the down- stream impacts of policies, we intend to support IT managers, engineering leaders, and decision makers in navigating AI policies within their organisational context. Methodology We conducted a semi-structured interview study (approved by the Monash University Hu- man Research Ethics Committee, Project ID: 44875) involving 19 software developers with ex- perience of using LLMs for software development tasks. We advertised our study on our professional social media, LinkedIn and X (formerly Twitter). The recruitment focused on participants with ex- perience using LLMs for software development tasks. Participants completed a pre-interview ques- tionnaire detailing their demographic and profes- sional background (Figure 1) and their companyâs AI policy regarding the use of LLMs for software development, where P18 had a prohibitive policy at the time of the interview while P2, P12, and P16 reported having moved from prohibitive to permissive policies. During the semi-structured interviews, rang- ing from 34 to 58 minutes, we sought details regarding their use of LLMs for software de- velopment including company policies by asking follow-up questions tailored to their context: ⢠âIn the pre-interview questionnaire, you indi- cated that your organisation [has / does not have] an explicit policy regarding the use of LLMs for software development. Could you elaborate on this? ⢠When was it introduced, and by whom? ⢠Do you know how it was developed or what prompted its introduction? ⢠How has this policyâor lack thereofâaffected you or your team? Has it been a help or a hindrance?â. We analysed the interview transcripts using socio-technical grounded theory for data analysis (STGT4DA) [10]. The first author conducted the data analysis, applying open coding, constant comparison, and memoing, while the co-authors reviewed the codes and memos throughout the 2 IEEE Software Gender Role Current AI Policy Years of Professional Experience Location Domain LLM Tools Gender Role AI Policy Years of Professional Experience Years of Experience (LLMs for Software Engineering) Location Domain LLM Tools Figure 1. Demographics and Professional Background of Interview Participants. process. The pre-interview questionnaire, the in- terview guide, and some de-identified examples of qualitative data analysis are available in our supplementary package 1 to support future re- searchers, in line with the ethical research ap- proval governing this study. Limitations. Nineteen practitioners is a mod- est sample size. Our sample size is limited regard- ing developer experiences of working under pro- hibitive AI policies. Our participant recruitment carries potential self-selection bias as a study limitation. Organisational Policies for Governing LLM Adoption As shown in Figures 1 and 2, interview participantsâ descriptions revealed four distinct AI organisational policies: allow LLMs, prohibit LLMs, no policy, and unsure. Organisations per- mitting LLMs either allow unrestricted access or limit usage to specific licensed models, whereas prohibiting organisations ban LLM use entirely in the workplace. Cases with no policy lack explicit guidelines on LLM usage, while uncertainty re- flects instance where an organisationâs stance on LLM adoption remains unknown to employee. Our interview participants described their un- derstanding of the motivations underlying organ- isational decisions to prohibit, permit, or defer LLM use (Figure 2). Prohibiting LLM use. Participants (P2 and P18) explained how their organisationsâmotivated 1 Supplementary file: https://doi.org/10.5281/zenodo.22581906 by the desire to prevent potential legal and secu- rity issuesâexhibited a risk averse approach and prohibited their developers from using LLMs. Customers may lose trust on how the organisation manages their data is another motivation (P18). âTheir policy was just to avoid using ChatGPT or any other LLMs. Their concern was more to do with the ownership of the code that was being generated, and how it might violate trademarks and violate the licenses. So they really didnât want any legal trouble.â - P2 (Software Engineer, IT). Despite this, shadow AI usage for code under- standing is still employed by P18 - e.g., âIâm not really using ChatGPT for my office coding work directly, but for [code] understandingâ. Enabling controlled LLM adoption. Organ- isations may treat LLMs as just another tool, and developers are clearly informed about their responsibilities regarding accountability (P8). De- velopers can use AI assistance during coding- related activities, but they may also need to explicitly declare it (P17). Several participants (P2, P7-P8, P14-P16) shared how organisations navigate concerns re- lated to security, code ownership, and company reputation when developing permissive policies for LLM use. To mitigate security issues, P14 reported that their organisation provides licensed LLMs, which may allow the organisation to monitor employeesâ usage of LLMs. P7 and P16 mention that their or- ganisation defines prompting guidelines and relies on developer prompting monitoring: âI did a training on using AI in the workplace, and they said they were building a company September 2026 3 Department Head policy, because at the moment theyâre just relying on their workers to not put company data into the promptsâ - P7 (BI Analyst, Telecommunica- tions). Additionally, the organisation may allow de- velopers to use LLMs but restrict full integration with internal systems. âIn a Power BI Pro account, thereâs an integrated Copilot that you can use, and itâs very handy [...] you can use it to create insights for visuals [..] I am assuming itâs because of security reasons [that] weâve [in my company decided] turned this function off. Iâm not sure if there would be a method to use it securelyâ - P7. P15 explained that they communicate with LLMs via private APIs while P2 and P8 argued that developers could be permitted to use LLMs after their organisations resolve code ownership concerns. âAs long as they sort of fix the whole ownership, like the licensing issues that are with LLMs, I think itâs okay using LLMs, because itâs just another tool that will help you do your jobâ - P2 (Software Engineer, IT). However, these security mitigation strategies might not work for every situation. For this reason, some organisations go the extra mile to allow LLMs - e.g., âBut other teams, like the data engineering team, would like to have additional security or safety procedures on top of that. So they were working on some kind of additional policies and guidelines to further safeguard the whole LLM ecosystem.â - P15 (Researcher, Engi- neering). P7 and P15 mention that their organi- sation decided to put effort into clearly defining the allowed boundaries - e.g., âthey were working on the [AI] policy to define it better and really clarify what specific data should not be passed into which LLMs or which tools to use.â - P15 (Researcher, Engineering). Deferring policy development. Although LLM policies can support organisational pro- cesses and help to mitigate LLM risks, the focus on product release for early-stage organisations may surpass security concerns, and introducing policies may slow down their developers (P5). This may also apply to organisations where the product does not differ that much from com- petitors (P13). Organisations may still be trying to understand the business value of LLMs, and drafting an AI policy is not a priority for them - e.g., âAI is quite new, and I think our company has yet to write a policy on it. Maybe they will [write an AI policy] at some point in time. But in general, weâre exploring ways that we can use AI in our platform, like we want to integrate some kind of AI into our platformâ - P13 (Software Developer, IT). Incremental and evolving approach. We found an incremental and evolving approach to AI policy development. Some organisations are gradually shifting from complete prohibition to permitting the use of licensed (P12, P16). âThe first policy they put in place was to commu- nicate company-wide that you cannot use Chat- GPT... and we had to wait for the licenses to come... I think theyâve been doing the licensing quite quickly, because we got access... so that there werenât any issues of data leak, because itâs a huge concern for the company.â - P16 (Software Engineer, Gaming). The product domain may also influence how organisations approach LLMs, e.g., âItâs always going to be depending on the sensitivity of what youâre doing. If a bank ends up doing a full app with an LLM, I wonât trust that bank anymore.â - P16 (Software Engineer, Gaming). Help or Hindrance? The Developer Impact The two-sided nature of permissive and pro- hibitive policies can be a help or hindrance to software developers, and developers shared their perceptions about the absence of clear policies. Figure 2 summarises the AI policies, positive and negative impact on developers. How do Policies Help? While some benefits of permissive policies, such as enabling workflows, may seem intuitive, our analysis reveals that prohibitive policies were also seen to be advantageous to developers and organisations in some ways. Helpful When Allowed. The benefit of per- missive policies is having access to enterprise grade LLMs. Going beyond mere permission, P14 and P19 argue that providing licensed LLMs ac- tively mitigates concerns regarding data leakage and unauthorised usage of data for LLM training. âThe [LLM] tools we have used, those are actu- ally for enterprise use. They have [an] enterprise [level service] agreement between my company and them, so those [data] are not actually used for trainingâ P19 (Machine Learning Scientist, IT). 4 IEEE Software Prohibited Organisation prohibits LLMs in the workplace ⢠Avoids AI system non-determinisn and human need to verify correctness ⢠Prevents security dependency on third parties ⢠Fear of missing out on possible productivity gains ⢠Constraints on developers/interns used to AI tools ⢠Overload on developers from experimenting with LLMs on side projects No Policy Organisation did not specify LLM usage policy in the workplace Not Identified ⢠Overreliance on LLMs to generate and debug code ⢠Mistakes from using LLMs (e.g., exposing API tokens) Allowed ⢠Automates coding and non-coding tasks (CLI tools, meeting summaries, codebase onboarding) ⢠Fosters a culture of knowledge sharing ⢠Mitigates data leakage concerns via enterprise-grade agreements ⢠Development friction from manually filtering confidential information in prompts ⢠Risk of peer AI misuse introducing unfit/poor quality LLM code Organisation allows all LLMs or only selected licensed LLMs in the workplace Perceived AI Policy How Policies Help How Policies Hinder Prohibited ⢠Avoiding potential legal and security issues ⢠Concerns over code ownership (trademark/license violations) ⢠Concerns about loss of security and confidentiality ⢠Avoids system non-determinism and need to verify correctness ⢠Prevents security dependency on third parties ⢠Downturn in productivity and lost innovation ⢠Tasks take longer to complete ⢠Constraints on developers/interns used to AI tools ⢠Causes stress/overload from using LLMs on personal side-projects No Policy / Unsure ⢠Deferring policy creation to explore LLM capabilities and integration into platforms first ⢠Prioritizing product releases over security early on Not Identified ⢠Irresponsible usage (e.g., exposing API tokens) ⢠Discomfort/grey area regarding what proprietary code can be shared ⢠Potential skill degradation due to unmoderated LLM overreliance Policy Context Allowed ⢠Automates coding and non-coding tasks (CLI tools, meeting summaries, codebase onboarding) ⢠Fosters a culture of knowledge sharing ⢠Mitigates data leakage concerns via enterprise-grade agreements ⢠Development friction from manually filtering confidential information in prompts ⢠Risk of peer AI misuse introducing unfit/poor quality LLM code ⢠Navigating security and code ownership threats ⢠Protecting company reputation ⢠Enabling monitoring of employee usage via licensed tools ⢠Facilitating safer access through private APIs, prompt monitoring, and extra safety/security procedures Motivational Drivers (Why Policies Exist) Impact on Developers (Help) Impact on Developers (Hindrance) Prohibited ⢠Avoiding potential legal and security issues ⢠Concerns over code ownership (trademark/license violations) ⢠Concerns about loss of security and confidentiality ⢠Avoids system non-determinism and need to verify correctness ⢠Prevents security dependency on third parties ⢠Downturn in productivity and lost innovation ⢠Tasks take longer to complete ⢠Constraints on developers/interns used to AI tools ⢠Causes stress/overload from using LLMs on personal side-projects No Policy / Unsure ⢠Deferring policy creation to explore LLM capabilities and integration into platforms first ⢠Prioritizing product releases over security early on Not Identified ⢠Irresponsible usage (e.g., exposing API tokens) ⢠Discomfort/grey area regarding what proprietary code can be shared ⢠Potential skill degradation due to unmoderated LLM overreliance Allowed ⢠Automates coding and non-coding tasks (CLI tools, meeting summaries, codebase onboarding) ⢠Fosters a culture of knowledge sharing ⢠Mitigates data leakage concerns via enterprise-grade agreements ⢠Development friction from manually filtering confidential information in prompts ⢠Risk of peer AI misuse introducing unfit/poor quality LLM code ⢠Navigating security and code ownership threats ⢠Protecting company reputation ⢠Enabling monitoring of employee usage via licensed tools ⢠Facilitating safer access through private APIs, prompt monitoring, and extra safety/security procedures AI Policies How Policies Help How Policies Hinder Unsure Developer does not know their organisationâs position towards usage of LLMs in the workplace Mitigates misunderstanding on what content is allowed in prompts Fear of missing out on LLM innovation capabilities ⢠Fear of of potential security issues ⢠Fear of customers losing trust in the company ⢠Fear of potential code ownership issues (e.g., trademark / license violations) ⢠Still exploring business value of LLMs for the company ⢠Prioritizing product releases over security early on ⢠Perceiving LLMs as just another tool ⢠Mitigated privacy and security concerns Perceived Motivations Not Identified Figure 2. Summary of AI policies, perceived motivations, and positive & negative impact on developers. Having access to LLMs it also enables au- tomating coding related as well as non-coding related tasks (P10, P11, P14, and P15). For tasks beyond coding, LLMs were seen to help with meeting summarisation (e.g., with Microsoft Copilot) and a smoother company onboarding process by supporting developers in familiarising themselves with the codebase. âA lot of times, youâre gonna miss some of the meetings. Thereâl be a lot of times where some meetings could have been an email. So in that case, if Iâm late to a meeting, I will ask Copilot to generate the summary of what Iâve missedâ â (P14 Data Engineer, Telecommunications) Access to LLMs was also seen to help foster a culture of knowledge sharing (P4, P12, and P17). âMy senior engineer said to me: âhey, you know what Iâm using [is] Copilotâ. [...] and then I was: âWhatâs the difference [between ChatGPT and GitHub Copilot]?â And he was like: âOh, yeah, it [GitHub Copilot] reads the whole codebase. And it knows what you ask for. [...] letâs try it outâ, and he just did a prompt there and [the response was] good.â - P12 (Software Engineer, Finance) Helpful When Prohibited. While the bene- fits associated with permissive AI policies were somewhat expected, one developer (P18) said that prohibitive AI policies helped her organisation to avoid non-determinism in their systems and the constant concern that the system response may not always be correct. It was also seen to prevent security exposure and dependency on third parties. âWhen it comes to AI, you lose security and confidentialityâ - P18 (Software Developer, Fi- nance). Helpful When Unsure. When asked about how his manager could help him, P1 expressed his desire for clear boundaries - e.g., âyou have to indicate the limits, indicate what can be done and what canât be doneâ - P1. Future research could validate these observa- tions across a larger population of IT profession- als working on projects under LLM-prohibitive policies (e.g., highly confidential projects, high risk domains). September 2026 5 Department Head How do Policies Hinder? Prohibitive policies were seen to cause hin- drances to developer experience, e.g., on account of missed opportunities. Perhaps somewhat sur- prisingly, permissive policies were also associated with being a hindrance to developers. Hindrance When Prohibited. A number of challenges were discussed in the context of pro- hibitive policies (P2, P11-P12, P15-P16, P18). Without LLM assistance in coding related tasks, P15 and P18 anticipated a downturn in pro- ductivity and innovation - e.g., âIt would take much longer to do something you [that] can do with ChatGPT or Claude nowadays [...] mostly debugging, sometimes even writing codeâ - P15 (Researcher, Engineering). P16 observed that coworkers who moved from organisations that allow LLM usage to others that prohibit them struggled with coding-related tasks: âWe have a lot of interns coming over [...] we have a couple of masters who [are used to using] GPT or Copilot a lot to code, and [now] they cannot inside the company. So, it is a constraint on them [not being able to use LLMs].â - P16 (Software Engineer, Gaming) P2 and P12 reported starting to explore LLM usage on the side, through personal projects, due to organisational restrictions: âto be honest, I started using this outside of work rather than at work, because we were told to not use it because of all the licensing issues...â - P2 (Software Developer, IT). These side projects can overload developers, resulting in accumulating stress and damage to their wellbeing [11]. Hindrance When Allowed. Under permissive policies, developers may encounter unintended development friction and expose teams to the risks of peer AI misuse (P7, P10, P15-P17). While navigating security issues, P7, P15, and P17 need to go through the hassle of filtering confidential information when prompting. P16 observed that security concerns are more com- mon among experienced developers, who better understand the implications of code leaks, and might prefer to avoid LLMs even when allowed. P10 shows concerns about developers using LLMs to introduce unfit quality LLM-generated code into the codebase - e.g., â[LLMs] might not always choose the best soft- ware engineering practices [...] if something is really popular, [it] doesnât mean itâs the best [for your project]. [It means] itâs just popular. A lot of code on GitHub is done by people who are just trying to learn things, and they might not actually have the experience with that, or know if that [code] scales wellâ - P10 (Software Engineer, IT). Hindrance when No Policy. Drawing on participantsâ experiences working without clear organisational policies, we found the following perceived challenges: irresponsible LLM usage, such as vibe coding in a way that developers overrely on LLMs to generate and debug code, and potential mistakes that expose sensitive infor- mation (e.g., API tokens) in prompts (P5, P13). Hindrance when Unsure. Our participant P1 reports challenges he faced while not aware of his organisationâs policy. For instance, P1 feels uncomfortable with the situation of putting pro- prietary code into an LLM without fully under- standing the level of sensitivity. âA lot of times when we work for a private company, we feel very uncomfortable sending code; you canât put private code into ChatGPT or that kind of thing. Iâd say itâs a grey area of understanding what you can and canât send to themâ - P1 (Software Developer, IT). There are also concerns about losing LLM innovative potential due to prohibitive policies - e.g., âWeâd lose so much in terms of time or innovation. Itâs already there; what are we going to do?â - P1. Recommendations for Evolving Policies to Better Support Developers Implications for Practice We organise our discussion around strategies to mitigate policy hindrances and an LLM policy progression checklist. Mitigating Policy Hindrances. We suggest the following approaches grounded in the litera- ture to manage the hindrances: ⢠Seamless security layers through automated prompt sanitisation and traditional code qual- ity check workflows can mitigate development friction arising from developers having to man- ually filter confidential information in prompts, the risks of peer AI misuse introducing poor- quality LLM code, and the risks of sensitive information being leaked to the LLMs [12], [13]. ⢠Providing a sandbox (e.g., CodeRabbit 2 ) as 2 https://docs.coderabbit.ai/code/environments 6 IEEE Software a safe and isolated development environment where developers who are accustomed to using AI tools for software development can work with fewer constraints [14]. ⢠Regular meetings focused on sharing experi- ences using AI tools (e.g., new features) can provide a welcoming environment for develop- ers who are experimenting with LLMs on side projects, as well as for those who are afraid of missing out on possible productivity gains from using LLMs [15]. LLM Policy Progression Checklist. To as- sist managerial decision-making when transition- ing from prohibitive to permissive policies, we suggest using the checklist below based on our empirical findings. Answering yes to most of these questions provides a strong indication that permissive policies could be adopted; otherwise, we recommend considering delaying deployment of new policies while addressing any gaps. ⢠Are there built-in safeguards and guardrails in the LLMs you are considering for your developers to use? ⢠Have the developers gone through responsible AI usage training? ⢠Is there a clear definition of what constitutes sensitive information across the organisation, including customer information? ⢠Are developers fully informed of the risks of using LLMs for development? ⢠Are developers aware of their selected LLM servicesâ privacy policy? ⢠Are the code ownership responsibilities clear? ⢠Is AI usage in code properly declared? ⢠Has the development team fully transitioned to LLM data protection services? ⢠Has the development team been introduced to any prompting guidelines? Recommendations for Future Research We suggest the following future investigations in human-centric AI governance: ⢠How accurately do software developers in- terpret organisational AI policies? What are the primary knowledge gaps between manager intent and developer understanding? ⢠To what extent can organisations monitor re- sponsible AI adherence during software work- flows without compromising developer pri- vacy? ⢠What shadow IT practices do developers adopt under restrictive or ambiguous AI policies? How can policy design mitigate them? ⢠To what extent do prohibitive AI policies drive developers to experiment with LLMs on per- sonal side projects? How does this contribute to developer stress and burnout? ⢠How do policies impact talent retention and developer satisfaction? Does prohibitive poli- cies correlate with increases in organisational turnover? ⢠What are the specific workarounds developers adopt to navigate and mitigate LLM-related security risks, enabling permissive policies? Conclusion Organisations are facing the challenge of de- ciding how to leverage LLM tools in software de- velopment while mitigating organisational risks. In this study, we addressed this through the lens of software developers by examining their experiences and perceptions of how organisa- tional AI policies impact them. We identified a governance progression across some participantsâ organisations, maturing from strict LLM pro- hibitions toward permissive access via licensed LLMs. We also found a two-sided nature of permissive and prohibitive policies, both serving as a help and a hindrance to software developers. To assist IT managers, we propose actionable recommendations to mitigate the hindrances and a LLM policy progression checklist. The main takeaway is that, aside from exceptional cases, AI governance could be treated as an evolving life- cycle, transitioning from prohibitive to permissive policies as soon as gaps are addressed. Acknowledgments Ferino is supported by a Faculty of IT Post- graduate Scholarship. We express profound grati- tude to all participants who took part in this study. We thank Humphrey Obie for feedback on this research and Nimmi Weeraddana and Haoyu Gao for helping with participant recruitment. REFERENCES 1. Google Cloud, âThe ROI of AI 2025: How Global Enterprise Leaders Are Unlocking Business Value,â September 2026 7 Department Head Google Cloud, Tech. Rep., Sep. 2025, accessed: 2026-09-02. [Online]. Available: https://cloud.google. com/resources/content/roi-of-ai-2025 2. McKinsey & Company, âState of AI Trust in 2026: Shifting to the Agentic Era,â McKinsey & Company, Tech. Rep., Mar. 2026, accessed: 2026-09-02. [Online]. Available: https://w.mckinsey. com/capabilities/tech-and-ai/our-insights/tech-forward/ state-of-ai-trust-in-2026-shifting-to-the-agentic-era 3. DeloitteInsights,âTheStateofAIinthe Enterprise:2026AIReport,âDeloitte,Tech. Rep., Feb. 2026, accessed: 2026-09-02. [Online]. Available: https://w.deloitte.com/us/en/what-we-do/ capabilities/applied-artificial-intelligence/content/ state-of-ai-in-the-enterprise.html 4. B. C. Das, M. H. Amini, and Y. Wu, âSecurity and privacy challenges of large language models: A survey,â ACM Computing Surveys, vol. 57, no. 6, p. 1â39, 2025. 5. E. Klotins, T. Gorschek, K. Sundelin, and E. Falk, âTo- wards cost-benefit evaluation for continuous software engineering activities,â Empirical Software Engineering, vol. 27, no. 6, p. 157, 2022. 6. C. Giardino, N. Paternoster, M. Unterkalmsteiner, T. Gorschek, and P. Abrahamsson, âSoftware devel- opment in startup companies: the greenfield startup model,â IEEE Transactions on Software Engineering, vol. 42, no. 6, p. 585â604, 2015. 7. M. Neumann, L. Bischof, N. E. Hinz, A. Altun, L. Stock- mann, D. Schrader, A. C. Ahaus, E. C. Demirci, B. Gabel, M. Rauschenberger et al., âBetween policy and practice: Genai adoption in agile software devel- opment teams,â in International Conference on Agile Software Development. Springer, 2026, p. 290â308. 8. K. Ronanki, B. Cabrero-Daniel, T. Herda, S. Sitkovich, J. Horkoff, and C. Berger, âRecommendations for ef- ficient and responsible llm adoption within industrial software development,â Information and Software Tech- nology, p. 108171, 2026. 9. R. Khojah, M. Mohamad, L. Erlenhov, F. G. de Oliveira Neto, and P. Leitner, âLLM Company Policies and Policy Implications in Software Organizations,â IEEE Software, 2025. 10. R. Hoda, Qualitative Research with Socio-Technical Grounded Theory. Springer, 2024. 11. J.C.A.Silva,L.Cerqueira,B.Santana, G. de Figueiredo Carneiro, S. Freire, M. Mendonc ̧a, and J. A. M. Santos, ââFrustrating, Stressful, and Overwhelmingâ: Insights into Software Practitionersâ Productivity from Stack Exchange Discussions,â in Simp Ě osio Brasileiro de Engenharia de Software (SBES). SBC, 2025, p. 237â248. 12. OWASP Foundation. (2025) LLM02:2025 Sensitive Information Disclosure. Open Web Application Security Project. [Online]. Available: https://genai.owasp.org/ llmrisk/llm022025-sensitive-information-disclosure/ 13. â. (2025) LLM07:2025 System Prompt Leak- age.OpenWebApplicationSecurityProject. [Online].Available:https://genai.owasp.org/llmrisk/ llm072025-system-prompt-leakage/ 14. N. Pombo and A. Faraji, âToward responsible autonomy: The opportunities and obstacles of large language mod- els in software engineering,â in Proceedings of the 2026 9th International Conference on Software Engineering and Information Management, 2026, p. 114â119. 15. A. Altork, I. Wiese, and J. Melegati, âMotivation and psychological well-being of software engineers in the generative ai era: An analysis of the online discourse,â Journal of Software: Evolution and Process, vol. 38, no. 8, p. e70162, 2026. Samuel Ferino is a PhD candidate at Faculty of Infor- mation Technology, Monash University, Australia. His research interests include LLMs for software develop- ment, and education in software engineering. Ferino received his Master in System and Computing from the Federal University of Rio Grande do Norte, Brazil. Contact him at samuel.demouraferino@monash.edu. Rashina Hoda is a Professor of Software Engi- neering at Monash University, Australia. Her research focuses on the human and socio-technical aspects of SE at the intersections of AI and digital health. She was named the 2025 Top Researcher in Soft- ware Systems in Australia by The Australian. In her 2024 Springer book âQualitative Research with Socio-Technical Grounded Theoryâ, she presents a modern socio-technical variation to the Grounded Theory methods for SE. Rashina serves on the ICSE steering committee and as a guest editor for TOSEMâs special issue on human-AI collaboration in SE. More about her on w.rashina.com Contact her at rashina.hoda@monash.edu. John Grundy,is an Australian Laureate fel- low and a professor of software engineering at Monash University, Melbourne, Australia. His cur- rent interests include domainâspecific visual lan- guages, modelâdriven engineering, large-scale sys- tems engineering, and software engineering edu- cation. Grundy received his PhD in computer sci- ence from University of Auckland, New Zealand. 8 IEEE Software He is a Fellow of the IEEE, Engineers Australia and ASE. He is an associate editor of the IEEE Transactions on Software Engineering, the Auto- mated Software Engineering Journal, and IEEE Soft- ware. More details about his research can be found at https://sites.google.com/site/johncgrundy/. Contact him at john.grundy@monash.edu. Christoph Treude, is an Associate Professor of Computer Science at Singapore Management Uni- versity. He has authored over 150 scientific articles with more than 250 coauthors. His work has received recognition, including an ARC Discovery Early Ca- reer Research Award (2018-2020) and funding from industry leaders such as Google, Facebook, and DST. Treude has received four best paper awards, includ- ing two ACM SIGSOFT Distinguished Paper Awards. Currently, Treude serves on the Editorial Boards of the IEEE Transactions on Software Engineering, the Springer Journal on Empirical Software Engineering, and the Wiley Journal of Software: Evolution and Pro- cess. He also holds the role of Open Science Editor for the Elsevier Journal of Systems and Software. He has chaired conferences such as ICSME 2020, ICPC 2023, and TechDebt 2023 and regularly participates in software engineering conference program commit- tees. Hashini Gunatilake, is a Research Fellow at Monash University, Melbourne, Australia. She received her PhD in information technology from Monash Uni- versity, Australia. Prior to her PhD, she was in the software industry. Her research interests are software engineering, human, social & technical aspects, human-AI interaction, agile methodology, data visualisation. More details of her research can be found at https://hashinig.com. Contact her at hashini.gunatilake@monash.edu. September 2026 9