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

Developers know efficient software matters, but many lack a clear way to find waste, measure an improvement, and make the case for fixing it.

That is the central finding from a new survey of 1,039 GitHub users conducted by GitHub and the Yale Program on Climate Change Communication. Eight in 10 respondents said they were interested in tools that help them write more energy-efficient code. Nearly as many wanted best practices for reducing software’s environmental footprint, and almost 75% wanted ways to measure the impact of their software or development process.

There is an opportunity to turn that interest into normal engineering work: identify unnecessary compute, propose a change, test it, and let maintainers decide what ships.

Developers care about climate change and AI’s environmental impact

The survey, drawn from GitHub monthly active users in the United States, asked about climate change, AI, software efficiency, and the responsibilities of organizations across the technology sector.

The concern was clear:

• 79% said they were worried about global warming.
• 71% said they were concerned about the environmental impact of AI systems, including their energy and water use and carbon emissions.
• 75% said it was important that their employer actively work to reduce its environmental impact.

These findings describe the views of survey respondents. They do not measure the environmental footprint of AI or any individual software system. The sample was drawn from GitHub users who had opted in to receive marketing communications, so the results should not be treated as representative of every developer or GitHub user.

They do show that many developers are thinking about the environmental effects of the systems they build and use.

GitHub users differ from the broader U.S. adult population

When asked questions that also appeared in Yale’s nationally representative Climate Change in the American Mind survey , GitHub users expressed greater concern about climate change than U.S. adults overall.

GitHub users were more likely to say global warming is happening (86% compared with 68% of U.S. adults), that it is at least somewhat personally important (82% compared with 65%), and that it will harm them personally at least a moderate amount (68% compared with 45%). They were also more likely to expect at least moderate harm to future generations (82% compared with 68%) and to say they were worried about global warming (79% compared with 66%).

One note on interpretation: the data in this report are based on a non-probability sample of GitHub users who had opted in to marketing emails, so the findings describe survey respondents rather than developers generally, and differences from data for U.S. adults reflect both population and survey design differences.

The gap is not interest. It’s a practical path to action

Only 10% of respondents said the way they develop and write software has a large effect on reducing their personal environmental impact. Another 28% said it has a moderate effect, while 63% said the effect is small.

At the same time:

• 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 asking for the same things they expect in other areas of engineering: useful tools, credible measurements, and changes they can review.

Open-ended survey responses illustrated the concrete. Respondents asked for help estimating the footprint of repositories and CI/CD workflows, finding unnecessary GitHub Actions runs, improving code efficiency, and comparing AI use with other sources of compute demand. Several also warned against making environmental claims without evidence.

That last point matters. Faster code can reduce resource use, but runtime alone does not prove a reduction in energy use or emissions. Hardware, workload, location, time, and the source of electricity all affect the result. Developers need measurements that match the claim.

Start with the waste you can see and measure

Software efficiency is already part of good engineering. It can lower infrastructure costs, improve performance, reduce latency, and free capacity. When an improvement reduces the compute needed to deliver the same successful result, it can also reduce energy use.

A practical starting point is to look for measurable waste in four areas:

1. Code: repeated computation, inefficient algorithms, unnecessary allocations, or expensive work that could be cached.
2. Data: over-fetching, unbounded queries, missing caching, or database calls that should be batched.
3. Network and I/O: duplicate requests, polling that could be event-driven, oversized payloads, or missing compression.
4. Frontend: unnecessary rendering, eagerly loaded off-screen assets, or media that could use smaller formats.

The right metric depends on the change. Execution time, CPU use, memory allocation, and network transfer size can all act as useful proxies for computational demand. Each has limits, so state what you measured and what you did not.

For example, a pull request that replaces 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. That is a stronger engineering case than calling the change “greener” without supporting data.

Use an agent to find opportunities, not to make the final decision

Finding efficiency work across a large repository can be slow. GitHub Agentic Workflows can help automate the search while keeping maintainers in control.

The open source Daily Efficiency Improver workflow reviews 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 the evidence and trade-offs for maintainers to review. It does not merge changes itself.

You can add the workflow to a repository with 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 suitable test repository or run it manually. Treat every recommendation as a hypothesis until the benchmark and tests support it.

The strongest pull requests should answer five questions:

1. What waste did the workflow find?
2. Which metric represents the expected improvement?
3. What was the baseline?
4. Did the change preserve functionality and quality?
5. What trade-offs should maintainers consider?

AI can help developers search, test, and document possible improvements. Humans still decide whether the evidence is sound and whether the change belongs in the codebase.

Make efficiency part of the engineering loop

Efficiency work is easiest to sustain when it fits the tools and decisions developers already use. A repository-level workflow can surface an opportunity. A draft pull request can show the proposed fix. Benchmarks and tests can establish whether it works. Maintainers can then accept, revise, or reject the change.

That loop gives developers the practical support survey respondents asked for: tools, measurement, and a path from concern to code.

Read the full Software Developers on Climate Change, AI, and Sustainable Software report from GitHub and the Yale Program on Climate Change Communication. Then try the Daily Efficiency Improver on a suitable repository and review its findings.

The post Developers want more efficient software. Here’s what over 1,000 GitHub users told us they need. appeared first on The GitHub Blog.