KI in Entwicklung und Technik: Code, Dokumentation und das Wissen, das im Kopf steckt

In Entwicklungsabteilungen, Konstruktionsbüros und technischen Serviceteams ist die Haltung zu KI meist zweigeteilt. Ein Teil nutzt sie längst und möchte nicht mehr darauf verzichten. Ein anderer Teil hält sie für überschätzt, weil die Ergebnisse bei anspruchsvollen Aufgaben nicht überzeugen.

Beide haben recht – sie sprechen nur über unterschiedliche Aufgaben. Es lohnt sich, genauer zu sortieren, wo der Nutzen tatsächlich liegt.

Programmierung: nützlich, aber nicht dort, wo man denkt

Bei der Codeerzeugung gilt eine einfache Regel: Je bekannter das Muster, desto besser das Ergebnis. Ein Datenzugriff, eine Umwandlung, ein Testfall, ein Skript zur Auswertung einer Protokolldatei – das gelingt zuverlässig und spart echte Zeit.

Je spezifischer das Vorhaben, desto schwächer wird die Unterstützung. Bei gewachsener Fachlogik, bei Nebenläufigkeit, bei Änderungen in einem großen Bestand, dessen Zusammenhänge nur teilweise sichtbar sind, entstehen Vorschläge, die plausibel aussehen und subtil falsch sind. Genau diese Fehler sind teuer, weil sie durch die Prüfung rutschen.

Wo der Nutzen dagegen selten bestritten wird:

• Fremden Code verstehen. Eine Funktion, die vor Jahren jemand anders geschrieben hat, erklären zu lassen, ist eine der dankbarsten Anwendungen überhaupt.
• Tests schreiben. Ungeliebt, gut automatisierbar, und das Ergebnis ist unmittelbar überprüfbar.
• Fehlermeldungen einordnen. Stapelverfolgungen und Protokollauszüge deuten und Hypothesen zur Ursache liefern.
• Übersetzungen zwischen Sprachen und Formaten. Konfigurationen, Abfragen, Datenstrukturen.
• Code-Prüfung als zweites Paar Augen. Nicht als Ersatz für die Prüfung durch Kollegen, aber als Vorstufe, die Offensichtliches abfängt.

Wichtig ist der Umgang mit Quellcode als Betriebsgeheimnis. Was in ein Werkzeug eingegeben wird, verlässt das Haus – bei Gratisdiensten mit unklaren Folgen. Für Entwicklungsabteilungen ist das einer der stärksten Gründe für eine freigegebene, vertraglich abgesicherte Lösung.

Technische Dokumentation: der unterschätzte Fall

Dokumentation ist in fast jedem technischen Bereich chronisch veraltet, weil sie immer die Aufgabe ist, die verschoben wird. Genau hier liegt ein Hebel, der wenig Risiko trägt.

Aus einem Änderungsprotokoll, einem Ticketverlauf oder einer Besprechungsnotiz lässt sich ein erster Entwurf für eine Dokumentation erzeugen, den ein Fachmensch korrigiert. Der Unterschied zwischen „von null schreiben“ und „einen Entwurf korrigieren“ entscheidet in der Praxis darüber, ob es überhaupt passiert.

Ebenso wirksam: aus vorhandener technischer Dokumentation eine Fassung für andere Zielgruppen ableiten – eine Kurzanleitung für Anwender, eine Übersicht für den Vertrieb, eine Checkliste für den Service. Die Substanz ist geprüft, es geht nur um die Aufbereitung.

Erfahrungswissen sichern

Der wertvollste Anwendungsfall in technischen Bereichen hat mit Code gar nichts zu tun.

In jedem Unternehmen gibt es Menschen, die eine Anlage, ein Produkt oder ein System seit zwanzig Jahren kennen. Sie wissen, warum eine Konstruktion so aussieht, welcher Fehler bei welcher Kundenanlage typisch ist und welche Lösung damals verworfen wurde. Dieses Wissen steht in keinem Handbuch. Es geht mit dem Ausscheiden verloren – und in den kommenden Jahren scheiden viele aus.

Ein an Tickets, Serviceberichte, Konstruktionsunterlagen und Projektakten angebundener Assistent macht einen Teil davon zugänglich. Nicht das Bauchgefühl, aber die dokumentierten Vorgänge: „Hatten wir bei Anlagentyp X schon einmal dieses Störungsbild?“ ist eine Frage, deren Beantwortung heute vom Gedächtnis einzelner Kollegen abhängt.

Damit das funktioniert, muss man ein unangenehmes Thema angehen: Serviceberichte und Ticketverläufe sind oft knapp und uneinheitlich. Der Aufwand liegt nicht in der Technik, sondern darin, die Dokumentationsqualität so weit zu heben, dass sie auswertbar wird.

Konstruktion und Fertigung

Hier ist Nüchternheit angebracht. Sprachmodelle konstruieren nicht und berechnen keine Festigkeiten. Was sie können, betrifft das Umfeld:

• Normen, Richtlinien und interne Vorgaben durchsuchbar machen und Fundstellen liefern.
• Stücklisten und Datenblätter vergleichen und Abweichungen aufzeigen.
• Anfragen mit früheren Projekten abgleichen: Was haben wir Ähnliches schon gebaut?
• Prüf- und Abnahmeprotokolle aus vorhandenen Angaben vorbereiten.
• Lieferantenunterlagen auf Vollständigkeit prüfen.

Alles davon sind Zuarbeiten. Die technische Verantwortung bleibt vollständig beim Ingenieur – und wo Produkte in regulierte Bereiche fallen, ist zusätzlich zu bedenken, dass KI in Produkten unter Anhang I des EU AI Act fällt, mit vollen Anforderungen ab August 2028.

Was technische Teams brauchen, damit es angenommen wird

Technische Fachleute sind gegenüber Werkzeugen, die ungenaue Ergebnisse liefern, besonders skeptisch – zu Recht. Drei Dinge entscheiden über die Akzeptanz.

Quellenangaben. Eine Antwort ohne Fundstelle ist für einen Ingenieur wertlos. Mit Fundstelle wird sie überprüfbar und damit brauchbar.

Ehrliche Grenzen. Ein System, das „Das steht in den angebundenen Unterlagen nicht“ antwortet, gewinnt mehr Vertrauen als eines, das immer etwas liefert.

Kein Zwang. Die Einführung sollte als Angebot erfolgen. Wer gute Ergebnisse sieht, nutzt es; wer nicht, nutzt es nicht. Verordnete Werkzeuge werden in technischen Teams zuverlässig unterlaufen.

Der Einstieg

Beginnen Sie nicht bei der Codeerzeugung, sondern bei der Suche im eigenen Bestand. Wählen Sie einen abgegrenzten Bereich – etwa die Serviceberichte der letzten drei Jahre zu einer Produktfamilie – und lassen Sie das Team eine Woche lang echte Fragen daran stellen.

Die Rückmeldung aus dieser Woche sagt Ihnen mehr über den Nutzen in Ihrem Haus als jede Produktvorführung – und sie zeigt zugleich, wie gut Ihre Dokumentation tatsächlich ist.

Wie technische Teams den Nutzen prüfen sollten

Fachleute überzeugt keine Vorführung, sondern ein Test an eigenen Fällen. Ein schlankes Vorgehen, das sich bewährt hat:

Wählen Sie einen abgegrenzten Bestand – etwa die Serviceberichte einer Produktfamilie aus drei Jahren. Sammeln Sie zwanzig Fragen, die im Alltag tatsächlich gestellt werden und deren richtige Antwort ein erfahrener Kollege kennt. Lassen Sie das Team eine Woche lang damit arbeiten und notieren, wo die Antworten trugen und wo nicht.

Werten Sie dann nicht nur die Trefferquote aus, sondern auch die Ursachen der Fehltreffer. Erfahrungsgemäß liegt ein großer Teil davon an der Dokumentationsqualität – knappe Berichte, uneinheitliche Begriffe, fehlende Kennzeichnung der gültigen Fassung. Das ist eine unangenehme, aber nützliche Erkenntnis: Sie gilt unabhängig von jedem Werkzeug.

Umgang mit Quellcode und Konstruktionsdaten

Für technische Bereiche ist der Umgang mit dem eigenen Betriebsgeheimnis die wichtigste Rahmenbedingung. Legen Sie drei Punkte fest: welche Codebestände und Unterlagen überhaupt in ein KI-Werkzeug gegeben werden dürfen, welches Werkzeug dafür freigegeben ist, und wie mit Bibliotheken und Lizenzen umgegangen wird, wenn erzeugter Code übernommen wird.

Der letzte Punkt wird oft übersehen: Übernommener Code sollte denselben Prüfschritten unterliegen wie jeder andere Beitrag – Review, Tests, Lizenzprüfung.

Häufige Fragen

Verlernen jüngere Kollegen dadurch das Programmieren?

Die Sorge ist ernst zu nehmen. In der Praxis hilft eine einfache Regel: Erzeugter Code wird nicht übernommen, ohne dass die Person ihn erklären kann. Das erhält die Lernwirkung und verhindert zugleich, dass unverstandener Code in den Bestand wandert.

Können wir das lokal betreiben?

Bei besonders schutzwürdigen Beständen ist ein Betrieb im eigenen Rechenzentrum möglich. Rechnen Sie mit dem Betriebsaufwand – Hardware, Aktualisierung, Verfügbarkeit – und prüfen Sie ehrlich, ob Sie ihn dauerhaft tragen wollen.

Was bringt es bei sehr spezieller Fachlogik?

Bei der Erzeugung wenig. Beim Verstehen, Dokumentieren und Testen dagegen viel – und genau dort liegt in gewachsenen Beständen meist der größere Zeitverlust.

Fällt KI in unseren Produkten unter den AI Act?

Wenn Ihr Produkt bereits einer Produktregulierung unterliegt und KI darin verbaut ist, greift Anhang I mit vollen Anforderungen ab August 2028. Klären Sie das früh, weil es Konstruktion und Dokumentation betrifft, nicht nur die Software.

Dokumentation systematisch nachziehen

In den meisten technischen Bereichen ist die Dokumentation nicht deshalb veraltet, weil niemand sie für wichtig hält, sondern weil sie immer die Aufgabe ist, die verschoben wird. Ein pragmatisches Vorgehen, das ohne zusätzliche Stelle auskommt:

Nicht rückwirkend alles aufholen. Der Versuch, drei Jahre Rückstand abzuarbeiten, scheitert zuverlässig. Setzen Sie stattdessen an der Gegenwart an: Jede Änderung ab heute erzeugt einen Dokumentationsentwurf.

Aus vorhandenen Spuren erzeugen. Änderungsprotokolle, Ticketverläufe, Besprechungsnotizen und Commit-Nachrichten enthalten den Sachverhalt bereits. Daraus einen strukturierten Entwurf zu erzeugen ist eine Umformungsaufgabe – genau das, worin Sprachmodelle stark sind.

Korrigieren statt schreiben lassen. Der Unterschied im Aufwand zwischen „von null schreiben“ und „einen Entwurf korrigieren“ ist der Grund, warum es diesmal tatsächlich passiert.

Rückwirkend nur, was gebraucht wird. Wenn eine Frage zu einem alten Bauteil dreimal aufkommt, ist das der Anlass, dessen Dokumentation nachzuziehen – nicht ein Plan, der alles umfasst.

Wissenssicherung vor dem Ausscheiden

Der wirtschaftlich wertvollste Anwendungsfall in technischen Bereichen hat eine Frist: Er wirkt nur, solange die Kollegen mit dem Erfahrungswissen noch da sind.

Ein Vorgehen, das sich bewährt hat, besteht aus drei Bausteinen. Erstens strukturierte Gespräche: Je Themenfeld ein bis zwei Stunden Gespräch, aufgezeichnet und transkribiert. Nicht als freies Erzählen, sondern entlang konkreter Fragen – welche Störungen treten bei diesem Anlagentyp typischerweise auf, warum wurde diese Konstruktion so gewählt, welche Lösung wurde damals verworfen und weshalb.

Zweitens Anbindung der vorhandenen Spuren: Serviceberichte, Tickets, Projektakten. Das Transkript allein hilft wenig; wertvoll wird es in Verbindung mit den dokumentierten Vorgängen.

Drittens Prüfung durch dieselbe Person: Solange der erfahrene Kollege noch da ist, kann er beurteilen, ob die Antworten des Systems taugen. Diese Prüfphase ist der eigentliche Wissenstransfer – und sie macht aus einer als Bedrohung empfundenen Technik eine Aufwertung der eigenen Rolle.

Wer damit erst beginnt, wenn die Kündigung auf dem Tisch liegt, hat den größeren Teil bereits verloren.

Ein Wort zur Dokumentationsqualität

Eine unbequeme Rückmeldung, die fast jedes technische Team aus dem ersten Test mitnimmt: Ein erheblicher Teil der schlechten Antworten liegt nicht am System, sondern an knappen, uneinheitlichen Serviceberichten. „Kunde angerufen, Problem behoben“ ist für einen Menschen eine Notiz und für jede Auswertung wertlos.

Das ist ärgerlich und zugleich die nützlichste Erkenntnis des Projekts, weil sie unabhängig von jedem Werkzeug gilt. Eine Handvoll Pflichtfelder im Berichtsformular – Symptom, Ursache, Maßnahme, verwendete Teile – verändert die Auswertbarkeit binnen weniger Monate grundlegend.