Der Prototyp ist fast immer der einfache Teil
KI-Coding erzeugt einen besonderen Effekt: Die ersten Ergebnisse kommen ungewöhnlich schnell. Was früher mehrere Tage Entwicklungsarbeit war, steht oft nach einem Nachmittag als klickbare Oberfläche da. Genau das ist auch das Konzept hinter vielen Anbietern. Cursor, Lovable, Replit und ähnliche Werkzeuge verkaufen den sichtbaren Quick Win. Der Screenshot, der intern Begeisterung auslöst, ist ihr Produkt. Wartung, Testing, Störungen und Verantwortung bleiben beim Betrieb.
Gerade deshalb entsteht der Eindruck: Wenn die ersten 80 Prozent so einfach waren, können die restlichen 20 Prozent nicht schwer sein. In der Softwareentwicklung ist häufig das Gegenteil der Fall. Sobald echte Mitarbeiter die Anwendung nutzen, wächst sie. Mehrere Benutzer, Rechte, mobile Nutzung, Schnittstellen, Fehlerfälle, Backups, Datenschutz, Monitoring, Updates. Aus einer kleinen App wird ein produktives System. Die Komplexität steigt nicht gleichmäßig mit. Ab bestimmten Schwellen wird sie sprunghaft größer.
Software bauen und Software betreiben sind zwei Jobs
Ein funktionierender Prototyp beantwortet nur eine Frage: Lässt sich der gewünschte Ablauf grundsätzlich abbilden? Produktive Software im Betrieb muss viele weitere Fragen aushalten.
- Was passiert, wenn eine Schnittstelle nicht erreichbar ist oder sich ihre Struktur ändert?
- Was passiert, wenn ein Datensatz doppelt ankommt oder jemand versehentlich löscht?
- Was passiert nach einem Update, bei zehn gleichzeitigen Nutzern oder bei einer falschen KI-Ausgabe?
- Was passiert, wenn das verwendete Modell oder der Hosting-Anbieter plötzlich nicht mehr verfügbar ist?
Genau hier beginnt Softwarebetrieb. Nicht beim ersten Screenshot, der intern Begeisterung auslöst.
Die gefährlichste Eigenentwicklung ist der erfolgreiche Prototyp
Ein schlechter Prototyp ist selten ein großes Problem. Er wird getestet, reicht nicht und wird verworfen. Interessanter ist der erfolgreiche. Eine interne Anwendung funktioniert. Ein Mitarbeiter nutzt sie, dann drei, dann zehn. Nach ein paar Monaten hängen Kundendaten, Automatisierungen und der Morgenablauf daran. Nur wurde die Architektur oft nie dafür gebaut.
Die wichtigste Frage lautet deshalb nicht: Funktioniert die Software heute? Sondern: Was passiert, wenn der Betrieb morgen davon abhängig ist?
Testing, Wartung und Support werden mit dem Wachstum sprunghaft teurer
KI senkt den Aufwand, Code zu schreiben. Sie senkt nicht den Aufwand, diesen Code zu prüfen, zu warten und bei Störungen zu erklären. Am Anfang hat eine Anwendung wenige Funktionen. Eine Änderung lässt sich schnell ausprobieren. Mit jeder Maske, jedem Feld und jeder Automatisierung steigen die Wechselwirkungen. Eine Änderung am Formular kann Datenbankeinträge, PDFs, Rechte, Schnittstellen oder bestehende Kundendaten treffen.
Irgendwann reicht es nicht mehr, die neue Funktion zu kontrollieren. Man muss prüfen, ob alles Vorherige noch gilt. Das ist Regression Testing. Nach größeren KI-Änderungen kommt oft noch Verstehen dazu: Welche Dateien wurden angefasst, welche Logik wurde umgebaut, welche Sicherheitslücke ist neu? Dazu manuelle Tests, Testdaten, Zeit der Leute, die den echten Ablauf kennen. Dieser Aufwand wächst schneller als die App selbst.
Die Kosten steigen deshalb selten linear mit. Sie springen. Der erste Nutzer ist günstig. Der zehnte braucht Rechte, Schulung und jemanden, der montags erreichbar ist, wenn nichts mehr geht. Die ersten internen Testdaten sind unkompliziert. Echte Kundendaten ziehen Datenschutz, Löschkonzept, Auskunftspflicht und Backups nach. Die erste Störung um 7:15 kostet nicht denselben Betrag wie das Tool-Abo. Sie kostet ausgefallene Einsätze, Support, Wiederherstellung und Vertrauen.
- Wartung: Updates, Abhängigkeiten, kaputte Schnittstellen, Modellwechsel.
- Regression: nach jeder größeren KI-Änderung prüfen, was vorher noch ging.
- Datenschutz: wächst mit echten Daten, nicht mit der ersten Maske.
- Störungen und Support: Wer reagiert, wenn zehn Leute nicht arbeiten können?
Der monatliche Preis eines AI-Coding-Tools ist deshalb nicht der Preis der Software. Abos, Tokens, Hosting, Datenbanken, APIs, Backups, interne Arbeitszeit, Fehleranalyse, Support, Schulung und irgendwann Migrationen gehören dazu. Der Quick Win am ersten Tag ist günstig und sichtbar. Genau dafür sind die Werkzeuge gebaut. Der Sprung kommt später, wenn aus der Demo ein System geworden ist.
Wer wartet sie, und wem gehören die Zugänge?
Viele Eigenentwicklungen hängen an einer Person. Ein digitalaffiner Mitarbeiter kennt die Prompts, die Datenbank, die API-Schlüssel, die Workarounds und die bekannten Fehler. Wenn diese Person geht oder der externe Entwickler nicht mehr erreichbar ist, steht der Bus-Faktor im Raum: Wie viele Leute können ausfallen, bevor niemand das System mehr betreiben kann?
Dazu kommt Eigentum, das bei Experimenten oft nebensächlich wirkt. Über welche E-Mail läuft das Hosting? Wer besitzt das Repository? Wer zahlt die Kreditkarte? Wo liegen API-Schlüssel? Sobald die Anwendung geschäftskritisch wird, müssen Accounts, Code und Zugänge dem Betrieb gehören. Nicht dem privaten ChatGPT-Account eines Mitarbeiters.
Datenschutz beginnt, sobald echte Betriebsdaten fließen
Ein Login ist noch kein Sicherheitskonzept. Sobald Namen, Adressen, Fotos von der Baustelle, Messwerte, Mitarbeiterdaten oder Vertragsinformationen in der Anwendung liegen, muss klar sein: Welche Anbieter verarbeiten die Daten, in welchem Land, welche Daten gehen an KI-Modelle, wie lange werden sie gespeichert, wer darf was sehen, gibt es Backups und ein Löschkonzept?
Gerade im Handwerk sind das oft dieselben Daten, die später als Nachweis, gegenüber Versicherern oder gegenüber dem Kunden stehen müssen. Dann reicht „es hat irgendwie funktioniert“ nicht.
KI-Agenten brauchen Grenzen, nicht nur ein Passwort
Ein klassisches KI-System beantwortet eine Frage. Ein Agent kann handeln: Dateien ändern, APIs aufrufen, Datenbanken schreiben, Mails auslösen oder andere Systeme anstoßen. Damit wird Berechtigung zur Architekturfrage. Nicht jeder Agent sollte alle Kundendaten und jedes Unternehmenssystem erreichen.
Im Juli 2026 wurde öffentlich, dass autonome Test-Agenten von OpenAI während einer Cybersecurity-Evaluation ihre vorgesehene Sandbox verlassen und auf Infrastruktur von Hugging Face zugreifen konnten. Das war ein spezieller Sicherheitstest mit sehr leistungsfähigen Systemen und bewusst reduzierten Schutzmechanismen. Es bedeutet nicht, dass ein normaler Chatbot aus dem Betrieb ausbricht. Es zeigt aber etwas Grundsätzliches: Je mehr ein Agent tun darf, desto wichtiger werden Isolation, Rechte, Monitoring und menschliche Freigaben. Im August 2026 berichtete AIBase, OpenAI habe daraufhin einen Teil der eigenen Trainingsarbeit für zwei Wochen gestoppt, Sandboxes stärker isoliert und die Überwachung verschärft. Selbst der Anbieter muss also anhalten, wenn die Grenzen nicht halten.
Abhängigkeit von Modellen und Plattformen ist ein Geschäftsrisiko
Wer Software auf externen KI-Modellen aufbaut, übernimmt deren Verfügbarkeit mit. Im Juni 2026 verhängte die US-Regierung Exportbeschränkungen gegen Claude Fable 5 und Mythos 5. Anthropic stellte den Zugang kurzfristig global ab, weil sich die Nationalität der Nutzer nicht zuverlässig in Echtzeit prüfen ließ. Die Beschränkungen wurden Ende Juni wieder aufgehoben. Die eigene Anwendung kann also technisch einwandfrei laufen und trotzdem stillstehen.
Ähnlich unbemerkt entsteht Vendor Lock-in. Viele AI-Plattformen bündeln Datenbank, Hosting, Login, Modell und Deployment in einer Oberfläche. Das ist produktiv. Es wird teuer, wenn später ein Wechsel nötig ist und genau diese Bausteine nicht portierbar sind. Die nützliche Frage am Anfang lautet: Könnten wir das theoretisch zu einem anderen Anbieter ziehen? Wenn die Antwort „ja, aber mit erheblichem Aufwand“ ist, sollte dieser Aufwand bewusst akzeptiert sein.
YouTube hat das Handwerk nicht ersetzt
Die falsche Schlussfolgerung wäre: Unternehmen sollten keine eigene Software mehr bauen. Das Gegenteil ist wahrscheinlich. KI senkt die Hürde ähnlich, wie YouTube Wissen gesenkt hat. Heute kann nahezu jeder in wenigen Minuten sehen, wie man eine Wand verputzt oder einen Wasserhahn tauscht. Trotzdem sind Fachbetriebe nicht verschwunden. Zugang zu Wissen ersetzt nicht Erfahrung, Haftung und saubere Ausführung.
Bei Software zeichnet sich dasselbe Muster ab. Betriebe werden deutlich mehr selbst machen können. Die Frage wird seltener „Eigenentwicklung oder Standardsoftware“ heißen. Sie wird heißen: Welche Teile individualisieren wir, und welche Infrastruktur wollen wir nicht selbst betreiben?
Individualisieren, ohne jedes Mal bei null anzufangen
Betriebe wollen eigene Abläufe. Sie wollen selten für jedes interne Tool erneut Benutzerverwaltung, Rechte, Datenbanken, PDF-Erzeugung, mobile Nutzung, Schnittstellen und grundlegende Sicherheit neu erfinden. Eine tragfähige Mitte sind Plattformen, die diese Grundlage schon mitbringen und trotzdem zulassen, dass der Betrieb seine Dokumente, Felder, Daten und Automatisierungen selbst formt.
Genau daraus ist ProtocolHero entstanden. Zuerst als digitale Protokolle und Nachweise fürs Handwerk. Unsere Annahme ist nicht, dass jeder Betrieb gleich arbeitet. Und auch nicht, dass die Zukunft nur aus starrer Standardsoftware besteht. Ein Betrieb soll eigene Formulare, Datenstrukturen, Freigaben und KI-gestützte Schritte abbilden können. Aber auf einem Fundament, das Benutzer, Rechte, Erfassung vor Ort, Unterschriften, PDFs und Archive nicht jedes Mal neu erfinden muss.
Was das im Betrieb konkret heißen kann
Ein Elektroinstallateur prüft beim Kunden eine Anlage. Dabei entstehen Kundendaten, Anlagendaten, Messwerte, Fotos, Mängel, Bewertungen, Unterschriften und am Ende ein Dokument. Der individuelle Teil ist der Ablauf des Betriebs: Prüfung abschließen, PDF erzeugen, an den Kunden senden, Mängel strukturiert speichern, den Auftrag im ERP aktualisieren, Daten an eine andere Software übergeben, vielleicht einen Rechnungsentwurf anstoßen.
Diesen Prozess soll der Betrieb selbst bestimmen können. Die Schicht darunter, also Rechte, Speicherung, Nachvollziehbarkeit, mobile Erfassung und das belastbare Dokument, muss dafür nicht jedes Mal eine neue Eigenentwicklung sein.
Fazit
KI-Coding ist keine Mode. Die Einstiegshürde für individuelle Software sinkt weiter, und Betriebe sollten das nutzen. Die wichtigste Frage bleibt trotzdem nicht: Wie schnell können wir das bauen? Sondern: Wer wartet es, wer testet nach Änderungen, wer übernimmt Support bei Störungen, wo liegen die Daten, wie abhängig sind wir von einer Person oder einem Anbieter, und was passiert, wenn die Kosten nicht linear weiterlaufen, sondern auf einmal springen?
Die Zukunft liegt wahrscheinlich weder nur in starrer Standardsoftware noch darin, für jeden Ablauf eine eigene Softwarefirma zu spielen. Sie liegt in Individualisierung auf einer Grundlage, die jemand dauerhaft betreibt. Individualisieren: ja. Jedes Mal wieder bei null anfangen: nicht unbedingt.