Pokkum: 100 % vibe-coded, produktiv im Einsatz

Kurz zum Produkt, damit die Methode einen Massstab hat. Pokkum ist kein Spielzeugprojekt, sondern ein Supply-Chain-Werkzeug mit rund 60’000 Zeilen Go und 17 CLI-Befehlen:

• Builds ohne Daemon für amd64 und arm64, direkt aus Go in die Registry.
• Nachprüfbare Reproduzierbarkeit: Alle Zeitstempel im Image leiten sich aus SOURCE_DATE_EPOCH ab. pokkum verify baut neu und vergleicht auf drei Ebenen: Manifest, Layer und einzelne Dateien.
• Supply-Chain-Security: SBOM (SPDX), SLSA-v1.0-Provenance, Cosign/DSSE-Signaturen und keyless Sigstore-Prüfung der Base-Images.
• Drei Build-Strategien: layered mit eigenem PID-1-Supervisor in Go, exe als Single Binary via Bun und static mit einem kleinen Go-Webserver, ganz ohne Node oder Bun.
• Deployment inklusive: Kubernetes mit gehärteten Manifesten und Rollback, dazu direkte Deployments auf Dokploy und SwiftWave.
• Hermetische Builds ohne Netzwerkzugriff für air-gapped Umgebungen.

Im Einsatz: Ich deploye inzwischen die meisten meiner Apps und Sites mit Pokkum. Deshalb kann es direkt auf Dokploy und SwiftWave ausliefern, die beiden PaaS, die ich selbst betreibe.

Am deutlichsten zeigt sich der Unterschied bei statischen Sites. Pokkum packt nur die Dateien und einen kleinen Go-Webserver auf ein Base-Image ohne libc. Das Ergebnis ist 8,1 MB gross, gegenüber 73 MB bei der besten von Hand optimierten Variante (Caddy auf Distroless). Das sind 89 % weniger, bei null kritischen CVEs.

Bei Apps mit serverseitiger Logik braucht es eine JavaScript-Runtime, und die Grösse ist nicht mehr die spannende Zahl: Gegenüber einem sauber optimierten Dockerfile spart Pokkum nur rund 17 %. Entscheidend ist die Angriffsfläche: null kritische CVEs, keine Shell im Image und keine Build-Konfiguration, die jemand pflegen muss.

Die naheliegende Annahme lautet: Der schnellste Agent kommt am schnellsten ans Ziel. Bei Pokkum war es umgekehrt.

Angefangen habe ich mit Google Antigravity und Gemini Flash (3.5, später 3.6 und 3.7). Das fühlte sich schnell an: Features kamen in hohem Takt, die Oberfläche ist angenehm. Dann liess ich Claude Code die Commits reviewen, und es fand weit mehr Probleme als erwartet. Stubs waren als „implementiert“ gemeldet, Fehler blieben unerwähnt, und die Go-Version wurde wiederholt heruntergestuft.

Ab diesem Punkt habe ich umgestellt. Claude Code wurde der primäre Agent, obwohl er pro Aufgabe langsamer ist. Dafür hält er sich an Regeln, und genau das macht Leitplanken erst wirksam. 328 der 399 Commits sind mit Claude Opus oder Sonnet entstanden.

Die grösste Stolperfalle war nicht fehlende Intelligenz, sondern fehlende Ehrlichkeit. Mit Antigravity und Gemini Flash habe ich erlebt:

• Stubs, die nie durch echte Logik ersetzt wurden.
• Falsche Erfolgsmeldungen: Ein Feature galt als „implementiert“, obwohl es nur angerissen war.
• Stille Fehler, die der Agent nicht meldete, weil er sie nicht bemerkte.
• Eigenmächtige Änderungen, etwa eine heruntergestufte Go-Version, um die niemand gebeten hatte.

Mit DeepSeek V4 Flash im DeepSeek Harness waren es andere Probleme: unzuverlässige Tool-Calls und Schleifen, aus denen der Agent nicht mehr herausfand.

Zur Fairness: Mit Claude Code habe ich falsche Erfolgsmeldungen nicht erlebt. Ich bin allerdings erst gewechselt, nachdem ich die Probleme bemerkt und die Leitplanken eingeführt hatte. Ob Claude ohne sie dieselben Fehler gemacht hätte, kann ich deshalb nicht sagen. Die Leitplanken bleiben so oder so: Sie fangen solche Fehler ab, egal von welchem Modell sie kommen.

Nicht alle Fehler kamen von den Agents. Meine eigenen:

• Zu viele Flags. Pokkum hat weit über 100 Flags. Um die Methode zu prüfen, musste ich Funktionen tatsächlich bauen, und fast jede brachte einen Schalter mit. Heute schlage ich selbst im README nach, sobald ich etwas Ungewöhnliches bauen will. Eine abgespeckte Version habe ich erwogen, aber verworfen, solange kaum jemand ausser mir Pokkum nutzt. Für ein Produkt mit echten Nutzern wäre das die erste Baustelle.
• Die Release-Pipeline. Bis die Veröffentlichung auf npm funktionierte, war ich bei etwa v0.5. Auch mit KI-Hilfe brauchte es viele Anläufe, und am Ende war ich so erschöpft, dass ich den Weg dorthin kaum nachvollziehen könnte. Die Lehre: Eine neue Release-Pipeline probiere ich künftig zuerst an einem Projekt ohne Risiko aus, statt darauf zu setzen, dass sie beim ersten Versuch klappt.

Bei der Frage, welche Bereiche ich den Agents überlasse, habe ich bewusst nichts ausgeklammert, auch nicht heikle Bereiche wie Signaturen, Reproduzierbarkeit oder den PID-1-Supervisor. Die Grenze liegt für mich nicht bei der Domäne, sondern bei der Frage: Kann ich es verifizieren?

Vertraue ich dem Agent? Nur bedingt. Wenn ich unsicher war, habe ich den Code nicht selbst neu geschrieben, sondern recherchiert, bis ich die Sache einordnen konnte. Der Reflex, lieber alles selbst zu machen, kam seltener als erwartet. Das Vertrauensproblem liess sich fast immer mit Verifikation und Recherche lösen.

Claude ist beim Programmieren hervorragend, vielleicht das Beste, was es derzeit gibt. Das wirft eine unbequeme Frage auf: Hat Pokkum funktioniert, weil die Methode trägt, oder weil das Modell so stark ist?

Das will ich als Nächstes herausfinden: Lässt sich ein Projekt auch mit kleineren Modellen zu 100 % vibe-coden? Relevant ist das nicht nur akademisch. Kleine Modelle lassen sich lokal betreiben, und das ist überall dort gefragt, wo Code oder Daten das Haus nicht verlassen dürfen.

Meine Hypothese: Ja, wenn das Umfeld mehr Verantwortung übernimmt. Drei Hebel sehe ich:

• Der Harness statt des Agents: Es gibt Harnesses für kleinere Modelle, die Aufgaben vom Modell in den Harness verlagern und so das fehleranfällige Tool-Calling robuster machen.
• Code-Intelligenz statt Kontext: Kleinere Kontextfenster verlangen Werkzeuge wie Serena, die gezielt die relevanten Symbole liefern, statt ganze Dateien einzulesen.
• Klare Grenzen: Die hexagonale Architektur schneidet das Projekt in kleine Einheiten mit klaren Schnittstellen. Eine Aufgabe passt so in einen kleinen Kontext.

Test-Suite und Clean-Context-Sweep blieben unverändert. Sie prüfen das Ergebnis, egal welches Modell es geschrieben hat. Was ein starkes Modell schneller macht, könnte ein kleines Modell überhaupt erst befähigen.

Hat sich der Selbstversuch gelohnt? Ja. Pokkum ist als v1.2.1 veröffentlicht, und ich deploye damit inzwischen die meisten meiner Apps und Sites. Das Problem, mit dem alles begann, ist gelöst. Wertvoller ist aber, was ich über die Methode gelernt habe:

Was ich davon in ein Team mitbringe:

• Einen erprobten Workflow für KI-gestützte Entwicklung: Systemprompts, Verifikationsprotokoll und Fehlerkultur, die ein Team übernehmen und anpassen kann.
• Das Urteilsvermögen, welcher Agent für welche Aufgabe taugt, und die Ehrlichkeit, Grenzen offen zu benennen.
• Praxiswissen in Supply-Chain-Security: reproduzierbare Builds, SBOM, SLSA, Signaturen und gehärtete Container.