What to know

  • GitHub discussed the research on 23 September.
  • The survey covers 1,039 opted-in US GitHub users.
  • Opinions about efficiency do not measure environmental impact.

The research account

GitHub’s 23 September 2026 report discusses a survey conducted with the Yale Program on Climate Change Communication. It covers 1,039 US GitHub users who had opted into marketing communications and describes interest in tools and guidance for more efficient software. The sample is not representative of all developers. The survey measures opinions, not the environmental footprint of an application or AI system.

Why measurement is the useful next step

It is easy for efficiency discussions to jump from concern to a broad claim of savings. Our interpretation is that a team should first identify a measurable unit of work. For a publication, that might be rendering one article or processing one image. For a data service, it might be answering one bounded query. A defined task makes it possible to compare changes without pretending that an isolated technical metric captures every environmental consequence.

A faster operation may still use more resources overall if it triggers additional requests. A smaller model may require more retries. A cache may reduce repeated computation while introducing storage and freshness costs. These are reasons to describe the system boundary, not reasons to abandon measurement. Readers should be able to tell what was counted and what remained outside the comparison.

A practical efficiency investigation

Start with logs or traces already available to the team and avoid collecting personal information unnecessarily. Look for repeated work with no useful outcome: duplicate image transformations, polling after a task is finished or rebuilding unchanged artifacts. Select one candidate, preserve correctness checks and measure before and after under similar conditions.

Report the observed technical change precisely. Lower CPU time for a bounded test is a stronger statement than an unsupported claim of a particular emissions reduction. If translating resource use into environmental estimates, identify the data source and assumptions separately. Keep the result reviewable so another engineer can challenge the method. Small, well-supported improvements can become normal maintenance work rather than a once-a-year sustainability announcement with no operational owner.

What the survey does not establish

A self-selected survey can reveal concerns among respondents without determining what every developer wants. It also cannot prove which tool would deliver the largest improvement. BijliCoin has not repeated the survey or audited respondents’ systems. The useful response is to connect interest with an achievable measurement practice: define a task, remove unnecessary work and preserve correctness. Teams can then decide whether the improvement merits continued investment, while leaving broader environmental claims to evidence capable of supporting them.

Sources

Editorial note: AI-assisted original BijliCoin synthesis. Original BijliCoin explanatory reporting and analysis based on linked sources. Supplier and researcher findings are attributed; BijliCoin has not independently benchmarked them. AI-generated conceptual illustration, not an event photograph.

Sources & context

  1. GitHub software-efficiency research account ↗
  2. GitHub and Yale survey report ↗

See our editorial policy or report a correction.