Agentische Entwicklung mit Next.js

Agentische Entwicklung mit Next.js

0:00 Zum Abschluss ein Modul über die Art, wie Software heute entsteht. Ein wachsender Teil des Codes wird nicht mehr getippt, sondern mit einem Assistenten erzeugt — und für Next.js ist das aus einem bestimmten Grund heikler als für andere Technologien. Ich möchte Ihnen dabei nichts verkaufen und nichts schlechtreden. Es geht um eine nüchterne Frage: Wo trägt diese Arbeitsweise, wo nicht, und woran erkennen Sie den Unterschied?

0:23 Sie werden merken, dass die Antwort weniger mit KI zu tun hat als mit allem, was Sie in den letzten dreizehn Modulen gelernt haben.

Warum dieses Modul dazugehört

0:31 Beginnen wir mit dem Grund, warum dieses Thema in ein Next.js-Seminar gehört und nicht in einen allgemeinen KI-Kurs. Es gibt nämlich eine spezifische Schwierigkeit, und die hat mit der Geschwindigkeit zu tun, mit der sich dieses Framework bewegt. Wer die kennt, kann gegensteuern. Wer sie nicht kennt, bekommt plausiblen Code aus dem Jahr davor.

0:51 Das Problem ist strukturell: Ein Assistent kennt das, was zum Zeitpunkt seines Trainings verbreitet war. Und für Next.js ist das eine andere Welt als die, in der wir arbeiten. Pages Router, die alten Datenlademethoden, das frühere Caching-Modell — all das war jahrelang der Standard und steht deshalb zehntausendfach im Netz.

1:10 Der Assistent schlägt es also nicht aus Unwissenheit vor, sondern weil es lange richtig war. Das macht die Sache tückischer, denn der Vorschlag ist gut formuliert und funktioniert sogar. Sehen Sie sich die linke Spalte an — jede dieser Zeilen haben wir in diesem Seminar besprochen. Der Router aus Modul zwei, die Datei aus Modul acht, das Caching aus Modul sechs, der Datenzugriff aus Modul fünf.

1:33 Und der Satz unter der Tabelle ist der entscheidende: Alle vier sind plausibel formuliert und alle vier sind falsch. Sie werden nicht durch eine Fehlermeldung auffallen. Der Code kompiliert, die Seite lädt, die Tests laufen. Nur ist die Architektur eine von gestern — und das merkt niemand, der das Framework nicht kennt.

1:53 Der vierte Punkt ist die eigentliche Kostenrechnung: Die Korrektur später ist eine Migration, kein Refactoring. Wenn ein Projekt drei Monate lang mit dem alten Router gebaut wurde, kostet der Wechsel Wochen — und niemand hat dafür Budget, weil ja alles funktioniert. Der dritte Punkt beschreibt, wie es so weit kommt: Ein so gebautes Projekt trägt die alte Architektur von Anfang an, weil die erste generierte Datei den Ton setzt und alle folgenden sich daran orientieren.

2:19 Der Weg ist danach eingeschlagen. Genau deshalb lohnt sich die Gegenmaßnahme im ersten Tag.

Versionsgenaue Dokumentation für Agenten

2:25 Und hier ist die Gegenmaßnahme — überraschend einfach und seit Version 16.3 weitgehend automatisch. Der Hersteller hat das Problem erkannt und eine Lösung gebaut, die ich für eine der klügeren Ideen der letzten Releases halte. Sehen wir uns an, was da passiert und was Sie noch selbst ergänzen sollten. Next.js liefert die zur installierten Version passende Dokumentation im Paket mit — sie liegt also in Ihrem Projektordner.

2:50 Eine Datei im Wurzelverzeichnis weist Assistenten darauf hin, und seit 16.3 legt der Entwicklungsserver diesen Hinweis selbst an und hält ihn aktuell. Der Effekt: Der Assistent liest die Doku zur tatsächlich installierten Version, ohne Netzwerkzugriff und ohne dass jemand daran denken muss. Wenn Sie aktualisieren, wandert die Doku mit. Das ist eine elegante Lösung für ein Problem, das andere Frameworks noch gar nicht angehen.

3:15 Lesen Sie den Text im Block — er ist bemerkenswert direkt formuliert: Diese Version hat Bruchänderungen gegenüber deinem Trainingsstand. Der Hersteller spricht den Assistenten also unmittelbar an und sagt ihm, dass sein Wissen veraltet sein könnte. Worauf es ankommt, steht in der Fußnote: Ihre eigenen Regeln gehören außerhalb der Markierungen, dort bleiben sie erhalten.

3:36 Der Block dazwischen wird bei jedem Start neu geschrieben — Sie können ihn also nicht sinnvoll bearbeiten, nur ergänzen. Der rote Faden ist eine Arbeitsteilung: Das Framework kümmert sich um sein eigenes Wissen, Sie kümmern sich um Ihres. Die Schritte drei und vier sind der eigentliche Gewinn — dort schreiben Sie auf, was kein Assistent wissen kann. Dass die Domäne Hafenmeister heißt und was ein Liegeplatz ist.

4:00 Dass jeder Datenbankzugriff durch den Zugriffs-Layer geht. Dass die Migrationsdateien nicht angefasst werden. Schritt fünf ist ein praktischer Hinweis, der Ärger spart: Den Block mitcommitten, sonst taucht er in jedem Diff wieder auf. Der erste Punkt fasst zusammen, was ohne diese Einrichtung passiert: Der Assistent greift auf seinen Trainingsstand zurück, und den haben wir uns eben angesehen.

4:24 Der zweite ist eine Beobachtung aus dem Alltag, die manche irritiert: Der Block wird bei jedem Start neu geschrieben. Wer ihn aus einem Diff löscht, hat ihn beim nächsten Start wieder — das ist kein Fehler, sondern Absicht. Und der dritte ist ein Hinweis für ältere Projekte: Auf Version 16.2 liegt die Doku zwar bei, wird aber nicht automatisch verlinkt. Dort legen Sie die Datei selbst an.

Ein Vorhaben planen statt drauflos generieren

4:47 Jetzt zu dem Punkt, an dem sich gute von schlechter agentischer Arbeit unterscheidet — und es ist nicht die Formulierung der Anweisung. Es ist die Frage, was vor der ersten Zeile Code passiert. Ich zeige Ihnen das an einer konkreten Erweiterung unseres Portals, die klein genug ist, um sie im Kopf zu behalten. Vor der ersten Zeile steht die Zerlegung: Welche Routen sind betroffen, welche Daten werden gebraucht, wo verläuft die Grenze zwischen Server und Client, was bedeutet das für Cache und Rechte?

5:15 Diese Planung gemeinsam mit dem Assistenten zu machen, ist wirkungsvoller als jede Verfeinerung der Anweisung beim Generieren. Der Grund ist einfach: Ein Plan lässt sich lesen und bestreiten. Zweihundert Zeilen erzeugter Code lassen sich das nur mühsam — und niemand tut es wirklich gründlich. Der rote Faden dieser fünf Schritte ist die Reihenfolge: Fachlichkeit vor Technik.

5:36 Schritt eins beschreibt den Ablauf in normalen Worten — ein Gast trägt sich für einen belegten Liegeplatz ein und wird benachrichtigt, wenn er frei wird. Erst danach kommen Routen, Grenzen, Cache und Rechte. Schritt vier ist der, der beim Generieren regelmäßig untergeht: Wer darf sich eintragen, wer darf die Liste sehen?

5:56 Wenn das im Plan steht, steht es später auch im Code. Wenn nicht, fehlt es meistens. Der erste Punkt ist der wichtigste: Ein Assistent trifft Architekturentscheidungen nebenbei und unsichtbar. Er entscheidet, wo die Client-Grenze liegt, ob gecacht wird, ob eine Aktion oder ein Endpunkt entsteht — und teilt Ihnen das nicht mit, weil er es nicht als Entscheidung wahrnimmt.

6:18 Im Plan werden diese Punkte ausgesprochen. Der vierte Punkt ist der praktische Gewinn: Am Plan lässt sich widersprechen, bevor Aufwand entstanden ist. Eine falsche Zeile im Plan kostet eine Minute. Dieselbe falsche Entscheidung in dreihundert Zeilen Code kostet einen Nachmittag. Die ersten beiden Punkte markieren die Grenzen nach beiden Seiten. Ein zu grober Plan verlagert alle Entscheidungen ins Generieren — dann können Sie ihn auch weglassen.

6:44 Ein zu feiner ist teurer als der Code selbst, dann tippen Sie lieber gleich. Die richtige Flughöhe liegt bei den Entscheidungen, nicht bei den Anweisungen. Der dritte Punkt ist eine organisatorische Empfehlung: Der Plan gehört ins Repository, nicht in den Chatverlauf. Denn in drei Monaten will jemand wissen, warum etwas so gebaut wurde — und der Chatverlauf ist dann weg.

Komponenten und Server-Funktionen generieren lassen

7:06 Jetzt wird generiert. Und hier zeigt sich, ob die Vorbereitung getragen hat. Ich gebe Ihnen dafür keine Liste guter Anweisungen mit, sondern etwas Nützlicheres: die vier Stellen, an denen Assistenten bei Next.js typischerweise danebenliegen. Wenn Sie gezielt dort hinsehen, finden Sie die meisten Probleme in Minuten. Die Empfehlung lautet: kleine Schritte, jeder geprüft.

7:28 Das klingt langsamer und ist im Ergebnis schneller, weil ein Fehler in fünfzig Zeilen leicht zu finden ist und in fünfhundert nicht. Und weil ein Fehler, der drei Generationen lang mitgeschleppt wurde, inzwischen an vier Stellen steht. Prüfen Sie nach jedem Schritt und achten Sie dabei besonders auf die vier Stellen, die wir uns gleich ansehen — die sind nicht zufällig gewählt.

7:50 Sehen Sie sich die rechte Spalte an: Modul vier, sieben, sechs, elf. Jeder dieser typischen Fehler ist ein Thema aus diesem Seminar. Das ist kein Zufall — es sind genau die Punkte, an denen Next.js von der Intuition abweicht, und deshalb auch die, an denen ein Assistent auf sein altes Wissen zurückfällt. Die Client-Grenze zu weit oben, weil das früher normal war. Kein Cache-Tag, weil es früher automatisch ging. Keine Besitzprüfung, weil sie in Beispielen selten steht.

8:19 Und keine Validierung, weil das Formular ja prüft. Hier ist meine eigentliche Botschaft für dieses Modul. Prüfen kann nur, wer weiß, wie es richtig aussieht. Die vier Fehler von eben erkennen Sie nicht, wenn Sie die Module davor nicht gehört haben — sie sehen völlig unauffällig aus. Der dritte Punkt formuliert das allgemeiner: Der Assistent beschleunigt das Schreiben, nicht das Urteilen.

8:43 Und wenn das Urteilen der Engpass ist, hilft schnelleres Schreiben nicht, sondern verschärft das Problem. Deshalb steht dieses Modul am Ende und nicht am Anfang — es ist ein Aufbaumodul, kein Einstieg. Der erste Punkt ist der Satz, den ich Ihnen aus diesem Kapitel mitgeben möchte: Generierter Code, der läuft, ist damit nicht richtig.

9:03 Das gilt für getippten Code genauso, nur tippt niemand dreihundert Zeilen in zwanzig Sekunden. Der dritte Punkt betrifft eine Versuchung, die groß ist: Ein Assistent, der sich selbst bestätigt, ersetzt keine zweite Meinung. Wenn Sie fragen, ob der Code gut ist, bekommen Sie fast immer ein Ja. Fragen Sie stattdessen, was daran schiefgehen kann — die Antworten sind deutlich brauchbarer.

Tests agentengestützt erstellen

9:26 Jetzt zu der Aufgabe, für die sich diese Arbeitsweise am besten eignet. Tests haben eine Eigenschaft, die sie ideal macht: Der Sollzustand lässt sich beschreiben, und das Ergebnis ist sofort überprüfbar. Es gibt allerdings eine Bedingung, ohne die der ganze Gewinn verschwindet — und die kostet Sie zwei Minuten je Test. Wir lassen zwei Sorten Tests erzeugen: Einheitentests für den Zugriffs-Layer und einen Durchstich für die Warteliste.

9:52 Beides ist gut beschreibbar — Sie sagen, welche Zusage geprüft werden soll, und bekommen einen Test. Und Sie sehen sofort, ob er läuft. Das ist eine bessere Rückkopplung als bei fast jeder anderen Aufgabe. Trotzdem gilt auch hier: Ein grüner Test ist erst dann ein Beleg, wenn Sie wissen, dass er überhaupt rot werden kann.

10:12 Die Schritte zwei und drei sind der ganze Inhalt dieser Folie: Entfernen Sie versuchsweise die Prüfung, die der Test absichern soll, und sehen Sie nach, ob er rot wird. Wenn nicht, ist er Dekoration. Das kostet zwei Minuten und ist der einzige Weg, das festzustellen — ansehen genügt nicht, weil ein Test durchaus richtig aussehen und trotzdem nichts prüfen kann.

10:32 Schritt eins ist die Vorstufe dazu: Wenn Sie die geprüfte Zusage nicht in einem Satz benennen können, prüft der Test vermutlich nichts Bestimmtes. Der zweite Punkt ist eine Beobachtung, die ich für verlässlich halte: Assistenten neigen dazu, den positiven Fall zu prüfen und den negativen wegzulassen. Das ist verständlich — der positive Fall steht im Plan, der negative ist die Abwesenheit von etwas. Nur ist der negative der wertvolle, wie wir in Modul zwölf gesehen haben.

11:01 Fragen Sie also ausdrücklich danach. Der dritte Punkt ist ähnlich: Erzeugte Testdaten sind oft zu freundlich. Namen mit Umlauten, leere Listen, sehr lange Texte — das kommt selten von allein.

Fehler systematisch analysieren

11:13 Jetzt zur Fehlersuche, und hier hat sich in den letzten Versionen einiges getan, das gut zusammenpasst. Die kurze Regel vorweg: Ein Assistent liefert nur so gute Antworten wie die Belege, die er bekommt. Ohne Belege rät er — und zwar sehr überzeugend, was die Sache nicht besser macht. Was ein Assistent bei einer Fehlersuche braucht, ist konkret: die Fehlermeldung im Wortlaut, die betroffene Route, der Rendering-Modus und, wenn vorhanden, die Traces aus der Instrumentation.

11:42 Also genau das, was wir in Modul dreizehn eingerichtet haben. Ohne diesen Kontext beschreibt er die wahrscheinlichste Ursache für dieses Symptom im Allgemeinen — was oft danebenliegt, aber immer plausibel klingt. Das ist die unangenehmste Kombination, die es bei einer Fehlersuche gibt. Der zweite Punkt ist der bemerkenswerte: Fehlermeldungen nennen benannte Lösungswege mit ihren Abwägungen. Nicht nur, was falsch ist, sondern drei Wege heraus und was jeder kostet.

12:09 Der dritte Punkt geht noch weiter: Jede Meldung verweist auf eine Seite, die ausdrücklich für Assistenten geschrieben ist — mit den kanonischen Mustern und den Fallen, die beim ersten Versuch übersehen werden. Dass ein Hersteller seine Fehlerseiten für Maschinen mitschreibt, ist neu. Und der erste Punkt ist praktisch: Browser-Fehler landen im Terminal, wo der Assistent sie ohnehin liest.

12:31 Sehen Sie sich die drei Zeilen mit den Klammern an — das sind benannte Lösungswege, keine Vermutungen. Strömen, cachen oder ausdrücklich blockieren lassen. Alle drei sind legitim, und die Wahl hängt an Ihren Daten. Genau das ist der Punkt, den ich hervorheben möchte: Die Meldung nimmt Ihnen die Entscheidung nicht ab. Sie legt die Optionen offen.

12:51 Ein Assistent, der diese Meldung liest, kann Ihnen die drei Wege erklären — entscheiden müssen Sie, weil nur Sie wissen, wie aktuell die Belegung sein muss. Der erste Punkt ist ein praktischer Hinweis für die Fehlersuche in Produktion: Ein Produktionsbuild minimiert den Servercode, und dann steht in der Meldung nichts Brauchbares mehr.

13:11 Es gibt dafür einen eigenen Schalter, der die Zuordnung wiederherstellt. Der dritte Punkt ist eine allgemeine Warnung, die für Menschen genauso gilt wie für Assistenten: Die erste plausible Erklärung ist oft nicht die richtige. Der Unterschied ist, dass ein Mensch zögert und ein Assistent sie sofort mit Überzeugung vorträgt.

Sicherheitskritische Änderungen prüfen

13:29 Jetzt eine Regel, bei der ich keine Ausnahme kenne. Es gibt vier Stellen in einer Next.js-Anwendung, die nicht durchgewinkt werden — egal wie gut der Assistent ist und wie eilig es ist. Wir nutzen dafür die Audit-Liste aus Modul elf, die kurz genug ist, um sie tatsächlich anzuwenden. Die vier Stellen sind: Server Actions, die Proxy-Datei, Endpunkte und der Zugriffs-Layer. Das sind genau die Orte, an denen über Zugriff auf fremde Daten entschieden wird.

13:57 Für Änderungen daran gilt eine eigene Regel — sie werden gelesen, nicht überflogen. Der Assistent darf sie erzeugen, gern sogar. Aber die Abnahme ist ein eigener Arbeitsschritt mit einer eigenen Checkliste. Das ist der Unterschied zwischen Werkzeug und Verantwortung. Der rote Faden ist eine Eskalation: Schritt eins entscheidet, ob die strenge Prüfung überhaupt greift — die meisten Änderungen berühren diese vier Bereiche nicht.

14:23 Wenn doch, wird es ernst. Schritt drei verlangt einen Nachweis für jede der drei Prüfungen einzeln, nicht ein Gesamtgefühl. Schritt vier ist der, den man vergisst: Auch die Rückgabewerte gehören angesehen, nicht nur die Prüfungen. Und Schritt fünf macht die Sache dauerhaft — ein negativer Test schreibt die Zusage fest, damit sie beim nächsten Umbau nicht still verschwindet.

14:44 Der zweite Punkt ist der entscheidende und gilt für dieses ganze Modul: Ein Fehler an diesen Stellen fällt nicht durch Absturz auf, sondern gar nicht. Es gibt keinen roten Balken, keine Meldung, keinen Eintrag. Es funktioniert einfach — nur eben auch für Leute, für die es nicht funktionieren sollte. Der dritte Punkt ist die nüchterne Abwägung: Der Aufwand einer Prüfung ist klein gegen einen Meldefall.

15:07 Und der vierte ist die praktische Voraussetzung dafür, dass es überhaupt gemacht wird — die Liste ist kurz genug.

Grenzen und Qualitätskontrolle

15:14 Zum Abschluss ordnen wir ein. Nach sieben Kapiteln über den sinnvollen Einsatz gehört die Gegenfrage dazu: Wo trägt diese Arbeitsweise nicht? Ich habe dafür eine Unterscheidung, die mir brauchbarer erscheint als die üblichen Kategorien — sie hat nichts mit der Schwierigkeit der Aufgabe zu tun. Der Unterschied liegt nicht in der Schwierigkeit, sondern in zwei anderen Fragen: Ist der Sollzustand klar, und ist das Ergebnis prüfbar?

15:39 Eine schwierige Migration mit klarem Ziel ist gut geeignet. Eine einfache fachliche Entscheidung ohne klaren Sollzustand ist es nicht. Das erklärt auch, warum manche Leute begeistert sind und andere enttäuscht — sie arbeiten an verschiedenen Sorten von Aufgaben und ziehen daraus allgemeine Schlüsse. Die Unterscheidung ist nützlicher als jede pauschale Bewertung.

16:00 Die untere Zeile ist die wichtigste, und die Begründung rechts sagt warum: Fachliche Regeln zu erfinden, ist die Aufgabe, bei der Assistenten am überzeugendsten danebenliegen. Sie bekommen eine Regel, die plausibel klingt, sich gut liest und für Ihren Hafen falsch ist — weil niemand außer Ihnen weiß, wie dort Liegeplätze vergeben werden.

16:19 Die oberen drei Zeilen sind dagegen echte Gewinne, und ich möchte das nicht kleinreden: Eine Migration über zweihundert Dateien ist eine Arbeit, die niemand vermisst. Der zweite Punkt ist der, der mir Sorge macht, wenn ich in Projekte schaue: Ein Team, das nur noch abnimmt, verliert die Fähigkeit zur Abnahme. Beurteilen kann man nur, was man selbst einmal gebaut hat — und diese Fähigkeit verkümmert, wenn sie nicht benutzt wird.

16:43 Der dritte Punkt fasst das in eine Formel: Geschwindigkeit ohne Prüfkapazität erzeugt Schulden statt Fortschritt. Der Engpass verschiebt sich dann vom Schreiben zum Verstehen — und Sie merken es erst, wenn niemand mehr weiß, wie die Anwendung eigentlich funktioniert. Diese Abschlussaufgabe führt alles zusammen: planen, generieren lassen, belastbar prüfen.

17:03 Der Erfolg ist bewusst dreiteilig, und der dritte Teil ist der, der zählt — ein negativer Test schlägt bei entfernter Prüfung fehl. Wenn das funktioniert, haben Sie nicht nur eine Warteliste gebaut, sondern eine abgesicherte. Und beachten Sie die Reihenfolge im Hinweis: zuerst der Plan. Wer gleich generieren lässt, macht die Erfahrung, die dieses Modul eigentlich vermeiden soll.

Modul 14 zusammengefasst

17:27 Vier Sätze zum Mitnehmen. Versionsgenaue Dokumentation im Projekt schlägt jeden Trainingsstand — und sie kommt inzwischen von allein. Der Plan vor dem Code ist der eigentliche Hebel, nicht die Formulierung der Anweisung. Die vier typischen Fehler sind die Themen der Module davor, und deshalb steht dieses Modul am Ende. Und der Satz, mit dem ich schließen möchte: Verantwortlich ist, wer den Merge-Knopf drückt.

17:50 Das war und bleibt eine menschliche Entscheidung, ganz gleich, wer den Code geschrieben hat.

Danke!

17:56 Damit sind wir am Ende. Sie haben in vierzehn Modulen eine vollständige Full- Stack-Anwendung gebaut — vom leeren Ordner bis in den Container. Wenn Sie eine Sache mitnehmen, dann bitte die Server-Client-Grenze aus Modul vier: Sie erklärt das Rendering, das Caching, die Bundle-Größe und die halbe Sicherheit. Alle Materialien liegen in der Freigabe, und bei Fragen erreichen Sie uns unter der genannten Adresse.

18:20 Vielen Dank für Ihre Aufmerksamkeit — und viel Erfolg mit Ihrem nächsten Projekt.