Ressourcen

Was KI in der Entwicklung leistet, und was nicht.

Sie schreibt Code schneller, als ein Mensch tippen kann, und liest sich in eine Datenbank ein, für die es keine Dokumentation mehr gibt. Sie urteilt nicht. Ob eine Anforderung sinnvoll ist und ob eine Annahme stimmt, entscheidet weiterhin ein Mensch.

Die kurze Antwort.

KI verschiebt den Aufwand. Der handwerkliche Teil der Entwicklung wird deutlich kürzer. Der Teil, der über Erfolg und Misserfolg eines Projekts entscheidet, bleibt gleich lang: verstehen, was Ihr Betrieb wirklich tut, entscheiden, was abgebildet wird, und prüfen, ob das Ergebnis stimmt. Wer Ihnen erzählt, KI mache ein Projekt pauschal um einen bestimmten Faktor billiger, hat entweder nie eins zu Ende gebracht oder verkauft gerade etwas.

Für Sie als Auftraggeber ist deshalb nicht interessant, ob jemand KI einsetzt. Das tun inzwischen fast alle. Interessant ist, was er tut, damit das Ergebnis trotzdem stimmt. Dieser Beitrag sagt beides: was die Werkzeuge können, und woran Sie saubere Arbeit erkennen.

Was tatsächlich schneller wird.

Vier Arbeiten, bei denen der Unterschied in den Projekten, die ich gesehen habe, am größten ist. Alle vier haben eine Gemeinsamkeit: Es gibt eine klare Vorgabe, und das Ergebnis ist überprüfbar.

• Code aus einer klaren Vorgabe

  Wenn beschrieben ist, was hinein und was heraus soll, entsteht der Code in Minuten. Das gilt für Auswertungen, Umrechnungen, Importe, Formulare, Berichte.
• Einlesen in gewachsene Systeme

  Ein Datenmodell mit Tabellennamen, die niemand mehr erklären kann, ohne Dokumentation, ohne den Kollegen, der es gebaut hat. Ein Modell liest die Struktur schneller als jeder Mensch und schlägt vor, was die Felder bedeuten könnten. Prüfen muss das jemand, der Ihren Betrieb kennt.
• Tests und Randfälle

  Tests sind unbeliebt, weil sie Fleißarbeit sind. Genau das nimmt ein Modell ab. Es findet auch Randfälle, an die unter Termindruck niemand denkt: leere Felder, negative Mengen, Stornos nach Monatsabschluss.
• Dokumentation, die jemand liest

  Dokumentation entstand früher am Ende, wenn das Budget schon weg war. Heute entsteht sie nebenher und ist aktuell. Das ist der stillste, aber vielleicht größte Gewinn, weil er darüber entscheidet, ob ein anderer Entwickler später weiterarbeiten kann.

Dazu kommen Arbeiten in der Breite: ein Begriff, der überall im Code anders heißen soll, eine Bibliothek, die ersetzt werden muss, ein Format, das sich ändert. Früher war das stumpfe Arbeit mit hohem Flüchtigkeitsrisiko. Heute ist es ein Auftrag und danach ein Durchgang durch die Änderungen.

Was sie nicht kann.

Die folgenden vier Punkte sind keine Kinderkrankheiten, die das nächste Modell behebt. Sie folgen daraus, was ein solches System ist: ein sehr gutes Fortsetzungswerkzeug für Text, das Ihren Betrieb nicht kennt und keine Absicht hat.

Wie ich damit arbeite.

Sechs Regeln, die nicht verhandelbar sind. Sie kosten Zeit und sind trotzdem der Grund, warum am Ende etwas steht, das Ihre Leute benutzen.

1. Schritt 1

   Die Anforderung steht vor der ersten Zeile Code

   Bevor irgendetwas erzeugt wird, steht in einem Satz, was herauskommen soll und woran man erkennt, dass es stimmt. Dieser Satz kommt aus dem Fachbereich, nicht aus der Entwicklung. Ohne ihn erzeugt ein Modell etwas, das läuft, und niemand kann sagen, ob es das Richtige ist.

2. Schritt 2

   Kleine Einheiten statt großer Würfe

   Ein Modell kann in einem Zug sehr viel Code erzeugen. Genau das ist die Falle: Was niemand in einem Stück prüfen kann, wird nicht geprüft, sondern geglaubt. Deshalb entstehen kleine, abgeschlossene Teile, die einzeln lesbar und einzeln abnehmbar sind.

3. Schritt 3

   Tests gegen echte Fälle, nicht gegen erfundene

   Modelle erzeugen Tests gern so, dass der eigene Code besteht. Brauchbar wird ein Test erst, wenn er einen Fall aus Ihrem Betrieb abbildet: die Bestellung mit der Teillieferung, der Artikel ohne Stückliste, der Kunde mit zwei Rechnungsadressen. Diese Fälle nennt Ihnen niemand außer Ihren eigenen Leuten.

4. Schritt 4

   Jede Zeile wird gelesen, bevor sie übernommen wird

   Nicht überflogen, gelesen. Wenn ich nicht erklären kann, warum eine Zeile dasteht, fliegt sie raus, auch wenn alles läuft. Code, den niemand versteht, ist keine Zeitersparnis, sondern eine Schuld, die später jemand bezahlt.

5. Schritt 5

   Annahmen werden aufgeschrieben und gegengeprüft

   Ein Modell füllt Lücken still. Fehlt die Angabe, wie mit Nachkommastellen umzugehen ist, entscheidet es und sagt es nicht. Jede solche Entscheidung kommt auf eine Liste und wird mit dem Fachbereich durchgegangen, bevor sie in den Betrieb geht.

6. Schritt 6

   Es gibt einen Menschen, der haftet

   Am Ende steht mein Name unter dem Ergebnis, nicht der eines Modells. Für Sie ändert sich damit nichts an Ihrer üblichen Erwartung an einen Auftragnehmer. Genau so soll es sein.

Woran Sie saubere Arbeit erkennen.

Sie müssen keinen Code lesen können, um das zu beurteilen. Die folgenden Punkte kann jeder Auftraggeber prüfen, und zwar während des Projekts, nicht erst danach. Fragen Sie sie ab. Bei mir und bei jedem anderen.

Zwei Fragen, die viel verraten

Die erste: Zeigen Sie mir eine Stelle, an der das Werkzeug Ihnen etwas vorgeschlagen hat, das Sie verworfen haben. Wer darauf keine Antwort hat, prüft nicht. Die zweite: Was passiert, wenn Sie morgen ausfallen? Die Antwort muss vom Repository und von der Dokumentation handeln, nicht von Ihrem Gedächtnis.

Verantwortung und Haftung.

Die Rechtslage ist an dieser Stelle einfacher, als die Debatte vermuten lässt. Sie beauftragen einen Auftragnehmer, und der schuldet Ihnen ein Ergebnis. Welche Werkzeuge er benutzt, ist seine Sache, solange das Ergebnis stimmt. Ein Statiker haftet auch dann für seine Berechnung, wenn er sie mit einem Programm gemacht hat.

Daraus folgt eine praktische Regel für Ihre Verträge: Nichts darin muss KI erwähnen, aber alles darin muss so formuliert sein, als hätte ein Mensch jede Zeile geschrieben. Gewährleistung, Abnahme, Rechteübertragung, Geheimhaltung, Mitwirkungspflichten. Wenn ein Anbieter an diesen Stellen Einschränkungen einziehen will, weil er mit generierten Anteilen arbeitet, ist das ein Warnsignal und kein Detail. Was die Rechteseite angeht, finden Sie den ausführlichen Teil unter Eigentum an Software.

Was von Ihren Daten das Haus verlässt

Für die Arbeit an Ihrer Software braucht es fast immer die Struktur und fast nie die Inhalte. Tabellennamen, Feldtypen, Beziehungen, ein paar anonymisierte Zeilen, damit klar ist, wie die Werte aussehen. Damit lässt sich ein Datenmodell verstehen, ohne dass Ihre Preise, Ihre Kunden oder Ihre Rezepturen irgendwo landen, wo sie nicht hingehören.

Wo das nicht reicht, etwa bei der Datenmigration, wird vorher festgelegt, welche Auszüge überhaupt bewegt werden, wohin, wie lange und wer sie wieder löscht. Schriftlich, nicht am Telefon. Das ist kein Misstrauen, sondern das Mindeste, was Sie Ihrem eigenen Haus schulden.

Wann KI Ihnen nicht hilft.

Es gibt Fälle, in denen der schnellere Bau die Sache schlimmer macht. Wenn niemand sagen kann, wie ein Prozess wirklich läuft, erzeugt schnelle Entwicklung nur schneller etwas Falsches. Wenn in Ihrem Haus seit Langem um eine Entscheidung gerungen wird, löst kein Werkzeug diesen Streit, es macht ihn nur teurer.

Und es gibt den Fall, in dem Sie gar nichts bauen sollten. Wenn ein vorhandenes Produkt Ihren Ablauf im Kern trifft und der Rest Gewohnheit ist, kaufen Sie das Produkt und ändern die Gewohnheit. Dass Entwicklung günstiger geworden ist, verschiebt diese Grenze, aber es hebt sie nicht auf. Die Abwägung im Einzelnen steht unter Make or Buy. Wo die Grenze zwischen Ergänzen und Ablösen verläuft, klärt der ERP-Selbsttest.