Git und KI verstehen

Git und KI verstehen

0:00 Es gibt einen Moment, den viele Teams gerade erleben: Der Agent liefert in zwanzig Minuten, wofür früher ein Nachmittag draufging — und niemand weiß mehr genau, was eigentlich passiert ist. Die Menge an Code steigt, die Nachvollziehbarkeit sinkt. Genau hier setzt dieses Seminar an. Es geht nicht darum, ob KI beim Programmieren hilft; das ist entschieden.

0:21 Es geht darum, wie wir das Ergebnis beherrschen. Und das Werkzeug dafür liegt längst auf jedem Rechner: Git. Wir schauen uns an, welche seiner Funktionen plötzlich eine ganz neue Bedeutung bekommen, wenn nicht mehr nur Menschen committen.

Git als Werkzeug für KI-generierten Code

0:35 In diesem ersten Modul legen wir das Fundament. Wir klären, was Sie mitbringen sollten, wir sehen uns an, wie ein Prompt am Ende zu einem Deployment wird, und wir lernen das Projekt kennen, das uns durch alle sechs Module begleitet. Noch tippen wir wenig — dieses Modul sortiert erst einmal das Problem. Denn die häufigste Ursache dafür, dass Werkzeuge nicht helfen, ist nicht die Technik.

0:58 Es ist die Reihenfolge: Erst wissen, was schiefgeht, dann etwas dagegen einsetzen. Vier Dinge nehmen Sie aus diesem Modul mit. Sie können benennen, welche Probleme KI-generierter Code in einem Repository überhaupt erzeugt — und das ist mehr als "zu viel Code". Sie lesen den Weg vom Prompt bis zur Produktion als eine Kette von Git-Ereignissen, nicht als eine schwarze Box.

1:20 Sie kennen die vier Stellen, an denen Git in diese Kette eingreifen kann. Und Sie haben das Beispielprojekt vor Augen, an dem wir das alles durchspielen. Das klingt nach wenig Handwerk für ein erstes Modul. Es ist die Landkarte, ohne die die nächsten fünf beliebig wirken.

Kursüberblick und Voraussetzungen

1:36 Beginnen wir mit einer ehrlichen Bestandsaufnahme: Was setzt dieses Seminar voraus, und worauf zielt es? Das ist keine Formalie. Wer die Voraussetzungen kennt, weiß auch, an welchen Stellen er selbst nachlegen muss, bevor die Übungen ab Modul zwei Spaß machen. Stellen Sie sich Git wie die Buchhaltung eines Projekts vor. Solange ein Mensch alle Belege einzeln einsortiert, bleibt sie übersichtlich.

2:00 Jetzt schüttet jemand täglich einen Karton dazu — die Buchhaltung ist nicht kaputt, sie ist nur überfordert. Genau das tut ein Agent mit Ihrem Repository. Dieses Seminar behandelt Git als das Werkzeug, mit dem Sie diese Menge wieder in den Griff bekommen. Es ist ausdrücklich kein Git-Einstieg und auch keine Schulung für ein bestimmtes KI-Produkt.

2:20 Was wir hier bauen, funktioniert mit jedem Agenten und in jeder Programmiersprache — weil Git sich für beides nicht interessiert. Vier Beobachtungen, die Sie vermutlich wiedererkennen. Erstens: Agenten committen gern und oft, aber ihre Nachrichten unterscheiden nichts. Fünfmal "Konfiguration angepasst" hilft niemandem. Zweitens: Sobald zwei Agenten parallel arbeiten, schreiben sie sich gegenseitig über die Finger.

2:46 Drittens: Qualitätsregeln greifen meist erst im Review oder in der Pipeline — also lange nachdem der Fehler entstanden ist. Und viertens, das ist die Grenze: Ein Agent, dem niemand Schranken gesetzt hat, reicht weiter, als irgendjemand beabsichtigt hat. Für die ersten drei Punkte hat Git sehr konkrete Antworten. Für den vierten auch — aber die heißt Konfiguration, nicht Vertrauen.

3:10 Diese Übersicht hat eine Logik, und die ist nicht zufällig. Wir arbeiten von innen nach außen. Modul zwei bleibt vollständig in Ihrer lokalen Historie — dort, wo der Schaden zuerst entsteht und am billigsten zu beheben ist. Modul drei erweitert das auf mehrere Agenten gleichzeitig. Modul vier zieht Prüfungen vor den Commit.

3:29 Erst Modul fünf und sechs verlassen den eigenen Rechner und beschäftigen sich mit dem, was auf dem Server durchgesetzt wird. Diese Reihenfolge hat einen praktischen Grund: Alles, was Sie lokal lösen, müssen Sie später nicht mit Ihrer Organisation verhandeln. Das hier ist kein Übungsblatt, sondern ein Selbsttest. Fünf Befehle, die ab Modul zwei in echten Aufgaben wieder auftauchen.

3:52 Wenn Sie beim Lesen bei jedem nicken — sehr gut, dann können wir Tempo machen. Wenn zwei davon eher vage Erinnerungen sind, ist das kein Problem, aber dann lohnt sich vorher eine halbe Stunde in der Git-Dokumentation. Besonders bei den letzten beiden: Wer bisect und interaktives Rebase nur vom Hörensagen kennt, kämpft in Modul zwei an der falschen Front.

4:13 Sie sollen dort verstehen, wofür man sie einsetzt — nicht, wie sie funktionieren. Bevor wir Werkzeuge einführen, lohnt ein Blick auf den Ist-Zustand. Nehmen Sie Ihr Hauptprojekt und beantworten Sie vier Fragen: Gibt es eine Commit-Vorlage? Läuft ein Pre-Commit-Hook? Existiert eine Anweisungsdatei für Agenten? Ist der Hauptbranch geschützt? Vier Zeilen genügen.

4:35 Der Reiz liegt darin, dass Sie diese Liste am Ende von Modul sechs noch einmal hervorholen — und die Lücken dann nicht mehr theoretisch sind. Erfahrungsgemäß ist bei den meisten Teams genau ein Punkt erfüllt, und es ist fast immer der Branch-Schutz. Der kam nämlich schon vor der KI. Diese vier Fehler kosten in der Praxis am meisten Zeit. Der häufigste: Werkzeuge einführen, bevor das Problem benannt ist.

5:01 Dann steht am Ende ein Hook im Repository, den alle mit einem Flag umgehen. Der zweite hängt damit zusammen — die Hoffnung, KI ersetze Prozessdisziplin. Sie tut das Gegenteil, sie skaliert das Fehlen von Disziplin. Der dritte ist eine Frage der Ehrlichkeit: Regeln, die in Ihrem Unternehmen niemand durchsetzen kann, sind Dekoration.

5:21 Und der vierte: Dieses Seminar ist keine Anleitung für ein bestimmtes KI-Produkt. Wenn Sie nach Produktnamen suchen, lesen Sie an der Substanz vorbei.

Wie Git und KI zusammenspielen

5:32 Jetzt wird es konkreter. Wir verfolgen den Weg, den generierter Code nimmt — vom ersten Prompt bis in die Produktion. Und wir markieren unterwegs die Stellen, an denen Git nicht nur zusieht, sondern eingreifen kann. Es sind genau vier. Zwischen Prompt und Produktion liegt eine Kette, und die ist erstaunlich stabil. Der Agent erzeugt Code, ein Commit hält ihn fest, ein Push trägt ihn nach außen, ein Pull Request führt ihn in den Hauptbranch, ein Deployment bringt ihn zum Kunden.

6:01 Denken Sie an eine Werkshalle mit mehreren Kontrollpunkten: Zwischen den Stationen kann man ein Werkstück prüfen — auf der Strecke dazwischen nicht. Genau so ist es hier. Jede dieser Übergabestellen ist eine Gelegenheit. Was Sie dort nicht prüfen, prüft niemand mehr, bevor es Kunden erreicht. Erzählen wir die Kette einmal am Stück. Alles beginnt mit dem Prompt, und je genauer er ist, desto brauchbarer wird die Antwort — das gilt unverändert.

6:27 Der Agent erzeugt Code, gestützt auf das, was er im Projekt vorfindet. Dann entsteht ein Commit; manche Werkzeuge legen ihn selbst an, bei anderen tun Sie es. Der Push bringt den Stand auf einen Branch im entfernten Repository, und der Pull Request führt ihn schließlich zusammen. Wichtig ist die Einsicht dahinter: Diese Abfolge ändert sich nicht, egal welches Modell Sie einsetzen.

6:49 Deshalb funktionieren die Maßnahmen aus diesem Seminar auch, wenn Sie das Werkzeug wechseln. Vier Stellen, vier Wirkungsweisen — und es lohnt sich, die Reihenfolge zu verstehen. Ganz vorn steht die Anweisungsdatei: Sie wirkt, bevor überhaupt Code entsteht, und ist damit die einzige vorbeugende Maßnahme. Die Commit-Vorlage wirkt im Moment des Festschreibens und rettet die Nachricht. Der Pre-Commit-Hook wirkt kurz davor und rettet den Code.

7:17 Und der Branch-Schutz wirkt ganz am Ende, wenn alles andere versagt hat. Je weiter vorn Sie ansetzen, desto billiger ist die Korrektur. Je weiter hinten, desto verbindlicher. Deshalb braucht man beides — und deshalb bekommt jede dieser Stellen später ihr eigenes Modul. Hier sehen Sie die vier Ansatzpunkte zum ersten Mal als Befehle. Nichts davon müssen Sie jetzt eintippen; wir bauen jeden dieser Schritte später sorgfältig auf.

7:43 Worauf es ankommt, ist die Beobachtung, wie unspektakulär das aussieht. Es sind Konfigurationszeilen und ein Blick in ein Verzeichnis — kein Framework, kein Dienst, keine Lizenz. Der Aufwand für die drei lokalen Maßnahmen liegt bei zusammengenommen vielleicht einer Stunde. Was daran schwierig ist, ist nicht das Einrichten.

8:03 Es ist die Entscheidung, dass es künftig für alle gilt. Zeichnen Sie den Weg für Ihr eigenes Projekt auf. Von der Codegenerierung bis zum Deployment, jede Station eine Box, und dann markieren Sie: Wo wird heute schon geprüft? Bei den meisten Teams sammelt sich alles an einer Stelle, nämlich in der Pipeline nach dem Push. Das ist nicht falsch, aber es ist spät.

8:25 Lassen Sie die Lücken bewusst offen — sie sind die Agenda der nächsten Module, und Sie werden diese Skizze noch mehrfach hervorholen. Wer mag, notiert daneben, wie viele Minuten zwischen Fehler und Rückmeldung vergehen. Diese Zahl überrascht oft. Vier typische Denkfehler auf dieser Ebene. Der erste: alle Prüfungen in die Pipeline legen. Bequem, aber jeder Fehler kostet dann eine Runde Wartezeit.

8:49 Der zweite: automatisch erzeugte Commits ungelesen übernehmen — der Agent fasst zusammen, was er für relevant hält, und liegt dabei nicht immer richtig. Der dritte: die Anweisungsdatei lokal halten. Dann arbeitet Ihr Agent nach anderen Regeln als der Ihrer Kollegin, und niemand merkt es. Und der vierte betrifft Erwartungen: Derselbe Prompt erzeugt zweimal nicht denselben Code. Wer darauf baut, baut auf Sand.

Das Szenario — Nordlicht Outdoor

9:16 Damit die nächsten Module nicht im Abstrakten bleiben, bekommen wir jetzt einen Kunden. Ein Unternehmen mit einer echten Aufgabe, echten Sorgen und einem Entwicklungsprozess, den Sie vermutlich wiedererkennen werden. Nordlicht Outdoor ist ein Händler für Outdoor-Ausrüstung — Zelte, Schlafsäcke, Wanderschuhe. Das Entwicklungsteam pflegt eine Produkt-API und erweitert sie zunehmend mit Hilfe von KI-Agenten. Damit steht es vor genau den Fragen, um die es hier geht.

9:43 Ein Hinweis dazu: Die Sorgen dieses Unternehmens werden sich nicht Punkt für Punkt mit Ihren decken, und das sollen sie auch nicht. Nehmen Sie es als Muster, nicht als Vorlage. Der Einzige, der weiß, was in Ihrer Organisation funktioniert, sind Sie. Ich liefere die Technik — die Übersetzung in Ihren Alltag bleibt Ihre Aufgabe.

10:03 Diese vier Sorgen haben eine Gemeinsamkeit: Keine davon ist neu. Fehlerursachen waren schon immer schwer zu finden — nur eben nicht bei diesem Tempo. Parallele Arbeit gab es schon immer — nur nicht mit Beteiligten, die im Sekundentakt Dateien schreiben. Qualitätsstandards gab es schon immer — nur wurden sie von Menschen verletzt, die man ansprechen konnte. Und Richtlinien gab es auch schon immer.

10:27 Was KI verändert, ist nicht die Art der Probleme, sondern ihre Frequenz. Deshalb reichen die alten Antworten im Kern noch — sie müssen nur konsequenter angewendet werden. So arbeitet das Team heute, und das ist bewusst unspektakulär: Branch von main, lokal entwickeln, Tests schreiben, Stilregeln einhalten, committen, pushen, Pull Request, Review, Merge, Deployment.

10:50 Wenn Sie diesen Ablauf kennen — genau darum geht es. Er bleibt nämlich bestehen. Wir schaffen nichts davon ab und ersetzen nichts. KI kommt an genau einer Stelle hinzu, nämlich beim Schreiben des Codes vor dem Commit. Alles, was wir in den nächsten Modulen tun, verstärkt diesen vorhandenen Prozess an den Stellen, an denen er dem neuen Tempo nicht mehr standhält.

11:13 Diese Tabelle ist der Bauplan des Seminars. Links steht, was das Team umtreibt, rechts, womit Git antwortet — und die Reihenfolge der Module folgt genau dieser Liste. Das ist mehr als eine Ordnungshilfe: Es ist ein Prüfstein. Wenn Sie am Ende eines Moduls nicht sagen können, welche Sorge es adressiert hat, war es entweder schlecht erklärt oder überflüssig. Sie dürfen mich daran messen.

11:36 Und Sie dürfen dasselbe für Ihre eigene Liste tun — jede Maßnahme, die Sie einführen, sollte einer konkreten Sorge zuzuordnen sein. Sonst pflegen Sie bald Konfiguration, die niemand mehr begründen kann. So sieht der Alltag am Beispielprojekt aus: ein Branch, ein Agent, der den Code erzeugt, ein Commit, ein Push. Vier Zeilen, die Sie hundertfach so schreiben.

11:58 Wichtig ist nur, was hier nicht steht: keine Prüfung, keine Vorlage, keine Kennzeichnung, dass hier eine Maschine mitgeschrieben hat. Genau in diese Lücken setzen wir in den nächsten Modulen etwas hinein. Übrigens: Es handelt sich um eine schlanke Node-Anwendung, aber Sie brauchen davon nichts zu verstehen. Wir sehen uns Commits an, keine Geschäftslogik.

12:20 Jetzt sind Sie dran. Gehen Sie die fünf Sorgen durch und prüfen Sie für Ihr eigenes Umfeld: Trifft das zu? Und wenn ja, wie dringend? Wichtig dabei — ein "Nein" ist ein vollwertiges Ergebnis, solange Sie es begründen können. Vielleicht arbeiten Sie allein, dann ist Parallelität kein Thema. Vielleicht gibt es bei Ihnen noch keine KI-Richtlinie, dann verschiebt sich Modul fünf nach hinten. Am Ende sollten Sie sagen können, wo bei Ihnen der größte Handlungsdruck liegt.

12:48 Das ist die Maßnahme, mit der Sie nach dem Seminar anfangen. Zum Abschluss dieses Kapitels vier Fallen, die weniger mit Technik zu tun haben als mit Haltung. Maßnahmen eines fremden Beispiels ungeprüft übernehmen — das führt zu Konfiguration ohne Überzeugung. Generierten Code milder beurteilen als handgeschriebenen; das passiert häufiger, als man zugibt, weil niemand sich angegriffen fühlt.

13:13 Governance aufschieben, bis die Richtlinie fertig ist — sie wird nie fertig. Und der subtilste: Guardrails als Misstrauen zu verkaufen. Sie sind das Gegenteil. Sie sind das, was es erlaubt, dem Agenten überhaupt etwas anzuvertrauen.

Modul 1 geschafft

13:27 Halten wir fest: Der Weg vom Prompt zur Produktion ist eine Kette mit vier Stellen, an denen Git eingreifen kann — vorbeugend über die Anweisungsdatei, ordnend über die Commit-Vorlage, prüfend über den Hook und verbindlich über den Branch-Schutz. Nordlicht Outdoor begleitet uns durch alle weiteren Module, und die Reihenfolge dieser Module folgt den Sorgen des Kunden.

13:47 Im nächsten Modul wird es handfest: Wir nehmen uns die Historie vor, finden mit bisect den Commit, der einen Fehler eingeschleppt hat, und machen aus fünf nichtssagenden Einträgen einen brauchbaren.