Codex im Softwareprojekt

Codex im Softwareprojekt

0:00 Demonstrationen von Coding-Agenten laufen fast immer auf der grünen Wiese: ein leeres Verzeichnis, eine überschaubare Aufgabe, ein beeindruckendes Ergebnis. Ihr Arbeitsalltag sieht anders aus. Da gibt es gewachsenen Code mit Geschichte, Altlasten mit guten Gründen und Tests, die aus verschiedenen Epochen stammen. Genau darum geht es in diesem Modul.

0:20 Wir sehen uns an, wie sich agentische Arbeit in einem echten Projekt schlägt — beim Einlesen, beim Feature, bei der Fehlersuche, beim Refactoring. Und wir klären, wann es klüger ist, abzubrechen und selbst zu schreiben.

Codex im echten Softwareprojekt

0:34 Der zweite Tag wird praktisch. Acht Kapitel führen durch die Arbeit, die tatsächlich anfällt: ein fremdes Projekt verstehen, ein Feature bauen, einen Fehler finden, refaktorieren, Tests erzeugen, querschnittliche Änderungen durchziehen, Ergebnisse prüfen und iterieren. Durchgehendes Beispiel ist unser Buchungsdienst kanuverleih — diesmal als gewachsenes Projekt gedacht, mit allem, was dazugehört.

0:57 Der rote Faden durch alle acht Kapitel lautet: Belege verlangen statt Plausibilität akzeptieren.

Bestehende Projekte analysieren

1:03 Beginnen wir da, wo jede Arbeit an fremdem Code beginnt: bei der Orientierung. Ein Agent kann sich erstaunlich schnell in ein Projekt einlesen und Ihnen erklären, wie es aufgebaut ist. Die Frage ist nur, wie viel davon Sie glauben dürfen. Sehen wir uns an, wie man eine Analyse so anlegt, dass ihr Ergebnis überprüfbar ist — und was man anschließend damit macht.

1:25 Vor jeder Änderung an fremdem Code steht die Orientierung: Wie ist das Projekt geschnitten, wo liegt die Fachlogik, wie wird gebaut und getestet, welche Bereiche sind heikel. Der Agent kann das erheben — bewerten müssen Sie. Der Unterschied ist wichtig. Erheben heißt: Dateien lesen, Zusammenhänge auflisten, Auffälligkeiten benennen.

1:45 Das kann er schnell und gründlich. Bewerten heißt: einschätzen, ob eine Auffälligkeit ein Problem ist oder eine bewusste Entscheidung. Dazu braucht es Kontext, den kein Repository enthält. Fünf Schritte für den Einstieg. Aufbau und Einstiegspunkte beschreiben lassen. Die Bau- und Testbefehle ermitteln — und selbst ausprobieren, nicht nur notieren.

2:07 Die drei wichtigsten Datenflüsse nachzeichnen lassen. Auffälligkeiten und Altlasten benennen lassen. Und dann Schritt fünf, der aus einer einmaligen Analyse dauerhaften Nutzen macht: die Erkenntnisse in die AGENTS.md überführen. Ohne diesen Schritt wiederholt sich die Analyse in jeder Session — und Sie zahlen jedes Mal dieselbe Rechenzeit für dasselbe Ergebnis.

2:29 Vier Zeilen für unser Beispielprojekt: Aufbau beschreiben, einen Datenfluss nachzeichnen, riskante Stellen benennen — und dann die entscheidende vierte Zeile: nichts ändern, alles mit Dateipfaden belegen. Der zweite Teil ist der Kniff. Eine Analyse ohne Dateiverweise klingt gut und lässt sich nicht nachprüfen. Mit Verweisen können Sie stichprobenartig zwei Dateien öffnen und sehen, ob die Beschreibung stimmt.

2:52 Das dauert zwei Minuten und ist der Unterschied zwischen Information und Vermutung. Der erste Punkt ist der wichtigste dieses Kapitels: Eine flüssige Beschreibung ist noch kein Beleg. Sprachmodelle sind gut darin, plausibel zu klingen — auch dann, wenn sie etwas zusammensetzen. Der zweite ist tückisch: Der Agent beschreibt gern das Ideal statt den Bestand, weil er Millionen sauber strukturierter Projekte gesehen hat.

3:18 Der dritte folgt daraus: Ohne Dateiverweise lässt sich nichts nachprüfen. Und der vierte ist eine Grenze, die bleibt: Altlasten erkennt er, ihre Gründe kennt er nicht.

Neue Features implementieren

3:28 Kommen wir zum Kernstück der täglichen Arbeit: ein neues Feature bauen. Hier zeigt sich schnell, ob die Vorarbeit aus den ersten Modulen sitzt — denn die Frage ist weniger, ob der Agent es kann, sondern wie Sie die Arbeit so schneiden, dass Sie das Ergebnis auch bewerten können. Sehen wir uns an, wie ein Feature in prüfbaren Portionen entsteht.

3:48 Ein Feature entsteht am verlässlichsten in Schnitten, die einzeln lauffähig sind: erst das Verhalten mit Test, dann die Anbindung, dann die Ränder — Dokumentation, Fehlerfälle, Konfiguration. Diese Reihenfolge ist kein Zufall. Sie beginnt mit dem Teil, der fachlich entscheidbar ist, und endet mit dem, der mechanisch ist.

4:06 Wenn unterwegs etwas grundsätzlich falsch läuft, merken Sie es also früh — und nicht erst, wenn schon Dokumentation und Konfiguration an der falschen Lösung hängen. Vier Zeilen, die Ihnen inzwischen vertraut sein sollten: Ziel, Kontext, Ergebnis, Grenzen. Hier geht es um eine Gruppenrabattierung in unserem Buchungsdienst.

4:26 Beachten Sie die Grenzen: kein neues Paket, die Schnittstelle nach außen bleibt unverändert. Beides sind typische Einschränkungen, die ein Agent von sich aus nicht kennt — er würde vielleicht eine praktische Bibliothek einbinden, weil sie das Problem elegant löst. Und die Fußzeile macht den Schnitt deutlich: Das ist ein Auftrag, die Anbindung an die API kommt als eigener.

4:48 Vier Gründe für das Schneiden. Jeder Schnitt ist einzeln prüfbar und rückholbar. Fehler zeigen sich früh und lokal, statt am Ende in einem großen Diff. Das Review bleibt in überschaubarer Größe — und damit überhaupt ein Review. Und ein Abbruch kostet nur den letzten Schnitt, nicht die ganze Arbeit. Der letzte Punkt ist der, der die Arbeitsweise entspannt macht: Wenn ein Versuch scheitert, verlieren Sie zwanzig Minuten.

5:13 Bei einem Rundumschlag verlieren Sie den Nachmittag — und stehen unter Druck, das Ergebnis trotzdem zu nehmen. Das Erfolgskriterium ist hier bewusst mechanisch: mindestens drei Commits, nach jedem laufen Build und Tests fehlerfrei. Der Hinweis nennt den nützlichsten Prüfstein für Ihre eigene Schnittführung: Wenn sich ein Schnitt nicht testen lässt, ist er falsch geschnitten.

5:36 Das ist eine harte Regel, aber sie funktioniert. Ein Schnitt, der nur eine halbe Funktion enthält, hat kein prüfbares Verhalten — also gehört er entweder mit dem nächsten zusammen oder er ist anders zu ziehen.

Fehler systematisch untersuchen

5:48 Jetzt zu der Tätigkeit, bei der Agenten am spektakulärsten glänzen und am spektakulärsten scheitern: der Fehlersuche. Der Unterschied zwischen beiden Fällen liegt an einer einzigen Voraussetzung, und die hat mit dem Modell nichts zu tun. Sehen wir uns an, welche das ist und wie eine Fehlersuche abläuft, die am Ende belastbare Ergebnisse liefert statt einer plausiblen Vermutung.

6:09 Es ist derselbe Unterschied wie zwischen einer Diagnose und einem Verdacht. Fehlersuche mit einem Agenten scheitert oder gelingt an einem Punkt: der Reproduktion. Ohne einen Weg, den Fehler auszulösen, rät der Agent — mit ihm kann er messen, eingrenzen und die Ursache belegen. Das ist derselbe Unterschied wie in der Werkstatt.

6:29 Ein Geräusch, das der Kunde beschreibt, führt zu Vermutungen. Ein Geräusch, das sich auf der Hebebühne reproduzieren lässt, führt zur Ursache. Der Agent hat hier sogar einen Vorteil gegenüber dem Menschen: Er wird beim hundertsten Reproduktionsversuch nicht ungeduldig. Fünf Schritte, und der erste trägt die anderen vier. Den Fehler reproduzierbar machen, notfalls als Test.

6:51 Beobachtung und Erwartung getrennt beschreiben — das klingt pedantisch, deckt aber oft schon das Missverständnis auf. Eingrenzen lassen, ohne Korrektur zu erlauben. Die Ursache erklären lassen und die Erklärung prüfen. Und erst dann beheben, mit einem Test gegen den Rückfall. Die Fußzeile schließt den Kreis: Der Test aus Schritt eins ist am Ende der Nachweis, dass der Fehler wirklich weg ist — nicht nur heute nicht mehr sichtbar.

7:18 Diese Tabelle stellt vier Zeilen gegenüber, aber es geht um eine einzige Sache: ob Sie über Belege reden oder über Meinungen. Ohne Reproduktion bekommen Sie plausible Vermutungen und Änderungen auf Verdacht — und der Fehler kommt später wieder. Mit Reproduktion bekommen Sie messbare Aussagen, Änderungen mit Nachweis und einen Test, der ihn fernhält.

7:38 Die Fußzeile benennt die eigentlichen Kosten: Der teuerste Bug ist der, der nach der Behebung erneut auftritt. Denn dann sucht ihn jemand ein zweites Mal — und glaubt beim dritten Mal niemandem mehr. Der erste Punkt ist die schärfste Formulierung dieses Kapitels: Behoben ohne Test heißt nur, heute nicht mehr sichtbar. Der zweite betrifft eine typische Schwäche — der Agent findet gern die erste Ursache, nicht die eigentliche; er hört auf, sobald das Symptom verschwindet.

8:06 Der dritte ist die logische Folge: Symptombehandlung wirkt schnell und hält kurz. Und der vierte ist ein praktischer Hinweis für die Analyse: Logs ohne Zeitbezug führen in die Irre, weil man Ursache und Wirkung vertauscht.

Refactoring delegieren

8:19 Refactoring ist die Aufgabe, bei der sich Delegation am stärksten auszahlt — und zugleich die, bei der die Regeln am klarsten sein müssen. Denn es gibt genau eine Bedingung, und die ist unverhandelbar. Sehen wir uns an, welche Bedingung das ist, wofür sich Delegation besonders eignet und woran ein Refactoring- Auftrag regelmäßig scheitert, noch bevor er überhaupt begonnen hat.

8:40 Die Antwort auf alle drei Fragen hat mit Tests zu tun. Refactoring ändert die Struktur, nicht das Verhalten. Für einen Agenten heißt das: Es muss vorher einen Test geben, der das Verhalten festhält — sonst ist die Einhaltung der Regel nicht überprüfbar. Ohne Test ist das, was Sie tun, kein Refactoring, sondern Umschreiben mit unbekanntem Ausgang.

9:01 Das gilt für Menschen genauso, nur merken Menschen manchmal beim Umbau, dass sich etwas ändert. Ein Agent merkt es nicht — er sieht keinen Unterschied zwischen einer Strukturänderung und einer Verhaltensänderung, wenn ihn nichts darauf stößt. Vier Kategorien, in denen sich Delegation besonders lohnt. Mechanische, wiederholte Umbauten über viele Dateien — genau die Arbeit, die Menschen ermüdet und deshalb fehleranfällig macht. Benennungen konsistent ziehen.

9:29 Duplikate zusammenführen, die niemand freiwillig sucht. Und tote Pfade finden und entfernen. Was diese vier verbindet: Sie sind konzeptuell einfach und im Umfang lästig. Genau das ist das Profil, bei dem ein Agent seine Stärke ausspielt, ohne dass Sie viel prüfen müssen — vorausgesetzt, die Tests stehen. Vier Zeilen für unser Beispiel: die Preisberechnung aus der API-Schicht in die Fachlogik ziehen. Die entscheidende Zeile ist die zweite — Verhalten unverändert, Tests unverändert.

9:59 Der zweite Teil ist die schärfere Bedingung, und die Fußzeile erklärt, warum: Sie verbietet das Anpassen der Messlatte. Ohne diese Einschränkung kann ein Agent, der einen Test rot bekommt, ihn anpassen und melden, dass alles grün ist. Formal hat er recht. Nur haben Sie dann kein Refactoring, sondern eine unbemerkte Verhaltensänderung.

10:20 Der erste Punkt fasst das Kapitel zusammen: Ohne Test vorher ist Refactoring nur Umschreiben. Der zweite ist die eben besprochene Falle mit angepassten Tests. Der dritte betrifft die Größe — große Umbauten in einem Diff sind nicht reviewbar, und gerade bei Refactorings entstehen sehr schnell sehr große Diffs. Und der vierte ist eine Disziplinfrage, die sich rächt: Refactoring und Feature im selben Commit zu vermischen macht beides unprüfbar.

10:46 Man sieht dann nicht mehr, welche Änderung Absicht war.

Tests erzeugen und ausführen

10:50 Ein Agent kann Tests schreiben, und er tut es schnell. Die interessante Frage ist, ob diese Tests etwas prüfen — oder nur die Implementierung nachzeichnen, die gerade entstanden ist. Der Unterschied ist entscheidend, denn im zweiten Fall bekommen Sie grüne Balken ohne Aussagekraft. Sehen wir uns an, woran man das erkennt und wie man es verhindert.

11:10 Tests sind für den Agenten Rückmeldung und Abnahmekriterium zugleich. Damit das trägt, müssen sie das gewünschte Verhalten prüfen und nicht die vorhandene Implementierung nachzeichnen. Genau hier liegt die Schwierigkeit: Wenn ein Agent Tests zu bereits geschriebenem Code erzeugt, liegt es nahe, dass er beschreibt, was der Code tut — nicht, was er tun soll.

11:30 Solche Tests sind immer grün und brechen bei jeder Umstrukturierung. Sie kosten also Pflegeaufwand, ohne Sicherheit zu geben. Der Unterschied wird an den Beispielen greifbar. Links prüft ein Test Verhalten: Rabatt ab fünf Personen greift, Storno nach 48 Stunden wird abgelehnt, der Fehlerfall liefert eine Meldung. Rechts zeichnet ein Test Code nach: eine Methode wird einmal aufgerufen, eine interne Konstante ist gesetzt, die Reihenfolge der Aufrufe stimmt.

11:58 Die Fußzeile bringt das Problem auf den Punkt: Der rechte Test bricht bei jedem Refactoring — und schützt trotzdem vor nichts. Er ist also doppelt schädlich, weil er Arbeit macht und Sicherheit vortäuscht. Fünf Schritte, deren dritter der wichtigste ist. Das zu prüfende Verhalten benennen, nicht die Umsetzung. Grenzfälle ausdrücklich mitgeben, sonst werden sie vergessen.

12:21 Den Test zuerst schreiben lassen und rot laufen sehen. Dann die Umsetzung beauftragen, bis der Test grün ist. Und den Testinhalt selbst lesen, nicht nur die Farbe. Die Fußzeile erklärt Schritt drei: Ein Test, der nie rot war, beweist nichts. Er könnte auch dann grün sein, wenn er das Falsche prüft oder gar nichts. Das Erfolgskriterium hat eine Bedingung, die leicht überlesen wird: Der Test läuft danach grün, ohne dass er angepasst wurde.

12:49 Genau daran scheitert der Versuch häufig — und das ist eine wertvolle Beobachtung. Der Hinweis fügt die zweite Prüfung hinzu: Lesen Sie den erzeugten Test. Prüft er wirklich das Verhalten oder nur den Aufruf? Diese Frage werden Sie sich nach dieser Übung bei jedem erzeugten Test stellen — und das ist der eigentliche Zweck.

Änderungen über mehrere Dateien

13:09 Jetzt kommen wir zu der Aufgabe, bei der Agentenarbeit am deutlichsten überlegen ist: Änderungen quer durch ein ganzes Projekt. Für Menschen ist das mühsam und fehleranfällig, für einen Agenten Routine. Aber es gibt eine Falle, und die hat mit der Vollständigkeit zu tun — genauer damit, wie man sie am Ende überhaupt noch überprüfen kann.

13:28 Sehen wir uns an, wie man sie umgeht, ohne vierzig Dateien einzeln zu lesen. Änderungen quer durch ein Projekt — eine Signatur, ein Namensschema, eine Schnittstelle — sind mechanisch, aber weitläufig. Genau hier spielt ein Agent seine Stärke aus, wenn Umfang und Prüfung geklärt sind. Der Vorteil ist real: Er wird bei Datei vierzig genauso sorgfältig sein wie bei Datei eins.

13:51 Das Problem verschiebt sich damit vom Durchführen zum Prüfen. Denn ein Diff über vierzig Dateien liest niemand Zeile für Zeile — und genau darauf muss die Arbeitsweise Rücksicht nehmen. Fünf Schritte mit einem klugen Trick am Anfang. Alle betroffenen Stellen zuerst auflisten lassen. Die Liste prüfen und Ausnahmen benennen.

14:10 In einem Durchgang ändern, nicht Datei für Datei. Build und Tests über das ganze Projekt laufen lassen. Und das Diff nach Mustern durchsehen statt Zeile für Zeile. Die Fußzeile nennt den Trick: Die Liste aus Schritt eins ist zugleich die Prüfliste am Ende. Sie müssen also nicht vierzig Dateien lesen — Sie müssen prüfen, ob die vierzig Stellen aus der Liste erledigt sind.

14:33 Der erste Punkt betrifft die klassischen Vergessensstellen: Konfiguration, Dokumentation, Tests. Der zweite ist technisch und wichtig — Zeichenketten und dynamische Zugriffe findet keine Suche. Wenn ein Name irgendwo als String zusammengesetzt wird, bleibt er stehen. Der dritte ist die schon erwähnte Realität großer Diffs.

14:52 Und der vierte beschreibt das schlechteste aller Ergebnisse: Teilweise durchgeführte Umbenennungen sind schlimmer als keine, weil das Projekt danach in zwei Zuständen gleichzeitig ist. Bei dieser Übung geht es um Vollständigkeit, nicht um Geschwindigkeit. Erstellen Sie vorab die Liste, arbeiten Sie sie ab, lassen Sie Build und Tests laufen.

15:13 Und dann kommt der Hinweis, den Sie sich merken sollten: Suchen Sie am Ende selbst nach dem alten Namen — auch in Kommentaren und Konfiguration. Diese eine Suche findet regelmäßig die drei Stellen, die keine automatische Erhebung erfasst hat. Sie kostet eine halbe Minute und ist der Unterschied zwischen fertig und fast fertig.

Codeänderungen kritisch prüfen

15:32 Wir kommen zu dem Teil, der über die Qualität am meisten entscheidet und im Alltag am ehesten leidet: dem Prüfen. Ein Agent liefert schnell, und Geschwindigkeit erzeugt Druck, mitzuhalten. Sehen wir uns an, worauf sich der Blick wirklich lohnt und welche Muster im Diff Sie stutzig machen sollten — auch und gerade dann, wenn die Erklärung daneben überzeugend klingt.

15:53 Denn genau darin sind Sprachmodelle besonders gut. Prüfen heißt, das Diff gegen die Absicht zu halten: Ist das gefordert worden? Ist etwas mitgeändert worden, das niemand verlangt hat? Ist die Begründung tragfähig oder nur flüssig formuliert? Der letzte Punkt ist der schwierigste, weil Sprachmodelle ausgesprochen gut darin sind, überzeugend zu klingen.

16:14 Eine Erklärung, die schlüssig ist, kann trotzdem nicht beschreiben, was der Code tatsächlich tut. Deshalb gilt: Die Quelle ist das Diff, nicht der Text daneben. Vier Muster, nach denen Sie gezielt suchen sollten. Änderungen außerhalb des Auftrags — das ist der schnellste Prüfschritt: Passt jede geänderte Datei zum Auftrag?

16:35 Stillschweigend entfernte Prüfungen und Sonderfälle; die verschwinden gern, weil sie im Weg standen. Neue Abhängigkeiten und stille Standardwerte. Und angepasste Tests statt angepassten Codes. Wenn Sie nur eine Minute haben, prüfen Sie diese vier — sie decken den Großteil dessen ab, was in der Praxis schiefgeht. Vier Handgriffe vor dem Commit: die Änderungen ansehen, sich Hinweise vom Agenten holen, selbst die Tests laufen lassen und bewusst einzeln übernehmen.

17:03 Die Fußzeile formuliert die Arbeitsteilung: Das eigene Testkommando ersetzt keine Durchsicht, und die Durchsicht keinen Testlauf. Beides prüft Verschiedenes. Der Testlauf findet, was kaputt ist. Die Durchsicht findet, was ungefragt hinzugekommen ist — und davon merken Tests naturgemäß nichts, denn neuer Code bricht keine vorhandenen Tests.

17:24 Der erste Punkt ist der menschlichste: Zustimmen, weil die Erklärung überzeugend klingt. Der zweite ist eine Frage des Umfangs — große Diffs am Stück durchzuwinken ist keine Entscheidung, sondern deren Vermeidung. Der dritte ist praktisch und lästig: Formatierungsrauschen verdeckt die eigentliche Änderung; deshalb sollten Formatierung und Inhalt nie im selben Commit stehen.

17:45 Und der vierte ist die Wiederholung des Kernsatzes: Die Erklärung des Agenten ist nicht der Code.

Iterativ verbessern

17:51 Zum Abschluss die Frage, die im Alltag am meisten Zeit kostet: Was tun, wenn das Ergebnis nicht passt? Nachschärfen, neu ansetzen — oder aufhören? Es gibt für alle drei den richtigen Moment, und ihn zu erkennen ist eine Fähigkeit, die man mit der Zeit entwickelt. Sehen wir uns die Anzeichen an, an denen sich die drei Fälle unterscheiden lassen — bevor der Nachmittag weg ist.

18:14 Iteration heißt: gezielt das eine ändern, was nicht passt, im selben Kontext. Das ist etwas anderes, als denselben Auftrag erneut zu stellen und auf ein besseres Los zu hoffen. Der zweite Weg ist verlockend, weil er so wenig Arbeit macht — man drückt einfach noch mal. Aber ein Modell, das beim ersten Mal die Aufgabe missverstanden hat, versteht sie beim zweiten Mal mit derselben Formulierung genauso.

18:38 Was sich ändert, ist der Zufall, nicht das Verständnis. Vier Situationen und je eine passende Antwort. Fast richtig, ein Detail stört? Gezielt nachschärfen. Der Ansatz ist grundsätzlich falsch? Verwerfen und neu planen — nicht am falschen Ansatz herumbessern. Der Kontext ist verworren? Eine neue Session mit klarem Auftrag.

18:59 Und die vierte Zeile: Beim dritten gescheiterten Versuch selbst schreiben. Die Fußzeile betont, dass das ernst gemeint ist. Nicht jede Aufgabe ist eine Agentenaufgabe, und das einzugestehen ist keine Niederlage, sondern eine Kostenrechnung. Vier Anzeichen. Dieselbe Fehlerklasse kehrt mehrfach zurück — das deutet auf ein strukturelles Missverständnis hin, kein Formulierungsproblem.

19:24 Jede Korrektur bricht etwas anderes; dann fehlt dem Agenten das Gesamtbild. Die Erklärungen werden allgemeiner statt genauer, ein zuverlässiges Zeichen dafür, dass er sich im Kreis dreht. Und der praktischste Indikator: Der Aufwand fürs Prüfen übersteigt den fürs Schreiben. Spätestens dann ist die Rechnung eindeutig. Diese Aufgabe klingt paradox — man soll das Scheitern üben. Der Punkt ist die Dokumentation: Was war der Grund für den Abbruch, und was blieb aus dem Versuch verwertbar?

19:55 Denn der Hinweis stimmt: Auch ein Abbruch hinterlässt Wert, meist die Analyse und die Tests. Beides können Sie behalten und selbst weiterverwenden. Wer das ein paarmal erlebt hat, bricht früher ab — und verliert dadurch insgesamt weniger Zeit als jemand, der aus Prinzip weitermacht. Vier Punkte zum Mitnehmen. Eine Analyse ohne Dateiverweise ist plausibel, aber nicht nachprüfbar — verlangen Sie Belege.

20:19 Ohne Reproduktion rät der Agent bei der Fehlersuche, egal wie stark das Modell ist. Refactoring braucht Tests, die vorher da waren und unverändert bleiben. Und Iterieren heißt gezielt nachschärfen — mit der Bereitschaft, rechtzeitig abzubrechen. Im nächsten Modul sichern wir das alles ab: Git, Sessions und die Frage, wie mehrere Aufgaben gleichzeitig laufen können, ohne sich in die Quere zu kommen.