Qualität, Sicherheit und Firmenumgebung

Qualität, Sicherheit und Firmenumgebung

0:00 In technischen Seminaren kommt dieses Modul meistens zu kurz, und in der Praxis entscheidet es über alles. Denn in vielen Java-Häusern lautet die erste Frage nicht „was kann das Werkzeug", sondern „wohin fließt unser Code". Wenn Sie nach diesem Seminar ein Pilotprojekt vorschlagen, werden Sie genau diese Fragen gestellt bekommen — von der Rechtsabteilung, vom Betrieb, vom Datenschutz.

0:22 Es lohnt sich also, vorbereitet zu sein. Und es lohnt sich zu wissen, welche dieser Fragen technisch beantwortbar sind und welche nicht.

Qualität, Sicherheit und Firmenumgebung

0:30 Wir sehen uns vier Dinge an: die stillen Nebenwirkungen agentischer Arbeit, allen voran neue Abhängigkeiten. Die Lizenz- und Urheberfragen, mit denen Sie konfrontiert werden. Die Randbedingungen im Unternehmen — Proxy, Betriebsmodell, Datenschutz. Und schließlich die Frage, was ein Agent eigentlich allein abschließen darf.

0:50 Dieses letzte Kapitel ist das, was ich Ihnen am dringendsten ans Herz lege, denn diese Grenze entsteht sonst zufällig. Vier Ziele. Erstens: die stillen Nebenwirkungen erkennen und begrenzen — das sind die Dinge, die im Diff nicht auffallen. Zweitens: die Fragen beantworten können, die in Firmen zuerst gestellt werden. Drittens: automatische Prüfungen vor die menschliche Prüfung setzen, damit Ihre Aufmerksamkeit für das Wesentliche frei bleibt.

1:17 Und viertens: festlegen, was ein Agent allein abschließen darf. Das ist der Punkt, an dem aus einem Experiment eine Arbeitsweise wird, mit der ein Team dauerhaft leben kann.

Abhängigkeiten, die beiläufig hereinkommen

1:29 Beginnen wir mit der häufigsten stillen Nebenwirkung agentischer Arbeit. Agenten lösen Probleme gern, indem sie eine Bibliothek hinzufügen — das ist die naheliegendste Lösung und oft sogar eine technisch gute. Nur ist eine Bibliothek in einem Firmenprojekt keine Codezeile, sondern eine Entscheidung mit jahrelanger Nachwirkung.

1:47 Und sie entsteht in einem Diff, in dem sie zwischen dreißig Codezeilen kaum auffällt. Eine neue Bibliothek zieht mehr nach sich, als der Diff zeigt: Pflege, Sicherheitsprüfungen, Lizenzfragen, transitive Abhängigkeiten. Nichts davon ist im Moment des Hinzufügens sichtbar. Es ist wie ein Haustier im Urlaub — die Entscheidung dauert eine Minute, die Verantwortung Jahre.

2:09 Und das Missverhältnis ist genau der Punkt: Der Zeitgewinn beträgt vielleicht zwanzig Minuten, die Bibliothek bleibt zehn Jahre. Deshalb gehört diese Entscheidung nicht in einen Arbeitsschritt, sondern in eine Rückfrage. Vier Zeilen, und die letzte ist die, die den Unterschied macht. Die ersten drei sind ein Verbot mit Rückfragevorbehalt — das allein würde dazu führen, dass der Agent stehenbleibt und Sie mit einer unspezifischen Frage konfrontiert.

2:36 Der letzte Satz macht daraus etwas Brauchbares: Vorschläge nennen Zweck und Alternative. Sie bekommen also nicht „darf ich eine Bibliothek hinzufügen", sondern „dafür brauche ich X, Alternative wäre Y von Hand". Damit können Sie in zehn Sekunden entscheiden statt nachzufragen. Der erste Punkt ist die Kernaussage: Eine Abhängigkeit bleibt Jahre, der Zeitgewinn war Minuten.

2:59 Der zweite ist der, den man in Java besonders ernst nehmen muss: Transitive Abhängigkeiten kommen ungefragt mit. Sie fügen eine Bibliothek hinzu und haben faktisch fünf weitere im Projekt, die niemand geprüft hat. Und der dritte Punkt ist die Folge davon, die erst später kommt: Sicherheitsmeldungen betreffen dann das ganze Projekt — inklusive einer Bibliothek, an deren Aufnahme sich niemand erinnert.

3:23 Der erste Punkt ist der praktische Prüffehler: nur den Diff im Quellcode prüfen und die Projektkonfiguration überfliegen. Genau dort steht aber die eigentliche Entscheidung. Nehmen Sie sich für die Konfigurationsdatei mehr Zeit als für den Code, nicht weniger. Der zweite Punkt wird oft mit einem Achselzucken abgetan: Testabhängigkeiten für unkritisch halten.

3:44 Sie landen zwar nicht in der Auslieferung, aber sie werden gepflegt, sie haben Sicherheitslücken, und sie binden das Projekt an bestimmte Stände. Unkritisch ist etwas anderes.

Lizenz- und Urheberfragen bei generiertem Code

3:55 Im zweiten Kapitel wird es rechtlich, und ich sage gleich vorweg: Ich bin kein Jurist, und dieses Kapitel ersetzt keine Rechtsberatung. Was wir hier machen, ist etwas anderes und aus meiner Sicht Nützlicheres — wir sortieren, welche dieser Fragen technisch beantwortbar sind und welche nicht. Denn genau dieser Unterschied wird in Firmendiskussionen ständig verwischt, und daraus entstehen teure Fehlentscheidungen.

4:18 Woher ein Vorschlag stammt, ist im Ergebnis nicht erkennbar. Das ist die schlichte Ausgangslage. Ein Sprachmodell liefert Ihnen keinen Quellenverweis, und es gibt auch keinen technischen Weg, ihn nachträglich zu ermitteln. Daraus entstehen Fragen nach Lizenzen, Urheberschaft und Nachweispflichten — und viele Unternehmen versuchen, sie technisch zu lösen. Das ist der Fehler.

4:40 Der größte Teil dieser Fragen ist vertraglich und organisatorisch zu klären. Was technisch geht, ist deutlich weniger, aber immerhin klar umrissen. Die Logik dieser Tabelle ist eine Sortierung nach Zuständigkeit. Ganz oben steht die Frage, die alle interessiert — stammt der Code aus einem fremden Projekt — und die Antwort ist unbequem: nicht feststellbar.

5:02 Darunter wird es besser, weil die Zuständigkeit klarer wird. Und die Fußzeile ist die eigentliche Botschaft: Nur die letzte Zeile lässt sich im Bauvorgang automatisieren. Alles andere ist Organisation. Wenn Sie das im Haus klar aussprechen, ersparen Sie sich die Suche nach einem Werkzeug, das es nicht gibt. Der erste Punkt ist der, weshalb dieses Kapitel überhaupt hier steht: Klarheit über die Antwortlage verhindert Scheinlösungen.

5:28 Es gibt einen Markt für Werkzeuge, die vorgeben, Herkunftsfragen technisch zu beantworten. Sie können damit einen Haken setzen, aber keine Frage beantworten. Der dritte Punkt ist der praktische Rat: Die Frage kommt in jedem Freigabeprozess. Wenn Sie vorbereitet hineingehen und sagen können, welcher Teil vertraglich geregelt ist und welcher organisatorisch, sind Sie deutlich schneller durch.

5:51 Der erste Punkt fasst zusammen, was ich eben gesagt habe: technische Werkzeuge kaufen für ein organisatorisches Problem. Der zweite ist der teuerste: die Frage vertagen, bis der erste Auslieferungstermin ansteht. Dann steht die Klärung zwischen Ihnen und dem Termin, und solche Klärungen dauern Wochen. Und der letzte Punkt ist der, der still Schaden anrichtet: interne Regelungen treffen, die niemand kennt.

6:14 Eine Regelung, die im Intranet steht und in keinem Team angekommen ist, schützt nicht — sie verlagert nur die Verantwortung.

Firmenumgebung: Proxy, Betrieb und Datenschutz

6:22 Und jetzt zu dem Kapitel, das ich für Tech Leads oft für das wichtigste des ganzen Seminars halte. Es geht um die Randbedingungen, an denen Pilotprojekte tatsächlich scheitern — und das sind fast nie technische Grenzen des Werkzeugs. Es sind Netzzugänge, Verträge und Zuständigkeiten. Ich bin gespannt auf Ihre Erfahrungen dazu, die Runde ist an dieser Stelle meistens sehr auskunftsfreudig.

6:45 Netzzugang über Proxy, Betriebsmodell, Datenschutz, und die Frage, welcher Code welchen Anbieter erreicht: In vielen Java-Häusern entscheidet genau das über den Einsatz — lange bevor über Funktionen gesprochen wird. Das ist keine Bürokratie, das ist die Realität regulierter Branchen. Und es hat einen unangenehmen Nebeneffekt: Diese Fragen werden meist von anderen Menschen gestellt als denen, die das Werkzeug einführen wollen.

7:10 Wer sie vorwegnimmt, spart sich eine Runde. Fünf Schritte, und sie stehen bewusst vor dem Pilotprojekt, nicht daneben. Schritt drei ist der, der am meisten Ärger erspart: ausdrücklich festlegen, welche Repositories einbezogen werden. Nicht alle Projekte im Haus unterliegen denselben Regeln — Kundenprojekte, Fremdcode, regulierte Bereiche. Wenn das nicht geklärt ist, arbeitet irgendwann jemand mit dem falschen.

7:35 Und Schritt fünf ist der, der aus einer Klärung eine Investition macht: schriftlich festhalten. Sonst führen Sie dieselbe Diskussion pro Team von vorn. Der zweite Punkt ist der, den ich aus der Praxis bestätigen kann: Frühe Klärung verhindert das Pilotprojekt, das nach zwei Wochen stoppt. Und ein gestopptes Pilotprojekt hat eine unangenehme Nachwirkung — es gilt danach als gescheitert, obwohl nie etwas erprobt wurde.

8:01 Der letzte Punkt ist der, den ich Skeptikern gern entgegenhalte: Klare Grenzen erlauben es, innerhalb ihrer schnell zu arbeiten. Wer weiß, was erlaubt ist, muss nicht bei jedem Schritt fragen. Regeln sind hier ein Beschleuniger, kein Bremsklotz. Der dritte Punkt ist der, der Sie Tage kosten kann: Proxy-Probleme als Werkzeugfehler fehldeuten.

8:21 Das Werkzeug meldet eine Zeitüberschreitung, Sie suchen im Werkzeug, und die Ursache sitzt in der Netzkonfiguration. Wenn etwas bei allen im Haus gleich schiefgeht, ist das der erste Verdacht. Der letzte Punkt ist eine Warnung an die Begeisterten: Zusagen machen, die die Vertragslage nicht deckt. Sagen Sie nichts über Datenverwendung zu, was Sie nicht nachlesen können — das fällt später auf Sie zurück.

Statische Analyse als zweite Instanz

8:45 Im vierten Kapitel geht es um Arbeitsteilung zwischen Maschinen und Menschen. Zwei automatische Prüfinstanzen haben wir schon kennengelernt: den Compiler im dritten Modul und die Tests im achten. Jetzt kommt eine dritte dazu. Und die Reihenfolge ist der eigentliche Punkt dieses Kapitels — automatische Prüfungen gehören vor die menschliche, nicht danach.

9:06 Sonst prüfen Sie, was eine Maschine billiger gefunden hätte. Werkzeuge für statische Analyse fangen einen Teil dessen ab, was beim Lesen durchrutscht: ungenutzte Ergebnisse, verdächtige Vergleiche, bekannte Fehlermuster. Nichts davon ist geistige Arbeit, alles davon ermüdet Menschen. Denken Sie an eine Rechtschreibprüfung.

9:26 Sie ersetzt kein Lektorat, aber sie sorgt dafür, dass das Lektorat nicht mit Tippfehlern beschäftigt ist. Genauso hier: Die Maschine räumt das Offensichtliche weg, damit Ihre Aufmerksamkeit für Fachlichkeit und Architektur frei bleibt. Diese Tabelle ist eine Zuständigkeitsordnung, und die Fußzeile sagt das Prinzip: Jede Instanz prüft, was die vorherige nicht kann. Der Compiler findet erfundene Namen.

9:51 Tests finden Verhaltensänderungen. Statische Analyse findet Muster und bekannte Fallen. Und der Mensch — die letzte Zeile — findet Fachlichkeit, Architektur und Angemessenheit. Das ist die einzige Zeile, die nicht automatisierbar ist, und deshalb ist es Verschwendung, wenn Ihre Zeit für die oberen drei draufgeht. Sie sind die teuerste Instanz.

10:12 Setzen Sie sich entsprechend ein. Der letzte Punkt ist der, der zu unserem Thema passt: Der Agent kann die Analyse selbst ausführen, wenn sie hinterlegt ist. Damit wird aus der statischen Analyse kein zusätzlicher Schritt für Sie, sondern ein Teil der Schleife, die ohnehin läuft. Der dritte Punkt ist der Gewinn im Team: Einheitliche Regeln machen Reviews kürzer und sachlicher.

10:34 Wenn ein Werkzeug entscheidet, wie eingerückt wird, muss darüber niemand mehr diskutieren — und Sie glauben nicht, wie viel Zeit das spart. Der erste Punkt ist der Einführungsfehler, der die Sache begräbt: alle Regeln aktivieren. Sie bekommen dreitausend Befunde, davon sind zweitausendachthundert egal, und niemand sieht sich das jemals wieder an. Fangen Sie mit wenigen, wirklich relevanten Regeln an.

10:58 Der zweite Punkt ist die Folge davon: Befunde dauerhaft unterdrücken statt sie zu beheben. Eine Unterdrückung ist eine Entscheidung, die begründet gehört. Wenn sie zur Gewohnheit wird, haben Sie ein Werkzeug, das läuft und nichts bewirkt.

Human-in-the-loop verbindlich machen

11:13 Und damit zum letzten Kapitel, das mir für die Praxis besonders am Herzen liegt. Die Frage lautet: Was darf ein Agent allein abschließen und was nicht? Diese Grenze existiert in jedem Team, das mit Agenten arbeitet. Die Frage ist nur, ob sie bewusst gesetzt wurde — oder ob sie sich aus Gewohnheit und Zeitdruck ergeben hat.

11:33 Wenn Sie diese Grenze nicht festlegen, entsteht sie trotzdem. Sie entsteht dann aus der Tagesform: Am Montag prüfen Sie jeden Diff, am Donnerstag winken Sie durch, weil der Sprint endet. Das ist keine Regel, das ist Zufall. Eine festgelegte Abstufung hat zwei Vorteile: Sie ist im Zweifel überprüfbar, und sie lässt sich bewusst verschieben, wenn Vertrauen wächst.

11:55 Beides geht bei einer stillschweigenden Praxis nicht — die kann man nur ändern, indem man sie zuerst benennt. Diese Tabelle ist nach Tragweite sortiert, nicht nach Aufwand. Oben stehen Dinge, die reversibel und lokal sind — Formatierung, ein ergänzter Test. Dort kann der Agent allein arbeiten, und das sollte er auch, sonst ersticken Sie in Freigaben. In der Mitte wird geprüft.

12:18 Und unten stehen drei Dinge, bei denen der Mensch vorher entscheidet: neue Abhängigkeit, Modulgrenze, Datenbankschema. Das sind genau die Entscheidungen, die schwer zurückzunehmen sind. Die Fußzeile ist wichtig: Das gehört in die Anweisungsdatei, nicht in eine Besprechung. Der dritte Punkt ist der, den man beim Aufschreiben von Regeln oft vergisst: Klare Freiräume beschleunigen die unkritischen Fälle.

12:43 Es geht hier nicht nur darum, etwas zu verhindern. Es geht auch darum, ausdrücklich zu erlauben — damit niemand aus Unsicherheit für jede Kleinigkeit fragt. Und der letzte Punkt ist der, der diese Tabelle lebendig hält: Die Abstufung lässt sich mit wachsendem Vertrauen verschieben. Sie ist eine Momentaufnahme, kein Gesetz.

13:02 In sechs Monaten sieht sie vermutlich anders aus. Der erste Punkt ist der, an dem gut gemeinte Regelwerke scheitern: alles freigabepflichtig machen. Wenn jede Formatierungsänderung eine Freigabe braucht, wird die Regel innerhalb einer Woche umgangen — nicht aus Böswilligkeit, sondern weil anders nicht gearbeitet werden kann.

13:21 Der letzte Punkt ist der schleichende: die Grenze nach dem ersten guten Ergebnis aufweichen. Das passiert immer, und es ist auch in Ordnung — aber dann verschieben Sie die Zeile in der Tabelle und schreiben es auf. Aufweichen im Stillen ist etwas anderes als eine Anpassung. Zum Abschluss dieses Moduls legen Sie die Abstufung für Lagerwerk fest und schreiben sie in die Anweisungsdatei. Das ist der einfache Teil.

13:45 Der eigentliche Auftrag ist der zweite: Benennen Sie für Ihr eigenes Projekt, welche Zeile dort anders aussehen müsste. In einem regulierten Umfeld wandert vermutlich einiges nach unten. In einem internen Werkzeug vielleicht einiges nach oben. Genau dieser Vergleich ist es, den Sie mit ins Haus nehmen sollen. Zusammengefasst: Neue Abhängigkeiten sind Entscheidungen mit jahrelanger Nachwirkung und brauchen deshalb eine Regel mit Rückfrage.

14:10 Lizenzfragen sind zum größten Teil organisatorisch und nicht technisch zu lösen — das zu wissen erspart die Suche nach dem Werkzeug, das es nicht gibt. Proxy, Betriebsmodell und Datenschutz entscheiden in vielen Häusern über den Einsatz, also klären Sie sie zuerst. Und die Freigabegrenze steht jetzt schriftlich — womit sie bewusst verschiebbar wird statt stillschweigend zu erodieren.