{"id":"088c0561-c2ec-443e-a692-b141edbb1548","arxiv_id":"2607.22168","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Developers rarely consider energy efficiency explicitly, and AI-assisted green-coding tools will be accepted only if they provide actionable, explainable suggestions, integrate into existing workflows, and prove net energy savings.","lead":"This study interviewed ten professional software developers about how energy efficiency shows up in their daily work and what they would want from an AI-assisted tool that helps write greener code. It finds that energy efficiency is mostly an afterthought, and that developers will only accept such tools if they are transparent, non-disruptive, and clearly save more energy than they consume.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Acceptance claim overreaches: based on hypothetical-tool self-reports, not observed adoption; sample size and homogeneity further weaken the 'strongly depends' assertion.","rationale":"The reader's weakest assumption was the sampling limitations, and I agree that the small, homogeneous, network-recruited sample limits generalizability. However, the more load-bearing problem is with the second central claim about acceptance: it is derived from responses to a hypothetical AI tool, not from observed adoption behavior. In the interviews, participants were asked to imagine such a tool, so their statements reflect anticipated concerns and requirements, not actual acceptance determinants. The interview guide did not include any ranking or trade-off exercises that would justify the word 'strongly.' The paper explicitly acknowledges limitations in Section V.E, which is a strength, but the abstract does not temper the claim accordingly. The descriptive claim that energy efficiency is rarely explicit is less problematic because it is a straightforward report from the sample, though still not generalizable. Given the transparent methodology, OSF availability, and reasonable intercoder agreement, the study provides a useful requirements-elicitation contribution. I would keep the conditional acceptance but suggest the authors soften the abstract's causal language and reframe the acceptance findings as hypotheses for quantitative validation.","tokens_in":17611,"tokens_out":4439,"duration_ms":47008,"concrete_test":"Conduct a vignette-based conjoint experiment with a larger, more diverse sample (e.g., n=100 developers) in which participants evaluate three AI-assisted energy-efficiency tool profiles that systematically vary the presence/absence of (a) data-use transparency, (b) net-energy-savings reporting, and (c) training-data disclosure. Estimate the marginal utility of each attribute using a mixed logit model. If none of the attributes has a statistically significant and practically meaningful effect on adoption intention, the 'strongly depends' claim is refuted.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section IV.G and Table IX show that participants mentioned concerns about data protection (I03, I05, I07, I08) and AI energy consumption (I02, I03, I05, I06, I09, I10), but these emerged from general questions about potential barriers, not from a systematic elicitation of attribute importance or trade-offs. The interview guide (Table I) asked 'Is there anything that would discourage you?' and asked participants to imagine an AI tool; it did not ask respondents to rank or weigh the three transparency dimensions. The abstract's claim that acceptance 'strongly depends' on (i) data-use transparency, (ii) net-energy-savings vs. tool consumption, and (iii) training-data disclosure is therefore a causal/strength claim not supported by the qualitative design. With n=10, nine male, predominantly German, recruited through the authors' networks (Section III.A; Section V.E), the sample cannot support a quantitative 'strongly' verdict. The study is useful as hypothesis generation, but the central acceptance claim is a candidate for further confirmation, not an empirically established finding.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper reports a qualitative interview study (n=10) with professional software developers, conducted within the European GreenCode project. The authors use semi-structured interviews, Mayring's structuring content analysis, and a subsequent interpretive pass through the Technology Acceptance Model (TAM) to answer two research questions about the current role of energy efficiency in development and about requirements/barriers for AI-assisted energy-optimization tools. The main reported findings are that energy efficiency is rarely an explicit development goal and is mostly achieved as a by-product of performance work; that developers see barriers in limited awareness, time pressure, and weak economic incentives; and that tool requirements center on actionable, explainable suggestions and seamless IDE/CI integration. For AI-assisted tools, the paper claims that acceptance strongly depends on transparency about data use, net energy savings relative to the AI's own consumption, and disclosure of training data.","tokens_in":17834,"tokens_out":5294,"duration_ms":55572,"significance":"If the findings are taken as hypothesis-generating, the study is a useful and methodologically transparent contribution to the green-software-engineering literature. Its strengths include a clearly described qualitative design, a published interview guide, an OSF repository for anonymized transcripts and coding guideline, an intercoder reliability check (74.85%), and an unusually candid limitations section. The study fills a real gap by shifting attention from technical optimization techniques to the workflow-level requirements and barriers perceived by practitioners. However, the main acceptance claim in the abstract goes beyond what this design can support; because that claim is central to the paper's contribution, it needs to be tempered or re-derived from the reported categories.","major_comments":[{"comment":"The abstract's strength claims (\"typically\" and \"strongly depends\") exceed the evidence. Table III assigns \"energy savings through performance focus\" to only four of ten participants (I02, I04, I08, I10), while three (I01, I07) say energy is not a topic and three (I05, I06, I09) say it is present only at company level; \"typically\" is an overquantification. Similarly, the interview guide (Table I) contains open questions (\"Is there anything that would discourage you?\"; \"Imagine you had a tool...\") and never asks participants to rank, weigh, or trade off transparency dimensions. Table IX reports a \"Higher energy and resource consumption than savings\" subcategory (six participants) and a \"Data protection concerns\" subcategory; that supports identifying these as salient themes, but not the claim that acceptance \"strongly depends\" on these factors. Recommend replacing \"typically\" with \"often\"","section":"Abstract; §IV.G; Table III"},{"comment":"The abstract lists \"disclosure of the training data used\" as one of three transparency requirements. This specific dimension is not present in the reported category system. Table IX and the text of §IV.G document data-protection worries about source-code access (I03, I05, I07, I08/I09) and concerns about AI-generated content entering future training data (I07, I09); neither is a requirement that the tool disclose its own training data to the developer. If such a requirement was voiced, it should be supported with a coded subcategory and illustrative excerpt; otherwise the abstract should be aligned with the actual findings.","section":"Abstract; §IV.G; Table IX"}],"minor_comments":[{"comment":"I04 is described in the text as a research associate at a university, but Table II lists the company size as \"Large.\" Clarify the organization type and whether \"company size\" is the appropriate label for a university position.","section":"§III.A; Table II"},{"comment":"The interviewee numbers for data protection are inconsistent: the text says I03, I05, I07, I09, while Table IX says I03, I05, I07, I08. Please align.","section":"§IV.G; Table IX"},{"comment":"Minor language error: \"the findings not fully reflect\" should read \"the findings do not fully reflect.\"","section":"§V.E"},{"comment":"The statement that sample sufficiency was \"assessed retrospectively based on the recurrence of the main categories across the final interviews\" is too brief. Specify the recurrence criterion or label the check as informal; otherwise the saturation claim is not verifiable.","section":"§III.A"},{"comment":"The abstract says energy savings are \"typically achieved indirectly through performance optimization.\" As noted in the major comment, Table III gives this position to only four participants. In the results section this is presented carefully; consider using \"often\" or \"in some cases\" in the abstract to match the data.","section":"§IV.A; Abstract"}],"recommendation":"major_revision","confidential_remarks":"The paper is methodologically sound and the open materials are a strength, but the abstract overstates the strength of two central findings, and one of the three transparency dimensions mentioned in the abstract (disclosure of training data) does not appear to be grounded in the reported qualitative categories. A carefully hedged revision would make this a useful contribution to the green software engineering literature."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a solid, honest little qualitative study. The durable finding is that energy efficiency is not an explicit goal in daily development; it comes as a byproduct of performance. That is consistent with prior work and is well-supported by the interviews.\n\nWhat's new: the requirements list for AI-assisted energy tools — actionable suggestions, IDE integration, explainability, impact transparency, trust in AI — is concrete and practically useful. The authors did the work properly: semi-structured interviews with a pilot, Mayring content analysis, a coding guideline, intercoder agreement at 74.85%, and OSF materials promised. Using TAM after the fact as an interpretive lens is fine and modest.\n\nThe soft spots are mostly in the abstract, not the body. \"Acceptance strongly depends on transparency…\" is a strength claim that the design cannot carry. The interviews surfaced those concerns, but did not measure their relative weight. No ranking, no trade-off, no observed adoption. With ten participants, nine male, mostly German, recruited through the authors' networks, \"strongly depends\" is too muscular. The body itself is more careful; the authors do list the sampling limitations and call the results transferable only with caution.\n\nAlso worth noting: the study is about a hypothetical tool, not a real one, so responses are expectations, not behavior. That is fine for requirements elicitation, but it should be framed as such.\n\nWho this is for: anyone building green coding tools, especially AI-assisted ones, and researchers working on green software engineering adoption. The requirements catalog and the TAM-based categories are directly usable. It deserves a serious referee, not because the claims are groundbreaking, but because it is a clear, reproducible qualitative study in a field that needs more empirical ground truth. The authors should be pushed to soften the \"strongly\" claim and add a sentence about the exploratory nature of the acceptance finding.\n\nRecommendation: send to peer review; the requested revisions are mainly about calibration of claims.","headline":"Useful requirements-elicitation study; the abstract overstates how strongly the identified transparency concerns drive acceptance.","tokens_in":18270,"tokens_out":1645,"would_cite":true,"duration_ms":17238,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Software developers treat energy efficiency as a byproduct, not a goal, and will accept AI tools only if the tools prove their own net energy savings.","keywords":["green software engineering","energy efficiency","developer perceptions","AI-assisted tools","semi-structured interviews","qualitative content analysis","technology acceptance","sustainable software"],"falsifier":"A direct test would be a larger, pre-registered survey or a workplace observational study with a balanced international sample of developers. If developers in that sample report energy efficiency as an explicit goal in daily work, or show willingness to adopt AI optimisation tools without transparency conditions, then the paper's central claims about absence and conditionality would be falsified. A controlled experiment could also measure adoption of an energy dashboard across two framings — performance versus environment — to test the claim that energy concerns are always secondary.","tokens_in":17530,"feed_emoji":"🔋","tokens_out":6706,"duration_ms":61039,"temperature":0.7,"pith_summary":"This paper sets out to explain why energy-efficient software development, despite technical advances, is rarely adopted in practice, and to derive what tool support developers would actually use. Based on ten semi-structured interviews with professional developers, it argues that energy efficiency is not an explicit goal in everyday work: it occurs mostly as a side effect of performance optimisation, resource-saving habits, and clean code. The study identifies barriers — limited awareness, release pressure, unclear customer value, and a perceived cost-benefit imbalance — that keep energy from becoming a design objective. It then finds that an AI-assisted energy-optimisation tool would be accepted only if it gives concrete, explainable suggestions, integrates into existing development environments, and transparently accounts for its own energy use against the savings it delivers. The paper's central claim is that sustainable software development will succeed when energy awareness is embedded in existing workflows rather than imposed as an additional responsibility.","feed_headline":"Developers get energy efficiency only as a side effect","feed_subtitle":"Ten developer interviews show AI energy tools need transparency and proven net savings to earn adoption","key_machinery":"The central mechanism is a qualitative empirical study: ten semi-structured interviews with professional developers working in companies of different sizes, analysed through structured qualitative content analysis. This interview corpus is the evidence base that surfaces barrier and requirement categories. The explanatory lens is a technology-acceptance model, which separates perceived usefulness from perceived ease of use; the paper maps developer statements onto these two dimensions to show what makes an energy-optimisation tool worth adopting. The combination of the interview categories and the acceptance lens is what produces the design requirements.","core_discovery":"The core discovery is that energy efficiency in software development is currently a second-order effect. Developers interviewed for this study pursue functionality, performance, and timely delivery; energy savings happen incidentally when those primary goals are reached — for example, when cleaner code or better resource use also reduces consumption. The authors find that developers' mental model equates energy efficiency with runtime performance, even though research shows the two do not always scale together. When asked about AI-assisted optimisation tools, the same developers condition their acceptance on transparency: they want the tool to disclose what data it uses, whether its own ener","pith_inferences":["A broader inference is that the transparency conditions developers set for energy tools — data use, training-data disclosure, net-energy proof — will likely apply to any AI-assisted code tool, so these findings may generalise beyond energy efficiency to trust in AI pair-programming generally.","A testable extension would be to run a field experiment where one group of developers receives energy tips framed as performance gains and another as environmental gains, predicting higher uptake in the performance-framed group based on the interviews.","Since the equation of energy efficiency with runtime performance appears to be a common mental model, an intervention that corrects this misconception could yield energy savings without requiring developers to change their other priorities.","The findings were gathered in one country via personal networks; a quantitative survey with a balanced sample could show whether the cost-benefit barrier and transparency demands hold across regions with different energy prices and regulatory cultures."],"forward_implications":["If energy efficiency is only ever a byproduct of performance work, then tooling that frames energy savings as an extension of performance tuning will meet less resistance than tooling that asks developers to adopt a separate sustainability goal.","Acceptance of AI-assisted tools depends on net-energy accounting: developers will want evidence that the tool's own computing and training footprint is smaller than the savings it creates.","Explainability is a precondition for trust: each optimisation suggestion must come with a justification the developer can verify, or the tool will not be used on production code.","Integration into existing IDEs and CI/CD pipelines, with non-disruptive feedback, is a necessary condition for regular use; pop-ups and additional workflow steps are explicitly rejected.","The perceived cost-benefit imbalance means tools must produce measurable impact reports that developers can show to management and customers to justify the effort."],"fun_headline_variants":["Energy efficiency in development is just a side effect","Devs see energy savings as accident of performance work","AI energy tools need transparency and proven net savings","Developers want AI energy help but demand transparency","Energy efficiency rarely explicit in dev, interviews find"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that ten developers recruited through the authors' professional networks — nine male, mostly German, averaging 7.5 years of experience — offer a sufficiently representative range of perspectives to ground generalisable requirements for AI-assisted energy-efficiency tools.","fun_headline_variants_meta":{"raw":{"variants":["Energy efficiency in development is just a side effect","Devs see energy savings as accident of performance work","AI energy tools need transparency and proven net savings","Developers want AI energy help but demand transparency","Energy efficiency rarely explicit in dev, interviews find"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000183,"raw_usage":{"total_tokens":1152,"prompt_tokens":745,"completion_tokens":407,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":489,"completion_tokens_details":{"reasoning_tokens":349}},"tokens_in":489,"tokens_out":407,"duration_ms":4423,"temperature":1.0,"reasoning_tokens":349,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T05:32:32.539430+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A direct test would be a larger, pre-registered survey or a workplace observational study with a balanced international sample of developers. If developers in that sample report energy efficiency as an explicit goal in daily work, or show willingness to adopt AI optimisation tools without transparency conditions, then the paper's central claims about absence and conditionality would be falsified. A controlled experiment could also measure adoption of an energy dashboard across two framings — performance versus environment — to test the claim that energy concerns are always secondary.","supporting_citations":[],"review_version":1}