Der erste Versuch ist zu 95 % Müll: Die Reise eines Staff Engineers mit Claude Code

 (sanity.io)
24 Punkte von GN⁺ 2025-09-03 | 5 Kommentare | Auf WhatsApp teilen
  • Ein Staff Engineer berichtet von einem sechswöchigen Experiment mit Claude Code, um einen Entwicklungs-Workflow gemeinsam mit KI zu erproben
  • Die Denkweise, KI als einen „nicht lernenden Junior-Entwickler“ zu betrachten, ist der Schlüssel für eine erfolgreiche Integration
  • Der erste Versuch ist meist ein 95%iger Fehlschlag, wird aber durch Wiederholungen schrittweise zu brauchbarem Code verfeinert
  • Mit projektspezifischen Kontextdateien (Claude.md) und MCP-basierter Tool-Integration wird das Kontextproblem der KI gelöst
  • Die Rolle von Entwicklern verlagert sich vom Schreiben von Code hin zu Problemlösung und Architekturdesign – ein neues Produktivitätsmuster im Zeitalter der KI-Nutzung

Hintergrund und Ansatz

  • Der Autor schrieb ursprünglich jeden Code selbst, inzwischen werden jedoch 80 % vom AI geschrieben, während er sich auf Architektur, Reviews und das Management mehrerer Entwicklungs-Threads konzentriert
  • Der Text schlägt keinen rosigen Ton im Sinne von „KI treibt die Innovation“ an, sondern teilt die Verwirrung und realistische Methodik, die bei der Integration von KI in einen echten Produktions-Workflow entstehen
  • Der Schlüssel zur erfolgreichen Nutzung liegt darin, KI als einen „nicht lernenden Junior-Entwickler“ zu behandeln

Der Wandel des Entwicklungsparadigmas

  • In den ersten fünf Jahren blieb die Arbeitsweise bei Entwicklung mit Büchern und SDK-Dokumentation
  • In den folgenden zwölf Jahren erfolgte der Wechsel zur Nutzung von Suche (Google) und kollektiven Wissensquellen
  • In den letzten 18 Monaten wurden KI-gestütztes Coding mit Cursor erprobt
  • In den unmittelbar vergangenen sechs Wochen gab es einen starken Wandel hin zu einer umfassenden KI-Delegation mit Claude Code
  • Die Eingewöhnung an Claude Code führte schon nach wenigen Stunden zu spürbar höherer Produktivität

Der reale KI-basierte Produktions-Workflow

  • Bei Code-Arbeit für die Produktion wird KI hauptsächlich zum „Denken“ genutzt
  • Perfekter Code in einem einzigen Durchlauf ist unmöglich. Die Aufgabe eines Engineers ist es, die beste Lösung für ein Problem zu finden
    • Erster Versuch (95 % Fehlschlag): Die KI baut Systemkontext auf und der Entwickler definiert das Problem, aber der Code ist fast vollständig falsch
    • Zweiter Versuch (50 % Fehlschlag): Das Kontextverständnis verbessert sich und der Ansatz wird konkreter, aber immer noch ist die Hälfte unbrauchbar
    • Dritter Versuch (brauchbarer Code): Durch Wiederholung und Review entsteht ein tatsächlich nutzbares Grundgerüst, das anschließend verbessert werden kann
  • Dieser Prozess ist kein Scheitern, sondern ein bewusst geplanter Ablauf aus Experimenten und iterativer Optimierung

Das Kontextproblem und die Lösung

  • KI kann keine Erinnerung über Sitzungen hinweg behalten, weshalb dieselben Erklärungen immer wieder wiederholt werden müssen
  • Als Lösung wird eine Claude.md-Datei verwendet, in der Architekturentscheidungen, Muster und Dokumentationslinks festgehalten werden
  • Über MCP-Integration werden Linear, Notion, GitHub, die Codebasis und Datenbanken angebunden, um automatisch Kontext bereitzustellen
    • Linear liefert Ticket-Kontext
    • Notion oder Canvas ermöglichen Zugriff auf Dokumentation
    • Eine Nicht-Produktionsdatenbank dient zur Prüfung von Datenstrukturen
    • GitHub liefert Hintergrundinformationen aus früheren PRs

Paralleler Betrieb mehrerer Claude-Instanzen und zentrale Strategien

  • Mehrere Claude-Instanzen werden parallel betrieben, mit einem Ansatz, der sich anfühlt wie das Management eines kleinen Entwicklungsteams, das jeden Tag sein Gedächtnis verliert
  • Strategien wie keine Parallelisierung innerhalb desselben Problemraums, das Festhalten aller Arbeiten in Projektmanagement-Tools wie Linear und die klare Kennzeichnung von Code, den Menschen direkt bearbeitet haben, werden etabliert
  • KI wird nicht nur beim Schreiben von Code, sondern auch aktiv im Code Review eingesetzt: fehlende Tests, offensichtliche Bugs und Verbesserungspunkte werden schnell erkannt, was repetitive Arbeit reduziert
  • Laut Unternehmensrichtlinie bei Sanity liegt die Verantwortung für die Endqualität auch bei KI-generiertem Code weiterhin beim Engineer
  • In einer Umgebung, in der von KI und Menschen erzeugter Code nicht klar unterscheidbar ist, sinkt die emotionale Bindung, wodurch kritischere und objektivere Code Reviews möglich werden

Der dreistufige Code-Review-Prozess

  • Code zu schreiben ist nur ein Teil der Arbeit, aber Code-Review ebenso
  • Review-Stufe 1: erste Prüfung durch Claude
    • Erkennung von Lücken in der Testabdeckung und offensichtlichen Bugs
    • Verbesserungsvorschläge sparen Zeit in der Kolleg:innenprüfung
  • Review-Stufe 2: mein eigenes Review
    • Prüfung von Wartbarkeit, Architektur, Business-Logik und Integrationsfähigkeit
    • Auch bei KI-generiertem Code trägt der Engineer die endgültige Verantwortung
  • Review-Stufe 3: reguläres Team-Review
    • Das Team weiß nicht, welche Teile KI-generiert sind. Es gelten dieselben Qualitätsstandards
    • Objektive Prüfung ohne emotionale Bindung ist möglich
  • Da die emotionale Bindung an von KI geschriebenen Code geringer ist, werden objektivere Reviews möglich

Slack-getriggerter Agent und Experimente zur Arbeitsautomatisierung

  • Mit Cursor wurde ein Slack-integrierter Agent pilotiert: einfache Änderungen an der Business-Logik gelangen, bei komplexen CSS-Layouts scheiterte er jedoch
  • Derzeit bestehen weiterhin Einschränkungen wie keine Unterstützung für private NPM-Pakete, unsignierte Commits und das Umgehen offizieller Nachverfolgung
  • Dennoch weckt das die Erwartung eines künftigen Szenarios, in dem Agenten nachts einfache, repetitive Tickets abarbeiten

Kosten und ROI

  • Die Nutzung von Claude Code verursacht für das Unternehmen erhebliche Kosten pro Engineer
  • Diese Investition führt jedoch zu Produktivitätsgewinnen
    • 2- bis 3-fach schnellere Feature-Releases
    • Mehrere Entwicklungs-Threads lassen sich gleichzeitig steuern
    • Wiederholten oder Boilerplate-Code muss man nicht mehr selbst schreiben
  • In der Anfangsphase der KI-Einführung ist für Senior Engineers ein Budget von 1000 bis 1500 US-Dollar pro Monat nötig; mit wachsender Routine wird eine bessere Kosteneffizienz erwartet

Fortbestehende Probleme und Grenzen KI-gestützter Entwicklung

  • Lernproblem: KI lernt nicht aus Fehlern und wiederholt dieselben Missverständnisse; die Lösung sind umfangreiche Dokumentation und explizitere Anweisungen
  • Vertrauensproblem: KI liefert falschen Code oft mit großer Überzeugung, daher ist Verifikation zwingend erforderlich – besonders bei komplexem State-Management, Performance und sicherheitskritischen Bereichen
  • Kontextgrenzen: Große Codebasen überschreiten das Kontextfenster der KI, daher müssen Probleme in kleine Einheiten zerlegt und mit klarem Kontext versehen werden

Der emotionale Wandel: vom Code zum Problem

  • Die Fixierung auf Code wird aufgegeben und durch ein problemlösungszentriertes Denken ersetzt
  • Fehlerhafter Code wird schneller gelöscht, Reviews werden objektiver und die Hürde für Refactoring sinkt => eine positive Veränderung
  • Wenn bessere KI-Tools erscheinen, besteht die Bereitschaft, sofort zu wechseln
  • Entscheidend ist nicht „der Code selbst“, sondern der Wert des zu lösenden Problems

Ratschläge zur KI-Einführung aus Engineersicht

  • 1. Experimente mit mehreren KI-Lösungen zulassen: Teams sollten verschiedene Tools selbst ausprobieren, um praktische Kompetenz aufzubauen
  • 2. KI zuerst auf repetitive und einfache Aufgaben anwenden: Dadurch sind schnelle Effekte zu erwarten
  • 3. Budget für Trial-and-Error sichern: Im ersten Monat muss mit Verwirrung gerechnet werden
  • 4. Review-Prozesse neu gestalten: Prüfungen müssen auf die Eigenschaften von KI-Code angepasst werden
  • 5. Gründlich dokumentieren: Guter Kontext vervielfacht die Produktivität
  • Engineers, die sich an neue KI-Workflows anpassen, werden feststellen, dass sich nun ein neues scharfes Messer in ihrem Werkzeugkasten befindet
  • Engineers, die KI-Workflows annehmen, entwickeln sich zu einer neuen Rolle weiter, in der sie mehrere KI-Agenten orchestrieren und sich auf Architektur, Reviews und komplexe Problemlösung konzentrieren

Ihr nächster Schritt

  • Wählen Sie ein kleines, klar definiertes Feature,
  • geben Sie der KI drei Chancen, dieses Feature zu implementieren,
  • und prüfen Sie das Ergebnis so, als würden Sie einen Junior-Entwickler coachen
  • Mehr braucht es nicht. Keine große Transformation, keine Prozessreform
  • Es braucht nur ein einziges Feature, drei Versuche und ein ehrliches Review
  • Die Zukunft besteht nicht darin, dass KI Entwickler ersetzt
    • sondern darin, dass Entwickler schneller arbeiten, bessere Lösungen entwickeln und die besten Tools nutzen

Verwandte Beiträge

5 Kommentare

 
helio 2025-09-05

„Bei einem derart ausgefeilten Verfahren ist es wohl besser, den Code einfach selbst zu schreiben.“
 
skageektp 2025-09-05

Die Haltung eines Teamleiters, der die Arbeit nicht an die Teammitglieder delegiert, sondern sie selbst erledigt, lol
 
greenbhj 2025-09-05

Scheint so, ist aber überhaupt nicht der Fall.
In den letzten 6 Monaten habe ich wiederholt im kleinen wie im großen Maßstab experimentiert.
 
iolothebard 2025-09-05

Wähle eine kleine, klar definierte Funktion aus,
gib der KI drei Chancen, diese Funktion zu implementieren,
und prüfe das Ergebnis so, als würdest du einen Junior-Entwickler mentorieren.
Wenn sie das ohne mich kann, ist das ein Gewinn … aber wenn ich dafür dabei sein muss … dann ist es letztlich effizienter, wenn ich es einfach selbst mache.
 
GN⁺ 2025-09-03
Hacker-News-Kommentare

  • Ich habe das Gefühl, dass es wichtig ist, Anweisungen unter Berücksichtigung der kognitiven Grenzen des Agenten zu geben. Zum Beispiel sollte man keine großen Änderungen auf einmal verlangen, sondern erst einen Plan erstellen, dann die Umsetzung in kleinen Schritten anweisen und jeden Schritt beim Fortschritt testen. Bei komplexen Schritten ist es hilfreich, Code schreiben zu lassen, der Probleme und Lösungswege visualisiert. Wenn ein Schritt fehlschlägt, sollte man Logging zum Code hinzufügen, die Logs speichern, testen und die Logs prüfen, um die Ursache zu ermitteln — diesen Prozess muss man wiederholt durchlaufen, damit er effektiv ist. Wenn man das Modell anhand des bestehenden Code-Designs erkennen lässt, welche Teile geändert werden müssen, verhindert man, dass die AI alles in eine einzige Datei stopft. Ich habe Blogs gesehen, in denen viele Leute solche Tipps teilen; es ist immer noch nicht perfekt, aber bei mir kommen nicht mehr bis zu 95 % unbrauchbare Ergebnisse heraus.

    • Ich probiere das alles schon aus, und trotzdem kommt meist unbrauchbarer Code heraus. Selbst wenn es halbwegs funktioniert, muss ich am Ende doch selbst Hand anlegen, damit es wirklich brauchbar wird. Es gibt zwar Fälle, in denen es wirklich gut läuft, und dann bin ich begeistert, aber persönlich spüre ich keinen großen Produktivitätsgewinn.
    • Bei großen, komplexen Aufgaben wirkt die Anweisung „Bitte schreiben Sie jetzt noch keinen Code. Ich werde jeden Schritt detailliert erklären.“ ganz gut. Man gibt dann zum Beispiel eine schrittweise Übersicht wie Eingaben lesen, Kandidaten erzeugen, Kandidaten bewerten, priorisieren und sortieren, Ausgabedatenstrukturen erzeugen, in die DB speichern usw. Claude organisiert diese Schritte als TODO-Liste und Dokumentation, sodass man später bequem weitermachen kann. Ich habe tatsächlich eine Stunde daran gearbeitet, dann aufgehört und gesagt: „Erzeuge für die abgeschlossenen Stages den Code und hinterlasse Kommentare, damit wir später weitermachen können“ — und so ließ sich die Arbeit problemlos fortsetzen.
    • Auch nach langer Nutzung verschiedener LLMs/Agenten ist es immer noch schwer, wirklich nützliche Ergebnisse zu bekommen. Um nutzlosen Output zu vermeiden, muss man mehr Energie in das Schreiben der Prompts stecken als in die eigentliche Arbeit. Dabei achtet man ständig auf Formulierungen, Tonfall und darauf, keine unerwünschten Assoziationen auszulösen, was einen unnötig nervös macht. Es wäre gut, wenn es ein Tool gäbe, das LLM-Prompts verwaltet, ähnlich wie ein separates Frontend-Framework. Es sollte allgemeine Prompt-Strukturen ordnen oder Best Practices standardmäßig anwenden, damit man sich beim Suchen im Code, beim Entwerfen neuer Features oder beim Schreiben von Tests viel weniger Gedanken machen muss.
    • Bei einem so ausgefeilten Verfahren denke ich, dass man den Code einfach besser selbst schreiben sollte.
    • Als ich in einem privaten Projekt AI und Vibe Coding ausprobiert habe, habe ich gemerkt, dass Test-driven Development sehr gut zu Vibe Coding passt. Ich empfehle, das Problem in kleine testbare Einheiten zu zerlegen, die AI zuerst Unit-Tests schreiben zu lassen und erst danach den eigentlichen Code zu implementieren.

  • Ich habe das Gefühl, dass solche Artikel inzwischen konkrete Beispiele für tatsächliche Aufgaben enthalten sollten, die nicht bloß simples Refactoring oder React-Boilerplate sind, sondern bei denen „Agenten tatsächlich verteilt arbeiten“. Es heißt, bei Sanity gebe es seit Langem angefragte Features, und der Agent erledige einen erheblichen Teil davon parallelisiert. Aber Aussagen in der Art, dass „80 % des Codes von einem Junior-Entwickler geschrieben wurden, der nichts gelernt hat“, finde ich schwer zu glauben.

    • Meiner Meinung nach ist die Formulierung „ein Junior-Entwickler, der nichts lernt“ unzutreffend. Claude ist eher wie ein hochgebildeter Senior, der nur die richtigen Antworten aus der Literatur kennt, aber keine Praxiserfahrung hat. Das enzyklopädische Wissen ist hervorragend, aber das Gespür für die Praxis fehlt. Ich baue derzeit mit Claude eine kommerzielle Codebasis auf, und der Großteil meines Inputs konzentriert sich auf den „Geschmack des Codes“ und die Definition von Erfolg; der Code selbst ist nur Wegwerfmaterial.
    • Während so viel AI-Code entsteht, stapeln sich in Open Source immer noch ungelöste Issues. Das ist schon ziemlich ironisch.
    • Wenn man echte Beispiele für an AI delegierte Aufgaben und deren Ergebnisse zeigen würde, hätte man wenigstens die Möglichkeit, überzogene Erwartungen zu hinterfragen. Stattdessen tauchen immer wieder nur Geschichten darüber auf, wie großartig Claude Code sei — ohne echte Praxisbeispiele.
    • Wenn ich technische Blogs von zu stark auf Sales getrimmten Engineers sehe, die statt „lessons“ Ausdrücke wie „learnings“ verwenden, habe ich das Gefühl, dass das genau entgegengesetzt zu meinem eigenen Weg ist: Mit zunehmender Entwicklungserfahrung bin ich weniger auf Google-Suchen angewiesen und schaue mir stattdessen einfach die Dokumentation an.

  • Der Autor sagte zwar, es gebe Produktivitätsgewinne, erwähnte aber gleichzeitig die üblichen Grenzen ganz offen, sodass inhaltlich eigentlich nicht viel dabei herauskam. Ich bin mir sicher, dass niemand die Entwicklung von Kernfunktionen an Claude Code delegieren würde.

  • Boilerplate zu vermeiden ist Teil der Arbeit von Entwicklerinnen und Entwicklern und zugleich eine Abstraktion, die dem zukünftigen Ich das Leben leichter macht. Wenn man Boilerplate mit AI generiert, wird es später eher lästig, wenn man alle Instanzen einzeln ändern muss; und wenn über den Code verstreute Boilerplate-Stellen inkonsistent werden, wird das Problem noch größer.

    • Frameworks und Tools bringen ohnehin meist schon Generatoren für Boilerplate mit. Daher frage ich mich, ob es wirklich so viel Mehrwert hat, dafür Tokens und Geld an AI auszugeben.

  • Interessant ist, dass diese Person versucht, mit AI die Grundimplementierung zu erstellen, während ich genau andersherum vorgehe: Ich baue das Fundament unbedingt zuerst selbst, damit ich die Struktur und Funktionsweise genau verstehe. Danach kann ich der AI die repetitiven Boilerplate-Aufgaben überlassen. AI ist gut darin, Vorlagen nachzuschreiben, aber bei Architekturdesign ist sie extrem schwach.

    • LLMs sind sehr schlecht darin, wartbare Architekturen zu planen. Wenn sich Code weiterentwickelt, refaktorieren sie die Struktur nicht mit, und wegen ihrer begrenzten Kontextauffassung dürfte hier eine klare Grenze liegen.

  • Schon das Grundgehalt ist teuer, und dann soll man zusätzlich noch 1.000 bis 1.500 Dollar pro Monat ausgeben, um in kleinere Probleme zu investieren, bei denen Produktivitätsgewinne vielleicht eintreten und vielleicht auch nicht? Das halte ich für fragwürdig. Mein Chef wäre davon jedenfalls wohl nicht begeistert.

    • Hardware-Unternehmen kaufen jedes Jahr allerlei EDA-Tool-Lizenzen, die teurer sind als Entwicklergehälter. Wenn die Produktivität dadurch sichtbar steigt, sind 1.000 Dollar praktisch nichts.
    • Wenn Entwicklergehälter so hoch sind, wäre es geradezu irrational, nicht zu investieren. Wenn man für 1.000 bis 1.500 Dollar pro Monat die Produktivität zuverlässig steigern kann, ist eher das Zögern ineffizient. Nur auf die Kosten für AI zu schauen, ist aus dieser Perspektive viel zu vereinfacht. Wenn man durch AI die Zahl der Entwickler senken kann, ist auch das ein realer Spareffekt.
    • Ich selbst gebe mit IntelliJ Pro AI nicht einmal 20 Dollar im Monat aus und habe mich gefragt, ob Claude wirklich so teuer sein kann; nach etwas Nachschauen scheint das tatsächlich möglich zu sein. Wie auch immer: In irgendeinem Budgetposten landet heute eben zusätzlich ein AI-Abo — genauso wie Unternehmen bereits für leistungsfähiges Internet bezahlen und AI-Kosten allmählich zum Standard werden.
    • Und man sollte daran denken, dass auch dieser Preis im Grunde noch subventionsbasiert ist.
    • Ich beobachte mit Interesse, wie sich Unternehmen künftig verändern werden. Klar ist jedenfalls: Entscheidend wird sein, nach welchen Maßstäben Entwickler am Ende bewertet werden. Wichtig wird, ob durch den Einsatz von AI das Risiko wächst, bei Leistungsbeurteilungen oder Entlassungen Nachteile zu erleiden, und wie man nachweist, dass nicht das LLM, sondern man selbst der eigentliche Leistungsträger war.

  • Ich verstehe nicht ganz, wie die im Artikel erwähnte Nutzung von MCP (Multi-Channel Processor) sinnvoll sein soll. Claude Code kann über die Shell mit curl, gh usw. ohnehin fast alle Drittanbieterdienste aufrufen, und mit MCP kann es sogar Probleme geben (zum Beispiel schneidet der Linear-MCP-Server Issues ab, wenn sie zu lang werden, während es bei direkten API-Aufrufen diese Beschränkung nicht gibt). Vielleicht übersehe ich etwas.

  • Anthropic hat ein Interview mit Boris Cherny (dem Erfinder von Claude Code) veröffentlicht, in dem auch Ideen zur Zukunft des Agent Coding und zu Einsatzmöglichkeiten von Claude Code geteilt werden: https://youtu.be/iF9iV4xponk

  • Als ich die Erwähnung eines „Budgets von 1000–1500 $/Monat“ sah, dachte ich, vielleicht wird hier nur mit API-Keys gearbeitet und man kennt Monatspläne wie claude MAX gar nicht. Ich denke, für 100 bis 200 Dollar im Monat reicht das völlig aus, solange man nicht einfach nur blind immer wieder Queries abfeuert.

    • 1.000 bis 1.500 Dollar wirken für mich viel zu hoch. Selbst der Max-Plan mit dem 20-fachen Umfang deckt für 200 Dollar im Monat schon sehr viel Nutzung ab, und das Kontingent wird alle fünf Stunden zurückgesetzt. Wenn man trotzdem täglich an die Grenze stößt, könnte tokenbasierte Abrechnung am Ende sogar noch teurer sein.

  • Wenn man Claude oder andere Agenten nutzen will, kann ich Logging nur dringend empfehlen. Wenn man die komplette Logdatei in die AI gibt, steigt die Wahrscheinlichkeit deutlich, dass sie das Problem sauber zusammenfasst, eine Antwort liefert oder zum nächsten Schritt übergehen kann. Logging ist wirklich alles.