Entwickelt, nicht generiert

Eine CRUD-Anwendung zu erzeugen kostet dieses Jahr keine Mühe mehr. Prompt eintippen, Maske bekommen, an eine Tabelle hängen. Die Vorführung sieht gut aus. Der Ärger fängt im vierten Monat an, wenn jemand etwas ändern muss — und niemand sagen kann, warum es so funktioniert, wie es funktioniert. Auch die Person nicht, die es erzeugt hat.

Das ist der Unterschied zwischen Software, die existiert, und Software, auf die sich ein Betrieb verlassen kann.

Unsere Regel

Wir setzen beim Bauen von Usable stark auf KI. Was wir nicht tun: Code ausliefern, den kein Mensch verstanden hat. Jedes Modul, das rausgeht, muss eine einfache Prüfung bestehen:

Könnte eine kompetente Entwicklerin, die diesen Code noch nie gesehen hat, ihn warten — ohne eine KI zu fragen, was er tut?

Lautet die Antwort nein, ist es nicht fertig. Nicht weil generierter Code grundsätzlich schlecht wäre, sondern weil Software, über die man nicht nachdenken kann, Software ist, die man unter Druck nicht reparieren kann. Und Betriebssoftware ist genau die Sorte, die unter Druck kaputtgeht: an einem Montagmorgen, mitten in der Schicht, während ein Kunde wartet.

Warum man den Unterschied nicht kaufen sehen kann

Das Unangenehme an dieser Grenze: Sie ist beim Kauf unsichtbar. In einer Vorführung sieht sauber gebaute Software genauso aus wie schnell erzeugte — manchmal sogar schlechter, weil sie weniger Effekte hat.

Alles, was in der rechten Spalte steht, entscheidet sich lange vor deinem Kaufzeitpunkt und wird lange nach ihm sichtbar. Deshalb ist es fair, dass Anbieter dazu etwas sagen müssen — und deshalb sagen wir es hier.

Wie das praktisch aussieht

• Jedes Modul trägt seine eigene Dokumentation — geschrieben für die Leute, die damit arbeiten, und für die nächste Person, die es wartet. Nicht als API-Referenz.
• Langweiliger, ausdrücklicher Code schlägt cleveren. Das Datenbankschema sagt, was es meint. Die Rechte sind in einer Datei lesbar.
• Wir löschen mehr, als wir erzeugen. Der größere Teil der Arbeit ist die Entscheidung, was nicht gebaut wird.
• Jede Datenänderung hinterlässt eine Spur. Nicht als Zusatzfunktion, sondern weil ein System ohne Spur im Streitfall nichts beweist — siehe Zeiterfassung und Prüffristen.

Nichts davon sieht man in einer Vorführung. Alles davon sieht man an dem Tag, an dem etwas schiefgeht — und das ist ehrlicherweise der einzige Tag, der zählt.

Wofür wir KI benutzen, und wofür nicht

Damit der Satz „wir nutzen KI" nicht als Floskel stehen bleibt, hier die Aufteilung, wie sie bei uns tatsächlich läuft:

Wofür	Warum es dort passt
Erste Entwürfe, Varianten durchspielen	Schnell verwerfen ist billiger als lange überlegen
Wiederkehrende Umbauten über viele Dateien	Mechanisch, gut prüfbar, langweilig für Menschen
Tests und Beispieldaten	Breite Abdeckung, geringes Risiko
Recherche zu Vorschriften und Fristen	Findet Quellen — die Bewertung machen wir
Nicht: Datenmodell festlegen	Der Zuschnitt ist die Entscheidung, nicht die Tipparbeit
Nicht: Rechte- und Rollenlogik	Muss von einem Menschen lesbar und verantwortet sein
Nicht: Migrationen ungelesen	Ein falscher Schritt trifft echte Daten in echten Betrieben

Der Trennstrich verläuft nicht zwischen „schwer" und „leicht", sondern zwischen „prüfbar" und „verantwortbar". Was ein Mensch in Minuten kontrollieren kann, darf eine Maschine schreiben. Was über Wochen still falsch bleiben könnte, nicht.

Warum das für dich eine Produktentscheidung ist

Der Zusammenhang ist nicht offensichtlich, aber direkt: Wartbarer Code ist der Grund, warum ein Modul, das an einer Stelle klemmt, ein Auftrag an uns sein kann statt dein Problem. Wer eine Codebasis nicht versteht, kann sie nicht anpassen — er kann nur drumherum bauen. Und genau daraus entsteht die Software, die dich zwingt, deinen Prozess zu verbiegen.

Das ist derselbe Gedanke wie beim Zuschnitt in Module, nur eine Ebene tiefer: Ein Stück Software bleibt nur so lange verhandelbar, wie jemand es noch versteht.