Kaum eine Branche wird dermaßen stark vom KI-Boom verändert wie die der Entwickler:innen. Tools wie Claude Code oder Googles Antigravity machen es möglich, dass einzelne Personen Programme entwickeln, die früher nur in Teams machbar gewesen wären. Wie bei der Generierung von Bildern, Musik und Videos senkt „Vibe Coding“ die Eintrittsschwelle. Sprich: jede:r ohne Coding-Kenntnisse kann sich eigene Programme oder Webseiten generieren lassen.
Diese neuen Möglichkeiten haben allerdings ihren Preis, denn die Coding-Assistenten nutzen generative KI. Deren Entwicklung und Betrieb geht mit massiven Kosten für die Umwelt einher. In Bezug auf KI-Chatbots haben wir über den Energieverbrauch, den steigenden Wasserbedarf und die menschlichen Kosten berichtet.
Der französische Entwickler Gaëtan Wittebolle hat mit „Claude Carbon“ ein Tool entwickelt, mit dem er die CO2-Äquivalente seiner eigenen Claude-Code-Nutzung berechnet. Wir haben mit Gaëtan darüber gesprochen, wie genau das funktioniert und wie er seinen eigenen CO2-Fußabdruck dadurch senken konnte.
Gaëtan, wie hat Claude Code deinen Arbeitstag verändert? Und was sind die Vorteile beim Coden mit generativer KI?
Es hat die Zeitspanne zwischen Idee und Prototyp drastisch verkürzt. Ich betreibe ein Beratungsunternehmen für die CO2-Bilanzierung von Unternehmen, baue eine Freelancer-Community auf und bringe als Einzelentwickler SaaS-Produkte (Software-as-a-service) auf den Markt – all das wäre ohne diese Technologie nicht möglich.
Die Vorteile liegen allerdings nicht in der Tippgeschwindigkeit. Das eigentliche Coden war nie der Engpass. Was sich geändert hat, ist die Möglichkeit, ein Produkt innerhalb von Stunden statt mehreren Wochen zu testen, bevor technische und finanzielle Kosten entstehen.
Ich persönlich habe dabei eine Sache immer im Kopf: Mehr Code ist nicht gleich besserer Code.
Warum hast du Claude Carbon entwickelt?
Ich arbeite als CO2-Berater für große Unternehmen und programmiere jeden Tag mit Claude Code. Allmählich fühlten sich die beiden Bereiche meines Lebens widersprüchlich an, daher wollte ich konkrete Zahlen zur Ökobilanz meiner Claude-Code-Nutzung erhalten, statt nur ein grobes Gefühl.
Existierende CO2-Tracker konzentrieren sich meist auf den Web-Traffic oder die Cloud-Workloads. Keiner von ihnen hat gemessen, was ein KI-Assistent tatsächlich während einer echten Programmier-Session in einer Entwicklungsumgebung verbraucht. Also habe ich einen entwickelt, als Open Source unter der MIT-Lizenz, mit Emissionsfaktoren, die in einer Datei direkt auf dem Rechner einsehbar sind.
Und wie arbeitet Claude Carbon? Stellt Claude-Code-Entwickler Anthropic die benötigten Daten zum Energieverbrauch zur Verfügung
Die kurze Antwort: Anthropic veröffentlicht keine Daten zu den Emissionen ihres Angebots. Es gibt keine PUE-Kennzahlen für ihre Rechenzentren, keine Echtzeitdaten zum Strommix und weder Scope-1, noch Scope-2- oder Scope-3-Emissionen. Daher setzt sich Claude Carbon aus mehreren Zutaten zusammen:
Das Tool analysiert zum einen die Anzahl der verwendeten Token. Die schreibt Claude Code in ein Dokument, das sich auf der Festplatte eines Computers einfach auslesen lässt.
Zum anderen nutze ich Emissionsfaktoren einer Studie zur Inferenz von Sprachmodellen auf einer Amazon-Web-Services-Infrastruktur aus dem Jahr 2025. [Das AI-Coding-Sprachmodell] Sonnet emittiert laut Studie 190 Gramm CO2-Äquivalente pro einer Million Input-Tokens und 1.140 Gramm pro einer Million Output-Token. [Die Bilanzen der anderen in Claude Code verfügbaren Modelle] Opus und Haiku habe ich von diesen Werten ableiten können.
Auf ein Detail möchte ich dabei noch hinweisen: Die Autoren der Studie haben Sprachmodelle auf einer AWS-Infrastruktur analysiert, nicht auf Anthropics eigener Hardware. Die Zahlen [von Claude Carbon] spiegeln daher nur eine realistische Obergrenze aus den veröffentlichten Forschungsergebnissen dar, nicht einen direkten Messwert für die GPUs von Anthropic.
Und wie konntest du deine Emissionen anschließend um fast 50 Prozent reduzieren?
Was mir hier wichtig ist: Meine Auskunft, dass ich meine KI-Emissionen um 50 – 70 Prozent reduzieren konnte, ist eine Hochrechnung und keine Analyse, die ich nach der Umsetzung meiner Maßnahmen durchgeführt habe. Ich habe die CO2-Bilanz meiner Claude-Code-Nutzung dafür eine Zeit lang gemessen – 215 Kilogramm CO2-Äquivalente über vier Monate, also 0,9 bis 1,5 Tonnen im Jahr. Dann habe ich vier Maßnahmen entwickelt, die zu einer 50 – 70 prozentigen Reduktion dieser Emissionen führen können, wenn man sie konsequent umsetzt. Aktuell sammle ich aber noch Daten, um diese Prognosen zu bestätigen. Aber die vier Hebel sind: Die Nutzung des richtigen Modells, das Einschränken der Funktion „Erweitertes Denken“, das Filtern von Prompts und Kontexten sowie früheres Kompaktieren von Kontexten.
Vier Hebel zur Reduzierung deiner Claude-Code-Emissionen!
Gaëtan hat uns vier Hebel genannt, wie er den CO2-Fußabdruck beim Vibe-Coding über Claude Code reduzieren konnte:
- Nutze das richtige Modell für die richtige Aufgabe: Ich habe damals standardmäßig „Sonnet“ oder „Opus“ für Aufgaben genutzt, wo das energiesparende „Haiku“ genauso gut gewesen wäre. Etwa das Auslesen von Dateien, die Suche oder für Reviews. Das ist der bisher größte Hebel, den ich finden konnte!
- Filtere deine Prompt und deinen Context! Ich nutze RTK (Rust Token Killer), ein CLI-Proxy, der „Rauschen“ von Shell-Outputs reduziert bevor sie vom Modell verarbeitet werden
- Schränke das „Erweiterte Denken“ bei Claude Code ein: Claude’s erweitertes Denken kann 32.000 versteckte Tokens pro Nutzung verbrauchen. Für Routinearbeiten ist das völlig verschwendete Rechenleistung. Die Einschränkung „
MAX_THINKING_TOKENS=10000"reduziert das „Denken“ um circa 70% ohne einen messbaren Qualitätsverlust - Früher Kompaktieren: Standardmäßig kompaktiert Claude Code Kontexte erst bei 95 %. Der Befehl „
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50"hält Sitzungen schlank!
Zusammen sollten diese Maßnahmen eine Reduktion von 50 – 70 Prozent bedeuten. Der jährliche CO2-Fußabdruck meiner Claude-Code-Nutzung sollte sich dadurch von circa 1,2 Tonnen CO2-Äquivalente auf 0,4 bis 0,6 Tonnen reduzieren.
Max Westing erzählte uns im Gespräch, dass generative KI auch Potenziale für eine energiesparende Optimierung von Code hat. Wie siehst du das?
Max Westings Position ist ein wenig differenzierter. Seine Studie zeigte, dass KI-Agenten einfachen Code „auf eine Weise optimieren konnten, die funktioniert“. Allerdings weist er auch darauf hin, dass es keine umfassende Lebenszyklusanalyse gibt, welche die Effizienz von menschlich geschriebenem Code mit der von KI-Code vergleicht. Und eben auch, dass KI-Systeme selbst sehr viel Energie verbrauchen.
Er wirft zudem ausdrücklich die Frage nach Rebound-Effekten auf: Wenn Entwickler:innen durch KI-Tools an Effizienz gewinnen, gleicht das dann die Kosten für deren Training und Betrieb aus?
Meiner Einschätzung nach ist das derzeit nicht der Fall. Der enge Optimierungsaspekt ist zwar real, wird aber von den Begleiterscheinungen überlagert.
Beim Vibe-Coding generieren Entwickler:innen häufig Code, ohne ihn zu lesen. Sie akzeptieren ihn, ohne zu hinterfragen und geben neue Prompts ein, statt den erzeugten Code zu debuggen. Jeder Zyklus kostet Ressourcen und erzeugt Code, der im Nachgang ausgeführt wird. Das führt zu einer übermäßige Generierung von Codezeile. Dabei werden etwa Funktionen ausgeliefert, nach denen niemand gefragt hat, Abhängigkeiten hinzugefügt, die niemand überprüft, und Abstraktionen für Probleme erstellt, die noch gar nicht existieren.
Wenn die Ausgabequalität gering ist, generieren Entwickler:innen den Code komplett neu. Ich bezeichne das gerne als Nachbearbeitungszyklen, die zu mehr Rechenleistung führen. Denn: Auch jede abgelehnte und überarbeitete Version muss erstmal generiert werden. Und das ist reine Verschwendung.
Den letzten Faktor nenne ich mal „Wartungsschulden“. KI-generierter Code ist statistisch gesehen langatmiger, vielschichtiger und unzusammenhängiger. Diese Codezeilen überleben in Produkten dann jahrelang.
Zusammenfassend: Ja, wenn wir Claude ausdrücklich darum bitten, Optimierungen vorzunehmen, werden die Ausgaben effizienter sein. Aber im Ganzen sind Projekte in der Regel umfangreicher und aufgeblähter, als sie es wären, wenn Menschen sie umgesetzt hätten. Die kleinen Gewinne wiegen die große Aufblähung ganzer Projekte nicht auf.
Der eigentliche Hebel liegt meiner Meinung nach darin, diese Tools zu nutzen, um weniger Code zu schreiben. Nicht etwa, um schneller mehr Code zu schreiben. Diese Diskussion findet aktuell aber noch nicht statt.
