Ein SaaS mit einem Coding-Agenten bauen: ein praktischer Workflow

Mit einem beobachtbaren Ergebnis beginnen

Ein Coding-Agent kann ein plausibel aussehendes UI erzeugen, bevor du entschieden hast, was es tun soll. Beginne mit einem kleinen Nutzerergebnis: Ein angemeldeter Nutzer bearbeitet ein Profil, speichert es und sieht den gespeicherten Namen nach einem Reload. Das gibt Implementierung wie Review ein konkretes Ziel.

Nenne im Briefing das aktuelle Verhalten, das gewünschte Verhalten und die wichtigen Fehlerfälle. Nenne das bestehende Modul, dem die Arbeit gehört. Eine Anfrage, Profilbearbeitung hinzuzufügen, sollte auf die Authentifizierungsschicht zeigen, statt den Agenten einen zweiten Nutzerspeicher erfinden zu lassen. Halte Zugangsdaten aus Prompts und Screenshots heraus — ein eingefügtes apps/web/.env.local oder Session-Cookie wird Teil des Gesprächsprotokolls.

Ein brauchbares Briefing liest sich so: „Erlaube im Konto-Screen einem angemeldeten Nutzer, seinen Anzeigenamen zu bearbeiten und ihn nach einem Reload zu sehen. Das Auth-Modul besitzt den Nutzerdatensatz; füge keine Tabelle hinzu. Ein leerer Name oder eine Anfrage, die den Datensatz eines anderen Nutzers nennt, muss abgelehnt werden. Beweise es mit pnpm test und einem manuellen Speichern bei schmaler Breite.“ Fünf Sätze, und das meiste Raten ist weg.

• Das für den Nutzer sichtbare Ergebnis, so formuliert, dass du es in der laufenden App prüfen kannst.
• Die Datei oder das Modul, dem das Verhalten heute gehört — und die Bereiche, die unberührt bleiben sollen.
• Mindestens ein Fehlerfall: ein unauthentifizierter Versuch, ungültige Eingabe oder eine wiederholte Anfrage.
• Die Prüfung, die es beweist — ein Testbefehl, ein Fixture oder ein expliziter manueller Durchlauf.

Lass das Repo sich selbst erklären

Dokumentiere, wie die App läuft, welche Prüfungen deterministisch sind und wo Besitz durchgesetzt wird. In supastack hält AGENTS.md die Workspace-Grenze fest und .ai/ die Entscheidungen auf Dateiebene. Diese Notizen sind am nützlichsten, wenn sie dem nächsten Beitragenden — Mensch oder Agent — erklären, warum eine Implementierung existiert, nicht nur welche Dateien sich geändert haben. Der Agent-Setup-Guide zeigt, wie das Kit dieses Material bereitstellt, und der lokale Setup-Guide ist die Anleitung, der der Agent tatsächlich folgen wird.

Bitte den Agenten, den relevanten Code vor Änderungen zu lesen. Eine enge Änderung braucht meist die Schnittstelle, ihre Server-Grenze und die Tests um diese Grenze. Das ganze Repo zu laden ist weniger hilfreich, als die wenigen Stellen zu verstehen, die entscheiden, ob das neue Verhalten korrekt ist: die Besitzprüfung, das Schema, die Berechtigung.

Wenn ein Feature Konfiguration berührt, nenne die Datei, statt sie abzutippen — „füge den Schlüssel zu apps/web/.env.local hinzu“ lässt Geheimnisse auf der Platte. Dieselbe Disziplin gilt für Anbieter-Dashboards: Beschreibe das Ziel, statt die Zugangsdaten einzufügen.

In kleinen, reviewbaren Änderungen arbeiten

Agenten sind am zuverlässigsten, wenn eine Änderung einen Besitzer und ein prüfbares Ergebnis hat. „Profilbearbeitung hinzufügen“ ist reviewbar; „verbessere den Konto-Bereich“ lädt zu Refactorings ein, um die niemand gebeten hat. Zerlegt sich ein Feature in Schemaänderung, Server-Grenze und Screen, führe sie als getrennte Briefings aus, die den Build jeweils grün lassen.

Committe oder setze einen Checkpoint vor jedem Agenten-Lauf. Eine saubere Basislinie macht aus einem schlechten Ergebnis einen gelöschten Diff statt einer archäologischen Übung — und sie gibt deinem Review ein stabiles Vorher-nachher zum Vergleichen.

Ein vollständiges Change nach dem anderen reviewen

Schreibe einen Akzeptanz-Check, bevor du Verhalten änderst. Für Profilbearbeitung decke ein gültiges Update und einen unbefugten Versuch ab. Baue die kleinste Implementierung, die diese Fälle erfüllt, und inspiziere dann die tatsächliche Interaktion mit realistischem Text und einem schmalen Viewport.

Reviewe den Diff ebenso wie das Ergebnis. Achte auf duplizierte Geschäftslogik, zu breites Exception-Handling und neue Abhängigkeiten, die ein Problem lösen, das der bestehende Stack bereits abdeckt. Führe die Projekt-Checks aus und halte fest, was sie belegen. Ein Browser-Fixture kann eine Formularinteraktion verifizieren; es kann nicht belegen, dass die Produktionsdatenbank oder ein externer Anbieter korrekt konfiguriert ist.

Jeder Befehl beantwortet eine andere Frage. pnpm test prüft Verhalten gegen deterministische Fake- und lokale Adapter, pnpm check deckt Lint, Typechecking und Formatierung ab, und pnpm build zeigt die Integrationsfehler, die erst beim Bundlen auftauchen. Zusammen sind sie die Untergrenze fürs Review — die Launch-Checkliste deckt ab, was in der echten Umgebung noch bewiesen werden muss.

pnpm test
pnpm check
pnpm build

Wenn der Agent danebenliegt

Wenn ein Ergebnis falsch ist, widerstehe der Versuchung, Folge-Prompts auf einen schlechten Diff zu stapeln. Kehre zum Checkpoint zurück, schärfe das Briefing um das Missverstandene nach — meist eine unausgesprochene Bedingung oder ein fehlender Besitzer — und starte erneut. Jeder neue Versuch sollte neue Information tragen, nicht nur neue Dringlichkeit.

Hartnäckiges Scheitern bedeutet meist, dass das Briefing Kontext annimmt, den das Repository nicht enthält. Erfindet der Agent immer wieder einen zweiten Ort zur Nutzerablage, ist die Lösung ein Satz in AGENTS.md darüber, wo Identität lebt — kein schärferer Ton. Aktualisiere das Dokument und wiederhole dann die Aufgabe — der Agenten-Guide ist der Ort, an dem das Kit diesen Workflow pflegt.

Häufige Fragen zu Agenten-Workflows

Ein paar Fragen kommen immer wieder auf, wenn Gründer anfangen, einem Coding-Agenten echte Produktarbeit anzuvertrauen.

• Kann ein Coding-Agent ein ganzes SaaS allein bauen? — Die sichtbaren Teile setzt er schnell zusammen, aber die tragfähigen — Autorisierung, Billing-Lifecycle, Datenisolation — brauchen weiterhin Briefing, Prüfung und Review. Tempo ohne diese Schleife wird zu Nacharbeit.
• Wie groß sollte eine Aufgabe für einen Coding-Agenten sein? — Klein genug, dass du das Ergebnis in der laufenden App in Minuten verifizieren kannst: ein nutzersichtbares Ergebnis, ein besitzendes Modul, ein Akzeptanz-Check.
• Was gehört nie in einen Prompt? — Anbieter-Geheimnisse, Session-Cookies, der Inhalt von .env.local und Kundendaten. Nenne Dateien und lass das Werkzeug sie lokal lesen, statt Werte in ein Chatlog zu kopieren.
• Verändert von Agenten geschriebener Code die Art des Reviews? — Das Review verschiebt sich vom Tippen zum Lesen: Prüfe den Diff auf duplizierte Logik, breites Exception-Handling und Abhängigkeiten, die ein Problem erneut lösen, das der Stack schon abdeckt.
• Welche Tests sind bei Agenten-Ergebnissen am wichtigsten? — Die, die Besitz und Fehlerverhalten festnageln: unbefugte Anfragen, ungültige Eingabe und wiederholte Einreichungen — nicht nur der Happy Path aus der Demo.