1. Einleitung

Während des größten Teils der Geschichte der Software war die knappe Ressource das Schreiben. Das Handwerk eines Entwicklers bemaß sich an der Fähigkeit, eine Absicht in korrekten Code zu verwandeln, und die Stunden flossen ins Tippen, Nachschlagen, Verdrahten von Bibliotheken und Beheben der kleinen Fehler, die Kompilierfehler und fehlschlagende Tests aufdeckten. Ein leistungsfähiger Coding-Agent nimmt den größten Teil davon ab. Gib ihm eine klare Anweisung und Zugriff auf eine Codebasis, und er erzeugt in Minuten eine funktionierende Änderung, in Idiomen, die er millionenfach gesehen hat, mit bereits korrektem Boilerplate. Der umgangssprachliche Name für diese Arbeitsweise, Anfang 2025 populär geworden, ist vibe coding: beschreiben, was man will, und das Modell es erzeugen lassen, gesteuert durch Ergebnisse statt durch das Schreiben jeder einzelnen Zeile. Es ist wirklich ein Qualitätssprung, und es ist leicht, ihn für die ganze Geschichte zu halten.

Es ist nicht die ganze Geschichte, denn Code erscheinen zu lassen war nie der schwierige Teil der Software, nur der mühsame. Die schwierigen Teile sind zu entscheiden, was zu bauen ist, und zu wissen, dass das Gebaute tatsächlich richtig, sicher und betriebstauglich ist. Diese werden nicht billiger, wenn die Generierung es wird; wenn überhaupt, werden sie schwieriger, denn es gibt nun weit mehr Code zu verstehen, schneller produziert, als ein Mensch ihn schrieb, von einem Autor, der selbstsicher ist, auch wenn er irrt. Der Engpass der Softwareentwicklung verschiebt sich. Früher saß er bei der Generierung, wie schnell ein Team korrekten Code schreiben konnte. Mit einem Agenten sitzt er bei der Verifikation: wie schnell ein Team sicher sein kann, dass der Code korrekt ist, und ihn durchlässt.

Dieser Aufsatz handelt von der Folge dieser Verschiebung für das Werkzeug, und er ist bewusst konkret. Wenn die Verifikation der Engpass ist, dann ist das Wertvollste, was eine KI-gestützte Umgebung tun kann, nicht, schneller zu generieren, sondern einem Team zu helfen, schneller und sicherer zu verifizieren, indem sie die Fehler des Agenten günstig und früh fängt. Wir beschreiben die konkrete Kette, die wir bei Nashua nutzen, um unser eigenes Produkt, die Nashua 360 Enterprise Platform, zu bauen und zu betreiben – Claude Code als der Agent, GitHub als das versionskontrollierte Rückgrat und Review-Gate, Vercel für eine laufende Vorschau jeder Änderung, Next.js als das Anwendungs-Framework und Postgres als die Datenbank –, und wir gehen darauf ein, wie jedes Stück tatsächlich funktioniert, denn im Detail liegt der Wert. Jedes Glied verdient seinen Platz, indem es eine Schleife enger zieht oder ein Gate hinzufügt, nicht indem es für sich genommen clever ist.

Der Beitrag ist ein Argument und eine ausgearbeitete Empfehlung, kein Benchmark. Abschnitt 2 legt dar, was die KI verändert hat und was nicht, und verortet den Engpass. Abschnitt 3 präsentiert die Kette als eine Schleife (Abbildung 1), begründet, dass Best-of-Breed für agentengestützte Arbeit konventionell bedeutet, und erklärt, warum unabhängige Gates sich multiplizieren. Die Abschnitte 4 bis 9 nehmen die fünf Stücke der Reihe nach vor und gehen auf ihr Innenleben ein, einschließlich der Laufzeitarchitektur, die ein Deployment tatsächlich hat (Abbildung 2), und des Teils, der die Leute überrascht, dass eine Änderung nun von einem Telefon aus angestoßen und geprüft werden kann. Die Abschnitte 10 bis 12 behandeln das menschliche Gate und seine Versagensarten, die realen Kosten und wie die Kette in der Praxis läuft. Die durchgängige Frage lautet: Sobald ein Agent den Code schreiben kann, was sollte ein Team um ihn herum stellen, damit schnelles Schreiben nicht bedeutet, Falsches auszuliefern?

2. Was die KI verändert hat und was nicht

2.1 Die Verschiebung

Die Veränderung, die ein Agent bringt, formuliert man am besten präzise. Es ist nicht so, dass die Maschine nun das Problem versteht; es ist so, dass die Kosten, eine plausible, oft korrekte Implementierung einer wohldefinierten Änderung zu erzeugen, kollabiert sind. Ein Entwickler, der einen Nachmittag an einem Feature verbracht hätte, kann eine erste Version in der Zeit haben, die es braucht, sie zu beschreiben, und kann mehrere Versionen günstig verwerfen. Die Arbeitsweise verschiebt sich vom Verfassen zum Dirigieren: Absicht angeben, Ergebnisse lesen, Kurs korrigieren. Das ist echter Hebel, und ein Team, das ihn verweigert, wird überholt werden.

2.2 Keine Wunderwaffe

Die Veränderung ist auch begrenzt, und die Grenze ist alt. Brooks (1987) zog die Unterscheidung, die hier noch immer gilt: Die akzidentelle Komplexität der Software, die Mühe, die unsere Werkzeuge und Sprachen auferlegen statt das Problem selbst, kann angegriffen und verringert werden, aber die essenzielle Komplexität, das Problem zu verstehen und eine korrekte Lösung zu spezifizieren, lässt sich nicht wegautomatisieren, weil sie das Problem ist. Ein Coding-Agent ist der mächtigste Angriff auf die akzidentelle Komplexität, der je gebaut wurde: Er absorbiert die Syntax, das Boilerplate, die API-Nachschlagevorgänge, die Idiome. Gegen die Essenz tut er nichts. Zu wissen, was das Geschäft braucht, das richtige Design zu entscheiden und festzustellen, dass eine bestimmte Änderung den Bedarf tatsächlich erfüllt, ohne etwas anderes zu zerbrechen, bleibt menschliche Arbeit, und sie ist die Arbeit, die schon immer schwierig war.

2.3 Die Verifikation wird zum Engpass

Setzt man die beiden zusammen, folgt die Schlussfolgerung. Die Generierung, der akzidentelle Teil, ist nun schnell und billig. Die Verifikation, in der die Essenz wohnt – dass diese Änderung korrekt ist, dass sie tut, was gewollt war, dass sie nichts zerbrochen hat, dass sie gefahrlos exponiert werden kann –, ist es nicht. In jeder Pipeline wird der Durchsatz von der langsamsten Stufe bestimmt, und wenn die Generierung an der Verifikation vorbeizieht, wird die Verifikation zum bindenden Engpass. Ein Team, das zehn Änderungen am Tag generieren, aber zwei verifizieren kann, wird zwei ausliefern und einen Rückstau unverifizierten Codes anhäufen, der eine Last ist, kein Gut. Schlimmer noch: Ein Agent produziert selbstsichere, oberflächlich korrekte Arbeit, sodass die Kosten des Unter-Verifizierens, des Mergens dessen, was richtig aussieht und es nicht ist, genau in dem Maße steigen, in dem die Versuchung dazu steigt. Der Rest dieses Aufsatzes handelt davon, eine Kette zu bauen, deren Aufgabe es ist, die Verifikationsgrenze anzuheben und das Unter-Verifizieren schwer zu machen.

3. Die Kette, und warum das Konventionelle gewinnt

3.1 Die Schleife

Eine gute KI-gestützte Umgebung ist eine Schleife, kein Werkzeug. Abbildung 1 zeichnet die, die wir nutzen. Ein Entwickler gibt eine Absicht an. Claude Code, der Agent, verwandelt sie in eine Änderung auf einem Branch, nicht am laufenden Code. Die Änderung wird zu einem GitHub-Pull-Request, wo zwei automatisierte Gates ohne jemandes Aufmerksamkeit laufen: der Typprüfer und die Continuous-Integration-Suite. Vercel baut den Branch zu einem echten, laufenden Preview-Deployment, einer vollständigen Kopie der Anwendung mit der Änderung live, erreichbar unter einer eigenen URL. Ein Mensch prüft die Änderung, liest das Diff und klickt sich durch die Vorschau, auf einem Desktop oder, zunehmend, auf einem Telefon. Erst dann wird sie in den Main-Branch gemergt, den Vercel in die Produktion deployt, gestützt auf Postgres. Das Ergebnis speist die nächste Absicht. Der Sinn des Diagramms ist, dass der Agent einen Kasten einnimmt; jeder andere Kasten ist eine sich schließende Schleife oder ein fangendes Gate, und daher kommen die Sicherheit und die Geschwindigkeit.

3.2 Best-of-Breed bedeutet konventionell

Der übliche Weg, Werkzeuge zu wählen, ist, sie nach Mächtigkeit zu ordnen und das leistungsfähigste zu nehmen. Für eine agentengestützte Kette ist das Kriterium ein anderes, und es ist die einzige nützlichste Idee in diesem Aufsatz. Ein Agent schreibt die Werkzeuge, die er am häufigsten gesehen hat, am besten. Seine Kompetenz bei einem Framework oder einer Datenbank ist eine Funktion dessen, wie viel korrekter Code, der dieses Werkzeug nutzt, in seinem Training war, und diese Menge folgt der Popularität des Werkzeugs, seiner Dokumentation und der Stabilität seiner Konventionen. Ein verbreitetes, gut dokumentiertes, konventionsreiches Werkzeug ist daher nicht bloß eine sichere menschliche Wahl; es ist die Wahl, bei der der Agent am leistungsfähigsten ist und am wenigsten dazu neigt, eine API zu erfinden, die nicht existiert. Der Effekt verstärkt sich: Populäre Werkzeuge bekommen mehr agentengenerierten Code, der funktioniert, was ihre Popularität bekräftigt. Für die KI-gestützte Entwicklung sind Best-of-Breed und das Konventionellste zusammengefallen, und jedes Werkzeug in Tabelle 1 wurde mit diesem Gedanken gewählt. Dies ist auch eine Warnung: Das exotische Framework, das ein menschlicher Experte brillant handhaben könnte, ist oft genau dort, wo ein Agent am schwächsten ist, weil er davon am wenigsten gesehen hat.

3.3 Warum unabhängige Gates sich multiplizieren

Die Kette vertraut keiner einzelnen Prüfung. Sie verifiziert eine Änderung durch mehrere Gates, die auf wirklich verschiedene Dinge schauen: Der Typprüfer prüft Formen, die Continuous-Integration-Tests prüfen Verhalten, das Preview-Deployment zeigt das laufende Ergebnis, und der menschliche Prüfer beurteilt die Absicht. Weil die Gates weitgehend unabhängig sind, multiplizieren sich ihre Fehlschläge, statt sich zu addieren: Ein Defekt erreicht die Produktion nur, wenn jedes Gate ihn zu fangen versäumt, sodass vier bescheidene Gates, die jeweils das meiste fangen, was sie sehen, nur einen kleinen Bruchteil des Produkts dessen durchlassen, was sie verfehlen. Dies ist das Prinzip der Verteidigung in der Tiefe, in der Sicherheitstechnik lange bekannt als die Schichtung unvollkommener Barrieren (Reason, 2000), und es hat ein scharfes praktisches Korollar. Ein Gate zu entfernen oder zu schwächen – die Vorschau zu überspringen, einen strikten Typ abzuschalten, ohne Lesen zu genehmigen – fügt nicht ein wenig Risiko hinzu; es multipliziert die Durchschlupfrate mit dem Kehrwert dessen, was dieses Gate zu fangen pflegte. Der billigste Weg, sicher zu bleiben, ist, mehrere verschiedene, unvollkommene Gates ehrlich zu halten, und genau das zu tun ist die Kette eingerichtet.

4. Der Agent: wie Claude Code sich einfügt

Claude Code ist der Agent: ein Werkzeug, das die Codebasis liest, Dateien schreibt und bearbeitet, Befehle ausführt, die Tests laufen lässt und Pull Requests öffnet, aus einer Anweisung heraus arbeitet und sich an den Ergebnissen, die es sieht, selbst korrigiert. Wie er betrieben wird, zählt mehr als die rohe Fähigkeit des Modells, und drei Dinge daran verdienen die Aufmerksamkeit eines Praktikers.

Das erste ist Kontext. Ein Agent ist nur so gut wie das, was er über deine Codebasis weiß, und das Artefakt mit dem höchsten Hebel ist eine eingecheckte Konventionsdatei, in unserem Fall ein projektweites CLAUDE.md, die dem Agenten die Hausregeln sagt: wie das Projekt aufgebaut ist, wie man den Typprüfer und die Tests ausführt, was wie zu deployen ist, was niemals anzufassen ist. Der Agent liest sie bei jedem Lauf, sodass eine einmal aufgeschriebene Korrektur aufhört, wiederzukehren. Darum herum liegt eine breitere Fläche: wiederverwendbare Skills für wiederkehrende Aufgaben, Hooks, die bei Tool-Aufrufen laufen, um eine Regel mechanisch durchzusetzen, und MCP-Server, die dem Agenten typisierten Zugriff auf äußere Systeme geben, GitHub unter ihnen, sodass er Pull Requests als erstklassige Aktionen öffnen und aktualisieren kann statt per Screen-Scraping. Context Engineering – zu entscheiden, was der Agent wissen und können soll – ist die eigentliche Arbeit, einen einzuführen, und es ist gewöhnliche Software-Hygiene: Schreibe die Konventionen auf, mache die Checks ausführbar, halte die Fläche klein.

Das zweite ist, dass der Agent in der Schleife läuft statt in Isolation. Von ihm wird erwartet, dass er den Typprüfer und die Tests selbst ausführt, liest, was sie melden, und es behebt, bevor ein Mensch hinsieht, sodass die automatischen Gates der Kette bereits grün sind, wenn ein Pull Request geöffnet wird. Für größere Aufgaben kann er die Arbeit an Subagenten verteilen, die jeweils ihren eigenen Kontext tragen und zurückmelden, was den Hauptthread fokussiert und den Kontext sauber hält. Die Disziplin besteht darin, das schnelle, billige Feedback – Typen und Tests – innerhalb der eigenen Schleife des Agenten geschehen zu lassen und das langsame, teure Feedback – den Menschen – für das Ende aufzuheben.

Das dritte ist, wo er läuft. Über das Terminal hinaus läuft Claude Code als Cloud-Session, erreichbar von einer mobilen App, was die Gestalt des Arbeitstags verändert. Eine Änderung kann von einem Telefon aus unterwegs angestoßen, in der Cloud laufen gelassen und ihr Pull Request und ihre Vorschau später vom selben Telefon aus geprüft und genehmigt werden. Wir tun dies bewusst, nicht weil mobiles Arbeiten eine Neuheit ist, sondern weil es die Schleife verkürzt: Die Lücke zwischen dem Bemerken von etwas und dem Anstoßen der Änderung, und zwischen einer fertigen Änderung und jemandem, der sie genehmigt, schrumpft von Stunden auf Minuten, was in einer verifikationsgebundenen Welt genau die Lücke ist, die zu schließen sich lohnt.

5. Das Rückgrat: GitHub

GitHub ist der Teil der Kette, der alles andere sicher macht, und er ist der am wenigsten glanzvolle. Er hält die einzige Quelle der Wahrheit, das Repository, und er setzt die Regel durch, auf der das gesamte Argument ruht: Der Main-Branch, der ausliefernde, ist geschützt und kann nur durch einen Pull Request erreicht werden, den ein Mensch genehmigt hat und dessen erforderliche Status-Checks bestanden sind. Der Agent bearbeitet niemals den Produktionscode direkt; er schlägt vor, auf einem Branch, und der Vorschlag ist ein Diff, das ein Mensch lesen und eine Maschine testen kann.

Die erforderlichen Checks sind dort, wo die automatischen Gates wohnen. Bei jedem Pull Request führt GitHub Actions die Suite aus, auf der wir bestehen, bevor irgendetwas gemergt wird: den Typprüfer, den Linter, die Testsuite und einen Produktions-Build, jeder ein erforderlicher Status, der den Merge-Button blockiert, bis er grün ist. Weil diese von der Plattform durchgesetzt werden statt von jemandes Disziplin, können sie nicht in der Eile übersprungen werden, und weil der Agent weiß, dass sie laufen werden, erfüllt er sie zuerst. Der Pull Request ist die Einheit der Änderung: klein, in sich geschlossen, einzeln prüfbar und einzeln rückgängig machbar, was das Review günstig und die Historie lesbar hält. Und weil jede Änderung ein Commit mit einem Autor und einer Nachricht ist, ist die Historie eine Prüfspur und das Rückgängigmachen vollständig – alles, was der Agent tat, kann gesehen, zugeschrieben und zurückgenommen werden. Ein Coding-Agent ist ein schneller, mächtiger und fehlbarer Akteur, und GitHub ist die Struktur, die es sicher macht, einen von der Leine zu lassen, indem sie sicherstellt, dass nichts, was er tut, ungeprüft, ungetestet oder unumkehrbar ist.

6. Die Augen: Vercel

Ein Diff zu lesen sagt dir, was sich geändert hat; es sagt dir nicht, was die Änderung bewirkt. Vercel schließt diese Lücke, indem es jeden Pull Request zu einem Preview-Deployment baut: einer vollständigen, isolierten, laufenden Instanz der Anwendung mit der angewandten Änderung, unter einer eigenen URL, automatisch erzeugt und bei jedem Push aktualisiert. Dies ist das Gate, das fängt, was Typen und Tests nicht fangen – das Layout, das zerbrach, der Ablauf, der einen Schritt länger wurde, das, was technisch korrekt und im Gebrauch falsch ist –, und es ist zum größten Teil der Grund, warum sich die Kette schnell bewegen kann, ohne sich blind zu bewegen. Ein Prüfer, und der Agent, klicken sich durch das tatsächliche Ergebnis, statt es sich aus dem Code vorzustellen.

Was die Vorschau vertrauenswürdig macht, ist, dass sie ein echter Build des gesamten Stacks ist, kein Mock (Abbildung 2): dasselbe Framework, dieselbe Laufzeit, eigene Umgebungsvariablen und, gut gemacht, eine eigene isolierte oder abgezweigte Datenbank, sodass ihr Betreiben die Produktionsdaten nicht berühren kann. Deployments sind unveränderlich: Jedes ist ein eigener, adressierbarer Build, sodass das Hochstufen einer geprüften Vorschau in die Produktion ein Zeigerwechsel ist statt eines Neubaus, und ein schlechtes Release ein sofortiges Rollback zum vorherigen unveränderlichen Deployment ist statt eines hektischen Hotfixes. Beim Merge in den Main-Branch baut dieselbe Maschinerie, die die Vorschau baute, die Produktion, sodass das, was geprüft wurde, das ist, was ausgeliefert wird. Im Modell dieser Kette sind Preview-Deployments ein billiges, automatisches Verifikations-Gate mit einer hohen Fangquote für eine Klasse von Defekten, die kein anderes Gate sieht.

7. Nahtlos durch git: warum die drei zusammenpassen

Der Grund, warum sich Claude Code, GitHub und Vercel weniger wie drei Werkzeuge und mehr wie ein System anfühlen, ist, dass sie eine einzige Schnittstelle teilen, und diese Schnittstelle ist git. Die natürliche Ausgabe von Claude Code ist kein Deployment; sie ist ein Branch und ein Pull Request. GitHubs Aufgabe ist, diese Commits zu speichern, die Checks laufen zu lassen und das Review zu halten. Vercel beobachtet das Repository und verwandelt jeden Branch in eine Vorschau und den Main-Branch in die Produktion. Keinem von ihnen musste von den anderen erzählt werden: Der Agent lernt nie eine Deployment-API, er öffnet einen Pull Request; Vercel lernt nie vom Agenten, es beobachtet das Repo. Die Naht zwischen ihnen ist das git-Protokoll, das alle drei bereits sprechen, weshalb das Hinzufügen eines Agenten zur Kette nichts daran änderte, wie das Deployment funktionierte, und weshalb der gesamte Weg von einem Prompt zur Produktion keine Übergaben enthält.

Die Folge ist, dass das Deployment aufhört, ein Schritt zu sein, den jemand ausführt, und zu einer Folge der git-Aktion wird, die man ohnehin vornehmen wollte. Ein Push ist ein Build. Ein Pull Request ist eine Preview-Umgebung, von selbst erzeugt und wieder abgebaut. Ein Merge in den Main-Branch ist ein Produktions-Deploy. Ein Revert ist ein Rollback. Niemand führt ein Release durch; man mergt, und das Release geschieht. Es gibt keinen Build-Server zu hüten, kein Deploy-Skript, das der Agent falsch machen könnte, kein separates Promotion-Werkzeug, kein Fenster, in dem jemand den Code geschrieben, aber noch nicht ausgeliefert hat. Für ein verifikationsgebundenes Team ist dies genau der richtige Ort, um Reibung zu entfernen: Der einzige bewusste, menschliche Akt, der im Weg verbleibt, ist das Review, das der eine Akt ist, der bewusst sein sollte, und alles Mechanische darum herum wird von den Werkzeugen erledigt, die git beobachten.

Dies ist auch der Grund, warum die Nahtlosigkeit sicher ist statt leichtsinnig, und die beiden Eigenschaften kommen aus derselben Tatsache. Weil das Deployment auf git reitet, erbt es die Garantien von git: Jeder Produktions-Deploy ist an einen bestimmten geprüften Commit gebunden, mit einem Autor und einer Nachricht; jede Vorschau ist an einen Branch gebunden; und weil Deployments unveränderlich sind, ist das Zurückrollen nur das Zeigen der Produktion auf den Build eines früheren Commits. Dieselbe Verdrahtung, die eine Änderung von einem auf dem Telefon getippten Prompt zu einer Live-Site fließen lässt, ohne dass jemand eine Deploy-Konsole berührt, stellt auch sicher, dass nichts diese Live-Site erreicht außer durch einen geprüften, zuschreibbaren, umkehrbaren Commit. Die Integration passt nicht, weil die Anbieter sie koordinierten, sondern weil alle drei gebaut wurden, git als die Quelle der Wahrheit zu behandeln, und als der Agent dieser Konvention beitrat, war die Pipeline, die er brauchte, bereits da.

8. Das Gelände: Next.js

Der Agent muss eine Codebasis navigieren, und das Framework der Codebasis ist das Gelände. Next.js ist aus zwei Gründen eine starke Wahl, die beide auf die Verifikation zurückkommen. Der erste ist, dass es TypeScript ist, und Typen sind das erste und billigste Gate. Im Strict-Modus betrieben, weist der Typprüfer eine große Klasse von Fehlern zurück – eine falsche Form, ein fehlendes Feld, einen Wert, der null sein könnte – in dem Moment, in dem der Agent ihn schreibt, was genau dann ist, wenn eine Korrektur am billigsten ist, bevor der Code läuft und lange bevor ein Mensch hinsieht. Wir treiben dieselbe Idee bis an die Ränder des Programms, indem wir externe Eingaben, Request-Bodies, Umgebungsvariablen und Datenbankzeilen gegen ein Schema validieren, sodass untypisierte Daten von außen an der Grenze typisiert und geprüft werden statt ihnen vertraut wird. Typen sind hier keine Bürokratie; sie sind das Gate, das den häufigsten Fehler des Agenten – eine plausible Form, die auf subtile Weise falsch ist – in eine rote Schlangenlinie verwandelt, die er selbst behebt.

Der zweite Grund ist, dass Next.js konventionell ist, und sein Modell, obwohl reich, ist ausgetreten genug, dass der Agent es flüssig schreibt. Es lohnt sich, bei diesem Modell konkret zu sein, weil dort viel der Ingenieursarbeit lebt. Der App Router rendert standardmäßig auf dem Server: Server Components laufen auf dem Server und liefern ihren Code nie an den Browser aus, wodurch Datenzugriff und Geheimnisse serverseitig bleiben, während Client Components, explizit markiert, die Interaktivität tragen. Mutationen laufen über Server Actions, Serverfunktionen, die ein Formular oder ein Button direkt aufrufen kann, und Route Handlers stellen die API-Fläche bereit. Jede Route wählt, wie sie rendert – statisch zur Build-Zeit, inkrementell nach einem Zeitplan neu erzeugt oder dynamisch pro Anfrage – und wo sie läuft – die leichtgewichtige Edge-Laufzeit nahe am Nutzer oder die vollere Node.js-Laufzeit –, wobei Middleware vor der Anfrage läuft, um Dinge wie Authentifizierung und Locale zu behandeln. Das sind viele Hebel, aber es sind öffentliche, dokumentierte, stabile Hebel, die der Agent im großen Maßstab korrekt verwendet gesehen hat, sodass er zum richtigen greift, und das Framework ist mächtig genug, um ein echtes Produkt zu bauen, während es das Gelände bleibt, auf dem der Agent am leistungsfähigsten ist, was, nach dem Argument aus Abschnitt 3, die Kombination ist, auf die es ankommt.

9. Der Zustand: Postgres

Alles Obige betrifft Code, der gefahrlos zu ändern ist, weil er versioniert und umkehrbar ist. Daten sind es nicht: Eine gelöschte Spalte oder eine schlechte Migration kann etwas zerstören, das kein Commit wiederherstellen kann. Postgres ist der dauerhafte, transaktionale Zustand am Grund der Kette, und die Disziplin um ihn herum ist bewusst strenger als die um Code. PostgreSQL verdient seinen Platz auf dieselbe Weise wie der Rest der Kette – es ist die konventionelle, kampferprobte, hervorragend dokumentierte Wahl, sodass der Agent korrektes SQL und korrekte Migrationen dagegen schreibt, und eine managed Instanz nimmt die betriebliche Mühe ab, ohne das Modell zu ändern.

Die Sorgfalt geht in die Änderung. Schemaänderungen sind Migrationen: geordnete, versionierte Dateien, die ins Repository eingecheckt und wie jede andere Änderung geprüft werden, gegen die Vorschau vor der Produktion ausgeführt und so geschrieben, dass sie umkehrbar sind. Eine laufende Datenbank kann nicht so geändert werden wie eine frische, also wird eine riskante Änderung als eine Folge sicherer vorgenommen, das Muster expand and contract (Ambler & Sadalage, 2006): die neue Spalte oder Tabelle hinzufügen und mit dem Schreiben darauf beginnen, nachfüllen, die Lesevorgänge hinüberverlegen und erst dann, in einem späteren Deployment, die alte Form entfernen, sodass bei jedem Zwischenschritt der laufende Code und das Schema kompatibel sind und der Schritt umkehrbar ist. Postgres hilft, indem es die meisten Schemaänderungen transaktional macht, sodass eine fehlgeschlagene Migration sauber zurückrollt, statt die Datenbank halb geändert zu hinterlassen. Zwei betriebliche Punkte zählen in einer serverlosen Umgebung, wo viele kurzlebige Funktionsinstanzen jeweils eine Verbindung wollen: Ein Connection Pooler ist nicht optional, weil eine Datenbank ein hartes Verbindungslimit hat, das eine Flotte serverloser Worker andernfalls erschöpfen wird; und Row-Level Security lässt die Datenbank selbst durchsetzen, wer welche Zeilen sehen darf, ein Sicherungsnetz, das nicht davon abhängt, dass die Anwendung jede Abfrage richtig macht. Die Regel, die wir einhalten, ist einfach und wert, ausgesprochen zu werden: Der Agent darf eine Migration vorschlagen, aber eine Migration ist die eine Art von Änderung, die ein Mensch stets mit voller Aufmerksamkeit liest, weil sie die eine Art ist, die die Kette nicht vollständig rückgängig machen kann.

10. Das menschliche Gate und wie es versagt

Jedes automatische Gate in dieser Kette existiert, um das menschliche Gate billig zu machen, nicht um es zu entfernen. Der Prüfer am Pull Request tut das eine, das kein Gate automatisiert: zu beurteilen, ob die Änderung das ist, was das Geschäft tatsächlich wollte, und ob sie gefahrlos exponiert werden kann – Fragen, die Typen, Tests und Vorschauen informieren, aber nicht beantworten. Der ganze Zweck der Kette ist, diesem Prüfer eine kleine, laufende, vorgeprüfte Änderung zu liefern, sodass das Urteil schnell und wohlbegründet ist. Aber das Gate hat charakteristische Versagensarten, und sie zu benennen gehört dazu, die Kette gut zu nutzen.

Die erste ist das Abnicken. Wenn der Agent meist recht hat, lernt der Prüfer, schnell zu genehmigen, und das Review degeneriert zu einer Formalität, die nichts fängt. Die Verteidigung besteht darin, Änderungen klein zu halten, sodass sie richtig zu lesen günstig bleibt, und die Vorschau als verpflichtend zu behandeln, nicht als optional: Ein Review, das sich nicht durch die laufende Änderung geklickt hat, ist kein Review. Die zweite ist das Übervertrauen, der Glaube, dass der Code, weil er den Typprüfer und die Tests bestand, korrekt sein müsse; diese Gates fangen Formen und Verhalten, aber nicht die Absicht, und der Mensch ist das einzige Gate für die Absicht. Die dritte ist die Skalenermüdung: Ein Agent kann mehr Pull Requests öffnen, als ein Team ernsthaft prüfen kann, und ein Rückstau halb geprüfter Änderungen ist das verifikationsgebundene Regime, das sich wieder durchsetzt. Die Antwort ist nicht, schneller zu prüfen, sondern bewusster zu generieren, den Agenten nur das produzieren zu lassen, was das Team tatsächlich verifizieren kann, weil unverifizierte Änderung eine Last ist, welchen Umfangs auch immer.

11. Kosten und Kompromisse

Die Kette ist eine Reihe von Entscheidungen, und Ehrlichkeit verlangt zu sagen, was sie kosten. Die offensichtlichste ist die Kopplung: Next.js und Vercel kommen vom selben Unternehmen, und auf ihnen zu bauen erkauft einen glatten, integrierten Weg um den Preis eines gewissen Lock-ins, sowohl an ein Framework, das sich schnell bewegt und manchmal die Kompatibilität zwischen Hauptversionen bricht, als auch an eine Hosting-Plattform, deren Preisgestaltung und Primitive man übernimmt. Wir halten den Handel für die Geschwindigkeit und die Qualität der Preview-Schleife für lohnend, aber es ist eine echte Abhängigkeit, und ein Team sollte seine Domänenlogik und seine Daten portabel halten, damit das Framework und der Host austauschbare Infrastruktur bleiben statt des Produkts. Die zweite Kosten ist die Disziplin, die das Gate verlangt: Die Kette ist nur so sicher wie das Review, in dem sie gipfelt, und ein Team, das das menschliche Gate zum Abnicken verfallen lässt, hat einen schnellen Weg, selbstsichere Fehler auszuliefern, was schlimmer ist als ein langsamer Weg, durchdachte auszuliefern. Die dritte ist der Zugriff des Agenten: Ein Werkzeug, das das Repository bearbeiten und Deployments auslösen kann, ist ein mächtiger Akteur und muss wie einer eingegrenzt werden, mit Branch-Schutz, mit Least-Privilege-Anmeldedaten, mit Geheimnissen, die aus dem Repository und aus der Reichweite des Agenten gehalten werden, und mit Berechtigungs- und Infrastrukturänderungen, die mit besonderer Sorgfalt geprüft werden. Die vierte ist die Unumkehrbarkeit von Daten, oben behandelt: die eine Stelle, an der das Sicherheitsnetz der Kette ein Loch hat, und die Stelle, an der die meiste menschliche Aufmerksamkeit aufzuwenden ist. Keine davon ist ein Grund, die Kette nicht einzuführen; jede ist ein Grund, sie bewusst einzuführen.

12. Wie wir die Plattform Nashua 360 darauf betreiben

Die Kette in diesem Aufsatz ist kein Vorschlag, den wir theoretisiert haben; sie ist die, auf der wir unser eigenes Produkt bauen und betreiben. Die Nashua 360 Enterprise Platform ist eine Next.js-Anwendung, auf Vercel deployt, gestützt auf Postgres, mit ihrem Quellcode auf GitHub, und sie wird mit Claude Code als dem Agenten entwickelt, auch von der mobilen App aus, wenn eine Änderung besser fern vom Schreibtisch angestoßen oder genehmigt wird. Eine eingecheckte Konventionsdatei sagt dem Agenten die Hausregeln; jede Änderung an der Plattform ist ein Branch und ein Pull Request; jeder Pull Request bekommt seine Typprüfung, seinen Continuous-Integration-Lauf und sein Preview-Deployment auf einer isolierten Kopie des Stacks; nichts erreicht den Produktions-Branch, ohne dass ein Mensch das Diff liest und sich durch die Vorschau klickt; und Migrationen sind die Änderungen, die wir am gründlichsten lesen. Wir haben diese Kette nicht zusammengestellt, um in Mode zu sein. Wir stellten sie zusammen, weil, sobald wir akzeptierten, dass ein Agent die Generierung billig und die Verifikation zum Engpass gemacht hatte, jedes Glied aus der Frage folgte, wie schnell und sicher zu verifizieren ist, und weil dieselbe Argumentation, die sie für uns richtig macht – konventionelle Werkzeuge, die der Agent gut handhabt, eingehüllt in Schleifen und Gates, die seine Fehler fangen –, sie für die meisten Teams richtig macht, die heute Web-Software bauen. Dass sie auch zulässt, ein ernsthaftes Produkt von einem Telefon in einem Zug aus voranzutreiben, ist nicht der Grund, warum wir sie wählten, aber es ist ein faires Zeichen dafür, wie weit sich die Gestalt der Arbeit verändert hat.

13. Einwände und Erwiderungen

Das ist nur Continuous Delivery mit einem angeschraubten Agenten. Zum großen Teil, mit Absicht. Die Praktiken, auf denen die Kette ruht – Versionskontrolle, kleine geprüfte Änderungen, Continuous Integration, automatisiertes Deployment mit Vorschauen und Rollback –, sind die etablierte Disziplin moderner Software-Auslieferung (Humble & Farley, 2010; Forsgren et al., 2018), und das ist der Punkt: Der Agent ersetzt diese Disziplin nicht, er erhöht ihren Stellenwert, weil sie die Disziplin ist, die die Verifikation liefert, die die Geschwindigkeit des Agenten nun verlangt. Der Beitrag ist keine neue Praktik, sondern das Argument dafür, warum die alten Praktiken mehr zählen, nicht weniger, sobald die Generierung billig ist.

Ein besseres Modell wird das Werkzeug überflüssig machen. Wird es nicht, weil das Werkzeug den Teil betrifft, den ein besseres Modell nicht berührt. Ein leistungsfähigerer Agent generiert schneller, und in einer verifikationsgebundenen Welt hebt schnelleres Generieren nicht an, was tatsächlich ausgeliefert wird; nur schnelleres Verifizieren tut das. Das bessere Modell produziert auch mehr Code, schneller, den ein Mensch prüfen muss, was die Gates nötiger macht, nicht weniger. Die Kette ist eine Wette auf die Verifikation, und diese Wette wird besser, nicht schlechter, wenn sich die Generierung verbessert.

Ihr seid an den Stack eines einzelnen Anbieters gebunden. Teilweise, und wir sagten es. Die Kopplung von Next.js und Vercel ist eine echte Kosten, akzeptiert für einen echten Nutzen, die integrierte Preview-Schleife, die für das gesamte Argument zentral ist. Die Milderung besteht darin, die wesentliche Logik – den Domänencode und die Datenbank – portabel zu halten und das Framework und den Host als austauschbare Infrastruktur zu behandeln. Ein Team mit einer anderen Risikoneigung kann die Gestalt der Kette – Agent, Versionskontrolle, isolierte Vorschau, typisiertes Framework, geprüfte Datenbank – auf anderen Komponenten beibehalten.

14. Grenzen

Dies ist ein an Praktiker gerichteter Rat, und seine Grenzen sollten genannt werden. Es ist eine begründete Empfehlung, gestützt auf unsere eigene Nutzung, kein kontrollierter Vergleich; wir haben die Kette nicht gegen Alternativen gemessen. Die konkreten Werkzeuge sind aktuell mit Stand Ende 2026, und dies ist ein schnelllebiges Feld: Das Argument – dass die Verifikation der Engpass ist und dass die Kette als Schleifen und Gates zu lesen ist – soll jedes einzelne Werkzeug überdauern, aber die einzelnen Werkzeuge werden sich ändern, und ein Leser sollte das Argument behalten und die Teile erneut prüfen. Die Empfehlung ist auf die Art von Software zugeschnitten, die wir bauen, Web-Anwendungen mit einer Datenbank, und überträgt sich weniger direkt auf Domänen mit anderen Beschränkungen, etwa Systeme, in denen die Kosten eines Verifikations-Gates selbst prohibitiv sind, oder in denen kein Agent genug vom Stack gesehen hat, um ihm darauf vertrauen zu können. Und die Sicherheit der Kette ruht auf einem menschlichen Gate, das die Kette billig macht, aber nicht automatisch machen kann; ein Team, das nicht bereit ist, dieses Gate ehrlich zu halten, sollte die Geschwindigkeit ohne die Sicherheit erwarten.

15. Fazit

Ein Coding-Agent macht das Schreiben von Software schnell und rückt dabei den schwierigen Teil ins Offene. Die Generierung, der Teil, der früher den Tag beherrschte, wird billig; die Verifikation – zu entscheiden, was zu bauen ist, und sicher zu sein, dass das Ergebnis richtig ist – wird es nicht und wird zum Engpass. Die Lehre für das Werkzeug ist, dass der Wert einer KI-gestützten Umgebung nicht im Agenten liegt, sondern in der Kette darum herum, die es einem Team erlaubt, im Tempo zu verifizieren, in dem der Agent generiert, und seine Fehler fängt, bevor es die Nutzer tun. Wir bauen und betreiben die Plattform Nashua 360 auf einer solchen Kette: Claude Code zum Schreiben, in einer Schleife mit den Checks und von einem Telefon aus erreichbar; GitHub, um jede Änderung zu einem geprüften, umkehrbaren Diff hinter einem geschützten Branch zu machen; Vercel, um jeder Änderung ihre eigene laufende Vorschau und jedem Release ein sofortiges Rollback zu geben; Next.js als ein typisiertes, konventionelles Gelände, dessen Typen das erste Gate sind; und Postgres als dauerhafter Zustand, geändert durch geprüfte, umkehrbare Migrationen. Jedes Glied schließt eine Schleife oder fügt ein Gate hinzu, die Gates sind unabhängig, sodass keines von ihnen perfekt sein muss, und das Ganze ist nach einem für diesen Moment besonderen Kriterium gewählt: dass für einen Agenten das konventionelle Werkzeug das leistungsfähige ist. Schreibe schnell, verifiziere schneller und lass nichts in die Produktion gelangen, das ein Mensch nicht hat laufen sehen. Das ist das Ganze, und es genügt.

Anhang A. Eine Einführungs-Checkliste

Die folgenden Praktiken sind das, was die Kette sicher statt bloß schnell macht. Keine ist neu; die Disziplin ist der Wert.

Literatur

Ambler, S. W., & Sadalage, P. J. (2006). Refactoring databases: Evolutionary database design. Addison-Wesley. ISBN 978-0-321-29353-5.

Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. In Proceedings of the 35th International Conference on Software Engineering (ICSE) (pp. 712–721). IEEE. https://doi.org/10.1109/ICSE.2013.6606617

Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley. ISBN 978-0-201-61641-5.

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532

Chen, M., Tworek, J., Jun, H., et al. (2021). Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374. https://arxiv.org/abs/2107.03374

Anthropic (2026). Claude Code documentation. https://code.claude.com/docs

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations. IT Revolution Press. ISBN 978-1-942788-33-1.

Fowler, M. (2006). Continuous integration. martinfowler.com. https://martinfowler.com/articles/continuousIntegration.html

GitHub (2026). GitHub documentation. https://docs.github.com

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation. Addison-Wesley. ISBN 978-0-321-60191-9.

Vercel (2026). Next.js documentation. https://nextjs.org/docs

Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv preprint arXiv:2302.06590. https://arxiv.org/abs/2302.06590

PostgreSQL Global Development Group (2026). PostgreSQL documentation. https://www.postgresql.org/docs/

Reason, J. (2000). Human error: Models and management. BMJ, 320(7237), 768–770. https://doi.org/10.1136/bmj.320.7237.768

Sadowski, C., Söderberg, E., Church, L., Sipko, M., & Bacchelli, A. (2018). Modern code review: A case study at Google. In Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) (pp. 181–190). ACM. https://doi.org/10.1145/3183519.3183525

Vercel (2026). Vercel documentation. https://vercel.com/docs