← Zurück zum Archiv
Vibe-Coding @xPatrick096
FeuerwehrHub
Tech-Stack
- Rust
- Axum
- Vanilla JS
- SQLite
- Docker
Ja, mit hoher Wahrscheinlichkeit weitgehend KI-generiert. Die Anzeichen sind zahlreich und deutlich.
Geschwindigkeit vs. Umfang. Das Repo existiert seit dem 22. März 2026, also 20 Tage. In dieser Zeit sind 30.000 Zeilen Code entstanden: ein Rust/Axum-Backend, ein Vanilla-JS-Frontend, 43 DB-Migrationen, Docker-Setup, CI/CD, PDF-Generierung, Audit-Logging, Rollen- und Berechtigungssystem, TOTP-2FA, Fahrzeugverwaltung, Einsatzberichte, Vereinsverwaltung, Zeiterfassung, Terminkalender mit iCal-Export. Das ist für einen Solo-Entwickler in 20 Tagen schlicht unmenschlich, erst recht in Rust, das keine schnelle Sprache zum Entwickeln ist.
Commit-Muster. Die Commits zeigen ein typisches „Prompt → Paste → Push”-Muster: viele Commits an einem Tag (18 am 28. März, 16 am 2. April, 15 am 4. April), fast alle mit nichtssagenden Messages wie Update verein.rs, update, v1.2.1. Kein einziger beschreibender Feature-Commit à la „Add qualification expiry warnings” oder „Implement role-based module access”. Das passt zu jemandem, der KI-Output nimmt und direkt commitet.
Versionsschema-Chaos. Die Versionierung springt wild: v0.0.1 → v1.0.0.5 → v1.0.06.1 → v1.0.0.7.1 → v1.0.0.7.2 → dann plötzlich v1.1.07 (ohne Punkt) → v1.1.1 — und innerhalb von zwei Tagen von v1.1.x auf v1.4.8. Das zeigt, dass niemand ein Versionsschema geplant hat; es wird einfach inkrementiert, um neue Docker-Images zu triggern.
Framework-Wechsel mitten im Projekt. Am 4. April steht im Commit: „Topnav in VanillaJS reimplementiert (Sidebar entfernt)” und „Dropdown-State als writable Store — garantiert reaktiv in Svelte 5”. Das Frontend wurde also von Svelte auf Vanilla JS umgestellt, mitten im laufenden Projekt, ohne Spur von Svelte im finalen Code. Das ist typisch: KI generiert in einem Framework, es funktioniert nicht, also lässt man es in einem anderen neu generieren.
Strukturelle Uniformität. Jede einzelne Datei folgt exakt demselben Muster: // ── Abschnittsname ──────── Trennkommentare (inklusive der perfekt ausgerichteten Unicode-Striche), identischer CRUD-Aufbau, identische Error-Handling-Struktur. Das ist nicht „guter Stil”, das ist eine KI, die ein gelerntes Template reproduziert. Ein menschlicher Entwickler hätte nach dem 10. CRUD-Handler eine Abstraktion gebaut oder zumindest ein Makro. Hier werden 76 Handler in verein.rs (2.461 Zeilen) einzeln ausgeschrieben.
Null TODOs, null FIXMEs, null console.logs. In 30.000 Zeilen Code gibt es keinen einzigen TODO-Kommentar, keinen FIXME, kein einziges vergessenes console.log. Das ist bei echtem iterativem Entwickeln praktisch unmöglich. KI-generierter Code kommt „fertig” raus, ohne die Spuren menschlicher Arbeit.
Null auskommentierter Code. Menschliche Entwickler hinterlassen auskommentierten Code, experimentieren, lassen Alternativen stehen. Hier: nichts. Jede Datei liest sich wie aus einem Guss, weil sie es auch ist.
Unnatürliche Breite bei fehlender Tiefe. Das Projekt hat ein beeindruckendes Feature-Set (Fahrzeuge, Einsatzberichte, Vereinsverwaltung, Zeiterfassung, Lager, Kalender, 2FA, Audit-Log). Aber die Tiefe fehlt: keine Input-Validierung jenseits von „nicht leer”, keine Rate-Limits auf sensiblen Endpunkten außer Login, keine JWT-Revocation, TOTP-Secrets im Klartext, unauthentifizierte Endpunkte. Ein erfahrener Entwickler würde weniger Module bauen, diese aber absichern. KI generiert gerne neue Features, kümmert sich aber nicht um die Ränder.
Namens- und Stilkonsistenz über Sprachgrenzen hinweg. Der Rust-Code hat deutsche Section-Comments („Hilfsfunktionen”, „Haupt-Update-Routine”), deutsche Fehlermeldungen, deutsche Variable-Comments — aber englische Funktionsnamen und Struct-Felder. Diese spezifische Mischung („German domain, English code”) entsteht typischerweise, wenn man auf Deutsch promptet und die KI englische Code-Strukturen mit deutschen Strings generiert.
Der Entwickler hat offensichtlich technisches Grundverständnis: Docker-Setup funktioniert, Proxmox-Deployment ist durchdacht, die CI/CD-Pipeline existiert, und der Security-PR wurde gemergt. Die esc()-Funktion und die Security-Header deuten darauf hin, dass jemand zumindest die richtigen Fragen stellt. Das bcrypt-Hashing und der Account-Lockout sind korrekt implementiert.
Das Projekt ist mit sehr hoher Wahrscheinlichkeit zu 80–90 % KI-generiert, mit einem Entwickler, der die Richtung vorgibt, promptet, und die Ergebnisse zusammenfügt. Der Mensch dahinter versteht Infrastruktur (Docker, CI/CD, Deployment) besser als Application Security. Das ist kein „Copy-Paste von ChatGPT ohne nachzudenken”, aber es ist auch kein handgeschriebener Code. Es ist das, was man typischerweise sieht, wenn ein technik-affiner Nicht-Fullstack-Entwickler mit KI-Unterstützung ein ambitioniertes Projekt hochzieht: beeindruckend breit, aber mit den blinden Flecken, die entstehen, wenn man nicht jede generierte Zeile kritisch prüft.