Ich baute ein zweites Gehirn, das meine PRs für mich schreibt
Letzten Donnerstag habe ich ein Feature geliefert, das 14 Dateien in drei Services berührte. Die PR-Beschreibung bestand aus zwei Absätzen sauberem, spezifischem Kontext. Das Statusupdate an mein Team war bereits in Slack ausformuliert, bevor ich meinen Kaffee ausgetrunken hatte. Die Übergabenotizen für den nächsten Entwickler lagen in einer Markdown-Datei, perfekt strukturiert, bereit zum Teilen.
Ich habe kein einziges Wort davon geschrieben.
Kein einziges Wort. Und bevor du annimmst, ich würde ein ausgeklügeltes Template-System oder ChatGPT-Kopien verwenden — nein. Mein Claude Code-Setup hat alles geschrieben, weil es bereits wusste, was ich gebaut hatte, warum ich bestimmte architektonische Entscheidungen getroffen hatte, welche Kompromisse ich erwogen hatte, und was die nächste Person, die das aufgreift, wissen muss. Es wusste all das, weil ich die letzten sechs Monate 30-Sekunden-Updates am Ende jeder Arbeitssitzung gemacht hatte.
Ich nenne es mein zweites Gehirn. Das klingt dramatisch, bis du siehst, wie es eine PR-Beschreibung generiert, die besser ist als alles, was ich manuell schreiben würde.
Warum KI auf Schreibaufgaben zu werfen (zunächst) nicht funktioniert
Das Problem ist strukturell, kein Qualitätsproblem mit der KI. Wenn du einen Diff in einen Chatbot einfügst, kann er sehen, was sich geändert hat. Er kann nicht sehen, warum es sich geändert hat. Er weiß nicht, dass du das Auth-Middleware überarbeitet hast, weil das Sicherheitsaudit letzten Monat eine Session-Fixation-Schwachstelle markiert hat.
Ich habe Prompt-Templates gebaut. Hat ein bisschen geholfen. Aber der Kontext wurde innerhalb von Tagen veraltet. Projekte entwickeln sich schnell.
Das grundlegende Problem mit all diesen Ansätzen: Der Kontext lebt in deinem Kopf, nicht im System. Was das eliminiert, ist der KI eine eigene persistente, lokale, kontinuierlich aktualisierte Wissensbasis zu geben.
Wie das lokale Kontextsystem von Claude Code wirklich funktioniert
Claude Code liest und schreibt Markdown-Dateien — typischerweise CLAUDE.md in deinem Projektstamm und zusätzliche Kontextdateien, die du erstellst. Diese Dateien bleiben zwischen Sitzungen bestehen. Sie verschwinden nicht, wenn du dein Terminal schließt.
Hier sieht meine Projektkontextdatei nach sechs Monaten angesammeltem Wissen aus:
# Projektkontext
## Architektur
- Laravel 11 Monolith mit Vue 3 SPA-Frontend
- PostgreSQL-Primärdatenbank, Redis für Caching und Warteschlangen
- Auf AWS ECS mit Terraform verwalteter Infrastruktur deployed
- Auth: Benutzerdefinierte JWT-Implementierung (von Sanctum in Sprint 14 migriert)
## Aktueller Sprint (Sprint 22)
- Zahlungsverarbeitungs-Refactoring: Stripe → Multi-Provider-Abstraktion
- Webhook-Handler von synchroner auf asynchrone Warteschlangenverarbeitung migrieren
## Aktuelle Entscheidungen
- Adapter-Muster gegenüber Strategie für Zahlungsanbieter gewählt (2024-01-15)
- Grund: Runtime-Provider-Wechsel pro Händlerkonfiguration benötigt
Diese Datei ist nicht magisch entstanden. Ich habe sie über die Zeit aufgebaut, 30 Sekunden auf einmal. Am Ende jeder Arbeitssitzung sage ich Claude Code: "Aktualisiere den Projektkontext mit dem, woran wir heute gearbeitet haben."
Dein zweites Gehirn aufbauen — Das 30-Sekunden-Ritual, das alles verändert
Schritt 1: Bring Claude Code dazu, deine Ausgangskontextdatei zu erstellen.
Schritt 2: Das End-of-Session-Update (30 Sekunden). "Aktualisiere den Projektkontext mit dem, woran wir heute gearbeitet haben." Das ist es.
Schritt 3: Periodische Verdichtung. Alle paar Wochen: "Die Kontextdatei wird groß. Konsolidiere sie."
Skills: Deiner KI beibringen, deine beste Arbeit zu wiederholen
Mein erster Skill — automatisierte PR-Beschreibungen:
- Ich ließ Claude Code manuell eine PR-Beschreibung für eine echte Änderung schreiben
- Korrigierte den Output: "Nicht nur die geänderten Dateien auflisten — das Warum hinter jeder Änderungsgruppe erklären"
- Format angepasst: "Verwende diese Struktur: Zusammenfassung, Motivation, Änderungen, Testnotizen, Folgeaufgaben"
- "Speichere das als Skill namens 'pr-description'"
Der Skill, der mich beim On-Call gerettet hat: SEV-Untersuchung.
Während eines Produktions-Incidents um 2 Uhr morgens letzten Monat aktivierte ich diesen Skill. In etwa 40 Sekunden gab er mir drei gerankte Theorien. Die zweite Theorie war korrekt.
Was ich falsch gemacht habe und was mich noch frustriert
Die Kontextdatei kann dich anlügen. Wenn du nach einer Sitzung aktualisierst, in der du einen Ansatz erkundet, aber letztendlich verworfen hast, könntest du diesen verworfenen Ansatz versehentlich als Entscheidung festhalten.
Skills sind nicht set-and-forget. Mein PR-Beschreibungs-Skill wurde siebenmal überarbeitet.
Was sich in meinem Engineering-Workflow wirklich verändert hat
PR-Beschreibungen: Durchschnittliche Schreibzeit sank von 8 Minuten auf unter 1 Minute. Qualität verbesserte sich um etwa 60%.
Status-Updates: Von 5 Minuten täglich auf etwa 30 Sekunden.
Vorfall-Untersuchung: Zeit bis zur ersten Theorie sank von 25 Minuten auf etwa 90 Sekunden.
Geschätzte Gesamtzeitersparnis: 4-6 Stunden pro Woche.
Meine Herausforderung an dich
Wähle ein Projekt, an dem du aktiv arbeitest. Investiere heute 10 Minuten in die Erstellung einer Kontextdatei. Dann verpflichte dich zwei Wochen lang zum 30-Sekunden-End-of-Session-Update.
Nach zwei Wochen bitte Claude Code, eine PR-Beschreibung für deine nächste Änderung zu schreiben. Vergleiche sie mit dem, was du manuell geschrieben hättest.
Dieser Vergleich wird dir alles sagen, was du wissen musst.
Lass uns zusammenarbeiten
Du möchtest KI-Systeme aufbauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.
- Fiverr: fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited: ramlit.com
- ColorPark: colorpark.io
- xCyberSecurity: xcybersecurity.io
