GitHub and Yale survey: 8 in 10 developers want energy-efficiency tooling

Survey finds strong demand for efficiency tooling

GitHub and the Yale Program on Climate Change Communication surveyed 1,039 GitHub users in the United States about software efficiency, climate change and the environmental impact of AI. According to the GitHub Blog post describing the research, the central finding is a mismatch: developers broadly care about the energy their software consumes, but many lack a clear way to find waste, measure an improvement and make the case for fixing it.

Eighty percent of respondents said they were interested in tools for writing more energy-efficient code. Close behind, 78 percent wanted best practices for reducing software's environmental footprint, 74 percent wanted ways to measure the impact of their software or development process, and 70 percent said they would be interested in contributing to open source projects focused on sustainability.

Concern about the wider picture ran high as well: 79 percent said they worry about global warming, 71 percent expressed concern about the environmental impact of AI systems, including their energy and water use and carbon emissions, and 75 percent said it is important that their employer actively works to reduce its environmental impact. The report notes these figures describe respondents' views and do not measure the actual footprint of AI or any individual software system.

GitHub users report more climate concern than US adults

The survey repeated several questions from Yale's nationally representative Climate Change in the American Mind study, and GitHub users consistently registered more concern than US adults overall. Eighty-six percent of respondents said global warming is happening, against 68 percent of US adults; 68 percent expect it to harm them personally at least a moderate amount, against 45 percent; and 82 percent expect at least moderate harm to future generations, against 68 percent.

The report is upfront about the limits of this comparison. The sample was a non-probability group of GitHub users who had opted in to marketing communications, so the results describe survey respondents rather than developers generally, and the gaps versus US adults reflect both population and survey design differences.

The gap is a path to action, not interest

Despite that concern, most respondents saw their own coding as a small lever. Only 10 percent said the way they develop and write software has a large effect on their personal environmental impact, 28 percent said a moderate effect and 63 percent said a small one.

Open-ended answers were notably concrete. Respondents asked for help estimating the footprint of repositories and CI/CD pipelines, identifying unnecessary GitHub Actions runs, improving code efficiency, and comparing AI usage against other sources of compute demand. Several also warned against environmental claims made without evidence, a point the post stresses: faster code can reduce resource use, but runtime alone does not prove lower energy use or emissions, since hardware, workload, timing, location and the source of electricity all shape the result.

The post proposes starting with measurable waste in four areas: code (repeated computation, inefficient algorithms, missing caches), data (over-fetching, unbounded queries, unbatched database calls), network and I/O (duplicate requests, polling that could be event-driven, oversized payloads), and the frontend (unnecessary rendering, eagerly loaded off-screen assets, oversized media). Execution time, CPU use, memory allocation and network transfer size can serve as proxies for computational demand, though each has limits.

An agent workflow that proposes, not decides

Alongside the research, GitHub highlights a concrete tool. Daily Efficiency Improver, an open source GitHub Agentic Workflow, scans a repository for opportunities across code, data, network, I/O and frontend performance, prioritizes changes that can be measured, runs the repository's tests and opens draft pull requests with evidence and trade-offs. It does not merge anything; maintainers stay in control.

The post advises reviewing the workflow's permissions, model use, expected run frequency and compute cost before scheduling it, and treating every recommendation as a hypothesis until benchmarks and tests support it. A strong pull request should state what waste was found, which metric represents the improvement, what the baseline was, whether functionality was preserved and what trade-offs remain.

Why it matters

The survey describes a practical gap in software sustainability: demand exists, but tooling and measurement have not caught up. The suggested path forward is to fold efficiency into the ordinary pull-request loop, with baselines, benchmarks and human review, so that it becomes routine engineering rather than a values statement. The insistence on evidence over green claims matters just as much, particularly as AI workloads grow and attention to datacenter energy use intensifies. GitHub's own answer is deliberately modest: let agents find candidates for improvement, and let people decide whether the evidence holds.