Developers want more efficient software. Here’s what over 1000 GitHub users told us they need.

Most developers accept that efficient software is worth having, but few have a repeatable way to locate waste, prove an improvement, or argue for shipping it. That gap is the headline result of a joint GitHub and Yale Program on Climate Change Communication survey of 1,039 GitHub users.

Interest is not the problem. Roughly 80% of respondents wanted tooling for writing more energy-efficient code, 78% wanted best practices for shrinking software's environmental footprint, and 74% wanted a way to measure the impact of their software or their development process. What's missing is the connective tissue that turns that interest into ordinary engineering work: spot unnecessary compute, propose a change, test it, and let maintainers decide what lands.

What respondents said about climate and AI

The survey drew on U.S.-based GitHub monthly active users and covered climate change, AI, software efficiency, and what organizations across the technology sector owe the environment. Among the results:

• 79% reported being worried about global warming.
• 71% were concerned about AI's environmental impact, naming energy and water use and carbon emissions.
• 75% said it mattered that their employer actively work to reduce its environmental impact.

These numbers describe survey respondents only. They say nothing about the actual footprint of AI or of any individual system, and because the sample was pulled from GitHub users who had opted in to marketing communications, it should not be read as representative of all developers or all GitHub users. What it does show is that a substantial share of these respondents think about the environmental effects of the systems they build and consume.

A sample that skews greener than the U.S. public

Where the survey repeated questions from Yale's nationally representative Climate Change in the American Mind study, GitHub users came out more concerned than U.S. adults as a whole. They were more likely to say global warming is happening (86% versus 68%), to call it at least somewhat personally important (82% versus 65%), and to expect at least moderate personal harm (68% versus 45%). They also more often anticipated at least moderate harm to future generations (82% versus 68%) and described themselves as worried (79% versus 66%).

The interpretation caveat carries over: this is a non-probability sample of opted-in GitHub users, so the gaps reflect differences in both population and survey design rather than a clean national comparison.

Interest outpaces perceived leverage

Only 10% of respondents believed the way they write and develop software has a large effect on reducing their personal environmental impact. Another 28% called the effect moderate; 63% called it small. Yet the same group asked for:

• tools for more energy-efficient code (80%);
• best practices for reducing software's environmental footprint (78%);
• measurement of software or process impact (74%);
• ways to contribute to open source sustainability projects (70%).

Strip away the framing and these are the same things developers expect anywhere else in engineering: useful tools, credible measurement, and reviewable changes. Open-ended answers made the requests concrete — estimating the footprint of repositories and CI/CD workflows, catching unnecessary GitHub Actions runs, tightening code efficiency, and comparing AI use against other sources of compute demand. Several respondents also pushed back on environmental claims made without evidence, and that instinct is sound: runtime is not emissions. Hardware, workload, location, time of day, and the generation mix behind the electricity all shape the outcome, so any claim needs a measurement that matches it.

Find the waste you can actually measure

Efficiency has always been part of good engineering. It cuts infrastructure cost, improves performance, reduces latency, and frees capacity — and when less compute delivers the same successful result, it can cut energy use too. Four areas are a reasonable place to start looking for quantifiable waste:

1. Code — repeated computation, poor algorithmic choices, unnecessary allocations, expensive work that caching would absorb.
2. Data — over-fetching, unbounded queries, absent caching, database calls that should be batched.
3. Network and I/O — duplicate requests, polling that could be event-driven, oversized payloads, missing compression.
4. Frontend — needless rendering, eagerly loaded off-screen assets, media that could ship in smaller formats.

Which metric to cite depends on the change. Execution time, CPU use, memory allocation, and network transfer size all work as proxies for computational demand, each with its own blind spots — so be explicit about what was and wasn't measured. A pull request swapping an O(n²) search for a hash-map lookup, for instance, should carry before-and-after numbers on a representative workload, the commands to reproduce the test, and any memory or maintainability trade-offs. That makes a far stronger case than labeling the change "greener" and stopping there.

Automate the search, keep the decision

Hunting for efficiency wins across a large repository is slow work. GitHub Agentic Workflows can automate the search while leaving maintainers in charge. The open source Daily Efficiency Improver workflow scans a repository for opportunities in code, data, network, I/O, and frontend performance, favors changes that can be measured, runs the repo's tests, and can open draft pull requests carrying the evidence and trade-offs. It never merges on its own.

Adding it to a repository goes through the GitHub CLI:

gh extension install github/gh-aw 

gh aw add-wizard githubnext/agentics/efficiency-improver

Before switching on any scheduled workflow, check permissions, configuration, model usage, run frequency, and likely compute cost. Run it manually or on a scratch repository first. Every recommendation is a hypothesis until benchmarks and tests say otherwise, and the pull requests worth merging answer five things: what waste was found, which metric captures the expected gain, what the baseline was, whether functionality and quality survived, and what trade-offs maintainers should weigh.

AI is useful for searching, testing, and documenting candidate improvements. The judgment call — is the evidence sound, does this change belong here — stays with people.

Close the loop

Efficiency work survives when it lives inside the tools and decisions developers already rely on: a repository-level workflow surfaces an opportunity, a draft pull request shows the fix, benchmarks and tests establish whether it holds, and maintainers accept, revise, or reject. That is the practical support the survey respondents were asking for — tools, measurement, and a route from concern to committed code.

The full Software Developers on Climate Change, AI, and Sustainable Software report is available from GitHub and the Yale Program on Climate Change Communication.