-
-
CI Waste Auditor
-
Pipeline
-
Jobs
CI Waste Auditor: Sustainable CI/CD
AI-Assisted Pipeline Optimization | Supervised Autonomy | Environmental Sustainability | Software Carbon Intensity
Core principle: Every optimization must justify its computational savings, preserve the checks that make software trustworthy, and make its environmental assumptions transparent.
CI Waste Auditor is an AI-assisted, human-supervised approach to identifying unnecessary CI/CD computation, evaluating pipeline optimization opportunities, and estimating their potential environmental impact. It brings together pipeline analysis, controlled changes, validation safeguards, performance comparison, and sustainability accounting in a single engineering workflow.
The objective is not merely to make pipelines faster. It is to make software delivery more resource-efficient, more accountable, and more sustainable—without trading away correctness, security, or engineering confidence.
Inspiration
Every software change passes through a delivery pipeline, but not every computation performed by that pipeline is necessary. Repeated dependency installation, redundant execution, inefficient caching, and avoidable job orchestration can consume computing resources without delivering proportional value.
This creates two connected engineering problems.
First, developers need to identify and eliminate unnecessary work without weakening the tests, security checks, and quality gates that protect software.
Second, engineering teams need a credible way to understand the environmental implications of their optimization decisions. Less execution time may indicate an opportunity for resource savings, but duration alone does not establish actual electricity consumption or carbon emissions.
We asked:
What if CI/CD pipelines could identify their own waste, propose safer optimization strategies, and quantify their potential environmental benefits—while keeping humans accountable for the final decision?
That question inspired CI Waste Auditor.
Our vision is to make sustainability a measurable engineering objective rather than a statement of intent. Every optimization should be evaluated through three lenses:
- Engineering efficiency: Does the change eliminate unnecessary computational work?
- Correctness and governance: Does it preserve required validation, security controls, and human authority?
- Environmental impact: What energy and carbon benefits can be supported by the available measurements and disclosed assumptions?
This is the foundation of our approach to supervised autonomy and sustainable software delivery.
What it does
CI Waste Auditor is designed to identify CI/CD inefficiencies, recommend targeted improvements, validate changes against configured safeguards, and compare baseline and optimized execution evidence.
Its workflow follows seven stages.
1. Analyze — Identify unnecessary computation
Inspect pipeline configurations and available execution evidence to identify repeated setup operations, redundant work, inefficient dependency installation, and other potential sources of wasted runner time.
The objective is to distinguish genuine optimization opportunities from changes that merely shift work elsewhere or weaken validation.
2. Recommend — Prioritize high-value improvements
Evaluate potential changes according to their expected efficiency benefit, implementation complexity, confidence, and risk.
Rather than optimizing for the lowest duration at any cost, the workflow is designed to favor improvements that reduce avoidable work while preserving the pipeline's required behavior.
3. Implement — Isolate changes from the baseline
Prepare proposed changes on a separate optimization branch rather than silently altering the original baseline.
This creates a traceable comparison between the original configuration and the proposed improvement, making it easier for engineers to inspect the exact change and evaluate its consequences.
4. Validate — Protect correctness and security
Evaluate optimized pipeline evidence against the configured validation policy.
The intended safeguards include required-job presence, acceptable job results, coverage thresholds, required security checks, and evidence completeness.
A missing check, failed gate, or incomplete result must not be interpreted as proof of a successful optimization. The equivalence gate is designed to reject unsafe or insufficiently supported changes.
5. Compare — Evaluate the actual engineering outcome
Compare baseline and optimized pipeline executions using both aggregate job duration and wall-clock duration.
These measurements answer different questions. Aggregate job duration indicates the sum of recorded job execution times, while wall-clock duration represents elapsed pipeline time. A change may reduce total job time without making the pipeline finish sooner.
Both measurements must therefore be reported rather than selecting only the most favorable metric.
6. Estimate — Connect pipeline efficiency to sustainability
Use recorded job durations and documented power assumptions to estimate the potential energy and operational carbon implications of the optimization.
The model is intended to make environmental accounting inspectable: inputs, units, conversion factors, and assumptions should be disclosed so that results can be reproduced and challenged.
Estimates are explicitly distinguished from direct energy measurements.
7. Govern — Keep humans in control
Present the proposed optimization, validation evidence, performance comparison, and environmental assessment for human review.
The intended supervised workflow requires human authorization before a consequential change is merged. Failed validation must not be overridden automatically, and an optimization must not be promoted merely because it appears faster.
The governing principle is simple: reduce unnecessary work, preserve required safeguards, quantify the impact, and require human approval.
How we built it
CI Waste Auditor combines GitLab CI/CD, pipeline configuration, optimization scripts, validation logic, execution evidence, and a documented environmental estimation method.
The project is structured around a reproducible engineering process rather than a dashboard that presents isolated performance numbers.
Pipeline configuration and optimization
We established a baseline pipeline and explored a consolidated dependency-installation strategy on an optimization branch.
The recorded optimization consolidates three dependency-installation jobs into one install:all job while retaining separate core, API, and worker test jobs.
This provides a concrete experiment for investigating whether repeated dependency setup can be reduced without eliminating the distinct test jobs that exercise the service components.
Supervised agent architecture
The project includes agent and flow definitions intended to connect pipeline analysis, optimization recommendations, isolated changes, validation, comparison, and human approval through the GitLab Duo Agent Platform.
The intended workflow is designed around bounded correction attempts, explicit safety policies, traceable evidence, and a human decision before merging.
The architecture separates the automation's responsibilities from the authority to accept its outcome. AI assistance can support analysis and proposed changes, but it should not silently remove required checks, override a failed gate, or merge an unapproved optimization.
A configured agent or flow definition is not itself evidence of successful execution. Platform execution, completed sessions, approval transitions, and end-to-end behavior must be supported by actual records before they are described as demonstrated capabilities.
Correctness and equivalence validation
The project includes an equivalence checker intended to detect missing required jobs, unacceptable coverage, and configured validation failures.
Its purpose is to prevent an optimization from appearing successful simply because it executes less work. The validation policy is intended to establish whether the optimized workflow still satisfies the requirements that matter to the project.
The recorded optimized pipeline reported the equivalence-gate job as skipped. Consequently, that execution does not independently prove that the gate passed or that equivalence was established.
A successful, inspectable gate execution and reconciled baseline-versus-optimized validation evidence remain important requirements for a conclusive result.
Environmental accounting
The project includes an environmental-impact calculation component and associated tests intended to estimate energy consumption and associated carbon emissions from pipeline execution evidence.
The documented approach uses assumed job power, job duration, a power usage effectiveness factor, and a disclosed carbon-intensity factor.
The model is deliberately treated as an estimation mechanism when runner telemetry is unavailable. Its output should not be represented as a direct measurement of electricity consumption or emissions from a specific runner.
The implementation, tests, and documentation must agree on the power assumptions, accounting boundary, units, and conversion factors before the results are treated as final.
Sustainability by design
Environmental responsibility is a design objective throughout CI Waste Auditor, not simply an additional report generated after optimization.
The project addresses sustainability through three complementary dimensions: computational efficiency, resource-aware architecture, and transparent carbon accounting.
1. Computational efficiency
Repeated dependency installations and unnecessary pipeline work can consume additional computing resources.
The recorded optimization experiment consolidates three dependency-installation jobs into one while preserving separate core, API, and worker test jobs. This is a targeted attempt to reduce repeated setup work rather than achieve a favorable result by indiscriminately removing validation.
The potential benefit is lower aggregate computational effort. Whether this translates into lower energy consumption must be evaluated using a consistent energy model or suitable measurements.
2. Resource-aware pipeline architecture
The workflow emphasizes isolated changes, evidence-based comparison, and the reuse or consolidation of work where technically appropriate.
Future optimization opportunities include more effective dependency caching, avoiding genuinely redundant operations, reducing unnecessary job execution, and evaluating whether job dependencies create avoidable serialization.
These changes should be evaluated against their actual resource requirements. For example, parallel execution may reduce wall-clock time while increasing concurrent resource use, so the best design cannot be selected from elapsed time alone.
The project therefore treats resource efficiency and correctness as joint constraints.
3. Supervised automation as a sustainability safeguard
Automation can itself introduce waste if it repeatedly retries failed operations, performs unnecessary analyses, or generates changes that require expensive rework.
The intended supervised workflow uses bounded correction attempts and stops when required validation fails or evidence is incomplete or inconsistent.
Human review provides an additional control against promoting an optimization whose claimed benefit is not supported by the available evidence.
These safeguards are intended to make optimization accountable: the workflow must justify not only what it changes, but also why the change should be accepted.
4. Transparent energy and carbon estimation
The documented environmental model uses the following relationship:
Estimated energy (kWh)
E = [Σ(Pⱼ × tⱼ) / 3,600,000] × PUE
Where:
- Pⱼ is the assumed power allocation for job j, in watts.
- tⱼ is the recorded duration of job j, in seconds.
- PUE is the assumed data-centre power usage effectiveness factor.
- The denominator converts watt-seconds into kilowatt-hours.
The corresponding operational carbon estimate is:
Estimated operational emissions (g CO₂e)
O = E × I
Where I is the selected carbon-intensity factor in grams of CO₂e per kilowatt-hour.
The documented illustrative assumptions include 100 W per assumed CPU core, 5 W per GB of assumed memory, 2 GB of assumed memory allocation, a PUE of 1.2, and a carbon-intensity factor of 475 g CO₂e/kWh.
Under those illustrative assumptions, the allocated power calculation is:
(100 + 2 × 5) × 1.2 = 132 W
These are modelling assumptions, not measurements of actual runner power consumption. The implementation and documentation must be reconciled if any calculation uses a different value, including 120 W.
A credible comparison must apply consistent assumptions and accounting boundaries to the baseline and optimized executions. It must also avoid double-counting infrastructure overhead already represented by PUE.
5. Alignment with the Software Carbon Intensity framework
CI Waste Auditor is designed to move toward an SCI-aligned assessment using the published Green Software Foundation Software Carbon Intensity specification, ISO/IEC 21031:2024.
SCI is a rate of software carbon emissions per functional unit:
SCI = (O + M) / R
Where:
- O — Operational emissions: emissions associated with energy consumed during software execution.
- M — Embodied emissions: the allocated share of emissions associated with manufacturing the hardware used within the defined software boundary.
- R — Functional unit: a consistent unit of useful work, such as one successfully completed CI pipeline.
For CI Waste Auditor, one successfully completed pipeline is a candidate functional unit. The precise boundary and denominator must be defined consistently before reporting a final score.
An SCI-style comparison should:
- Define the software and infrastructure boundary included in the assessment.
- Select a consistent functional unit for the baseline and optimized workflows.
- Quantify operational emissions using measured energy where available, or a documented model where measurement is unavailable.
- Account for embodied hardware emissions when sufficient data and an appropriate allocation method are available.
- Apply a justified carbon-intensity factor, documenting its source, geographical relevance, and time resolution where available.
- Report the resulting carbon intensity alongside the assumptions, limitations, and measurement method.
The current duration-based model does not independently establish all components of a complete SCI score, particularly embodied emissions. We therefore describe it as an environmental-impact estimate and an SCI-aligned measurement direction—not as a completed, fully measured SCI assessment.
Official methodology: https://greensoftware.foundation/standards/sci/
Specification: https://github.com/Green-Software-Foundation/sci/blob/main/SPEC.md
6. What the environmental evidence establishes today
Our recorded experiment shows a reduction in aggregate job duration. This is relevant evidence of a potential resource-efficiency improvement, but it is not equivalent to measured electricity or carbon savings.
The current comparison is a single recorded experiment. Runner utilization, hardware characteristics, execution variability, and other infrastructure factors can affect the relationship between job duration and energy consumption.
The environmental model should therefore be interpreted as a transparent estimate whose reliability depends on its assumptions and accounting boundary.
We do not claim that aggregate job duration fell by the same percentage as energy consumption or carbon emissions. Nor do we claim a fully validated SCI reduction without a complete, consistently scoped calculation.
This distinction is central to the project's approach: environmental claims should be reproducible, qualified, and supported by evidence.
Recorded optimization experiment
The current evidence compares two pipelines for the sample service.
- Baseline pipeline:
2961931268 - Baseline commit:
fc8c027c2e338e695999ac2e23410eaa55c8a6a4 - Optimized pipeline:
2967073962 - Optimization branch:
m3/consolidated-install - Optimized commit:
2f526706e1a544848cd5139a27987516055a6c66
The optimization consolidates three dependency-installation jobs into one install:all job while retaining separate core, API, and worker test jobs.
Recorded results
| Metric | Baseline | Optimized |
|---|---|---|
| Dependency-installation jobs | 3 | 1 |
| Summed recorded job duration | 241 seconds | 162 seconds |
| Wall-clock pipeline duration | 116 seconds | 121 seconds |
Aggregate job-duration change: 79 seconds lower, approximately 32.8%.
Wall-clock change: approximately 5 seconds longer, or 4.3%.
The result suggests that the optimization reduced summed job execution time, but it did not improve end-to-end pipeline duration in this comparison.
Because this is a single-run comparison rather than a controlled statistical benchmark, it should be treated as an initial observation. Repeated runs under comparable conditions would provide stronger evidence of a consistent performance effect.
The skipped equivalence gate also means this pipeline pair alone does not prove that every required validation condition was satisfied.
The recorded evidence supports a specific conclusion: the optimized configuration used less aggregate job time in this run. Energy savings, carbon savings, correctness equivalence, and improved wall-clock performance require their own supporting evidence.
The supervised autonomy model
CI Waste Auditor is designed around supervised autonomy: the automation performs bounded analysis and validation work, while a human retains authority over consequential changes.
| Stage | Intended behaviour | Safety objective |
|---|---|---|
| Analyze | Inspect pipeline evidence and identify possible inefficiencies | Base recommendations on available evidence |
| Recommend | Rank candidate optimizations by expected impact, confidence, and risk | Avoid indiscriminate changes |
| Implement | Prepare changes on an isolated branch | Protect the baseline |
| Validate | Run configured tests and safety checks | Reject failed or incomplete validation |
| Compare | Evaluate baseline and optimized results | Avoid misleading performance claims |
| Report | Present results, assumptions, and environmental estimates | Make decisions auditable |
| Approve | Require an explicit human decision before merging | Preserve human accountability |
The intended workflow includes a maximum of two correction attempts and is designed to stop when validation fails or evidence is inconsistent.
These are intended workflow safeguards; their actual enforcement and successful end-to-end execution must be demonstrated through code, pipeline logs, and agent-session evidence.
The system should never override a failed gate, silently remove a required security check, or merge an optimization without authorization.
This makes supervised autonomy part of the sustainability strategy as well as the safety architecture: it provides a controlled mechanism for evaluating proposed resource savings without treating unverified efficiency as success.
Challenges we ran into
Measuring the right thing
Pipeline performance cannot be summarized by a single duration. Aggregate job time and wall-clock time measure different aspects of execution, and neither directly establishes energy consumption.
This forced us to distinguish resource-efficiency indicators from elapsed-time outcomes and environmental estimates.
Balancing efficiency with correctness
A pipeline can appear faster simply because a test or security check was removed. The project treats validation as a constraint on optimization rather than an optional trade-off.
The skipped equivalence gate in the recorded optimized pipeline reinforced the need to distinguish a configured safety mechanism from a successfully executed validation result.
Building a credible environmental model
Duration-based energy estimates depend on assumptions about power, memory, infrastructure overhead, and carbon intensity.
The model must also remain internally consistent: units, power allocations, PUE, and conversion factors must agree across the implementation, tests, and documentation.
Applying SCI appropriately
A duration-based estimate is not automatically a complete SCI score. A defensible SCI assessment requires a defined boundary, a consistent functional unit, quantified emissions, and disclosure of the methodology. Embodied hardware emissions must also be considered within the chosen scope.
The challenge is to make the environmental comparison useful without presenting incomplete data as a definitive measurement.
Working within the agent execution environment
Defining an agent or flow is different from completing an agent execution. Platform access, execution credits, and session completion presented practical constraints.
We therefore distinguish the intended supervised workflow from verified agent-platform execution and do not claim a completed autonomous run without supporting evidence.
These challenges reinforce the same principle: credible sustainability engineering requires measurable outcomes, explicit limitations, and verifiable safeguards.
Accomplishments we're proud of
- A concrete pipeline optimization experiment: Compared a baseline pipeline with a consolidated dependency-installation strategy.
- A measurable reduction in aggregate job duration: Recorded a decrease from 241 to 162 seconds, approximately 32.8%.
- Preserved separate test jobs in the optimization: The recorded configuration retains distinct core, API, and worker test jobs.
- A correctness-conscious design: Includes an equivalence-checking mechanism and documented validation requirements, while acknowledging that the recorded optimized gate was skipped.
- An environmental estimation approach: Documents an energy and operational-carbon model with explicit assumptions and limitations.
- An SCI-oriented measurement direction: Identifies the need for a defined boundary, functional unit, operational emissions, and embodied emissions before claiming a complete SCI score.
- A supervised automation architecture: Designs the workflow around isolated changes, bounded correction attempts, validation, traceability, and human approval.
- Transparent reporting: Separates aggregate job duration, wall-clock duration, model-based environmental estimates, and verified execution evidence.
We are particularly proud of treating limitations as part of the engineering result. The project does not equate less job time with measured carbon savings, or a configured safety gate with a successful validation outcome.
What we learned
Sustainability is an engineering property. It must influence architecture, pipeline design, resource use, and measurement—not simply appear in a final report.
Less computation is an opportunity, not proof of lower emissions. Power draw, infrastructure overhead, hardware allocation, and electricity carbon intensity determine the environmental result.
SCI is a rate, not merely a total. Comparisons require a consistent functional unit and a clearly defined software boundary.
Correctness is non-negotiable. A reduction achieved by removing necessary tests or security checks is not a trustworthy optimization.
Supervised autonomy makes optimization accountable. AI can identify opportunities and propose changes, but engineers must retain meaningful control over consequential decisions.
Measurement quality determines claim quality. Repeatable experiments, consistent formulas, traceable pipeline records, and explicit assumptions are necessary for defensible conclusions.
Transparency improves trust. Reporting an unfavorable wall-clock result or a skipped gate is more valuable than hiding it behind a favorable metric.
What's next for CI Waste Auditor: Sustainable CI/CD
Our roadmap focuses on converting the current optimization experiment into a reproducible, validated, and more environmentally rigorous workflow.
1. Complete correctness validation
Investigate the skipped equivalence gate, execute it successfully, and preserve its logs. Reconcile baseline and optimized coverage evidence, required test-job results, security-check statuses, and configured thresholds.
2. Strengthen performance measurement
Run repeated baseline and optimized comparisons under comparable conditions. Report aggregate job duration, wall-clock duration, and relevant variability rather than relying on a single favorable observation.
3. Reconcile the environmental model
Ensure the implementation, tests, and documentation use consistent power assumptions, unit conversions, and PUE treatment. Report the energy and operational-carbon estimates for both configurations using the same model and accounting boundary.
4. Improve energy measurement
Where suitable runner telemetry is available, replace assumed power values with measured or better-substantiated energy data. Where models remain necessary, document the assumptions, data sources, uncertainty, and omitted infrastructure components.
5. Build a defensible SCI assessment
Define the software boundary and functional unit, quantify operational emissions, investigate defensible embodied-emissions allocation, and calculate a comparable SCI rate when the necessary inputs are available.
6. Expand waste detection
Investigate redundant operations, dependency caching, repeated downloads, unnecessary job execution, and inefficient orchestration. Rank opportunities by expected resource benefit, confidence, risk, and validation cost.
7. Strengthen supervised execution
Establish a reproducible GitLab Duo Agent Platform execution path with inspectable recommendations, isolated changes, bounded retries, completed validation evidence, explicit approval, and traceable session records.
8. Introduce sustainability feedback into optimization decisions
Explore using historical pipeline evidence and environmental estimates to prioritize changes that offer meaningful resource savings without compromising correctness.
The longer-term goal is a feedback loop in which every proposed optimization is evaluated for its computational cost, correctness, operational outcome, and environmental implications.
The vision
Software delivery should not have to sacrifice engineering confidence to improve efficiency, nor should sustainability claims depend on assumptions hidden from developers.
CI Waste Auditor explores a future in which AI helps teams identify unnecessary computation, supervised automation keeps consequential decisions accountable, correctness remains non-negotiable, and environmental performance is measured through transparent, repeatable methods.
The ambition is not to label every optimization green. It is to establish an engineering process in which improvements can be inspected, validated, quantified, and challenged.
Optimize the work. Preserve the safeguards. Measure the impact. Keep humans in control.
CI Waste Auditor — Less unnecessary computation. More trustworthy automation. A more sustainable path to software delivery.
Built With
- agents
- ai
- automation
- carbon-estimation
- ci-cd
- continuous-delivery
- continuous-integration
- devops
- duo-agent-platform
- energy-efficiency
- environmental-impact
- equivalence-checking
- gitlab
- gitlab-ci-cd
- gitlab-duo
- green-software
- human-in-the-loop
- performance-optimization
- pipeline-optimization
- python
- software-engineering
- supervised-autonomy
- sustainable-computing
- testing
- yaml
