Vibe Coding für Agenturen: Ein internes Tool in einem Wochenende bauen

Vibe Coding heißt, Software im Dialog mit einer AI zu entwickeln: Sie beschreiben, was das Tool tun soll, die AI schreibt den Code, Sie prüfen, korrigieren und lenken. Für Agenturen ist das interessant, weil viele Probleme klein sind: ein Dashboard für Kundenreports, ein Tool zum Prüfen von Meta-Daten, eine Übersicht über Backlink-Antworten. Solche Werkzeuge lassen sich an einem Wochenende bauen, wenn Sie das richtige Projekt wählen und sauber vorgehen.

Dieser Beitrag beschreibt einen Ablauf, den ich für realistisch halte, und nennt die Stellen, an denen er in der Praxis hakt. Er ersetzt keine Softwareentwicklung für Systeme, an denen Ihr Geschäft hängt. Er richtet sich an Agenturen, die ein internes Werkzeug brauchen und dafür bisher entweder eine Tabellenkalkulation missbraucht oder ein Abo für ein Tool bezahlt haben, das 90 Prozent Überschuss mitbringt.

01 Das richtige Projekt wählen

Gut geeignet:

• Interne Dashboards und Reporting
• Automatisierung wiederkehrender Marketing-Aufgaben
• MVPs und Prototypen, um eine Idee zu testen
• Kleine Vermittlungs- oder Verwaltungstools mit klar abgegrenztem Umfang

Weniger geeignet: sicherheitskritische Systeme, große Altsysteme und alles, was viele Nutzerrollen und Sonderfälle von Beginn an braucht. Die Faustregel: ein Problem, eine Nutzergruppe, ein Ergebnis.

Bauen, kaufen oder weiter mit der Tabelle arbeiten

Nicht jedes Problem verdient ein eigenes Tool. Die folgende Übersicht hilft bei der Entscheidung, sie ist meine Einschätzung und keine Messung.

Situation	Sinnvoll
Aufgabe fällt einmal im Quartal an, drei Personen sind betroffen	Tabelle oder bestehendes Tool behalten
Ein fertiges Produkt deckt 80 Prozent ab und kostet wenig	Kaufen, Rest per Export oder Zapier-Alternative lösen
Der Ablauf ist agenturspezifisch, kein Produkt passt, die Daten sind unkritisch	Selbst bauen
Es werden Kundendaten mit Personenbezug verarbeitet	Nur bauen, wenn Sie Hosting, Zugriffsrechte und Datenschutz sauber klären können
Niemand im Team will das Tool in einem Jahr noch pflegen	Nicht bauen oder deutlich kleiner schneiden

Ein Beispiel für den dritten Fall: Eine Übersicht, in der Outreach-Antworten nach Status sortiert werden und offene Nachfassaktionen sichtbar sind. Wie solche Kampagnen aufgebaut werden, steht im Beitrag zu Sniper Outreach. Die Auswertung dazu ist genau die Art Werkzeug, für die sich ein eigenes kleines Tool lohnen kann, weil jede Agentur ihren Ablauf anders führt.

02 Freitagabend: Scope festlegen

Schreiben Sie vor der ersten Codezeile ein kurzes Anforderungsdokument (PRD) auf einer Seite:

1. Welches Problem löst das Tool, für wen?
2. Was sind die drei Must-haves? Alles andere ist „später“.
3. Welche Daten gehen hinein, welche Ergebnisse kommen heraus?
4. Woran erkennen Sie am Sonntag, dass es fertig ist?

Dieses Dokument ist der wichtigste Hebel gegen das häufigste Problem: eine AI baut bereitwillig alles, was Sie ihr sagen, auch das, was Sie nicht brauchen.

Ein kurzes PRD-Beispiel

So knapp darf das aussehen. Angenommen, Sie wollen eine Übersicht für Meta-Daten-Prüfungen:

• Problem: Das Team prüft Title und Description von Kundenseiten von Hand in einer Tabelle. Das dauert und wird vergessen.
• Nutzer: Zwei bis drei Mitarbeiter, kein Kundenzugang.
• Must-haves: Liste von URLs hochladen, Title und Description samt Länge auslesen, Ergebnis als CSV exportieren.
• Später: Verlauf, Benachrichtigungen, Kundenlogin.
• Fertig, wenn: 200 URLs in unter fünf Minuten verarbeitet sind und ein fehlerhafter Aufruf die Liste nicht abbricht.

Der letzte Punkt, das messbare Fertig-Kriterium, verhindert am Sonntagabend die Diskussion, ob noch ein Feature fehlt.

Vorbereitung, die den Samstag rettet

Legen Sie vorab Konten an und halten Sie Zugangsdaten bereit: Git-Repository, Hosting, Datenbank, gegebenenfalls ein API-Schlüssel für eine externe Schnittstelle. Wer am Samstagvormittag noch auf eine Domain-Freischaltung oder eine Zahlungsfreigabe wartet, hat den Zeitplan schon verloren. Dazu gehört auch ein Beispieldatensatz mit echten, aber unkritischen Daten. Die AI baut mit realistischen Eingaben deutlich bessere Logik als mit „Beispiel 1, Beispiel 2“.

03 Samstag: Prototyp und Aufbau

Beginnen Sie mit einem klickbaren Stand, der den Ablauf zeigt. Erst wenn der Ablauf stimmt, kommt der echte Unterbau: Anmeldung, Datenbank, die eigentliche Logik. Ein bewährter Stack für solche Tools ist Next.js mit TypeScript, Supabase für Datenbank und Anmeldung und Vercel zum Veröffentlichen. Wichtig ist weniger die konkrete Wahl als die Entscheidung, bei einem Stack zu bleiben, den Sie und die AI gut kennen.

Arbeiten Sie in kleinen Schritten: eine Funktion beschreiben, Ergebnis prüfen, committen. Große „Baue alles“-Aufträge erzeugen Code, den niemand mehr nachvollziehen kann.

Eine Projektdatei für die Regeln

Die meisten AI-Coding-Werkzeuge lesen eine Anweisungsdatei im Projektordner (je nach Werkzeug etwa CLAUDE.md oder AGENTS.md). Tragen Sie dort ein, was nicht jedes Mal neu erklärt werden soll: der Stack, die Namenskonventionen, der Befehl für Lint und Tests, und Regeln wie „keine neuen Pakete ohne Rückfrage“. Das kostet zehn Minuten und spart über das Wochenende eine Menge Korrekturschleifen.

Reihenfolge, die sich bewährt

1. Klickbare Oberfläche mit Dummy-Daten, damit Sie den Ablauf sehen, bevor Logik existiert.
2. Datenmodell: Welche Tabellen, welche Felder? Lesen Sie das Schema selbst durch, bevor darauf aufgebaut wird.
3. Kernlogik mit Tests, zuerst für den Normalfall, dann für zwei, drei Fehlerfälle.
4. Anmeldung und Zugriffsrechte.
5. Erst danach Komfort: Filter, Export, Optik.

Wer die Anmeldung auf Sonntag verschiebt, merkt oft, dass die halbe Anwendung angepasst werden muss. Bauen Sie sie lieber vor dem Komfort ein.

Wie Sie der AI Aufträge geben

Ein guter Auftrag nennt das Ziel, die betroffene Datei oder Funktion, die erwartete Ein- und Ausgabe und ein Kriterium zur Prüfung. „Die Funktion parseMeta soll bei fehlendem Title einen leeren String liefern statt zu werfen, dazu ein Test“ funktioniert. „Mach die Meta-Prüfung robuster“ erzeugt eine Menge Änderungen an Stellen, die Sie nicht erwartet haben. Wenn die AI sich festfährt, hilft oft ein Neustart der Sitzung mit einer kurzen Zusammenfassung des Stands, statt den zehnten Korrekturversuch im selben Verlauf.

04 Sonntag: Prüfen, absichern, veröffentlichen

Hier trennt sich ein Wochenendprojekt von einem Risiko. AI-generierter Code funktioniert oft sofort, ist aber nicht automatisch sicher. Veracode hat in seinem GenAI Code Security Report 2025 über 100 Sprachmodelle an 80 Programmieraufgaben getestet und in 45 Prozent der Fälle unsichere Lösungen gefunden (Veracode, 2025). Die Zahl bezieht sich auf diese Testaufgaben mit vorgegebenen Schwachstellen-Kategorien, nicht auf Code in echten Projekten. Als Größenordnung taugt sie trotzdem: Der Code lief, die Lücken fielen erst bei der Prüfung auf. Das spricht nicht gegen Vibe Coding, aber gegen das Weglassen der Kontrolle.

Ihre Mindestprüfung:

pnpm lint && pnpm typecheck && pnpm test

• Automatische Checks laufen durch: Linter, Typprüfung und mindestens Tests für die Kernlogik.
• Zugangsdaten und Schlüssel: nie im Code, nur in Umgebungsvariablen. Prüfen Sie die Historie, bevor Sie ein Repository veröffentlichen.
• Zugriffsrechte: Wer darf welche Daten sehen? Bei Supabase gehören Row-Level-Security-Regeln dazu und ein Test, dass sie greifen.
• Abhängigkeiten: Prüfen Sie, ob jedes Paket, das die AI vorschlägt, wirklich existiert und gepflegt wird. Erfundene Paketnamen sind ein bekanntes Einfallstor.
• Eingaben: Alles, was Nutzer eingeben können, wird validiert.

Row Level Security bei Supabase

Laut Supabase-Dokumentation muss für jede Tabelle, die über die Data API erreichbar ist, Row Level Security aktiviert sein. Tabellen, die Sie im Dashboard anlegen, haben RLS standardmäßig aktiv; wer Tabellen per SQL-Editor oder Migration erzeugt, muss es selbst einschalten, und genau so arbeiten AI-Werkzeuge meistens (Supabase-Dokumentation). Aktives RLS ohne Policy liefert keine Zeilen zurück, was die sichere Voreinstellung ist. Prüfen Sie am Sonntag deshalb zwei Dinge: Ist RLS bei jeder Tabelle an, und sieht ein zweiter Testnutzer wirklich nur das, was er sehen soll? Supabase bringt dafür einen Security Advisor im Dashboard mit.

Erfundene Pakete

Zum Thema erfundene Paketnamen gibt es Forschung: Spracklen und Kollegen haben auf der USENIX Security 2025 untersucht, wie oft Code-Modelle Pakete empfehlen, die es nicht gibt. Nach den Berichten, die ich dazu gefunden habe, war es rund jedes fünfte empfohlene Paket über 16 getestete Modelle, bei Open-Source-Modellen häufiger als bei kommerziellen. Die genauen Prozentwerte habe ich nicht am Originalpapier nachgeprüft, nehmen Sie sie bitte als Hinweis auf die Größenordnung. Das Risiko dahinter ist praktisch: Ein Angreifer kann einen solchen erfundenen Namen selbst registrieren und mit Schadcode füllen. Für Sie heißt das: Neues Paket nur installieren, wenn es auf npm oder PyPI existiert, eine nachvollziehbare Downloadzahl und Wartungshistorie hat und Sie es zuvor selbst nachgeschlagen haben.

Datenschutz bei Kundendaten

Sobald Namen, E-Mail-Adressen oder Kundenzugänge im Tool liegen, gilt die DSGVO. Klären Sie vor der Veröffentlichung, wo die Daten liegen (Region des Datenbankanbieters), wer Zugriff hat und ob ein Auftragsverarbeitungsvertrag mit dem Anbieter nötig ist. Das kann ich hier nicht abschließend beantworten, das gehört im Zweifel zu Ihrem Datenschutzbeauftragten oder Anwalt. Für ein Tool, das nur öffentliche Webdaten verarbeitet, ist die Lage deutlich einfacher, und das ist ein guter Grund, das erste Projekt genau so zu wählen.

Veröffentlichen

Für ein Team-Tool reicht meistens ein geschütztes Deployment: Anmeldung vorschalten, eine Produktionsumgebung getrennt von der Entwicklung, Variablen im Hosting-Dashboard statt in Dateien. Legen Sie außerdem einen automatischen Datenbank-Backup-Rhythmus fest und testen Sie, ob sich ein Backup wirklich einspielen lässt. Ein Sicherungsplan, der nie ausprobiert wurde, ist keiner.

05 Wo es hakt

• Der letzte Feinschliff dauert: Fehlerfälle, leere Zustände und Sonderfälle brauchen länger als der erste Prototyp.
• Die AI verliert den Überblick: Bei größerem Umfang ändert sie Dinge, die schon funktionierten. Kleine Commits und Tests fangen das ab.
• Kosten laufen weiter: Hosting, Datenbank und AI-Schnittstellen kosten dauerhaft. Rechnen Sie sie vorab durch.
• Wartung: Jemand muss das Tool pflegen. Wenn das niemand sein wird, bauen Sie es kleiner.
• Feature-Wildwuchs: Am Samstagabend fallen Ihnen zehn Ergänzungen ein. Schreiben Sie sie in eine Liste „v2“ und lassen Sie sie bis Montag liegen.
• Abhängigkeit von einem Werkzeug: Wenn ein Builder den Code nicht exportierbar macht, sitzen Sie fest. Achten Sie darauf, dass der Code in Ihrem eigenen Git-Repository liegt.

Realistisch ist auch: Wer noch nie programmiert hat, braucht für das erste Projekt eher zwei Wochenenden als eins, weil Fehlermeldungen, Git und Deployment ungewohnt sind. Einen Zeitplan für „zwei Tage“ sollten Sie nur aufstellen, wenn Sie den Stack oder jemanden im Team kennen, der ihn kennt.

06 Nach dem Wochenende

Montag ist der Tag für den ersten echten Test mit dem Team. Lassen Sie zwei Kollegen die Aufgaben aus dem PRD ohne Erklärung durchspielen und notieren Sie, wo sie stocken. Die Rückmeldungen daraus sind wertvoller als jedes weitere Feature. Planen Sie dann eine feste Stunde pro Monat für Updates der Abhängigkeiten ein, sonst veralten Pakete unbemerkt.

07 Häufige Fragen

Brauche ich Programmierkenntnisse für Vibe Coding?

Für einen Prototyp nicht unbedingt. Für ein Tool, das Sie im Team einsetzen, schon eher: Sie müssen Code nicht schreiben, aber so weit lesen können, dass Sie Zugriffsrechte, Schlüssel und Abhängigkeiten beurteilen können. Sonst fehlt Ihnen die Kontrolle, die der Sonntag verlangt.

Was kostet so ein Tool im Betrieb?

Das hängt vom Anbieter und Umfang ab, deshalb nenne ich keine Pauschale. Rechnen Sie Hosting, Datenbank, Domain und gegebenenfalls Kosten für AI-Schnittstellen zusammen und prüfen Sie die aktuellen Preisseiten. Für kleine interne Tools sind die laufenden Kosten häufig niedrig, im Zweifel entscheidet der Pflegeaufwand.

Ist AI-generierter Code für Kundenprojekte geeignet?

Für interne Werkzeuge ja, mit den beschriebenen Prüfungen. Für Systeme, die Zahlungen, Gesundheitsdaten oder viele Nutzerrollen abbilden, würde ich einen Entwickler zur Prüfung hinzuziehen, auch wenn der erste Entwurf von einer AI stammt.

Welchen Stack sollte ich nehmen?

Den, den Sie und Ihr Werkzeug am besten kennen. Next.js, Supabase und Vercel sind eine verbreitete Kombination mit viel Dokumentation, was der AI hilft. Ein exotischer Stack bringt Ihnen am Wochenende nur mehr Fehlersuche.

Wenn Sie ein konkretes Tool im Kopf haben und wissen wollen, ob es als Wochenendprojekt taugt, schauen Sie auf die Seite Vibe Coding. Die Software hinter meinen eigenen Lead-Portalen und meinem Linkbuilding-Tool entsteht nach demselben Ablauf, den Hintergrund zu den Portalen beschreibt der Beitrag Lokale Lead-Portale aufbauen.