Developers Want More Sustainable AI - CourtneyR.dev's 2nd Brain

Developers Want More Sustainable AI ![rw-book-cover](https://res.cloudinary.com/leaddev/image/upload/f_auto/q_auto/dpr_auto/c_limit,w_4000,h_2250/next/2025/02/5.png) 🔗 **Source:** [Developers Want More Sustainable AI](https://leaddev.com/ai/developers-want-more-sustainable-ai) > [!note]+ Document Notes > tags: [sustainable-ai, ai-energy-consumption, developer-sentiment, climate-change, software-efficiency] > author: Bill Doerrfeld > source: LeadDev > reference: https://leaddev.com/ai/developers-want-more-sustainable-ai > date created: 2026-09-28 08:39 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Developers want more sustainable AI >  ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [GitHub x Yale YPCCC joint report](https://climatecommunication.yale.edu/publications/github-survey/) — the survey the whole article reports on - [IEA: Energy demand from AI](https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai) — source for the 1.5%-of-global-electricity figure - [MIT Sloan: Will AI derail global climate goals?](https://mitsloan.mit.edu/press/will-ai-derail-global-climate-goals?utm_source=chatgpt.com) — source for the 0.1 degree C warming estimate ## 📝 Summary - **What happened.** A joint GitHub / Yale Program on Climate Change Communication (YPCCC) report surveyed 1,039 US GitHub monthly active users on climate change, AI's environmental impact, and sustainable engineering practice. - **The claim.** 63% think AI systems contribute to climate change "a great deal" or "a moderate amount"; 70% want tech companies and employers to do more; 80% want tools that help them write more energy-efficient code. - **Concrete asks.** The report's qualitative section (¶20, list) names seven specific developer requests: renewable-powered data centers, tools to measure software's environmental impact, energy-efficiency scores for large open-source projects, metrics for the computational toll of GitHub Actions, delaying unnecessary compute-heavy CI/CD steps, more efficient open-source local AI models, and help writing efficient code. - **Why it matters.** The survey lands as AI workloads drive new data-center construction, and as IEA names AI the top driver of future electricity demand growth. - **Key stakeholders.** GitHub (Paull Young, head of sustainability), Yale YPCCC, Pascal Joly (IT Climate Ed), anonymous surveyed developers, and by extension employers, cloud providers, and regulators, whom respondents assign more responsibility than themselves. - **Risks and tradeoffs.** The sample is US-only, self-selected GitHub users, and the article says so plainly. The MIT Sloan 0.1 degree C figure is one modeled scenario, not a settled forecast. Respondents rate their own individual impact as "small" (63%) while naming institutional-level fixes (data centers, OSS scoring, CI/CD metrics) rather than personal habit changes — consistent, not contradictory, though the article never tests whether GitHub or employers act on the list. - **Bottom line.** Developers want the fix applied upstream of their own keyboard: efficient models, employer accountability, and better visibility into energy costs, more than they want to change their own habits. ## 📖 Main content - The report's spine is a belief gap: strong agreement that global warming is real and AI contributes to it, next to a belief that responsibility sits mostly with institutions rather than individual coding choices (¶2, ¶6, ¶18). - Compute scale gives the belief its backdrop: data centers used about 1.5% of global electricity in 2024 per the IEA, and MIT Sloan models AI's direct emissions contributing roughly 0.1 degree C of extra warming by 2100 under current trends, rising in a high-adoption scenario (¶8-¶9). - Pascal Joly (IT Climate Ed) widens the footprint past electricity: air pollution from backup generators, cooling-system noise, and water consumption (¶10), arguing operational emissions "may look small" today but are "growing rapidly" (¶11). - The qualitative comments name two waste sources: model choice ("give me efficient AI, not frontier AI," ¶14) and general software bloat that stays invisible to the people writing it (¶15-¶16). The article links this to separate reporting on AI-era duplicate code, technical debt, and maintainability decline (¶17), though that's the reporter's extension, not a survey finding. - Between the complaints and the experts' advice sits a direct developer wishlist (¶20, list): renewable-powered data centers, tools to measure software's environmental impact, energy-efficiency scores for large open-source projects, metrics for the computational toll of GitHub Actions, delaying unnecessary compute-heavy CI/CD steps, more efficient open-source local AI models, and help writing efficient code. These are the surveyed developers' own asks, distinct from the Young/Joly recommendations that follow. - Recommendations from Young and Joly are concrete and sequential: start with a problem the team already wants fixed (¶22), get educated on the scale of the problem (¶24), then baseline and track AI energy/emissions alongside cost dashboards and consider smaller open-weight models sized to the task (¶25-¶26). - Uncertain or contested: the survey's representativeness (self-flagged, ¶27); whether "small individual impact" is accurate self-assessment or diffusion of responsibility; and whether GitHub, as the entity commissioning the report, has an incentive to frame the fix as tooling it can sell rather than models it should shrink. ## 🗒️ Notes #### ¶0–¶13 Developers care deeply about future sustainability - Frame (¶0-¶1): developers say they care about sustainability and want employers to act on AI's environmental impact. - Headline numbers (¶2-¶4): the GitHub/Yale YPCCC survey of 1,039 US GitHub monthly active users finds 63% think AI contributes to climate change "a great deal or a moderate amount," and 70% want tech companies and employers to do more; Paull Young frames this as developers wanting help making software more efficient. - Climate belief context (¶6-¶7): 86% say global warming is happening, higher than the general US-adult comparison in Yale's national survey; 79% are worried, and 82% expect it to harm future generations at least moderately. - Compute-scale context (¶8-¶9): data centers used about 1.5% of global electricity in 2024 (IEA), which names AI the top driver of future growth; MIT Sloan estimates AI's direct emissions could add roughly 0.1 degree C of warming by 2100, or push a 25%-GWP-boost scenario from 3.3 to 3.6 degrees C above pre-industrial levels. - Broader footprint and concern (¶10-¶13): Joly adds air pollution, generator noise, and water use to the footprint, warning operational emissions are "growing rapidly"; 71% are concerned about AI's environmental impact and three in four say it matters that their employer actively reduces its footprint. #### ¶14–¶19 Developers: kill unnecessary resource drains - Model inefficiency (¶14): one respondent wants "more efficient AI models," explicitly preferring local, efficient AI over frontier models. - Process waste (¶15-¶16): another respondent says a "ton of wasted energy" comes from inefficient, unwanted software generally, and that energy and environmental impacts stay hidden from developers because they're abstracted away. - AI-generated code risk (¶17): the article links this to separate reporting on rising duplicate code, technical debt, and declining maintainability in the AI coding era, as a further, unmeasured resource driver. - Responsibility split (¶18): 63% rate their own individual coding practices as having only a "small" environmental effect, and place more responsibility on governments, regulators, cloud providers, and employers. - Tooling appetite (¶19): despite that, 80% say they're interested in tools that help them write more energy-efficient code. #### ¶20–¶26 Ways software teams can improve efficiency - Setup (¶20, list): the report's qualitative section lists seven concrete developer asks: renewable-powered data centers, tools to measure software's environmental impact, energy-efficiency scores for large open-source projects, metrics for the computational toll of GitHub Actions, delaying unnecessary compute-heavy CI/CD steps, more efficient open-source local AI models, and help writing efficient code. - Training call (¶21): one respondent wants help to "train the current and future generations of developers in how to architect and design for sustainability." - Start small (¶22-¶23): Young recommends starting with something the team already wants fixed, whether a slow build, an expensive workload, or unnecessary code, and looping in the sustainability team, since cost, performance, and sustainability teams "often have more shared interests than they realize." - Education first (¶24): Joly says the first step is getting educated, so leaders can "clearly communicate to their team the magnitude of the problem." - Measure and downsize (¶25-¶26): Joly recommends baselining AI tools' energy consumption and emissions, tracking them alongside token-cost dashboards, and considering smaller open-weight models matched to the task, which can carry a lower carbon footprint than frontier models. #### ¶27–¶29 Doing our bit for sustainable AI - Caveat (¶27): the survey isn't representative of programmers at large, but GitHub's scale (over 200 million developers) makes it a useful signal of developer attitudes. - Business stakes (¶28): sustainability could affect morale and talent retention, and the rising cost of AI platforms is a second motivator beyond climate concern. - Generalization (¶29): most recommendations, aimed at GitHub, could apply to software organizations broadly as they build more efficient coding and AI practices. ## 📚 References - [GitHub x Yale YPCCC joint report](https://climatecommunication.yale.edu/publications/github-survey/) — primary source for the 63%/70% headline figures (¶2) and the survey's methodology. - [IEA: Energy demand from AI](https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai) — source for the 1.5%-of-global-electricity-in-2024 figure and AI as the top demand driver (¶8). - [MIT Sloan: Will AI derail global climate goals?](https://mitsloan.mit.edu/press/will-ai-derail-global-climate-goals?utm_source=chatgpt.com) — source for the 0.1 degree C warming estimate and the 3.3-to-3.6-degree scenario (¶9). - [LeadDev: GreenOps offers a sustainable solution for busy engineering teams](https://leaddev.com/culture/feeling-the-squeeze-greenops-offers-a-sustainable-solution-for-busy-engineering-teams) — linked from the term "climate change" (¶1), a related LeadDev piece on operationalizing sustainability. - [McKinsey: Colocation data centers, the infrastructure race behind AI](https://www.mckinsey.com/mgi/our-research/colocation-data-centers-the-infrastructure-race-behind-ai) — linked from "being constructed" (¶5), supporting the data-center build-out claim. - [LeadDev: Best AI coding assistants](https://leaddev.com/ai/best-ai-coding-assistants) — linked from "AI" near the top; a related LeadDev topic hub, not evidence for a specific claim. - [LeadDev: How AI-generated code accelerates technical debt](https://leaddev.com/technical-direction/how-ai-generated-code-accelerates-technical-debt) — supports the technical-debt extension in ¶17. - [LeadDev: Code maintainability plummets in the AI coding era](https://leaddev.com/ai/code-maintainability-plummets-in-the-ai-coding-era) — supports the maintainability-decline extension in ¶17. - [LeadDev: The Engineering Leadership Report 2026](https://leaddev.com/the-engineering-leadership-report-2026/) — linked from "engineering leadership" (¶22). - [LeadDev: How to maintain team morale during a downturn](https://leaddev.com/management/how-maintain-team-morale-during-downturn) — supports the morale point in ¶28. - [LeadDev: Seven things you need to know about retaining engineering talent](https://leaddev.com/career-development/seven-things-you-need-know-about-retaining-engineering-talent) — supports the talent-retention point in ¶28. - [LeadDev: Why your AI bill is bigger than it should be](https://leaddev.com/ai/why-your-ai-bill-is-bigger-than-it-should-be) — supports the "rising cost of AI platforms" point in ¶28. - Two links in the markup ("article hero" and one blank anchor) both point back to the article's own URL. These are navigational/masthead chrome, not citations, and are not evidence for any claim in the piece. ## 🗣️ Paraphrase - A GitHub/Yale survey of over a thousand US GitHub users finds most developers already believe AI has a climate cost, and most want their employers to do something about it. - Belief in climate change generally runs higher in this developer sample than in the US public comparison Yale uses, and most are worried about it. - The scale question is real: data centers already draw a meaningful slice of global electricity, and AI is the reason that slice is growing. - An independent voice, Pascal Joly, adds that the footprint isn't just electricity: it's air pollution, cooling noise, and water use too, and it's compounding. - When developers get specific about waste, they point first at model choice (efficient over frontier) and second at generic software bloat that no one can see the cost of while writing it. - Developers mostly don't blame themselves: most rate their own coding choices as a small factor and put more weight on governments, cloud providers, and employers. - Even so, most want tools that would make their own code more efficient, which is a real appetite for something that doesn't fully exist yet. - The advice from both quoted experts is sequential and practical: pick a fight the team already wants, get educated on the scale, then measure your AI tools' energy and emissions the way you already measure their dollar cost. - The article is upfront that the sample isn't representative of all programmers, but argues GitHub's reach still makes it a useful read on attitudes. ## 📰 Newsletter **Developers want the fix upstream of their own code.** A new GitHub/Yale survey finds most developers believe AI carries a real climate cost, and most want employers, cloud providers, and regulators to act on it before they change their own habits. The concrete asks are specific and varied: renewable-powered data centers, tools to measure software's environmental impact, energy-efficiency scores for large open-source projects, compute-toll metrics for GitHub Actions, delaying compute-heavy CI/CD steps, more efficient open-source local models, and help writing efficient code, on top of the baseline-then-downsize sequence Joly recommends. For anyone building or documenting AI-assisted WordPress workflows, the practical takeaway is Pascal Joly's sequence: baseline your AI tool's energy use before you pick a smaller model, because you can't show the savings without a starting number. And if your team already tracks a slow build or an expensive workload, that's the entry point Paull Young recommends, not a separate sustainability initiative competing for attention. ## ✅ Action items #### DevRel - Developer advocacy: build a short talk or post on "picking a model size for the task," using Joly's baseline-then-downsize sequence as the worked example. - Education: run a workshop that has developers estimate their AI tool's per-task energy/cost, then compares the guess against an actual baseline. - Developer experience: when documenting AI-assisted tooling, publish the smallest model that still meets the task, not just the most capable one. - Developer marketing: don't lead with the vendor's own commissioned-survey number without naming the sample size and scope, the way this article does in ¶27. - Community management: host a thread asking developers what "efficient AI, not frontier AI" (¶14) means in practice for their own stack. - Internal/external/cross-project: track whether GitHub ships the tooling its own survey says 80% of respondents want, and revisit this note when it does. #### OSPO - Policy & Governance: evaluate whether project defaults nudge contributors toward the largest available model when a smaller one would do. - License Compliance: not directly addressed by this source. - Security Management: no security claim in this source to act on. - Software Inventory: add default model size/provider to any agent or AI-tooling SBOM entry, alongside license and version; the survey's own wishlist (¶20, list) separately asks for energy-efficiency scores on large open-source projects and compute-toll metrics for GitHub Actions, both are inventory-shaped asks OSPO could pilot directly. - Developer Support: publish a short guide on matching model size to task, referencing Joly's recommendation. - Community Engagement: watch whether upstream AI-tooling projects publish energy/emissions baselines alongside cost, per Joly's ¶25 recommendation. - Strategic Alignment: add "energy/emissions baseline exists" as a criterion alongside cost when evaluating AI tooling adoption. #### Community - Maintainers: state, in project docs, which model size the project defaults to and why, so downstream users can judge the tradeoff themselves. - Contributors: when proposing an AI-assisted feature, note the model size used and whether a smaller one was tried. - Sponsors: consider funding an independent, non-vendor-commissioned version of this survey outside the US and outside GitHub's own user base, since the article names both as limits (¶27). - Ecosystem: share a common format for reporting AI tool energy/emissions baselines, so teams can compare across projects. #### WordPress - Core: not applicable. Nothing in this source touches WordPress core directly. - Core Performance: the survey's own asks for "metrics for the computational toll of GitHub Actions" and "delaying unnecessary compute-heavy CI/CD steps" (¶20, list) map directly onto wordpress-develop's GitHub Actions test matrix; the "start with what the team already wants fixed" advice (¶22) applies the same way. Add compute-time tracking to the existing performance-profiling backlog. - Core AI: when documenting Core AI features, note the model size/provider default and whether a smaller model was evaluated, echoing Joly's task-matching advice. - **Core Program Team:** add "does this feature's AI default match task size" as a cross-team question for AI-facing proposals. - Mobile: not applicable. - Playground: not applicable. No AI-tooling angle specific to Playground in this source. - Community: WordCamp talk angle: "your plugin's AI feature has a carbon line item," pairing this survey's numbers with the aws-strands note's token-cost angle. - Training: add a Learn lesson on choosing model size for AI-assisted WordPress workflows, referencing this survey's tooling-interest number (80%). - Marketing: not applicable. This is developer-sentiment research, not a WordPress-specific announcement. - Support: not applicable. - Design: not applicable. No UI in scope. - Documentation: not applicable directly, though any docs on AI feature configuration could note model-size tradeoffs. - Photos: not applicable. - TV: not applicable. - Polyglots: not applicable. - Accessibility: not applicable. The source has no accessibility content of its own. - Meta: not applicable. - CLI: not applicable. - Hosting: hosts running AI-adjacent infrastructure could publish per-workload energy/emissions figures, mirroring Joly's baselining advice at the hosting layer. - Tide: not applicable. - Openverse: not applicable. - Themes: not applicable. - Plugins: plugin authors adding AI features should default to the smallest model that meets the feature's task, and document that choice. #### The WPOCC - Programs: consider a microgrant for an independent replication of this survey scoped to WordPress contributors specifically. - Projects: not a natural fit for a dedicated project; nearest relevance is documentation work on model-size defaults for community AI tooling. - Funding experiments: test a milestone payout for publishing a reproducible energy/emissions baseline for a community-run AI tool. ### FAIR - Technical independence: Joly's push toward smaller, open-weight models sized to the task, and the survey's own request for "more efficient, open-source local AI models" (¶20, list), both line up with FAIR's preference for options that don't require a single large vendor's frontier model. - Policies and covenants: not directly addressed; the source has no governance-capture content. - Productized governance artifacts: the survey's request for "energy-efficiency scores for large open-source projects" (¶20, list) is a ready-made scorecard row FAIR could adopt directly. ## 🧪 Hypotheses - H1: Developers who report high concern about AI's environmental impact (the 71% figure, ¶12) are more likely to say they want energy-efficient coding tools (the 80% figure, ¶19) than developers with low concern. - H2: Teams that adopt smaller, task-matched open-weight models show measurably lower per-task energy and cost than teams defaulting to frontier models, without a proportional drop in output quality. - H3: Publishing energy/emissions dashboards alongside existing token-cost dashboards increases the rate at which teams act on identified inefficiencies, following Young's "start with what the team already wants fixed" (¶22). - H4: AI-generated code with elevated duplicate-code or technical-debt markers correlates with higher compute cost per feature shipped, independent of which model generated it. - H5: Developers' self-reported "small" individual environmental impact (63%, ¶18) is a systematic underestimate once they're shown their own AI tool's actual per-task energy or cost baseline. ## 📊 Methodology - H1: cross-tabulate the concern-level survey item against the tooling-interest item in the underlying GitHub/Yale dataset, controlling for role and company size. - H2: run matched coding tasks on a frontier model and a smaller open-weight model sized to the same task, measuring energy draw (or a token-times-carbon-intensity proxy) and task success rate. - H3: pilot an energy/emissions line item on an existing cost dashboard in one engineering org for a quarter, and compare remediation rate against a control team without it. - H4: correlate duplicate-code rate and complexity delta in AI-assisted repos against measured build/CI compute time, controlling for repo size. - H5: have a sample of developers estimate their AI tool's per-task energy or cost, then show them Joly's kind of actual baseline, and measure the gap between estimate and reality. ## ❓ Questions - How much of the gap between "AI contributes to climate change" (63%) and "employers should do more" (70%) reflects genuine belief about scale versus a preference for blaming institutions over self? - Does "efficient AI, not frontier AI" (¶14) mean smaller open-weight models specifically, or also routing and caching strategies that avoid a model call entirely? - What is the actual per-task energy difference between a frontier model and a matched smaller model on the tasks these developers run daily? - Would GitHub's own product roadmap reflect the 80% tooling-interest figure, or lag behind it? - How sensitive is the MIT Sloan 0.1 degree C estimate to the 25%-GWP-boost assumption, and what does the estimate look like under lower-adoption scenarios? - Does baselining energy and emissions, as Joly recommends, actually change model-selection behavior, or does it produce a report nobody acts on, the way many carbon dashboards do? - Is the "abstracted away" complaint (¶16) really about visibility, or about developers lacking the authority to act once visibility exists? ## 🔮 Future research - Longitudinal tracking of whether "interested in efficiency tools" (80%) converts into actual adoption once such tools ship. - Comparative energy and cost benchmarking across model sizes on realistic, not synthetic, developer workloads. - Study of whether merging sustainability and cost dashboards changes engineering prioritization decisions, versus running as parallel, ignored metrics. - Replication of the GitHub/Yale survey outside the US and outside GitHub's own user base, directly testing the representativeness caveat the article raises itself (¶27). ## 💡 Implications - **Practice.** Model-size selection and tool-output efficiency become a visible line item next to cost, following Joly's baseline-and-track recommendation (¶25). - **Policy.** The survey's own framing (¶18) puts more responsibility on governments, regulators, and cloud providers than on individual developers, which argues for disclosure requirements, such as per-query energy or carbon reporting, rather than developer-facing nudges alone. - **Security.** Not a strong throughline in this source. The nearest connection is that "wasted," unwanted software (¶15) overlaps with the same bloat that widens attack surface, though the article doesn't draw that line itself. - **Education.** Young and Joly both name education as the first lever (¶21, ¶24), pointing toward curricula that teach architecting for sustainability alongside cost and performance, not as a separate elective. - **Funding.** The "shared interests" argument (¶23) suggests sustainability work gets funded fastest when bundled with cost or performance initiatives, not pitched as a standalone ask. ## 🧠 Learning styles assessment - Reading level estimate: Flesch-Kincaid grade approximately 11, estimated from roughly 860 prose words, an average sentence length near 18 words, and recurring multisyllabic technical and statistical vocabulary ("environmental," "infrastructure," "gross world product," "pre-industrial"). #### 👀 Visual learners - Present: no charts or graphs in the captured content, and the article's numeric findings sit in prose rather than a table or figure. - Improve: a simple bar chart of the headline percentages (63, 70, 86, 79, 82, 71, 63, 80) would carry more information than the current paragraph-by-paragraph delivery. #### 🔊 Aural learners - Present: none in the captured content. - Improve: a short audio summary of the headline stats for anyone skimming rather than reading closely. #### 🗣️ Verbal learners - Present: direct, attributed quotes from Young and Joly plus anonymous developer quotes give verbal learners real voices to anchor each point. - Improve: a one-line glossary for "YPCCC," "gross world product," and "open-weight models." #### 🧩 Kinesthetic learners - Present: nothing hands-on; this is a reporting piece, not a how-to. - Improve: a linked checklist version of Joly's three-step recommendation (baseline, track, match model size to task). #### 🧠 Logical learners - Present: a clean run of numbered stats (63%, 70%, 86%, 79%, 82%, 71%, 63%, 80%) across the piece. - Improve: one table mapping each stat to its source study (GitHub/Yale survey vs. IEA vs. MIT Sloan) would remove the need to track which number came from which source while reading. #### 🧑‍🤝‍🧑 Social learners - Present: three named, attributed voices plus anonymous developer comments simulate a small panel of perspectives. - Improve: a comment thread or forum link where developers could compare their own AI tool's energy or cost baseline against others'. #### 🧘‍♀️ Solitary learners - Present: short, self-contained sections a reader can finish in under five minutes. - Improve: a short self-check tied to Joly's baselining advice, such as "do you know your own AI tool's per-task energy draw?" #### 🌿 Naturalistic learners - Present: the entire piece is already framed in environmental terms: emissions, water use, air pollution, warming scenarios. - Improve: a link to a per-model or per-provider footprint comparison would give the aggregate figures a concrete point of contrast. ## 📊 Accessibility assessment #### Screen reader semantics - Present: the article's four section headings ("Developers care deeply about future sustainability," "Developers: kill unnecessary resource drains," "Ways software teams can improve efficiency," "Doing our bit for sustainable AI") give real landmarks, not generic "Section 1/2/3" labels. - Improve: the "article hero" link and one blank-text anchor near the top both point to the article's own URL with no descriptive link text; a screen reader announces either "link" or an unverified image alt text with nothing to distinguish the two. #### Keyboard navigation - Not assessable from captured content. This needs a live-page audit for focus order and skip links. #### Contrast and readability - Not assessable from captured content. No color or typography data was captured; the reading-level estimate above is measurable, contrast is not, from this capture. #### Text resizing and reflow - Not assessable from captured content. #### Media and captions - No embedded audio or video in the captured markup. Not applicable. #### Forms and interactions - No forms in the captured content. Not applicable. #### Standards reference - WCAG 2.4.4 Link Purpose in Context: most in-body links use descriptive anchor text ("engineering leadership," "morale," "talent retention," "rising technical debt," "declining code maintainability"), which passes. The masthead-style "article hero" link and the blank anchor fail this in spirit, even if they're template chrome rather than body copy. - WCAG 1.1.1 Non-text Content: the hero image's alt text wasn't captured by this pipeline, so it can't be verified either way. - WCAG 1.3.1 Info and Relationships: the four section headings, if rendered as real heading elements on the live page, give the piece a navigable structure; this can't be confirmed from the captured markup alone. ## 🌍 DEIB assessment #### Cultural breadth - Present: the survey is explicitly scoped to US GitHub users (¶4) and compared against a US-adult baseline (¶6), and the article names this limit rather than hiding it. - Improve: no non-US developer voices, and no discussion of how regional grid mix changes the per-query footprint the article discusses only in aggregate. #### Inclusive language - Present: gender-neutral throughout; anonymous respondent quotes carry no gendered framing. - Improve: terms like "gross world product" and "open-weight models" go undefined for a non-specialist reader. #### Neurodiversity support - Present: short paragraphs, largely one stat per sentence, and four clear section headings. - Improve: no summary box up top collecting the headline numbers before the narrative unpacks them. #### Representation - Present: three named voices (Doerrfeld reporting, Young at GitHub, Joly at IT Climate Ed) mix a vendor perspective with an independent consultancy, plus anonymous developer quotes. - Improve: no voice from a data-center operator, a grid or utility engineer, or a developer already shipping an efficient-AI product, any of which would sharpen the "who actually acts on this" picture. #### Psychological safety - Present: a respectful, non-alarmist tone that treats climate concern as widely shared rather than fringe. - Not applicable beyond that: no conflict, blame, or harm content to flag. ## ✅ Logical validity #### Strong reasoning - The article separates belief-in-the-problem (86% say global warming is happening) from responsibility-for-the-fix (63% rate their own coding impact as small, ¶18), rather than treating "developers care" and "developers should personally fix this" as the same claim. That distinction is the piece's most defensible piece of reasoning. - It also flags its own survey's limits (¶27) at the exact point a reader might over-read the number, rather than burying the caveat elsewhere. #### Fallacies - **Appeal to scale (¶27).** The article cites GitHub's "over 200 million developers" as grounds for calling the survey "a useful window," but a self-selected, US-only, 1,039-respondent sample of GitHub users doesn't inherit representativeness from GitHub's total user count. Fix: report the sample's role, seniority, and regional breakdown alongside the platform-scale figure. - **Unsourced causal extension (¶17).** "Inefficient AI-generated code could also contribute to unnecessary resource consumption" reads as a plausible extension of the survey's findings, but it is the reporter's inference: no study cited in the piece measures the energy cost of duplicate code specifically. Fix: label the sentence explicitly as inference, separate from the cited GitHub/Yale data. - **False precision (¶9).** "0.1 degree C of additional global warming by 2100" is stated first as a plain figure, with the underlying scenario's 25%-GWP-boost assumption arriving only in the next sentence. Fix: state the scenario's assumption in the same sentence as the headline number. #### Tone of voice - Measured, advocacy-adjacent trade-press tone. It largely platforms GitHub's own sustainability messaging, since Young is a GitHub employee, without much daylight between the vendor's framing and the reporter's; Joly's independent quotes supply a second, less GitHub-centric voice. ## 🛡️ DARVO analysis - Deny: none. No party in the piece denies a claim made against them. - Attack: none. No attacks on critics, accusers, or competitors appear. - Reverse victim/offender: none. - Not applicable to this source: it is a survey report with no accusation or dispute in play, not a response to criticism. ## 🎯 Conclusion - Bottom line: developers believe AI carries a real climate cost, across several belief measures ranging from 63% to 86%, and want employers, vendors, and regulators, not just themselves, to fix it, while 80% say they'd use tools that made their own code more efficient. Developers' own list of asks (renewable-powered data centers, environmental-impact measurement tools, open-source energy-efficiency scores, GitHub Actions compute metrics, trimming compute-heavy CI/CD, more efficient open local models, and help writing efficient code) sits alongside the expert-recommended levers: model-size matching, energy and emissions baselining next to cost dashboards, and starting from a problem the team already wants fixed. - Next steps: read the underlying GitHub/Yale YPCCC report for the demographic breakdown behind the topline percentages. Before picking a smaller model for any AI-assisted workflow, baseline the current one's energy or cost first, per Joly's sequence, since the savings can't be shown without a starting number. ## 🔄 Refactor Appendix — Developers want more sustainable AI > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. ### 📚 Literature Atoms (H3) #### [H1] Developers place responsibility on institutions, not themselves > [!quote] ¶18 > they place more responsibility on governments and regulators, cloud providers, tech companies, and employers to act **Context & use**: - Follows the 63%-say-small-impact finding on individual coding practices. - Reframes "developers care about sustainability" as a demand for upstream fixes, not a personal-behavior pledge. **Tags**: #xref  #### [H2] Developers ask for efficient models, not frontier ones > [!quote] ¶14 > Give me more efficient AI models. I don’t care about frontier models. **Context & use**: - Anonymous respondent quote under "model inefficiency." - Names the specific lever (model size/efficiency) developers point to first, ahead of process or tooling fixes. **Tags**: #xref #articleseed  #### [H3] Energy costs stay invisible to the people writing the code > [!quote] ¶16 > The energy and environmental impacts are completely obscured from the developers as they are abstracted away, **Context & use**: - Follows the "wasted energy" quote about inefficient, unwanted software. - The visibility gap this names is exactly what Joly's baselining recommendation (¶25) is meant to close. **Tags**: #xref #share  ### 🧠 Permanent Candidates (H4) #### [P1] Model size is a sustainability lever, not just a cost one **Claim** (one sentence, Courtney's voice): Choosing the smallest model that meets a task cuts both the AI bill and its energy footprint together, so the two are the same decision, not a tradeoff. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds when a team can verify the smaller model still meets the task's accuracy bar; weakens for tasks that genuinely need frontier-level capability, where downsizing trades quality for savings instead of removing waste. **Links** (≥1 with annotation): - [[Tool output size is an agent cost lever]] — because contrasts on which layer carries the cost, harness context-management versus model-size choice - [[AI energy consumption]] — because extends - [[WordPress Core AI]] — because applies-in choosing default models for AI-assisted content workflows  ### ✏️ Fleeting Queue - [F1] Pull the actual demographic breakdown from the GitHub/Yale YPCCC report (role, seniority, region) behind the topline percentages — https://climatecommunication.yale.edu/publications/github-survey/ #fleeting #inbox - [F2] Check whether any WordPress Core AI feature documents its default model size, and whether a smaller one was evaluated #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a short note on baselining an AI tool's energy or cost before swapping model size — Joly's sequence, ¶25 #things - [ ] Read the GitHub/Yale YPCCC report methodology section for the sample's role/seniority breakdown #things  📄 **Full text:** [[Full Document Contents/Articles/Developers Want More Sustainable AI.md|Developers Want More Sustainable AI by Bill Doerrfeld]] ## Highlights - One respondent highlights model inefficiency: “Give me more efficient AI models. I don’t care about frontier models. I care about local AI. I care about efficient AI.” ([View Highlight](https://read.readwise.io/read/01m3m10h7cnwmeysvdd8qeyr7b)) - Note: [H2] Developers ask for efficient models, not frontier ones - Tags: atom/literature/h2 - The energy and environmental impacts are completely obscured from the developers as they are abstracted away, they add. “Highlighting the energy and environmental impacts to the development community needs more attention.” ([View Highlight](https://read.readwise.io/read/01m3m10j1zf8wq08vw5zg108a5)) - Note: [H3] Energy costs stay invisible to the people writing the code - Tags: atom/literature/h3 - Most respondents see their individual coding practices as having a relatively small environmental impact – 63% say its effect is “small.” Instead, they place more responsibility on governments and regulators, cloud providers, tech companies, and employers to act. ([View Highlight](https://read.readwise.io/read/01m3m10gg397tc32jvsrwkd76q)) - Note: [H1] Developers place responsibility on institutions, not themselves - Tags: atom/literature/h1