Vibe Coding: Vom Prototyp zur verlässlichen Software

Nehmen wir an, die Geschäftsführerin eines Fachverbands hat an einem Freitagnachmittag eine gute Idee. Die Anmeldung zur Herbsttagung läuft bisher über ein PDF-Formular, das ausgedruckt, ausgefüllt, eingescannt und in der Geschäftsstelle abgetippt wird. Sie öffnet ein KI-Werkzeug, beschreibt in ganzen Sätzen, was sie braucht, und zwei Stunden später steht eine kleine Web-App: ein Formular, ein Mitgliederpreis, eine Bestätigungsmail, eine Teilnehmerliste für die Geschäftsstelle. Sie hat keine Zeile Code geschrieben. Die App funktioniert.

Für diese Art zu arbeiten gibt es seit Februar 2025 einen Namen. Andrej Karpathy, Mitgründer von OpenAI, beschrieb damals auf X eine Arbeitsweise, bei der man sich ganz den Vibes überlässt, die Vorschläge der KI übernimmt, ohne sie im Detail zu lesen, und irgendwann vergisst, dass es den Code überhaupt gibt. Er nannte das Vibe Coding und ordnete es gleich selbst ein: Für Wegwerfprojekte am Wochenende sei das gar nicht so schlecht. Collins kürte den Begriff zum Wort des Jahres 2025. Die Einschränkung auf wenig folgenreiche Projekte hat seine Verbreitung weniger gut überstanden.

Dieser Text handelt davon, was zwischen jenem Freitagnachmittag und dem Moment liegt, in dem sich dreihundert Mitglieder auf die App verlassen. Die kurze Antwort lautet: mehr, als man der App ansieht. Die lange Antwort beginnt mit einer Würdigung.

Die Geschäftsführerin hat etwas Wertvolles geleistet. Sie hat ein Problem, das sie genau kennt, in eine greifbare Form gebracht, ohne Lastenheft, Ausschreibung und drei Abstimmungsrunden. Wer erlebt hat, wie zwanzig Seiten Anforderungsprosa von drei Menschen auf drei Arten gelesen werden, weiß, was ein klickbarer Prototyp wert ist. Er beendet Missverständnisse, bevor sie teuer werden, und macht aus einer vagen Idee etwas, über das man konkret sprechen kann.

Hinzu kommt eine Klasse von Software, deren Entwicklung sich früher oft nicht gelohnt hätte: das Skript, das einmal im Quartal eine Exportdatei umsortiert, der Rechner für eine interne Kalkulation, die kleine Übersicht, die genau eine Abteilung braucht. Solche Werkzeuge sind oft gar keine Prototypen. Sie sind fertig und bleiben über Jahre nützlich, gerade weil ihr Zweck begrenzt ist. Für sie war professionelle Entwicklung immer zu aufwendig und das Selbermachen zu mühsam. Viele Menschen erleben dabei zum ersten Mal, dass sie Software selbst gestalten können, statt sie nur zu benutzen. Diese Selbstwirksamkeit ist ein echter Gewinn und kann ein Einstieg sein, sich mit der Funktionsweise von Software zu beschäftigen.

Der Begriff selbst wird inzwischen sehr unterschiedlich verwendet. Im engen Sinne meint Vibe Coding, dass man den erzeugten Code nicht prüft und nur das Ergebnis auf dem Bildschirm beurteilt. Der britische Entwickler Simon Willison hat früh darauf hingewiesen, dass das etwas anderes ist, als KI beim Programmieren zu nutzen: Wer den generierten Code liest, testet und versteht, entwickelt Software, nur eben mit einem sehr leistungsfähigen Werkzeug (1). Im Alltag ist Vibe Coding dagegen längst zum Sammelbegriff für jedes Programmieren per Beschreibung geworden. Karpathy schlug Anfang 2026 für die professionelle Variante, bei der Menschen KI-Agenten anleiten und deren Arbeit überprüfen, den Begriff Agentic Engineering vor. Wichtiger als das Etikett ist die Frage, ob jemand prüft, was entsteht, und woran.

Zurück zur Tagungsanmeldung. Beim ersten Ausprobieren speichert das Formular eine Anmeldung, der Mitgliederpreis erscheint, die Mail kommt an. Dann geht die App online, und die Anforderungen ändern sich, ohne dass sich an der Oberfläche etwas ändert. Die Tagung hat 120 Plätze. Eine Minute nach dem Versand des Newsletters klicken zwei Mitglieder gleichzeitig auf den letzten freien Platz. Beide sehen „verfügbar", beide erhalten eine Bestätigung. Dafür braucht es keine zwanzigtausend Nutzer, zwei genügen. Entwickler sprechen von einer Race Condition. Die Datenbank muss die Prüfung und die Vergabe des letzten Platzes so absichern, dass zwei gleichzeitige Buchungen ihn nicht beide erhalten, etwa durch eine Transaktion mit einer geeigneten Sperre. Die Transaktion allein, also ein Vorgang, der vollständig oder gar nicht stattfindet, genügt dafür nicht immer; es kommt darauf an, wie streng sie gleichzeitige Zugriffe voneinander trennt.

So geht es weiter. Der Mitgliederpreis darf nur gewährt werden, wenn die Mitgliedschaft tatsächlich besteht, geprüft auf dem Server und nicht bloß im Browser, wo jeder den Preis verändern könnte. Das ist eine Frage der Autorisierung. Der Zahlungsdienstleister meldet eine Zahlung manchmal verspätet oder doppelt; die App muss erkennen, dass es dieselbe Zahlung ist, statt zwei Tickets auszustellen. Fachleute nennen diese Eigenschaft Idempotenz.

Die Geschäftsstelle soll die Teilnehmerliste sehen, die Referentin nur ihre Sessionteilnehmer, das Mitglied nur die eigene Buchung. Fällt der Mailversand aus, darf die Anmeldung trotzdem nicht verloren gehen. Geöffnet wird die App zudem auf älteren Dienstrechnern, auf iPhones und Android-Geräten, in Safari, Chrome und Firefox, und jede dieser Umgebungen stellt das Formular ein wenig anders dar und behandelt manche Eingaben anders. Und wenn im nächsten Jahr ein Frühbucherrabatt dazukommt, muss eine Änderung am Datenmodell die bestehenden Buchungen unversehrt lassen.

Keine dieser Anforderungen ist exotisch, und KI kann bei der Umsetzung jeder einzelnen helfen. Dafür müssen sie allerdings erkannt, beschrieben und anschließend überprüft werden. Das Tückische ist, dass die App ohne sie genauso aussieht wie mit ihnen.

Die Softwaretechnik hat diesen Unterschied früh beschrieben. 1975 unterschied Fred Brooks, der bei IBM die Entwicklung des Betriebssystems OS/360 geleitet hatte, zwischen einem Programm, das bei seinem Autor läuft, und einem Programmprodukt, das andere nutzen und warten können, das getestet, dokumentiert und für beliebige sinnvolle Eingaben gerüstet ist. Muss es zusätzlich mit anderen Systemen zusammenarbeiten, wird daraus ein Programmsystemprodukt. Brooks schätzte den Aufwand für jede dieser Stufen auf etwa das Dreifache der vorigen. Diese Faktoren stammen aus einer anderen Epoche und lassen sich nicht auf heute übertragen, zumal KI inzwischen auch beim Testen, Dokumentieren und Integrieren hilft. Die Unterscheidung selbst bleibt nützlich, weil sie zeigt, dass es sich um verschiedene Arten von Arbeit handelt.

Elf Jahre später argumentierte Brooks in No Silver Bullet, dass keine einzelne Neuerung die Produktivität innerhalb eines Jahrzehnts um eine Größenordnung steigern werde, weil die eigentliche Schwierigkeit im Problem selbst liege, in seinen Regeln, Ausnahmen und Widersprüchen (2). Erhebliche Fortschritte durch das Zusammenwirken vieler Verbesserungen hielt er ausdrücklich für möglich. Übertragen auf den Verband heißt das: KI kann helfen, eine komplizierte Beitragsordnung mit Ermäßigungen und Übergangsregeln zu analysieren und umzusetzen. Welche Regeln gelten sollen und ob die Umsetzung fachlich stimmt, muss trotzdem jemand klären, der den Verband kennt.

Sicherheitsmängel sind im Alltag unsichtbar. Eine unsichere App lädt genauso schnell wie eine sichere und hat dieselben Knöpfe. Wie das praktisch aussieht, zeigte sich im Frühjahr 2025 bei Lovable, einem der populärsten Werkzeuge für Vibe Coding. Der Entwickler Matt Palmer, beschäftigt beim Konkurrenten Replit, stellte fest, dass damit erstellte Apps direkt aus dem Browser auf ihre Datenbank zugriffen und den Schutz der Daten allein den Datenbankregeln überließen (3). Diese Regeln, die Row Level Security, legen fest, welcher Nutzer welche Zeile einer Tabelle sehen oder ändern darf. In betroffenen Projekten fehlten sie oder waren unzureichend. Mit einer leicht veränderten Anfrage ließen sich dann Namen, E-Mail-Adressen, Zahlungsstatus oder API-Schlüssel auslesen, teils sogar verändern.

Ein Detail ist für Laien leicht misszuverstehen: Der Zugangsschlüssel, mit dem der Browser die Datenbank anspricht, ist bei diesem Aufbau bewusst öffentlich. Seine Sichtbarkeit ist kein Fehler. Die Sicherheit hängt vollständig daran, dass die Berechtigungen dahinter zur Geschäftslogik passen. Palmers Bericht enthält dazu eine aufschlussreiche Randbemerkung: Lovables damalige Prüfung vor der Veröffentlichung meldete, ob Regeln aktiviert sind, sagte aber nicht unbedingt, ob sie ausreichen. Eine Regel kann existieren und trotzdem das Falsche erlauben. Lovable hat seine Sicherheitsprüfungen seither deutlich erweitert und schreibt in der eigenen Dokumentation, dass sie eine gründliche Sicherheitsprüfung nicht ersetzen. Das ist eine faire und bemerkenswert ehrliche Auskunft.

Dass solche Muster kein Einzelfall sind, legen Benchmark-Studien nahe. Der Sicherheitsanbieter Veracode, der naturgemäß ein geschäftliches Interesse an dem Thema hat, lässt regelmäßig Sprachmodelle Programmieraufgaben mit bekannten Sicherheitsfallen lösen. Im Bericht von 2026 war der erzeugte Code fast immer syntaktisch korrekt, bestand die Sicherheitsprüfung aber im Schnitt nur in 56 Prozent der Fälle, kaum besser als ein Jahr zuvor (4). Das beschreibt einen bestimmten Aufgabenbestand, keine Fehlerquote aller KI-Software. Der Befund zeigt vor allem, dass formal korrekter Code bekannte Sicherheitslücken enthalten kann. Ob er die fachliche Aufgabe richtig erfüllt, ist noch einmal eine eigene Frage.

Ähnlich lehrreich ist ein Fall aus dem Juli 2025. Der Investor Jason Lemkin entwickelte mit dem Agenten der Plattform Replit eine Kontaktdatenbank und hatte ausdrücklich einen Änderungsstopp verhängt. Der Agent löschte trotzdem die Produktionsdatenbank mit Einträgen zu mehr als 1.200 Führungskräften. Replit reagierte mit einer technischen Trennung von Entwicklungs- und Produktionsdatenbank, und darin liegt die eigentliche Lehre. Eine Anweisung im Chat ersetzt keine Berechtigung. Was ein System nicht darf, sollte es technisch gar nicht erst können.

Lemkins späterer Rückblick macht den Fall erst richtig interessant (5). Entgegen der ursprünglichen Auskunft des Agenten ließ sich die Datenbank doch wiederherstellen. Im selben Text beschreibt er drei Apps, die sein Team inzwischen mit KI entwickelt und veröffentlicht hat und die nach seinen Angaben Tausende Menschen täglich nutzen. Das Rezept dafür laut Lemkin: ein eng begrenzter Umfang, vorab geprüfte Fachlogik und bewährte Dienste für alles, was nicht zum Kern gehört. Das ursprüngliche, deutlich komplexere Projekt war dagegen weiterhin nicht veröffentlicht. Derselbe Anwender erlebt also beides, einen gravierenden Fehler und einen erheblichen Nutzen.

Wer sich mit Softwarequalität beschäftigt, landet schnell bei automatisierten Tests. Das ist richtig, reicht aber nicht. Angenommen, die Beitragsordnung des Verbands sieht für Mitglieder im Ruhestand eine Ermäßigung vor, allerdings erst ab dem zweiten Jahr der Mitgliedschaft. Die KI übersieht diese Einschränkung, gewährt die Ermäßigung allen Ruheständlern und schreibt anschließend die passenden Tests dazu. Umsetzung und Tests beruhen auf demselben Missverständnis. Alle Prüfungen sind grün, und der berechnete Beitrag ist trotzdem falsch.

Dahinter steht eine Frage, die in der Informatik als Test Oracle Problem bekannt ist: Woher kommt eigentlich das erwartete Ergebnis, gegen das die Software geprüft wird, und wie lässt sich richtiges von falschem Verhalten zuverlässig unterscheiden (6)? Das heißt nicht, dass KI-generierte Tests wertlos wären. Auch das menschliche Code-Review ist kein Allheilmittel, denn lesbarer Code kann eine falsche fachliche Annahme ganz sauber umsetzen. Es heißt, dass der fachliche Maßstab nachprüfbar sein muss.

Praktisch bedeutet das: Bevor die Tagungsanmeldung live geht, legt die Geschäftsstelle realistische, fachlich geprüfte Beispiele fest, mit erfundenen Personendaten und unabhängig von der Software. Was zahlt ein Mitglied im Ruhestand im ersten und im dritten Jahr, was eine Studentin, was ein Nichtmitglied mit Frühbucherrabatt? Wer darf die Teilnehmerliste sehen, wer ausdrücklich nicht? Was passiert, wenn dieselbe Zahlung zweimal gemeldet wird? Solche Referenzfälle kann eine KI anschließend in automatisierte Tests übersetzen und um weitere Randfälle ergänzen. Auch beim Ableiten erwarteter Ergebnisse aus der Beitragsordnung kann sie helfen. Verbindlich werden diese erst durch den Abgleich mit den fachlichen Regeln und eine unabhängige Prüfung.

Wie viel schneller KI die Softwareentwicklung tatsächlich macht, ist erstaunlich schwer zu messen. Das gemeinnützige Institut METR ließ Anfang 2025 sechzehn erfahrene Open-Source-Entwickler 246 echte Aufgaben in ihren eigenen, großen Projekten erledigen, zufällig verteilt mit und ohne KI. Mit KI brauchten sie im Schnitt 19 Prozent länger, obwohl sie selbst überzeugt waren, schneller gewesen zu sein (7). METR bezeichnete das Ergebnis ausdrücklich als Momentaufnahme der Werkzeuge von Anfang 2025.

Im Februar 2026 legte das Institut Daten aus einer Nachfolgestudie vor (8). Sie deuten auf einen Zeitgewinn hin, sind aber kaum belastbar: Immer mehr Entwickler wollten nicht mehr ohne KI arbeiten und blieben der Studie fern oder reichten bestimmte Aufgaben nicht ein, und wer mehrere Agenten parallel laufen ließ, konnte seine Zeit kaum sauber erfassen. METR vermutet, dass die Beschleunigung heute größer ist als 2025, hält ihre Größe mit diesem Versuchsaufbau aber für nicht zuverlässig bestimmbar. Die belastbarste Lehre lautet: Produktivität muss man messen, nicht erfühlen.

Der DORA-Bericht 2025, ein von Google Cloud getragenes Forschungsprogramm, beschreibt KI vor allem als Verstärker (9). Teams mit guten Abläufen und einer soliden Testkultur profitieren; wo diese Grundlagen fehlen, beschleunigt KI auch die Probleme. Das ist eine Interpretation aus Befragungsdaten, kein Naturgesetz, aber sie passt zu allem, was bisher gesagt wurde.

Die folgenreichsten Entscheidungen fallen oft, ohne dass jemand sie trifft. Ein denkbarer Verlauf: Die Tagungsanmeldung funktioniert, zwei Kolleginnen nutzen sie mit, im nächsten Jahr werden die Mitgliederdaten importiert, damit der Preis automatisch stimmt. Irgendwann ersetzt die App die alte Excel-Liste, und die Geschäftsstelle kann kaum noch auf sie verzichten. Eine bewusste Entscheidung, sie in den Produktivbetrieb zu übernehmen, hat es nie gegeben.

Dann stellen sich Fragen, die am Freitagnachmittag niemand gestellt hat. Was passiert, wenn die Erstellerin den Verband verlässt oder drei Wochen krank ist? Gehören das Hostingkonto und die Zugangsschlüssel der Organisation oder einem privaten Account? Kann jemand anderes die App neu bereitstellen, und lassen sich die Daten vollständig exportieren, falls man die Plattform wechseln will? Entwickler sprechen vom Bus-Faktor. Ein Bus-Faktor von eins bedeutet: Fällt eine bestimmte Person aus, fehlen entscheidendes Wissen oder Zugänge, um das System verlässlich weiterzuführen.

Was sich hier ansammelt, könnte man eine Verständnisschuld nennen. Sie umfasst mehr als unverstandenen Code: das fehlende Wissen darüber, warum bestimmte Entscheidungen getroffen wurden, welche Annahmen im Datenmodell stecken, welche Änderung an welcher Stelle etwas anderes beeinflusst und wie sich der Betrieb fortsetzen lässt, wenn der ursprüngliche Chatverlauf nicht mehr greifbar ist. Wie technische Schulden verzinst sie sich still und wird meist in einem ungünstigen Moment fällig.

Auch der Betrieb selbst ist eine eigene Aufgabe. Eine Datensicherung ist erst dann belastbar, wenn ihre Wiederherstellung einmal erprobt wurde; die DSGVO verlangt in Artikel 32 ausdrücklich die Fähigkeit, Daten nach einem Zwischenfall rasch wiederherzustellen, und ein Verfahren zur regelmäßigen Überprüfung der Schutzmaßnahmen. Eine App kann erreichbar sein, während Bestätigungsmails seit Tagen ausbleiben oder Zahlungen falsch zugeordnet werden. Eine sinnvolle Überwachung prüft deshalb auch fachliche Vorgänge, nicht bloß, ob der Server antwortet. Und während sich eine neue Programmversion meist zurücksetzen lässt, ist eine bereits ausgeführte Datenmigration oft nicht ohne Weiteres umkehrbar.

Auch die Umgebung der App bleibt nicht stehen. Apple, Google und Microsoft aktualisieren Betriebssysteme und Browser in kurzen Abständen, Zahlungsdienste und Bibliotheken kündigen ältere Schnittstellen ab, und eine App, die heute überall läuft, kann nach dem nächsten Update auf einem Teil der Geräte hängen. Software braucht deshalb laufende Pflege, selbst wenn an ihr niemand etwas ändern möchte.

Dazu kommt eine Veränderung, die sich schleichend bemerkbar macht. Im ersten Jahr lädt die Teilnehmerliste mit dreißig Einträgen sofort. Nach einigen Jahren enthält die Datenbank Tausende Buchungen, und die App fragt für jede Zeile der Liste einzeln Mitgliedsstatus und Zahlungsstand ab. Aus einer Datenbankabfrage werden Hunderte; Fachleute kennen das Muster als N+1-Problem. Ein großer Export bremst dann womöglich gleichzeitig laufende Anmeldungen aus. Eine Anwendung muss nicht zusammenbrechen, um im Alltag unbrauchbar zu werden. Deshalb gehören realistische Datenmengen, Antwortzeiten, gleichzeitige Nutzung und Ressourcenverbrauch zu jeder ernsthaften Prüfung. Professioneller Betrieb bedeutet zudem, dass möglichst wenig von einzelnen Köpfen und glücklichen Umständen abhängt: dokumentierte Abläufe, geklärte Vertretungen und Warnungen, die rechtzeitig die richtige Person erreichen.

In Debatten über Vibe Coding taucht Datenschutz meist nur als Folge von Sicherheitslücken auf. Er beginnt aber viel früher, und zwar auf zwei Ebenen. Die erste betrifft die Entwicklung. Wer der KI zum Testen einen echten Export der Mitgliederliste gibt, eine Fehlermeldung mit Namen und Adressen in den Chat kopiert oder einen Datenbankauszug hochlädt, übermittelt bei cloudbasierten Werkzeugen personenbezogene Daten an den Anbieter und womöglich an weitere Dienstleister. Bei lokal betriebenen Modellen muss das nicht so sein. Zu klären sind unter anderem die Rechtsgrundlage, die Rollen der Beteiligten, erforderliche Verträge wie etwa zur Auftragsverarbeitung nach Artikel 28 DSGVO, Speicherfristen, eine mögliche Nutzung für das Training und etwaige Übermittlungen in Drittländer. Für Tests genügen fast immer erfundene Beispieldaten.

Die zweite Ebene ist der Betrieb. Welche Daten braucht die Tagungsanmeldung wirklich, zu welchem Zweck und wie lange? Wer hat Zugriff, welche Dienste für Zahlung, Mailversand oder Hosting sind beteiligt, und wie werden Auskunft, Berichtigung und Löschung umgesetzt, wenn ein Mitglied danach fragt? Artikel 25 DSGVO verlangt, dass solche Fragen schon bei der Gestaltung beantwortet und datenschutzfreundliche Voreinstellungen gewählt werden. Diese Pflichten gelten unabhängig davon, ob ein Mensch oder eine KI den Code geschrieben hat.

Zwei verbreitete Irrtümer lassen sich dabei gleich ausräumen. Ein europäischer Serverstandort beantwortet nur einen Teil dieser Fragen, denn auch Dienstleister, Unterauftragnehmer und Datenflüsse zählen. Und eine Datenschutzerklärung macht eine unpassende Verarbeitung nicht nachträglich zulässig. Sie beschreibt, was geschieht; ob es geschehen darf, entscheidet sich vorher.

„Sicher", „professionell", „auditfähig": Solche Worte klingen gut und lassen sich von außen kaum überprüfen. Greifbar wird Qualität, wenn man sie in Fragen übersetzt, die eine Organisation über ihre eigene Software beantworten können sollte. Welche Version läuft gerade, und was hat sich gegenüber der letzten geändert? Welche Anforderungen wurden geprüft, mit welchem Ergebnis, und wer hat die Änderung freigegeben? Welche fremden Bibliotheken stecken darin, und sind für sie Schwachstellen bekannt? Lässt sich nachvollziehen, wer mit Administratorrechten welche Eingriffe vorgenommen hat? Und wann wurde die Wiederherstellung einer Sicherung zuletzt tatsächlich erprobt?

Dabei lohnt eine Unterscheidung, die oft übersehen wird. Der Änderungsverlauf im Code dokumentiert, wie sich die Software entwickelt hat. Er sagt nichts darüber, wer im laufenden System den Tagungspreis von 180 auf 150 Euro gesetzt hat. Dafür braucht es ein fachliches Protokoll in der Anwendung selbst. Wer Qualität systematisch angehen will, findet in öffentlichen Rahmenwerken konkrete Orientierung, etwa im Secure Software Development Framework der US-Standardisierungsbehörde NIST für den Entwicklungsprozess oder im Application Security Verification Standard der OWASP-Stiftung für überprüfbare Sicherheitsanforderungen an Webanwendungen. Beide sind Werkzeuge, kein Gütesiegel und kein Nachweis vollständiger Rechtskonformität.

Hier zeigt sich auch, wo KI die Qualität unterstützen kann, wenn der Rahmen stimmt. Sie kann Randfälle vorschlagen, an die niemand gedacht hat, aus Referenzfällen zusätzliche Tests ableiten, Dokumentation verständlicher machen, Code auf bekannte Schwachstellenmuster untersuchen oder alternative Umsetzungen gegeneinanderstellen. Nichts davon garantiert Qualität. Es erklärt aber, weshalb professionelle Teams diese Werkzeuge längst täglich einsetzen.

Ebenso wichtig ist die Frage, was man überhaupt selbst entwickeln muss. Anmeldung, Zahlungsabwicklung oder Mailversand gibt es als erprobte Dienste, die täglich Millionen Vorgänge verarbeiten. Sie klug auszuwählen, sauber zu konfigurieren und sicher zu verbinden, ist bereits ein wesentlicher Teil guter Architektur.

Wer oder was den Code geschrieben hat, beantwortet die Frage nach der Verlässlichkeit noch nicht. KI kann auch produktionsreife Software hervorbringen. Ob eine konkrete Anwendung dafür taugt, muss sich an nachvollziehbaren Anforderungen und Prüfungen zeigen, und dabei helfen vier Fragen. Welche Daten und Entscheidungen hängen von der Anwendung ab? Welchen Schaden können falsche Ergebnisse, unberechtigte Zugriffe oder Ausfälle anrichten? Wie gut lassen sich Fehler erkennen und rückgängig machen? Und wer hält das System über seine gesamte Nutzungsdauer verlässlich am Laufen?

Mit diesen Fragen verschiebt sich die Grenze an eine überraschende Stelle. Ein kleines internes Werkzeug für sechs Beschäftigte kann eine hohe Fallhöhe haben, wenn es Personalakten verarbeitet oder Mitgliedsbeiträge berechnet. Eine öffentliche, überwiegend statische Seite kann dagegen sehr viele Besucher problemlos bedienen, ohne dass viel auf dem Spiel steht. Und selbst ein einmaliges Skript verdient einen zweiten Blick, wenn es Originaldateien überschreibt oder Daten an einen fremden Dienst schickt. Die Zahl der Nutzer ist ein Faktor unter mehreren, und selten der wichtigste.

Für die Geschäftsführerin mit ihrer Tagungsanmeldung heißt das keineswegs, dass ihre Arbeit umsonst war. Ihr Prototyp macht Abläufe und Erwartungen früh besprechbar. In einem verantwortlichen Übergang wird er geprüft: Welche Teile sind tragfähig und lassen sich übernehmen? Was muss abgesichert, was fachlich überprüft, was neu entwickelt werden? Wir arbeiten dabei selbst täglich mit KI-Agenten, in der Konzeption wie in der Entwicklung. Der Unterschied liegt darin, dass Anforderungen, Prüfungen, Zuständigkeiten und Betrieb von Anfang an mitgedacht werden.

Der Nachmittag gehört dem Einfall, die Jahre danach gehören der Verantwortung.