Luís Cruz, Co-founder of GreenSeal.dev and Assistant Professor at TU Delft, works at the intersection of sustainable software engineering and Green AI. His work focuses on how software design decisions influence energy consumption and environmental impact.

This topic is becoming increasingly relevant as digital infrastructure and AI systems expand rapidly. While sustainability discussions often focus on energy, transport, or manufacturing, software remains embedded within Scope 2 and Scope 3 emissions and is rarely addressed directly.

In a conversation hosted by Net Zero Compare, Luís Cruz explained why this gap exists, how software sustainability can be approached in practice, and what companies can do today to reduce the environmental footprint of their digital systems.

🎥 Watch the Full Conversation: This discussion covers both the academic perspective on sustainable software and the practical implementation through GreenSeal.dev. It provides additional context on trade-offs, real-world constraints, and how companies can approach software-related emissions without overcomplicating implementation. If you are working with AI systems, cloud infrastructure, or digital products, watching the full conversation offers a clearer view of how these concepts apply in real business and engineering environments.

Why Software Sustainability Has Been Overlooked

Sustainability efforts in software have lagged behind other sectors primarily because the problem is complex and still evolving. Unlike transportation or energy systems, software lacks standardized methods for measuring and optimizing environmental impact.

Most organizations focus on higher-level indicators such as renewable energy usage or fleet electrification because these are easier to quantify and communicate. In contrast, addressing software requires changes at the level of engineering practices, system design, and organizational priorities, which makes it more difficult to implement.

As a result, software emissions are often indirectly included in reporting but rarely optimized at their source. This creates a structural blind spot within many sustainability strategies.

What “Sustainable Software” Means in Practice

Sustainable software operates across multiple layers, and focusing on just one is not sufficient. At the code level, decisions such as algorithm design, data structures, and programming languages influence how efficiently tasks are executed. Even small inefficiencies can scale significantly in high-volume systems.

At the architecture and infrastructure level, system design decisions have a direct impact on energy use. These include how cloud resources are managed, how data is transferred across regions, and how workloads are scheduled. Inefficient architecture can result in unnecessary compute usage even when the code itself is optimized.

At the product level, user-facing features also contribute to energy consumption. Design choices such as auto-play video, infinite scrolling, or default high-resolution media increase resource usage without always delivering proportional value to users.

Taken together, these layers show that sustainable software is not a single optimization task but a system-level discipline.

Energy Efficiency Is Not a Single Metric

Evaluating software sustainability requires considering more than just energy consumption. Hardware, lifecycle impacts, and user behavior all play a role, making it difficult to isolate a single metric.

For example, adopting more energy-efficient hardware may reduce electricity consumption in the short term, but replacing existing hardware too quickly introduces additional emissions through manufacturing and supply chains. In some cases, extending the life of existing hardware can be the more sustainable choice.

A similar trade-off exists in AI systems. Training large models is energy-intensive, but it is typically a one-time cost. The ongoing impact comes from inference, where models are used repeatedly at scale. This means that optimizing usage patterns can be more important than focusing solely on training efficiency.

The Rebound Effect in Software and AI

Efficiency improvements do not automatically lead to lower overall consumption. The rebound effect, also known as the Jevons paradox, shows that increased efficiency often results in higher total usage.

In the context of software, this can lead to more applications being created, more AI-generated code, and greater overall demand for compute resources. As development becomes faster and cheaper, the volume of software increases, offsetting gains in efficiency.

This dynamic is particularly relevant in AI, where improvements in model efficiency may drive broader adoption and, ultimately, higher total energy consumption.

The Real Environmental Impact of AI Systems

AI systems have both direct and indirect environmental impacts. Direct impacts include the electricity required to train and run models, especially at scale in data centers. Indirect impacts include the production and lifecycle of hardware, such as GPUs, which depend on resource-intensive supply chains involving rare materials.

The key issue is not whether AI should be used, but how it is applied. When AI is used for high-value applications such as optimizing energy systems or reducing waste, it can deliver net positive outcomes. However, deploying large models for low-value use cases increases environmental impact without clear benefits. This reinforces the need for companies to evaluate both the purpose and the efficiency of their AI deployments.

Education Is Improving, but Industry Adoption Is Slower

Universities are making progress by integrating sustainable software concepts into computer science and AI curricula. Courses and materials are becoming more widely available, helping new engineers understand the environmental implications of their work.

In contrast, industry adoption is less consistent. Many organizations rely on high-level reporting frameworks and assume that compliance is sufficient. This can lead to a disconnect between executive-level reporting and the day-to-day practices of engineering teams. As a result, opportunities to improve software efficiency at the operational level are often overlooked.

Why Measurement Should Be Practical, Not Perfect

One of the key challenges in sustainable software is measurement. While precise metrics are valuable, they are often complex and expensive to implement. This can discourage teams from taking action.

A more practical approach is to use simpler metrics that provide directional insights. These metrics may not be perfectly accurate, but they are easier to adopt and allow teams to make improvements without significant overhead.

This approach prioritizes action over precision. By enabling developers to see the impact of their decisions, even imperfect data can drive meaningful change.

GreenSeal.dev: Bringing Sustainability Into Development Workflows

GreenSeal.dev focuses on embedding sustainability into software development through a certification approach rather than treating it as a final reporting step. Its Green Software Practices (GSP) certification recognizes how organizations design, build, and improve software across areas such as governance, measurement, architecture, and continuous improvement.

As part of this approach, teams are encouraged to introduce visibility into how development decisions affect energy consumption over time. This can include tracking how different versions of a system perform and identifying inefficiencies early in the development lifecycle.

This approach shifts sustainability from a compliance exercise to an operational capability within engineering teams.

Limitations of Existing Certification Models

Existing certification models often fall short because they either focus on organizational practices or rely on isolated product metrics. High-level certifications typically assess factors such as renewable energy use, but do not address how software is built.

Product-level certifications, on the other hand, often rely on total energy consumption metrics. These metrics lack context and are difficult to compare across different types of software, which perform different functions and operate under different conditions.

As a result, these models do not provide actionable insights for developers or meaningful comparisons for decision-makers.
In contrast, GreenSeal.dev’s Green Software Practices (GSP) certification takes a practices-based approach. Instead of relying on isolated energy consumption metrics, it evaluates whether development processes consistently enable teams to build more efficient software over time. This shifts the focus from one-time measurement to continuous improvement within the software lifecycle.

Connecting Software to ESG and Regulatory Frameworks

Frameworks such as ESG reporting and regulatory requirements like CSRD operate primarily at the organizational level. They focus on disclosing emissions data and ensuring transparency for stakeholders.

However, these frameworks do not address how software systems are designed or how engineering decisions affect emissions. This creates a gap between reporting requirements and operational practices.

Addressing this gap requires tools and processes that operate within development teams rather than relying solely on top-level reporting. A key distinction is that GreenSeal.dev focuses on product-level software sustainability rather than corporate-level ESG reporting. While frameworks such as CSRD operate at the organizational level, this approach targets how software itself is designed and developed. This helps address gaps that are not captured by high-level reporting alone.

Where the Business Case Is Strongest

The business case for sustainable software is becoming clearer as regulatory and market pressures increase. Compliance is a key driver, particularly as new regulations begin to require more detailed reporting of energy use, especially in AI systems.

Procurement is another important factor. Organizations are increasingly selecting vendors based on sustainability criteria, which creates incentives for companies to demonstrate improvements in their software practices.

While cost savings can also play a role, regulatory and competitive pressures are currently the primary drivers.

Common Misconceptions About Implementation

Many companies assume that improving software sustainability requires significant investment with limited returns. In practice, this is often not the case.

Development teams frequently already recognize inefficient patterns in their systems. Addressing these issues can require relatively small changes, but they are often deprioritized because they are not seen as critical.

This means that meaningful improvements can often be achieved with moderate effort, especially when sustainability is integrated into existing workflows.

Conclusion

Software is now a core component of modern infrastructure, and its environmental impact is increasing alongside the growth of AI and cloud computing. Addressing this impact requires more than reporting. It requires changes in how software is designed, built, and maintained.

The key takeaway is that sustainability in software is primarily an engineering and process challenge. Companies that focus on practical measurement, developer empowerment, and continuous improvement will be better positioned to reduce their digital footprint.

As regulatory requirements evolve and digital systems continue to scale, integrating sustainability into software development will become a standard part of doing business rather than an optional initiative.