Mein GitHub-Graph für 2025 sieht aus, als hätten zwei verschiedene Entwickler daran gearbeitet. Die erste Jahreshälfte ist fast leer. In der zweiten stehen mehr als 4.000 Commits.
Ich hatte nicht plötzlich mehr Freizeit. Ich kombinierte weiterhin einen Vollzeitjob mit Side Projects. Verändert hatte sich die Reibung zwischen einer Idee und einer funktionierenden Version: Ich begann, AI-Coding-Tools deutlich ernsthafter einzusetzen.
Diese Zahl sollte man nicht überinterpretieren. Die Anzahl der Commits ist für sich genommen keine Produktivitätsmetrik. 4.000 Commits beweisen weder 4.000 sinnvolle Verbesserungen noch gute Codequalität. Sie zeigen aber sehr deutlich, dass sich mein Arbeitsrhythmus verändert hatte: Ich baute, iterierte und brachte Dinge viel kontinuierlicher in einen funktionierenden Zustand als vorher.
Der eigentliche Engpass war die Aktivierungsenergie
Bei Side Projects begegnete mir immer wieder dasselbe Problem: Die erste nützliche Version liegt oft hinter einer Menge Routinearbeit. Routing, Validierung, Skripte, Tests, Konfiguration und Aufräumarbeiten können die Energie verbrauchen, bevor ich überhaupt herausfinde, ob eine Idee etwas taugt.
Früher verschob ich Experimente, sobald der erste brauchbare Stand nach mehreren Abenden Setup aussah. AI-Coding-Tools haben diese Arbeit nicht beseitigt, aber die Kosten des ersten Entwurfs gesenkt und mich schneller zu einer testbaren Version gebracht.
Der größte Gewinn war deshalb nicht schnelleres Tippen, sondern geringere Aktivierungsenergie: Mehr Ideen erreichten überhaupt den Punkt, an dem ich echtes Feedback sammeln konnte.
Wie sich mein Node.js-Workflow verändert hat
Ich habe meinen Entwicklungsprozess nicht durch ein Chatfenster ersetzt. In Node.js-Side-Projects nutzte ich DeepSeek als zweite Hand für klar abgegrenzte Aufgaben: einen ersten Entwurf erstellen, unbekannten Code erklären, Tests vorschlagen, Stack Traces analysieren, Refactorings in kleinere Schritte zerlegen und Deployment-Annahmen prüfen.
- Scaffolding: die langweilige erste Version von Handlern, Validierung, Skripten oder Tests.
- Code Reading: Request- oder Datenpfade nachverfolgen, bevor ich etwas ändere.
- Refactoring: mechanische Änderungen in kleine, gut prüfbare Diffs zerlegen.
- Debugging: aus Logs mehrere Hypothesen bilden statt der ersten Erklärung zu glauben.
- Verifikation: Edge Cases und Regressionstests nach dem Happy Path ergänzen.
Je klarer Inputs, Outputs, Constraints und bestehende Konventionen waren, desto leichter ließ sich die Antwort prüfen. Bei vagen Aufgaben entstand dagegen häufiger eine plausibel klingende, aber unpassende Abstraktion.
Deshalb behandelte ich AI-Output als Candidate Patch, nicht als fertige Lösung. Type Checking, Tests, Build und der reale Flow waren Belege; selbstbewusste Formulierungen waren es nicht.
Wo DeepSeek am meisten half — und wo nicht
DeepSeek war für mich vor allem deshalb nützlich, weil ich es bei konkreten Programmieraufgaben häufig einsetzen konnte. Ich konnte einen ersten Vorschlag anfordern, Teile verwerfen, den echten Fehler zurückgeben, die Aufgabe enger fassen und schnell iterieren.
Das ist kein Benchmark. Ich habe keine kontrollierte Studie gegen jedes Konkurrenzmodell durchgeführt, und Modellfamilien ändern sich schnell. Die belastbare Aussage ist enger: DeepSeek passte gut genug zu meinem Workflow, dass ich AI-Unterstützung deutlich häufiger einsetzte.
Am stärksten war es bei Problemen mit billigem Feedback: Funktion, Tests, echter Fehler. Schwächer war es bei unausgesprochenem Produktkontext oder subtilen Architekturentscheidungen. Dort konnte eine flüssige Antwort eine falsche Annahme gefährlich fertig wirken lassen.
AI hat die Kosten des Experimentierens verändert
Die wichtigste Veränderung war für mich nicht „AI schreibt Code, also ist Entwicklung automatisiert“. Vielmehr wurden viele kleine Bausteine billig genug, um sie überhaupt auszuprobieren. Ein Feature, das früher nach zu viel Setup aussah, konnte nun zum Prototyp werden, solange mich die Idee noch interessierte.
Diese Unterscheidung ist wichtig. AI senkte die Kosten bis zu einer testbaren Version. Architektur, Produktentscheidungen, Deployment und Korrektheit verschwanden dadurch nicht. Generierter Code kann falsch sein; ein erfolgreicher Build kann zur Laufzeit scheitern; ein deployter Prototyp kann trotzdem ein schlechtes Produkt sein.
Der praktische Gewinn war für mich Momentum. Sobald ich das Gesamtsystem einmal funktionieren sah, fiel es mir deutlich leichter, weiter daran zu arbeiten.
Was ein stärkerer Benchmark bräuchte
Für einen reproduzierbaren Benchmark würde ich exakte Modellversionen, feste Programmieraufgaben, Repository-Snapshots, Prompts, Rohantworten, Zeitaufwand, akzeptierte und verworfene Patches, Review-Zeit, Testergebnisse und Nacharbeit festhalten.
Außerdem würde ich mehr als Commits messen: Zeit von der Idee bis zur verifizierten Version, Defekte, Rollbacks und Rework. Ohne diesen Kontext sind 4.000 Commits ein Hinweis auf Aktivität und verändertes Verhalten, aber kein Beweis für Softwarequalität.
Was sich für mich verändert hat
2025 war das Jahr, in dem ich aufgehört habe, jedes Side Project als Berg von Setup zu betrachten, den ich komplett manuell erklimmen muss. AI machte die erste funktionierende Version günstig genug, dass ich häufiger zu dem Punkt kam, an dem die eigentlichen Produktentscheidungen wichtig wurden.
Deshalb sieht die zweite Hälfte meines GitHub-Graphs so anders aus. Nicht weil AI mir mehr Stunden am Tag gegeben hätte und nicht weil jede generierte Zeile gut gewesen wäre. Sie reduzierte die Reibung, an der frühere Ideen starben, bevor sie real wurden.
2026 interessiert mich deshalb vor allem die weniger spektakuläre zweite Hälfte der Gleichung: den Workflow weiter verfeinern, Qualität ernster messen und sicherstellen, dass schnellere Entwicklung bessere Software hervorbringt statt nur mehr Commits.