Nach diesem Modul können Sie:
Vibe Coding heißt: Software entsteht im Gespräch mit einem Sprachmodell. Sie beschreiben in eigenen Worten, was ein kleines Programm tun soll, das Modell schreibt den Code, Sie probieren das Ergebnis aus und beschreiben die nächste Änderung. Den Begriff prägte der KI-Forscher Andrej Karpathy im Februar 2025 in einem Kurzbeitrag. Er meinte damit ausdrücklich Wegwerf-Projekte: kleine Experimente, bei denen man den erzeugten Code gar nicht mehr Zeile für Zeile liest, weil nichts Ernstes daranhängt.
Für die Verwaltung passt dieses Bild nur mit Einschränkungen. Ein Amt kann sich Wegwerf-Code leisten, solange er wirklich wegwerfbar bleibt. Sobald ein Werkzeug im Alltag hängen bleibt, ändert sich die Lage, und genau das ist der Punkt, den dieses Modul klärt.
Für Prototypen und kleine interne Helfer eignet sich Vibe Coding gut, ebenso für Werkzeuge, die vollständig im Browser laufen und mit fiktiven oder unkritischen Daten arbeiten. Zwei Beispiele von civitasai.de zeigen, wie das in der Praxis aussieht.
Die Organigramm-Maschine liest eine Excel-Tabelle vollständig im Browser ein und zeichnet daraus ein Organigramm im Berlin-Design, druckfertig als DIN-A3-PDF. Sie kommt ohne KI und ohne eigenen Server aus, der komplette Rechenweg läuft auf dem Gerät der Nutzerin. Die Erfahrungsmaschine bestimmt die Erfahrungsstufe nach § 16 Absatz 2 TV-L. Ihr Rechenkern, also die Datumsmathematik nach den §§ 187 und 188 BGB und die Prüfung der Stufenschwellen, ist deterministischer Code im Browser. Ein Sprachmodell kommt nur an einer einzigen, eng begrenzten Stelle zum Einsatz, nämlich bei der Prüfung, ob ein Abschnitt der Erfahrung überhaupt einschlägig ist, und beim Entwurf eines Aktenvermerks. Beide Werkzeuge arbeiten ausschließlich mit fiktiven Daten.
Das ist die Bauart, um die es in diesem Modul geht: klein, nachvollziehbar, ohne dass Personendaten das eigene Gerät verlassen.
Ungeeignet ist Vibe Coding, sobald ein Werkzeug Personendaten verarbeitet, ein bestehendes Fachverfahren ersetzt oder ohne Prüfung durch IT und, wo einschlägig, Datenschutz in den Dauerbetrieb übergeht. In diesen Fällen braucht es die reguläre Beschaffung oder Entwicklung, mit Abnahme und Dokumentation. Ein im Chat erzeugtes Skript, das Sozialdaten sortiert oder Fristen berechnet und danach ungeprüft in einem Referat weiterläuft, hat den Status eines Prototyps längst verlassen. Es ist ein Fachverfahren ohne Abnahme, und genau dort verläuft die Grenze zwischen freiem Ausprobieren und Prüfpflicht.
Die Arbeitsschleife bleibt bei jedem Vibe-Coding-Projekt gleich. Am Anfang steht eine Anforderung in Alltagssprache, kein Pflichtenheft, aber ein klarer Satz, was das Werkzeug tun und was es ausdrücklich nicht tun soll. Wer klein anfängt, testet mit einer einzigen Funktion, statt gleich mehrere Aufgaben gleichzeitig zu verlangen. Das Modell erzeugt einen ersten Stand, den man mit eigenen Beispieldaten ausprobiert und nicht mit den einzigen echten Zahlen, die man zur Hand hat. Jede Änderung wird gelesen, bevor sie übernommen wird, nicht nur angeklickt. Ein funktionierender Stand wird gesichert, bevor die nächste Änderung beginnt, damit ein Rückschritt jederzeit möglich bleibt. Dann beginnt die Schleife von vorn.
Deterministische Logik, also Fristen, Rechenformeln oder Schwellenwerte, gehört dabei in Code, den man Zeile für Zeile lesen und mit einer Testrechnung prüfen kann, und nicht in einen Prompt, dessen Ergebnis bei jedem Lauf leicht anders ausfallen kann.
Vor dem Start jedes selbstgebauten Werkzeugs sollten diese Punkte geklärt sein. Das ist keine Bürokratie, das ist das Mindestmaß an Verantwortung für etwas, das andere Menschen benutzen werden.
Für Führungskräfte heißt das: Vibe Coding im eigenen Haus braucht einen Rahmen, kein Verbot und keine stillschweigende Duldung. Ein Referat, in dem eigene kleine Skripte still entstehen, hat entweder eine Spielwiese mit klaren Regeln oder ein Schatten-IT-Problem, das erst auffällt, wenn etwas ausfällt. Der wirksame Rahmen braucht drei Elemente. Eine Spielwiese mit fiktiven Daten erlaubt das Ausprobieren, ohne dass ein Fehler echten Schaden anrichtet. Ein klarer Übergabepunkt zur IT markiert, ab wann ein Werkzeug geprüft und offiziell übernommen wird, statt informell weiterzuleben. Und ein Verzeichnis der selbstgebauten Helfer im eigenen Bereich macht sichtbar, was es überhaupt gibt, bevor ein Prüfungsfall oder ein Ausfall es unangenehm zeigt.
Ein Referat ohne Übergabepunkt zur IT hat am Ende zwei parallele Systeme: das offizielle und das, was eine einzelne Kollegin sich vor zwei Jahren selbst gebaut hat. Nur eines davon kennt die IT, und nur eines davon läuft noch, wenn die Kollegin das Haus wechselt.
Eine Kollegin aus dem Sachgebiet Wohngeld möchte mit einem Sprachmodell ein kleines Werkzeug bauen, das eingehende Anträge nach Vollständigkeit vorsortiert. Sie bittet Sie um eine erste Anforderung in Alltagssprache, die sie dem Modell geben kann.
Formulieren Sie die Anforderung in vier bis sechs Sätzen. Beschreiben Sie, was das Werkzeug tun soll, mit welchen Daten es arbeitet und was es ausdrücklich nicht tun soll.
Ihre Eingaben bleiben in diesem Browserfenster. Sie werden nicht gespeichert und nicht übertragen, ein Neuladen der Seite verwirft sie.
„Ich brauche ein Werkzeug, das eine Liste von Wohngeldanträgen prüft und für jeden Antrag meldet, ob die Pflichtunterlagen laut unserer Checkliste vollständig vorliegen. Als Eingabe bekommt es eine Tabelle mit Antragsnummer und einer Spalte je Unterlage, testweise nur mit den zehn fiktiven Übungsfällen, die ich beilege. Es soll ausschließlich Vollständig oder Unvollständig mit fehlender Unterlage ausgeben, keine Einschätzung zum Anspruch und keinen Bescheidtext. Es soll nichts automatisch verschicken, das Ergebnis bleibt eine Liste, die ich mir ansehe.“
Ordnen Sie jede Situation der passenden Einschätzung zu. Sie erhalten sofort eine Rückmeldung mit kurzer Begründung.
Sie leiten ein Sachgebiet. Eine Mitarbeiterin hat sich ohne Rücksprache ein kleines Skript für die Terminplanung gebaut und benutzt es seit drei Wochen im Alltag. Sie wollen das Ausprobieren im Team nicht abwürgen, aber auch nicht das Skript unbesehen weiterlaufen lassen.
Schreiben Sie den Gesprächseinstieg in drei bis fünf Sätzen auf. Nennen Sie darin, was Sie an der Eigeninitiative anerkennen, und die eine Frage, die vor der Weiternutzung geklärt sein muss.
Ihre Eingaben bleiben in diesem Browserfenster. Sie werden nicht gespeichert und nicht übertragen, ein Neuladen der Seite verwirft sie.
„Schön, dass Sie sich das selbst gebaut haben, das zeigt, wie schnell sich mit den neuen Werkzeugen etwas Nützliches bauen lässt. Bevor es im Team weiterläuft, brauche ich zwei Dinge von Ihnen: eine kurze Beschreibung, welche Daten das Skript sieht, und fünf Minuten, in denen Sie mir den Code zeigen. Danach klären wir gemeinsam mit der IT, ob es so bleiben kann oder was sich ändern muss. Bis dahin bitte nur mit den Testterminen weiterarbeiten, die ohnehin niemandem zugeordnet sind.“
Anerkennung und Prüfung schließen sich nicht aus. Wer nur lobt, lässt ein ungeprüftes Skript weiterlaufen. Wer nur prüft, entmutigt die Eigeninitiative, die das Referat eigentlich braucht. Beides gehört in denselben Satz.
Wie nutzen Sie KI in Ihrer Behörde zu diesem Thema? Teilen Sie Erfahrungen, stellen Sie Fragen, anonym oder mit E-Mail. Kommentare liegen auf eigenen Servern (DSGVO-konform).