$ cat wie.txt
Ich entscheide, was gebaut wird. Der Agent schreibt den Großteil vom Code.
Ein fester Ablauf hält uns beide ehrlich: besprechen → planen → umsetzen → prüfen → ausliefern.
Nichts wird veröffentlicht, bevor es nicht auf meinen eigenen Installationen lief.
Vibe Coding vs. Agentic Coding
Auf der Startseite steht Vibe Coder. Da hab ich angefangen, und der Name ist hängen geblieben. Hier das Kleingedruckte — weil die beiden Begriffe ständig in einen Topf geworfen werden, und sie sind nicht dasselbe.
vibe coding
Du beschreibst, was du willst, die KI spuckt Code aus, du kopierst die Fehlermeldung zurück. Wiederholen, bis es irgendwie läuft.
- prompten → hoffen → Fehler kopieren → nochmal
- keiner weiß so richtig, was im Code steckt
- kein Plan, keine Tests, kein Gedächtnis zwischen Sitzungen
- super fürs Wochenend-Spielzeug, schlecht für alles, worauf sich jemand verlässt
agentic coding ← das bin ich
Die KI arbeitet als Agent direkt im Projekt: liest den Code, führt Befehle und Tests aus, schreibt Commits. Ich bin nicht mehr der, der tippt — ich gebe die Richtung vor, treffe die Entscheidungen und prüfe die Arbeit.
- Agent arbeitet direkt in Repo & Terminal
- Entscheidungen und Pläne stehen fest, bevor Code entsteht
- jeder Schritt wird geprüft — von Tests und von mir
- das Was und das Warum gehören dem Menschen
Der Ablauf
Mein Setup: Claude Code als Agent, und obendrauf GSD — ursprünglich „Get Shit Done“, heute GSD Core. GSD zwingt zur Struktur: Jede Phase eines Projekts läuft durch denselben Ablauf, Entscheidungen und Pläne liegen als Dateien im Repo, und die schwere Arbeit machen frische Sub-Agents — damit die KI nicht langsam dümmer wird, je voller ihr Gedächtnis ist.
-
00
Ideeich
Jedes Projekt fängt mit einem echten Problem an — meinem, oder dem von jemandem, den ich kenne. Ganz ohne KI. Führerhaus, 6 Uhr früh, Kaffee, und ein „wär doch cool, wenn…“.
-
01
Besprechen
/gsd-discuss-phaseich + agentBevor auch nur eine Zeile Code entsteht: Was genau bauen wir, was gehört nicht dazu, welche Entscheidungen treffe ich. Der Agent stellt die nervigen Fragen, ich beantworte sie. Ergebnis: eine schriftliche Grundlage, auf der die ganze Phase aufbaut.
-
02
Planen
/gsd-plan-phaseagentich: freigebenDer Agent recherchiert und zerlegt die Phase in kleine Pläne, jeder so groß, dass er in einen frischen Kontext passt. Ich lese sie und widerspreche, wo sie danebenliegen. Kein Plan, kein Code.
-
03
Umsetzen
/gsd-execute-phaseagentJetzt programmiert der Agent — in parallelen Wellen, frischer Kontext pro Plan, ein sauberer Git-Commit pro Aufgabe. Das ist der Teil, an den alle denken, wenn sie „KI programmiert“ hören. Es ist vielleicht ein Drittel der eigentlichen Arbeit.
-
04
Prüfen
/gsd-verify-workichIch gehe durch, was gebaut wurde, klicke mich durch, versuche es kaputt zu machen. Was nicht passt, wird zum Fix-Plan. Nichts ist „fertig“, nur weil der Agent das sagt.
-
05
Ausliefern
/gsd-shipich + agentPull Request, Review, Merge, Release über Jenni. Dann läuft es erst mal auf meinen eigenen Installationen — wochenlang, nicht tagelang. Dann die nächste Phase. Fertig ist, wenn’s fertig ist.
So sieht das aus
Eine gekürzte Wiedergabe, wie ein Feature entsteht — das Wetter-Protokoll in Schneespur. Echter Ablauf, Ausgabe gekürzt und vereinfacht. Grün bin ich, grau ist der Agent.
> /gsd-discuss-phase 7
● Phase 7 — Wetter zum Zeitpunkt des Einsatzes
? Die Anbieter liefern unterschiedliche Werte. Welcher gilt?
michael › BrightSky in Deutschland, Open-Meteo als Fallback. Rohwerte mitspeichern.
? Ein Messwert pro Tour oder einer pro Stopp?
michael › Pro Stopp. Genau darüber wird später gestritten.
✓ CONTEXT.md geschrieben — 6 Entscheidungen fix, 2 vertagt
> /gsd-plan-phase 7
● recherchiere Anbieter · lese Codebasis …
✓ 3 Pläne · passen je in frischen Kontext · Plan-Check bestanden
michael › Plan 2 cacht für immer. Wetter veraltet — maximal 10 Minuten.
✓ Plan 07-02 überarbeitet
> /gsd-execute-phase 7
● Welle 1 · 07-01 Anbieter-Schnittstelle + BrightSky / Open-Meteo
● Welle 1 · 07-02 Messwert pro Stopp + Cache
● Welle 2 · 07-03 Wetterblock im PDF-Einsatznachweis
✓ 11 Commits · alle Tests grün
> /gsd-verify-work 7
michael › Im PDF steht 3,0 °C, in der App 2,9. Rundung?
● analysiere … PDF rundet, App schneidet ab → Fix-Plan 07-04
✓ behoben · von michael nachgeprüft
> /gsd-ship 7
✓ PR offen. Nächster Halt: meine eigenen Installationen. Fertig ist, wenn’s fertig ist.
Wer macht was
ich
- die Idee, und das Warum dahinter
- jede Entscheidung über Umfang und Verhalten
- Pläne lesen — und Nein sagen
- testen auf echten Installationen, unter echten Bedingungen
- entscheiden, was veröffentlicht wird, und wann
der agent
- die ganze Codebasis auf einmal im Blick
- Recherche und erste Entwürfe jedes Plans
- den Großteil vom Code und den Tests schreiben
- Commits, Refactorings, die langweiligen Sachen
- Dinge finden, die ich übersehen hätte
Wo’s schiefgeht
Die KI liegt manchmal mit voller Überzeugung daneben. Sie baut zu viel. Sie vergisst, was wir gestern beschlossen haben. Das ist kein Grund, sie nicht zu nutzen — es ist der Grund für den Ablauf: Entscheidungen auf Platte, frischer Kontext für jede Aufgabe, ein Mensch, der prüft, und eine lange Testphase auf meinen eigenen Installationen.
Ich bin kein gelernter Programmierer. Deshalb vertraue ich Code nicht, weil er richtig aussieht. Ich vertraue ihm, weil er gelaufen ist.
- Zwei ernste Befunde in meiner eigenen App. Ich habe einen zweiten KI-Agenten auf Schneespur losgelassen — sieben Befunde, zwei davon übel. Alle behoben, alle veröffentlicht. Die Pentest-Geschichte →
- Ein Monat verschwendeter API-Aufrufe. Ein kaputter n8n-Workflow hat alle paar Minuten leise wieder bei OpenAI angefragt; das Dashboard hat es angezeigt, ich habe nicht hingeschaut. Monitoring ist seitdem Pflicht. Mein größter Fail →
Du hast eine Idee?
Das Beste daran: Du musst nichts davon selbst lernen. Wenn du eine Idee für ein Tool hast — irgendwas, das dich in der Arbeit, im Betrieb, im Verein oder in deiner Gemeinde nervt — und keine Lust hast, dich selbst mit einer KI herumzuschlagen: lass uns reden.
Das hier ist keine Leistungsseite. Es gibt kein Paket und keinen Stundensatz. Ich mach das, weil es Spaß macht, und eine gute Idee ist der beste Treibstoff, den es gibt.
$ am liebsten so
Wir bauen es als Open Source. Dein Problem ist gelöst — und alle anderen mit demselben Problem haben die Lösung auch.
Genau so ist Schneespur entstanden: das Problem eines Kollegen, heute kann es jeder kostenlos installieren.
Was passiert, nachdem du schreibst
- Du beschreibst das Problem. Drei Sätze, kein Pflichtenheft. Ich antworte innerhalb weniger Tage — abends, du erinnerst dich.
- Ich sage dir ehrlich, was ich denke. Lässt sich das mit KI bauen, wie groß ist es ungefähr, und kann es Open Source werden? Wenn die Antwort „nicht mit mir“ ist, sage ich das und zeige dir, wo es besser aufgehoben ist.
- Wir bauen etwas, das du anfassen kannst. Ein Prototyp, unter einer echten URL, meist innerhalb weniger Wochen. Dann entscheiden wir gemeinsam, ob es weitergeht.
Was sonst noch geht
- Du willst eine ehrliche Einschätzung: Lässt sich das mit KI bauen — und grob wie?
- Du bist eine Firma und willst sehen, wie Agentic Coding bei euch aussehen könnte.
- Es ist etwas, das nicht offen sein kann. Passt — erzähl’s mir trotzdem, ohne Versprechen in beide Richtungen.
Passt / passt nicht
- interne Tools, die einen Excel-und-E-Mail-Prozess ersetzen
- selbst gehostete Web-Apps (Laravel, PHP), WordPress-Plugins
- Automatisierung & Workflows
- Prototypen, um zu sehen, ob eine Idee trägt
- „das nächste Uber, bis Freitag“
- alles mit 24/7-Bereitschaft — ich bin auf der Autobahn
- geschlossene SaaS, deren ganzer Sinn ist, Leute einzusperren
$ mail michael
Drei Sätze reichen:
1. Was ist das Problem? 2. Wer hat es? 3. Was gibt’s schon?
// Antworten kommen abends & am Wochenende — tagsüber bewege ich 40 Tonnen.