Research conducted jointly by GitHub and the Yale Program on Climate Change Communication has identified substantial appetite among developers for resources that enable them to identify and eliminate inefficient computing. The core challenge, however, is not motivation: most developers recognize that efficient software matters. Instead, they struggle with the mechanics—pinpointing where resources are wasted, demonstrating measurable improvements, and building a case for optimization work within their teams.
The findings come from a survey of 1,039 GitHub users. Eight in 10 respondents expressed interest in tools designed to help them write code that consumes less energy. A similarly high proportion sought guidance on reducing their software's environmental footprint. Roughly three-quarters wanted the ability to measure how their code or development practices affect resource consumption.
The research points to a concrete opportunity: developers can systematize efficiency work by following familiar engineering practices—spotting unnecessary compute, proposing a fix, validating it through testing, and letting code maintainers make the final call on whether to merge.
Environmental concerns run deep among GitHub's developer base
The survey examined attitudes toward climate change, artificial intelligence, software efficiency, and the role of technology companies in addressing environmental harm. Respondents were drawn from GitHub's U.S. monthly active users.
- 79% reported worry about global warming
- 71% expressed concern about the environmental footprint of AI systems, including their energy consumption, water use, and carbon output
- 75% said their employer should actively pursue environmental impact reduction
The survey results reflect the views of respondents only and do not quantify the actual environmental footprint of AI or any specific software. The sample consisted of GitHub users who had opted into marketing communications, so the data should not be generalized to all developers or GitHub users. That said, the responses indicate many developers are actively considering the environmental implications of the systems they create and rely on.
GitHub developers show stronger climate concern than the general U.S. population
When researchers posed questions that also appeared in Yale's nationally representative Climate Change in the American Mind survey, GitHub users demonstrated greater concern about climate issues than U.S. adults as a whole.
- 86% of GitHub users said global warming is occurring, compared with 68% of U.S. adults
- 82% said it is at least somewhat personally important to them, versus 65% of U.S. adults
- 68% expected it to cause them at least moderate personal harm, compared with 45% of U.S. adults
- 82% anticipated at least moderate harm to future generations, versus 68% of U.S. adults
- 79% reported worry about global warming, compared with 66% of U.S. adults
The comparison reflects both demographic differences between the two groups and differences in survey methodology. The GitHub data come from a non-probability sample of users who had opted in to marketing emails, so they describe survey respondents rather than developers as a category.
Interest exists, but developers need practical tools and measurement frameworks
When asked how much their development and coding practices contribute to reducing their personal environmental impact, only 10% of respondents said the effect is large. Another 28% described it as moderate, while 63% said it is small.
- 80% were interested in tools for writing more energy-efficient code
- 78% wanted to learn best practices for reducing software's environmental footprint
- 74% were interested in measuring the environmental impact of their software or development process
- 70% were interested in contributing to open source projects focused on sustainability
Developers are requesting what they expect from other areas of engineering: practical tools, reliable measurements, and changes they can review before acceptance. Open-ended responses pointed to specific needs: estimating the footprint of repositories and CI/CD workflows, identifying unnecessary GitHub Actions runs, improving code efficiency, and comparing AI resource use against other sources of computational demand. Several respondents also cautioned against environmental claims made without supporting evidence.
That last concern is significant. While faster code can reduce resource consumption, execution speed alone does not prove lower energy use or emissions. Hardware, workload, geographic location, time of day, and the energy source all influence the outcome. Developers need measurements that substantiate the claims being made.
Start by identifying and measuring observable waste
Software efficiency is already recognized as sound engineering practice. It lowers infrastructure costs, improves performance, reduces latency, and frees up capacity. When an improvement cuts the compute required to deliver the same result, it can also lower energy consumption.
A practical first step is to search for measurable waste in four categories:
- Code: repeated computation, inefficient algorithms, unnecessary allocations, or expensive operations that could be cached
- Data: over-fetching, unbounded queries, missing caching, or database calls that should be batched
- Network and I/O: duplicate requests, polling that could be event-driven, oversized payloads, or missing compression
- Frontend: unnecessary rendering, eagerly loaded off-screen assets, or media that could use smaller formats
The appropriate metric depends on the specific change. Execution time, CPU use, memory allocation, and network transfer size can all serve as useful proxies for computational demand. Each has limitations, so it is important to state what was measured and what was not.
For instance, a pull request replacing an O(n²) search with a hash-map lookup should include before-and-after measurements for a representative workload, the commands needed to reproduce the test, and any trade-offs in memory or maintainability. This approach builds a stronger engineering case than labeling the change "greener" without data.
Let AI agents surface opportunities, but keep humans in charge of decisions
Searching a large repository for efficiency opportunities can be time-consuming. GitHub Agentic Workflows can automate the search while preserving maintainer control.
The open source Daily Efficiency Improver workflow examines a repository for opportunities across code, data, network, I/O, and frontend performance. It prioritizes changes that can be measured, runs the repository's tests, and can open draft pull requests with evidence and trade-offs for maintainers to review. It does not merge changes on its own.
To add the workflow to a repository using the GitHub CLI:
gh extension install github/gh-aw gh aw add-wizard githubnext/agentics/efficiency-improver
Before enabling a scheduled workflow, review its permissions, configuration, model use, expected run frequency, and likely compute cost. Start with a test repository or run it manually. Treat every recommendation as a hypothesis until benchmarks and tests validate it.
The strongest pull requests should address five questions:
- What waste did the workflow find?
- Which metric represents the expected improvement?
- What was the baseline?
- Did the change preserve functionality and quality?
- What trade-offs should maintainers consider?
AI can assist developers in searching, testing, and documenting potential improvements. However, humans remain responsible for determining whether the evidence is sound and whether the change should be included in the codebase.
Embed efficiency into the standard engineering workflow
Efficiency work is most sustainable when it integrates with the tools and processes developers already use. A repository-level workflow can identify an opportunity. A draft pull request can present the proposed solution. Benchmarks and tests can verify whether it works. Maintainers can then accept, modify, or decline the change.
This cycle provides the practical support survey respondents requested: tools, measurement, and a clear route from concern to code.