Kann Claude mir nicht einfach das Plugin bauen?

Von /

Die Antwort ist: doch, kann er. Nur nicht so, wie du denkst — und nicht beim ersten Versuch.

Der Reddit-Post, der das Bild geradegerückt hat

Vor ein paar Tagen ist mir auf r/vibecoding ein Beitrag von einem AI-SWE bei einem FAANG-Konzern aufgefallen. Überschrift: „How we vibe code at a FAANG.“ Die Pointe: KI ist im Produktiv-Code angekommen — aber der Weg dahin ist langweiliger, als die Twitter-Demos suggerieren. Sieben Schritte, von denen genau einer „Code schreiben“ heißt. Der Rest ist Design-Doc, Review, Backlog, Tests, Code-Review, Staging.

Das Verhältnis ist das Interessante. Wer denkt, KI-gestützte Entwicklung sei „eine Idee in Claude reinwerfen und Enter drücken“, baut nicht mit KI — der baut mit Glück.

Warum das auch dich betrifft, wenn du keine 50-köpfige Plattform-Crew hast

Mein erster Reflex beim Lesen: schön für FAANG, aber ich baue als selbstständiger Berater kleine Sachen für KMU. Plugins, Schnittstellen, VBA-Module. Brauche ich Design-Reviews mit drei Senior Engineers, bevor ich ein WordPress-Formular schreibe?

Nein. Den Punkt aber, den der FAANG-Mann front-loading the pain nennt — den Schmerz nach vorn ziehen — den brauchst du genauso. Nur in deiner Größenordnung.

Aus meiner Praxis: Vor einigen Monaten habe ich für sesoft.de einen IT-Haftungscheck als WordPress-Plugin gebaut. Formular mit Lead-Erfassung, eigentlich überschaubar. Ich habe direkt losgelegt. Claude CLI auf, Prompt rein, Code raus, einbauen, läuft nicht, korrigieren, läuft halb, korrigieren, irgendwann läuft es. Mehrere Tage, verteilt über drei Wochen. Ehrlicherweise: ich wusste es damals nicht besser.

Der gleiche Funktionsumfang heute, mit Design-Doc vorab, wäre an einem halben Tag fertig.

Was „Design-Doc vor Code“ für eine kleine Lösung bedeutet

Du brauchst kein 30-seitiges Architekturpapier. Du brauchst eine Markdown-Datei, fünf Abschnitte, und du musst sie schreiben, bevor Claude das erste Mal Code generiert.

  1. Was tut das Ding? In drei Sätzen. Nicht aus Marketing-Sicht, sondern aus Funktions-Sicht.
  2. Was sind die Datenstrukturen? Welche Tabellen, welche Felder, welche Datentypen. Bei einem WP-Plugin: welche Custom Post Types, welche Optionen, welche Tabellen in der DB.
  3. Was sind die Schnittstellen? Welche Hooks, welche REST-Endpunkte, welche Shortcodes. Welche externen Dienste werden aufgerufen.
  4. Was sind die Edge Cases? Was passiert bei leeren Eingaben, doppelten Submissions, nicht erreichbarem Mail-Server.
  5. Was ist explizit nicht drin? Diese Liste ist die wichtigste. Sie verhindert, dass du beim Bauen in Versuchung kommst, „nur noch schnell“ eine Funktion mitzuziehen.

Die Datei legst du in den Projekt-Ordner. Claude CLI liest sie mit, wenn du im Ordner arbeitest. Ab da spricht ihr beide über dasselbe System.

Der eigentliche Hebel: Tests vor Code

Der FAANG-Engineer schreibt: „I have the AI coding agent write the tests first for the feature I’m going to build. Only then do I start using the agent to build out the feature.“ Genau das.

Was unscheinbar klingt, ist die größte Effizienz-Dividende beim Arbeiten mit Claude CLI. Wenn die Tests existieren, bevor der Code existiert, hat das drei Effekte:

  • Claude weiß, woran erfolgreicher Code sich messen lassen muss. Das ist eine andere Information als „bau ein Formular“.
  • Du erkennst Halluzinationen sofort. Wenn der Test rot ist, ist der Code falsch — egal wie überzeugend er aussieht.
  • Du kannst das Feature in kleinen Schritten bauen, weil du nach jedem Schritt eine messbare Antwort hast.

Bei einem WordPress-Plugin bedeutet das: PHPUnit-Tests für die Plugin-Klasse, die ohne aktive WP-Installation laufen. Bei VBA: ein Test-Modul mit Sub TestNNN_Beschreibung-Routinen, die Debug.Print oder eine simple Assert-Funktion aufrufen. Bei T-SQL: eine Test-Datenbank mit bekannten Datensätzen und erwarteten Ergebnissen pro Stored Procedure.

Aufwand für die Test-Infrastruktur: ein bis zwei Stunden. Einmalig.

Wie der Workflow mit Claude CLI dann aussieht

Wer Claude CLI ohne IDE-Anbindung nutzt — also rein im Terminal, ohne Visual Studio Code, ohne JetBrains-Plugin — hat einen wirklich schlanken Workflow zur Verfügung. Genau dieser schlanke Workflow ist für KMU-Verhältnisse oft der bessere.

So sieht das praktisch aus:

  1. Projekt-Ordner anlegen. Lokal, mit Git initialisiert. git init ist nicht optional. Es ist deine Rückversicherung gegen jeden Vorschlag, den Claude dir macht und der das Projekt zerlegt.
  2. Design-Doc als DESIGN.md ablegen. Die fünf Abschnitte von oben.
  3. Claude CLI im Projektordner starten. Erste Anweisung: „Lies DESIGN.md. Stell mir alle Fragen, die das Dokument offenlässt. Schreib noch keinen Code.“ Das ist der Schritt, der dich am meisten Zeit spart. Claudes Fragen decken Lücken auf, die du beim Schreiben nicht gesehen hast.
  4. Lücken in DESIGN.md eintragen. Selbst eintragen, nicht von Claude eintragen lassen. Du bist der Architekt.
  5. Backlog ableiten. Eine Datei BACKLOG.md, in der du die Arbeit in Tickets schneidest. Jedes Ticket sollte in unter zwei Stunden umsetzbar sein. Wenn ein Ticket größer ist, ist es in Wahrheit zwei.
  6. Pro Ticket: Tests zuerst. „Schreib mir die Tests für Ticket #3. Noch keinen Implementierungs-Code.“ Tests prüfen, ob sie sinnvoll sind, dann committen.
  7. Pro Ticket: Code danach. „Schreib jetzt den Code, der die Tests aus Ticket #3 grün macht. Keine zusätzlichen Features.“ Tests laufen lassen. Wenn grün: committen. Wenn rot: Claude die Fehlermeldung zeigen, korrigieren, erneut.
  8. Nach jedem Ticket: kurzer Review. Diff lesen. Was hat Claude geändert, was du nicht erwartet hast? Bei kleinen Lösungen ersetzt das den FAANG-„two dev approval“-Schritt.

Das klingt nach mehr Aufwand als „bau mir ein Plugin“. Es ist weniger.

Wo die Methode an Grenzen stößt

Ich verkaufe dir nichts. Drei Punkte, an denen der Ansatz hakt:

  • Bei reinen Wegwerf-Skripten (einmaliger Datenexport, Quick-and-Dirty-Migration) ist der Overhead aus Design-Doc und Tests größer als der Nutzen. Da reicht ein gut formulierter Prompt und gesunde Skepsis beim Lesen des Outputs.
  • Bei Themen, in denen du gar nicht beurteilen kannst, was richtig wäre, hilft dir auch das beste Design-Doc nicht. Wenn du nicht weißt, wie eine REST-Authentifizierung sicher gebaut wird, kannst du auch nicht prüfen, ob Claudes Vorschlag sicher ist. Hier brauchst du entweder Eigenstudium vorab oder einen Sparringspartner mit Domänen-Wissen — kein Tool ersetzt das.
  • Claude CLI hat im Terminal keine UI für Code-Diffs. Du musst git diff lesen können und wollen. Wer das nicht mag, ist mit der Desktop-App oder einer IDE-Anbindung besser bedient — der Workflow oben funktioniert dort genauso.

Was das für dich heißt, wenn du selbst nicht entwickelst

Wenn du als Geschäftsführer oder IT-Verantwortlicher jemanden beauftragst, „mit KI“ eine kleine Lösung für dein Unternehmen zu bauen, frag nach drei Dingen, bevor der Auftrag rausgeht: Gibt es ein Design-Dokument? Gibt es Tests? Liegt der Code in einem Versionskontrollsystem?

Wenn die Antwort dreimal Nein ist, bekommst du keine Software. Du bekommst ein Glücksspiel mit deinen Daten als Einsatz. Es kann gut ausgehen. Häufig tut es das.

Anlaufstelle

Wer eine bestehende KI-generierte Lösung im Haus hat und unsicher ist, ob sie hält, was sie soll: Ich schaue mir das einmalig in einem kostenlosen Erstgespräch an. Erreichbar über sesoft.de/kostenloses-erstgespraech-sichern.

Quellen

Über den Autor

Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei Datenarchitektur, Access-Modernisierung und der Anbindung von KI an Bestandsdaten. Er arbeitet von Neustadt in Holstein aus und hat selbst die ersten Plugins mit Claude CLI ohne Design-Doc gebaut — der Lerneffekt aus diesen Wochen steckt in diesem Beitrag. Mehr zu Sönke und der Marke Datenschäfer.

Ähnliche Beiträge

Nach oben scrollen