KI-gestützte IaC-Entwicklung

KI-gestützte IaC-Entwicklung

0:00 Das letzte Modul dieses Seminars handelt von einem Helfer, der in kaum einem Team mehr fehlt: KI-Werkzeuge, die Code schreiben. Für Infrastruktur ist das verlockend, denn HCL ist regelmäßig und gut dokumentiert — ein Modell produziert in Sekunden, wofür man selbst eine halbe Stunde braucht. Genau darin liegt aber das Risiko.

0:18 Ein falsches Argument in einer Anwendung führt zu einem Fehler, ein falsches Argument in der Infrastruktur womöglich zu einem offenen Datenbankport. In diesem Modul geht es deshalb nicht darum, wie man ein Modell möglichst viel schreiben lässt, sondern darum, wie man seine Vorschläge prüft und wo der Mensch die Entscheidung behält.

KI-gestützte IaC-Entwicklung

0:37 Der Satz auf dieser Folie fasst das Modul in einem Gedanken zusammen: Ein Modell schreibt schnell HCL, aber ob die Infrastruktur danach stimmt, zeigt nur der Plan. Damit schließt sich ein Kreis, denn der Plan war vom zweiten Modul an unser wichtigstes Werkzeug. Wir sortieren zuerst, welche Aufgaben sich für KI-Werkzeuge eignen.

0:56 Dann bauen wir eine Prüfkette für ihre Vorschläge, sehen uns den Terraform MCP Server an und ziehen die Grenze, an der ein Mensch entscheiden muss.

Geeignete Aufgaben für KI-Werkzeuge

1:05 KI-Werkzeug ist nicht gleich KI-Werkzeug. Bevor wir über Prüfung sprechen, klären wir, womit wir es überhaupt zu tun haben — und wie viel Spielraum jedes davon bekommt. Die Tabelle ordnet die Werkzeuge nach zwei Fragen: Was sieht es, und was tut es? Von oben nach unten wächst beides. Der Chat-Assistent kennt nur, was Sie ihm hineinkopieren, und liefert Text. Der IDE-Assistent sieht Ihr Projekt und ändert direkt im Editor.

1:31 Der Coding Agent schließlich arbeitet im Repository und im Terminal und führt selbst Befehle aus. Das ist ein bisschen wie der Unterschied zwischen einem Berater am Telefon, einem Kollegen am Nachbartisch und jemandem, dem Sie den Schlüssel zum Serverraum geben. Der Satz unten ist der wichtigste: Wer plan aufrufen darf, kann auch apply aufrufen. Die Rechte legt das Team fest, nicht das Modell.

1:55 Ein Modell ist nur so gut wie das, was es über Ihre Lage weiß. Fehlt die Provider-Version, greift es auf sein Gedächtnis zurück, und das stammt oft aus älteren Releases — dann tauchen Argumente auf, die es so nicht mehr gibt. Die Schnittstelle eines Moduls mit Variablen, Typen und Outputs steckt den Rahmen ab, in dem ein Vorschlag sich bewegen darf.

2:15 Sicherheitsvorgaben gehören ebenfalls dazu: Bei Saatplan etwa, dass der Datenbankport von saatplan-db nie veröffentlicht wird. Und nennen Sie Werkzeug und Version ausdrücklich. Wer nur Terraform sagt, aber OpenTofu meint, bekommt womöglich Code, der beim eigenen Werkzeug gar nicht läuft. Die ersten drei Stolpersteine handeln alle davon, was man einem Modell besser nicht gibt.

2:38 Eine Fehlermeldung wird samt Datenbankpasswort in den Prompt kopiert, weil es schnell gehen musste. Ganze State-Dateien oder Plan-Ausgaben landen im Chat, und mit ihnen sensible Werte, die dort nichts zu suchen haben. Und ein Agent bekommt die Verbindungsdaten des pg-Backends im Terminal — damit hat er Schreibzugriff auf den State.

2:57 Der vierte Punkt ist anderer Natur: Ein ganzes Modul auf einmal generieren zu lassen, wirkt effizient. Aber niemand kann einen solchen Vorschlag wirklich prüfen. Kleine Änderungen sind hier keine Pedanterie, sondern die Voraussetzung für ein ernsthaftes Review.

Vorschläge verifizieren

3:13 Ein Modell klingt immer überzeugt, auch wenn es sich irrt. Deshalb brauchen wir eine Prüfung, die nicht auf den Tonfall hört, sondern auf das, was das installierte Werkzeug tatsächlich sagt. Diese Kette kennen Sie in Teilen schon aus den Modulen über Tests und Pipelines, nur kommt der Code diesmal aus einer anderen Quelle.

3:32 Am Anfang steht eine kleine Änderung, damit sie überhaupt prüfbar ist. Formatieren und Validieren fangen die groben Fehler ab. Der gespeicherte Plan zeigt, was wirklich passieren würde. Tests und Prüfungen sichern das Bestehende ab, und am Ende schaut ein Mensch auf den Diff. Das Entscheidende steht unten: Jede Stufe darf den Vorschlag stoppen, und keine wird übersprungen, nur weil der Text überzeugend klang.

3:55 Ein Vorschlag aus einem Modell verdient genau dieselbe Prüfung wie einer von einem neuen Kollegen. Diese Befehle funktionieren mit tofu genauso wie mit terraform, und sie ersetzen Vertrauen durch Belege. Zuerst die Version, denn sie bestimmt, welche Argumente es überhaupt gibt. Dann das Provider-Schema als JSON. Das ist der Moment, in dem Sie das Modell beim Wort nehmen können: Steht ein vorgeschlagenes Argument nicht im Schema, gibt es es nicht, egal wie plausibel es klingt.

4:24 Formatprüfung und Validierung folgen. Und schließlich der gespeicherte Plan, ebenfalls als JSON ausgegeben. Damit haben Sie zwei Dokumente, die sich nicht irren können: Das Schema sagt, was möglich ist, der Plan sagt, was tatsächlich passiert. Diese Stolpersteine zeigen, wie leicht man die Prüfung wieder aushebelt. Das Modell erklärt den Plan, und die Erklärung klingt gut — aber niemand hält sie gegen die echte Ausgabe.

4:50 Ein erfundenes Argument fällt erst bei der Validierung auf, weil der Vorschlag vorher einfach übernommen wurde. Besonders tückisch ist der dritte Punkt: Das Modell passt nicht nur den Code an, sondern auch die Tests, bis alles grün ist. Dann prüfen die Tests nur noch sich selbst. Und der vierte: In einem langen Diff geht unter, dass die Datenbank ersetzt werden soll. Bei saatplan-db wäre das kein Schönheitsfehler, sondern womöglich ein Datenverlust.

Der Terraform MCP Server

5:16 Ein großer Teil der Fehler entsteht, weil das Modell veraltetes Wissen mitbringt. Der Terraform MCP Server setzt genau dort an — und wirft dabei eine neue Frage auf: Wie viel darf ein Werkzeug tun? Das Model Context Protocol ist so etwas wie eine Steckdosennorm für KI-Werkzeuge: ein gemeinsamer Anschluss, über den ein Modell an externe Quellen und Funktionen kommt.

5:39 HashiCorp liefert dafür einen eigenen Server. Er gibt dem Werkzeug Zugriff auf die aktuelle Dokumentation von Providern und Modulen sowie auf Policies aus der Terraform Registry. Statt aus der Erinnerung zu antworten, kann das Modell also nachschlagen. Darüber hinaus kann der Server Workspaces und Runs in HCP Terraform oder Terraform Enterprise bedienen, und an dieser Stelle wird aus einem Nachschlagewerk ein Werkzeug mit Handlungsmacht.

6:04 Er läuft lokal oder über das Netz. Die Tabelle zeigt, wie der Server seine Fähigkeiten in Gruppen schnürt, und die Logik dahinter ist eine Treppe. Ganz unten steht die öffentliche Registry, das ist der Standard und braucht keinerlei Zugangsdaten. Mit jeder Stufe darüber kommt mehr Reichweite und eine weitere Voraussetzung hinzu: erst ein Token für private Inhalte und Workspaces, dann für schreibende Werkzeuge noch ein ausdrücklicher Schalter.

6:30 Das ist gut gedacht, denn wer mehr will, muss es bewusst einschalten. Für Saatplan ist die Antwort einfach. Wir arbeiten ohne HCP Terraform, also genügt die Registry, und alles andere bleibt aus. Hier sehen Sie, wie man die beiden Server in einem Coding Agent einträgt, und das Muster dahinter heißt: so wenig wie möglich.

6:50 Der Terraform-Server läuft lokal in einem Container, mit einer fest angegebenen Version statt der jeweils neuesten, und beschränkt auf das Registry-Toolset. Für OpenTofu gibt es einen eigenen Server mit eigener Registry, der über das Netz angebunden wird. Der Hinweis unten zeigt eine zweite Stellschraube: Statt ganzer Gruppen lassen sich auch einzelne Werkzeuge freigeben. Nur beides zugleich geht nicht.

7:13 Das Prinzip kennen Sie aus jedem Berechtigungskonzept — erst eng beginnen, dann bei Bedarf gezielt erweitern. Ein Server, der aktuelle Dokumentation liefert, ist ein echter Gewinn — aber er liefert eben die Dokumentation von Terraform. Was nur OpenTofu kann, etwa for_each im Provider-Block aus dem letzten Modul, steht dort nicht.

7:33 Für OpenTofu-Code gehören deshalb opentofu.org und der OpenTofu MCP Server in den Kontext. HashiCorp selbst rät, die Antworten vor dem Einsatz zu prüfen und den Server nicht mit fremden Clients oder Modellen zu betreiben. Und ein praktischer Tipp zum Schluss: Wer im Prompt exakte Namen nennt, etwa docker_container oder den Provider kreuzwerker docker, trifft die richtigen Werkzeuge deutlich zuverlässiger als mit einer vagen Beschreibung.

Menschliche Entscheidungen einfordern

7:59 Prüfen ist die eine Hälfte. Die andere ist die Frage, welche Entscheidungen ein Modell gar nicht erst treffen soll — und woran man merkt, dass ihm schlicht Informationen fehlen. Die vier Felder ordnen Aufgaben nach ihrem Risiko, und sie lesen sich wie ein Delegationsplan für ein neues Teammitglied. Dokumentation nachschlagen, formatieren, Testgerüste vorschlagen — das darf das Werkzeug einfach erledigen. Neue Ressourcen oder Refactorings übernimmt man, aber nur nach Prüfung.

8:27 Bei Ports, Netzen und Datenhaltung, oder wenn ein bestehender Container ersetzt würde, entscheidet ein Mensch. Und das letzte Feld ist nicht verhandelbar: Anwenden, Freigaben, Secrets und Eingriffe in den State gibt man nie aus der Hand. Der Gedanke dahinter ist einfach. Je schwerer ein Fehler rückgängig zu machen ist, desto näher muss die Entscheidung beim Menschen liegen.

8:50 Das vielleicht Unterschätzteste an KI-Vorschlägen ist, was sie verschweigen. Ein Modell fragt selten nach, es füllt Lücken mit Annahmen und präsentiert das Ergebnis, als wäre alles klar. Ein Handwerker, der ohne Rückfrage ein Bad fliest, hat vielleicht schöne Arbeit geleistet — nur eben nicht unbedingt die Farbe, die Sie wollten.

9:08 Wenn ein Vorschlag nicht nach Ports, Volumes oder der Zielumgebung fragt, ist das ein Signal: Hier fehlt eine Anforderung. Gute Vorschläge benennen ihre Annahmen ausdrücklich, schlechte wirken einfach vollständig. Und die Rückfrage an die Fachseite ist deshalb kein Umweg, sondern der eigentliche Fortschritt. Diese Tabelle ist eine Entscheidungshilfe für das Review, und ihre Zeilen spiegeln sich gegenseitig.

9:32 Links steht, was einen Vorschlag annehmbar macht: Der Plan zeigt genau die beabsichtigte Änderung, jedes Argument ist im Schema belegt, die Tests laufen unverändert, und die Annahmen sind ausgesprochen. Rechts steht jeweils das Gegenstück, das zur Ablehnung führt. Auffällig ist, dass keine Zeile fragt, ob der Code elegant aussieht. Es geht ausschließlich um Belege.

9:54 Und der Hinweis unten verdient Beachtung: Die Begründung gehört in den Pull Request, gerade auch bei einer Ablehnung. Nur so lernt das Team, und nur so lässt sich die Entscheidung später nachvollziehen.

Übung

10:06 Zum Abschluss eine Übung, die alles zusammenbringt. Sie bekommen einen Vorschlag, der auf den ersten Blick gut aussieht — und der genau die Fehler enthält, über die wir gesprochen haben. Die Übung simuliert eine Situation, die Sie im Alltag sicher erleben werden. Ein KI-Werkzeug ergänzt einen Wartungscontainer für Saatplan, und der Code wirkt sauber.

10:27 Darin verstecken sich vier Fehler, und der Hinweis auf der Folie verrät bereits, welcher Art sie sind. Das Lernziel ist nicht, diese vier zu finden, sondern ein Vorgehen einzuüben, das sie zuverlässig findet: Prüfen gegen Schema, Plan, Tests und Anforderungen, und dann eine begründete Entscheidung. Erfolgreich sind Sie, wenn alle Fehler behoben sind, Tests und Pipeline unverändert grün laufen und der Pull Request erklärt, warum Sie so entschieden haben.

10:53 Die fünf Schritte folgen der Prüfkette aus dem zweiten Kapitel, und der Zweck jedes Schritts ist, eine bestimmte Art von Fehler sichtbar zu machen. Zuerst lesen Sie nur und notieren die Annahmen, die der Vorschlag stillschweigend trifft. Dann halten Sie jedes Argument gegen das Provider-Schema. Der gespeicherte Plan wird mit der Erklärung des Modells verglichen, nicht ihr geglaubt. Beim Beheben laufen die bestehenden Tests mit, und zwar unverändert.

11:18 Und am Ende steht die Pipeline samt einer Freigabe mit Begründung. Wenn Sie diesen Ablauf einmal bewusst durchlaufen haben, wird er bei echten Vorschlägen zur Gewohnheit. Die letzten Stolpersteine: Ein Fehler wird so lange ans Modell zurückgegeben, bis die Prüfung schweigt, verstanden ist er damit nicht. Der offene Port fällt nicht auf, weil die Validierung ihn für gültig hält. Und das gelöschte Passwort steht noch in der Git-Historie. Damit endet das Seminar.

11:45 In fünf Tagen haben wir Saatplan von der ersten Konfiguration über Module, State und Secrets bis zu Umgebungen, Bestandsübernahme, Tests, Pipelines, Betrieb, Werkzeugwechsel und KI-Unterstützung begleitet. Der Gedanke, der alles verbindet, steht im vierten Stolperstein: Freigegeben wird nicht, weil die Pipeline grün ist, sondern weil der Plan verstanden wurde.

12:06 Vielen Dank fürs Mitmachen.